Mail Archives: opendos/1997/02/20/06:05:25
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
> LFN?
Win95 does this with new INT21 functions, with AH=71, and ...
AL = 39h create directory
...
4Eh find first file
4Fh find next file
56h move (rename) file
6Ch create/open file
We ought to maintain compatibility with the DOS apps which are aware
of these functions (but maybe not Win32 console apps - at least to
begin with ;-) so should simply use this API.
For the full details on these functions, look at Ralf Brown's
interrupt list. I've got an online version, with the relevant bits
at http://rioja.eimages.co.uk/david/rbil/alpha-W.htm#Windows95, or
for the full version, http://rioja.eimages.co.uk/david/rbil/index.html
For the FAT/VFAT driver, these functions should behave exactly as per
Win95. For ext2/ntfs/hpfs/MacHFS the AH=71 versions should operate
using 'long' names and the old-style DOS functions should operate
using 'short' names. If we ever have a FS which does NOT support
LFNs, the FS driver should ensure that the AH=71 functions return
errors if used with incompatible names, but if a valid name is given,
will work as normal.
Why use a system which doesn't have LFNs? Well, I use a lot of
CP/M-style disks with 22DISK, mainly for transferring files from my
8-bit machine to the PC for uploading to archives, and for
transferring downloaded games from the PC. I'd rather have a CPM.IFS
driver which would recognise my disks - perhaps using a 22DISK-style
disk definition file.
--
David Cantrell, http://www.eimages.co.uk/users/davidc/
Internet==Kindergarten ?
- Raw text -