From: mharris AT blackwidow DOT saultc DOT on DOT ca Date: Thu, 20 Feb 1997 19:27:20 -0500 (EST) Reply-To: mharris AT blackwidow DOT saultc DOT on DOT ca To: "'OpenDOS newsgroup'" cc: opendos-developer AT mail DOT tacoma DOT net Subject: Re: [opendos] Re: [opendos-developer] Potential serious FS problem In-Reply-To: Message-ID: Organization: Total disorganization. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-opendos AT mail DOT tacoma DOT net Precedence: bulk On Wed, 19 Feb 1997, Colin W. Glenn wrote: > On Wed, 19 Feb 1997, Jim Lefavour wrote: > > I just realized - whatever FS we use, we have to be careful. Most > > DOS programs expect filenames to be uppercase, and many are written > > If we implement LFN support, we could not use the INT21 functions which > normally deal with the filesystem, we would _have_ to use a new set of > functions else how else would the OS know whether it's dealing with an > older app which can only handle 8.3 or a new app which likes the flavor of > LFN? Say if a program calls for a directory search, if it calls the > current function AH=04Eh, then the OS knows to return it a properly parsed > and valid 8.3 name. If on the other hand, the program calls AH=(YTBD), > then the OS will hand it a pointer to the LFN match. (which ought to use > the current table of function 04Eh, with an extension to the table for > either adding a pointer to the LFN, or additional space for the LFN). Yes, the INT 21h functions will be patched to return valid 8.3 case insensitive mangled names to legacy apps. These 8.3 names will be mangled from the actual case sensitive long filenames on case sensitive filesystems (ext2, and other unix FS's). Thus the old INT 21h functions will allow OLD apps to use files created on newer filesystems. Files may still be created with the old calls as well on new file systems, and will be UPPERCASE 8.3 names. Programs that use the Win95 LFN API, will still work also as our new LFN's will be mangled into that API as well. That way W95 should be able to use other filesystems in the near future as well. It will access them through it's own LFN API, or could take advantage of our NEW API which will allow ANY filesystem to be available under a common API (including the current 8.3 & braindamaged W95 VFAT). This illustrates it graphically: API's What's available under API OLD8.3 Old 8.3 filenames, mangled names for new filesystems W95LFN W95 LFN's, mangled long names for new filesystems NEWIFS Full long name support with case sensitivity for filesystems that support it. FS's that don't support case sensitivity will show up in single case. Old 8.3 FS's will show up under this API as well and will be flagged as single case. W95 LFN's (VFAT) will also show up under this API, and will be subject to the same rules as it is under the W95LFN API. IMHO, the above method will put an end to the chaotic mess that M$ has left us with for once and for all, and FOR GOOD! Old programs will still work the old way, and will have access to new filesystems through mangled names. Old W95 programs will have access to things the normal way (through either 8.3, or W95LFN), and can access new filesystems through these old API's (by the new API providing mangled names to the old API's). New W95 programs could also use the new API themselves, instead of the older API's. The only problem that I can see with the above is that new W95 programs that use ONLY the new API won't run on W95 machines that are not running OpenDOS under W95. Well a simple solution to that would be to include the API as a W95 driver or some other kludge, until M$ supports it directly. Besides, W95 programmers would probably either stick to the old 8.3 filenames, or the W95LFN's which would still work like usual. Other programmers would include supporting the NEWAPI, and then fall back to the old method if the new API isn't there. Since all of this could be totally hid from the end programmer via C libraries that autodetect the API's available, the point is fairly moot. The result of all of this is: Full backwards compatibility, full future compatibility, a new powerful FS layer, access to many powerful existing filesystems. This is IMHO how it *should* be done at the API level, not necessarily how it will be done though unless we discuss it more fully. I've CC'd my responce to the [opendos-developer] list, as that list is more appropriate for this discussion. I'm interested in hearing everyone's responses to my above voiced opinions. Lets get the discussion rolling on this important topic, and start into the planning stages. I would also like to see some feedback from Caldera about this important issue. Gene? Can we start a plan of attack and start dividing up the chores? We'd better do it soon otherwise there will be 10000 different incompatible implementations coming out from people who don't want to wait. Mike A. Harris | http://blackwidow.saultc.on.ca/~mharris Computer Consultant | My webpage has moved and my address has changed. My dynamic address: http://blackwidow.saultc.on.ca/~mharris/ip-address.html mailto:mharris AT blackwidow DOT saultc DOT on DOT ca