Mail Archives: opendos/1998/09/23/22:52:25
>> þ Support for Windows 9x VFAT (good work with the betas of
>> long file name, but still not finished) and FAT32. (Also
>> Windows NT HPFS?)
>
>I'd have to disagree. Microsoft's LFN storage is terrible -- consider
>how even Microsoft's own disk utilities, like DOS 6.x SCANDISK, trash
>them. This isn't Caldera's fault, but I question the wisdom of cloning
>such an awful standard. Especially when it conflicts with passwords,
>the only real innovation DR DOS adds to the filesystem. A better idea
>might be to store the LFNs in a separate file, as 4DOS does.
An even better idea would have been something akin to OS/2's extended file
attributes -- thereby also freeing Windows from the brain-dead idea of tying
application associations to file extensions.
In Microsoft's defense, however, since DOS 6 predates long filenames,
Scandisk could hardly be expected to support LFNs. (On the other hand, one
might ask why Scandisk trashes those bytes in the first place; but that
would be a Really Bad Design Flaw(tm) in Scandisk, not LFNs.)
But I do agree with you that Microsoft's LFN implementation is pretty sad;
it was one of the first RBDFs to leap out at me.
(The other was the Start Menu mess and the lack of object orientation in the
desktop in general. The first time I sat down in front of 95 and clicked on
the Start button, my immediate reaction was, "What a kludge!" Three years
later, while IE4 has taken a couple of half-hearted stabs at improving
things, neither the desktop kludge nor my opinion has changed.)
>FAT32 would be a useful improvement to add. HPFS -- don't hold your
>breath.
HPFS - not likely. However, what Guti said was "NT HPFS", so he actually may
have had in mind NTFS. NTFSDOS has proven that DOS-level NTFS support (at
least R/O support) can be done. And it would be a bit of poetic justice to
watch Microsoft throw hissy fits if a future release of DR-DOS were to start
blowing holes in NT's vaunted security.
-Calvin
- Raw text -