delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/1997/02/21/15:54:28

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'" <opendos AT mail DOT tacoma DOT net>
cc: opendos-developer AT mail DOT tacoma DOT net
Subject: Re: [opendos] Re: [opendos-developer] Potential serious FS problem
In-Reply-To: <Pine.GSO.3.95.970219180622.14555B-100000@sparkie.gnofn.org>
Message-ID: <Pine.LNX.3.95.970220184648.2153B-100000@capslock.com>
Organization: Total disorganization.
MIME-Version: 1.0
Sender: owner-opendos AT mail DOT tacoma DOT net

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


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019