Comments: Authenticated sender is <alaric+abwillms AT sdps DOT demon DOT co DOT uk>
From: "Alaric B. Williams" <alaric AT abwillms DOT demon DOT co DOT uk>
To: Benjamin D Chambers <chambersb AT juno DOT com>, opendos AT mail DOT tacoma DOT net
Date: Sat, 1 Mar 1997 21:33:03 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [opendos] [OpenDOS] Wishlist part 2 
Reply-to: alaric AT abwillms DOT demon DOT co DOT uk
In-reply-to: <19970301.095133.4935.0.chambersb@juno.com>
Message-ID: <857251847.1019046.0@abwillms.demon.co.uk>
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

On  1 Mar 97 at 12:48, Benjamin D Chambers wrote:

> 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?

I think that what he meant was that we use normal SFNs for 
identifying files internally, but convert to the "long" names for 
user interaction, and vice versa.

Eg:

const char *make_sfn(const char *lfn);
const char *make_lfn(const char *sfn);

...

cout << "Enter a filename: ";
char _filename[BIG_ENOUGH];
cin >> _filename;
const char *filename = make_sfn(_filename);
FILE *fp = fopen(filename,"rb");

...

const char *command = getenv("COMSPEC");
cout << "Your command interpreter is " << make_lfn(command) << endl;

> 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?

We can put those mangling functions in libc for DJGPP, and either 
make Borland/M$ programmers do it the laborious way, like above, or 
make macros that override the stdio etc. functions (ie, 
lfn_fopen(...))

> ...Chambers

ABW 
--
Governments are merely protection rackets with good images.

Alaric B. Williams Internet : alaric AT abwillms DOT demon DOT co DOT uk
http://www.abwillms.demon.co.uk/