Date:	Sat, 1 Mar 1997 08:23:08 -0500 (EST)
From:	Paul W Brannan <brannanp AT musc DOT edu>
To:	"Colin W. Glenn" <cwg01 AT gnofn DOT org>
cc:	"'OpenDOS newsgroup'" <opendos AT mail DOT tacoma DOT net>
Subject:	Re: [opendos] [OpenDOS] Wishlist part 2
In-Reply-To:	<Pine.GSO.3.95.970301012142.22154A-100000@sparkie.gnofn.org>
Message-ID:	<Pine.ULT.3.95.970301081139.4973C-100000@atrium.musc.edu>
MIME-Version:	1.0
Sender:	owner-opendos AT mail DOT tacoma DOT net

> > The info zip team might get lfn support first, and given the whole
> > spirit behind opendos priority for support might better go to zip and
> > unzip rather than pkzip. 
> 
> Good point, but remember, I was making an abstract point, there's probably
> a lot of other 8.3 programs people use in an specific manner and expect
> the same results regardless filenames, unless they were modifying one of
> the files involved in their progam, the last thing you would want to have
> happen is a silent crash which goes un-noticed for several months.

Speaking of lfn support, what would be the best way of going about it?  So
many DOS functions rely on the 8.3 filename system, it would be almost
impossible to modify these interrupts or to provide new ones (well, not
impossible to provide new ones, but certainly inefficient).  For example
the PSP contains the name of the program as arg 0.  If a program is called
with an lfn, but it doesn't understand it (it's got self-modifying code?),
then it's gonna do who-knows-what.  Any function that returns an lfn would
confuse a non-lfn-enabled program.  Functions that accept filenames,
though, could certainly accept lfn's.  Or perhaps we should just have a
function that returns the sfn version of a given lfn, and require all
programs to use sfn's?  If this were built into the compiler, it would be
transparent to the programmer.

- Raw text -