X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Date: Wed, 9 Jan 2002 13:09:38 -0500
Message-Id: <200201091809.g09I9cp23351@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <20020109120548.A4095@kendall.sfbr.org> (message from JT Williams
	on Wed, 9 Jan 2002 12:05:48 -0600)
Subject: Re: WIP: lfn under dosemu
References: <250B3114DA16D511B82C00E0094005F8055AC853 AT MSGWAW11> <20020109120548 DOT A4095 AT kendall DOT sfbr DOT org>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> Would an LFN driver for plain DOS necessarily have to be
> written/compiled as 16-bit code?  What would be the advantages
> and disadvantages to an LFN TSR developed as a 32-bit app?

For my purposes, the LFN driver must be written (at least partly) in
not just 32-bit code, but as part of dosemu, so that it has access to
the linux system calls.

Once you have to do part of it in dosemu's source, you might as well
do all of it in dosemu's source, to cut down on the amount of 640k dos
memory you're using.

For plain DOS, you could write an LFN driver in DJGPP, but then you
have the same "issue" as any other djgpp-based TSR: once you've loaded
the tsr, you can't unload the DPMI server, and some of them leak, so
the number of djgpp apps you can run (think "ls" and "cp") is limited.
You also can't run a 16-bit DPMI app at all once you've loaded a DJGPP
TSR.