If you are still writing MS-DOS based applications ( and let's not be ashamed; even the Sun Java Compiler is MS-DOS based ) you will undoubtedly have run in to problems with long filenames running MS-DOS under a Windows 95 environment.
The problem is that long filenames ( with spaces therein or with a filename or extension having other than the standard 8 dot 3 format characters ) are not represented in an easily usable format for MS-DOS use.
When MS-DOS is used; a long filename, say Hippy.java, becomes, in standard 8 dot 3 format, HIPPY~1.JAV and w.x.y.z becomes WXY~2.Z or similar. Likewise, a directory such as My Programs becomes PROGRA~1 and DevStudio becomes DEVSTU~3 or similar.
If you have a legacy MS-DOS application you will at some point need, due to persistent user complaints, to try and handle long filenames. A typical case is when using an, in-house designed, MS-DOS based editor to edit, say, *.java files.
Unless some handling of long filenames is added then a user editing Hippy.java must refer to the file as HIPPY~1.JAV or whatever name that it has been given in the MS-DOS environment.
A big problem is that the 8 dot 3 name may be HIPPY~1.JAV, HIPPY~5.JAV or even HIPP~101.JAV and a file with the same long filename may have a different name in each directory or on each computer in which it exists.
There is however a neat trick that can be used to upgrade legacy MS-DOS applications ...
After the long filename, say Hippy.java, is created; the link between the long filename and the standard 8 dot 3 format filename ( HIPPY~1.JAV ) is maintained when the file is referenced ( that is read or read and then written ) by an MS-DOS application.
This means that when an MS-DOS application opens HIPPY~1.JAV, changes its contents and saves the new contents in the same file it can still be referenced as Hippy.java.
What this consequently means is that, providing the legacy MS-DOS application can convert the user specified long filename into the standard 8 dot 3 format, then a file with a long filename can be read, or read and written, by legacy MS-DOS application without losing or changing the long filename.
So all a legacy MS-DOS application needs to do is convert a long filename specified as its argument to a standard 8 dot 3 format and it will still work.
Converting a long filename to 8 dot 3 format is allegedly not simple. There should be some MS-DOS INT Function that does it but I am not aware of one.
The alternative is to automatically ( and silently ) shell out of the application, use a DIR command with the results redirected to a named file, parse the result and determine the association between the long filename and the MS-DOS 8 dot 3 name.
This unfortunately fails if the PC was booted straight in to MS-DOS ( so the application is not running in an MS-DOS prompt window ) as the DIR command does not reveal the long filenames and, in an MS-DOS prompt window, there is always the danger that there may not be enough memory to allow the shelling out process to work.
A much simpler solution is to try and fudge the conversion within the application.
This is much easier than it first appears ...
If you follow the procedure below you will be able to convert most long filenames to their 8 dot 3 format equivalents and also use filenames already in the 8 dot 3 format.
The question mark is used as a wildcard as we don't know what number has been assigned after the tilde ( ~ ) by the long filename handler under Windows 95.
The same technique can be applied to long directory names. If a filename specified includes a directory path specification it will be necesary to individually determine the 8 dot 3 directory names involved and the 8 dot 3 filenames before the fully qualified MS-DOS filename is found.
There are of course a number of caveats associated with this trickery ...
There is no guarantee that it will work with Windows 98, Windows NT or any other future versions of Windows.
Providing there are only a few files in the target directory, the chances are that ambiguous associations will not be found. Ambiguous associations are rejected by the above algorithm anyway so there should be no chance of accidentally editing or altering the wrong file.
If the long filename Hippy.java has the 8 dot 3 name of HIPPY~1.JAV then both Hippy.java and Hippy.javb would reference HIPPY~1.JAV. This is in reality no worse than the old MS-DOS problem where all filenames were truncated to 8 dot 3 format but could cause problems in some circumstances.
There may be various aspects of long filename conversion to 8 dot 3 format that I have not correctly understood ( the conversion process has been determined by trial and error and has not been exhaustively tested ).
Which means that there may be certain circumstances that I have not catered for. The most obvious that springs to mind are where either a long filename or an 8 dot 3 filename includes a tilde ( ~ ) as part of its name or extension and has not appeared solely as part of the long filename to 8 dot 3 format association and the handling of unusual, non-alphabetical and non-digit characters such as comas ( , ) and plus signs ( + ).
This program demonstrates how the FNshorten$() routine provided passes through standard 8 dot 3 filenames ( including wildcards ) and performs name converstion for long filenames. Note that the program can only convert long name filenames if it can find that file in the directory in which the program is run :-)
|Home Links Info||This page was last changed on the 31st of August, 1998|