To: opendos AT mail DOT tacoma DOT net
Subject: Re: [opendos] [OpenDOS] Wishlist part 2 
Message-ID: <19970301.095133.4935.0.chambersb@juno.com>
References: <Pine DOT ULT DOT 3 DOT 95 DOT 970301081139 DOT 4973C-100000 AT atrium DOT musc DOT edu>
From: chambersb AT juno DOT com (Benjamin D Chambers)
Date: Sat, 01 Mar 1997 12:48:37 EST
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk


On Sat, 1 Mar 1997 08:23:08 -0500 (EST) Paul W Brannan
<brannanp AT musc DOT edu> writes:
>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.
I'm not sure what you mean here.  If all programs are required to use
sfn's, what would be the point of implementing lfn's?
Also, having 'transparant' to the programmer like this would only work
for compilers that we can modify to make do so - in other words, no
Borland, no M$, etc.  Admittedly, I wouldn't touch their compilers
anyways, but someone else might.  What happens then?

...Chambers