Date: Thu, 20 Feb 1997 19:40:37 -0600 (CST)
From: "Colin W. Glenn" <cwg01 AT gnofn DOT org>
To: "'OpenDOS newsgroup'" <opendos AT mail DOT tacoma DOT net>
Subject: Re: [opendos] Re: [opendos-developer] Potential serious FS probl
In-Reply-To: <1355686916-13908286@diablo.eimages.co.uk>
Message-ID: <Pine.GSO.3.95.970220193450.612B-100000@sparkie.gnofn.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

On Thu, 20 Feb 1997, David Cantrell wrote:
> Colin (cwg01 AT gnofn DOT org) wrote:
> > 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
> 
> Win95 does this with new INT21 functions, with AH=71, and ...
> AL = 39h create directory
> We ought to maintain compatibility with the DOS apps which are aware 
> of these functions (but maybe not Win32 console apps - at least to 

Ahhh, I _knew_ M$ would not ditch familar function calls, they just rehash
old code, in this case, moving the file/dir function into AL instead of
AH.  They probably did this with a macro, which explains code bloat.

If all the LFN support is through AH=71, then implementation sounds easy,
just write a driver which hooks into INT21 looking for AH=71.

  <! PrePared HTML!  Just export as a HTML file and Click!>
A Christian Web Site!  The Light 
  <a href="http://www.thelight.org/">.</a><br>
A neat place to visit. HotSpot 
  <a href="http://www.hspro.com/hotspot/">.</a><br>
Caldera, Inc. / Makers of OpenDOS
  <a href="http://www.caldera.com/">.</a><br>
Caldera's OpenDOS page
  <a href="http://www.caldera.com/dos/dos.htm">.</a><br>