Mail Archives: djgpp/1994/01/28/19:49:17
Greetings,
Wonderful idea, and I applaud it wildly. Unfortunately, I
don't think it'll work. I ran into a lot of problems a long time ago,
when I tried implementing long file names and soft links.
*sigh* This is one of those things which just about everyone
has wanted, forever. The primary problem is, however, that the
data structure for the findfirst/findnext field is more often than
not compiled directly into the executables.
Sure, you can build an extended file system onto DOS. No major
programs will be using it though. The reason? The programs which
allocate space for filenames do it with a constant, not by requesting
the size of the necessary structure from the operating system.
You can have 256 character long filenames, no problem. You'll be
able to access them from the command line, and maybe a few programs
you write specifically for it. Almost everything else will need to
access the normal file name files. This is even more true if the
program searches for the file to make sure it exists first. Execution
of programs would have to be redone as well, since it uses
findfirst/findnext.
It's almost identical for the wildcard problem. There is
(IMHO) no decent wildcarding under DOS. It's fixed *A LITTLE* in
Chicago, as I recall, but regexp's and even multiple searchnames
aren't available. (i.e. '*File[1-9]' is not possible to do.)
The problem? The wildcard information for DOS is an 11 character
buffer. Again, it's an allocation problem.
As long as you're using custom apps, or apps written to handle
whatever 'standard' you come up with, it's not a problem.
Go to the new OS's. (I fully recommend that you wait a little
while for either of Chicago or Cairo. I don't think Chicago will have
much help for file names, but as a windowing system it's *MUCH* nicer
than Windows 3.1, and once you're under a windowing system, the
filename problem is much less.)
-- Morgan Schweers
- Raw text -