Date: Thu, 16 Jan 1997 08:20:06 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Leath Muller <leathm AT gbrmpa DOT gov DOT au>
cc: scott AT statsci DOT com, djgpp AT delorie DOT com
Subject: Re: DJGPP w/long file name support
In-Reply-To: <32DD7DF3.29E5@gbrmpa.gov.au>
Message-ID: <Pine.SUN.3.91.970116081518.16632B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Thu, 16 Jan 1997, Leath Muller wrote:

> Could someone say how LFN affects things if DJGPP is not running in a
> LFN environment? Does DJGPP see if the DOS environment is capable of LFN?

Yes.  The startup code calls an LFN function that should return volume 
info; if it fails (or if you set LFN=n in the environment), the LFN 
functions are disabled for that drive.

> If this is how it does things, then wouldn't it think that cmd.exe on 
> NT is not LFN capable and show dir listings in the 8.3 format?

This has nothing to do with cmd.exe.  If you call `system("dir")' on NT, 
you will get the long filenames, because it spawns cmd.exe which does 
display long filenames.  But if you call `findfirst' from the DJGPP 
program, you only get 8+3 aliases.

>  
> > > If not, somebody should find out how can a DOS program access LFN on NT
> > > (e.g., how does NT Command.com does it when you type DIR?) and add that
> > > support to low-level libc functions in DJGPP, or at least post the
> > > information so others could add it.
>  
> > Yes!  Hmmm..maybe 'dir' is a builtin for the NT cmd.exe and cmd.exe uses
> > the underlying _findfirst() function?  At any rate, another [possibly
> > equivalent] question is "how does _findfirst/_findnext do its trick?"
> 
> With NT, you have to remember it doesn't use command.com, it uses a
> custom
> cmd.exe - command.com won't run. I have little knowledge of the cmd.exe
> because the majority of stuff I do under NT is D3D stuff - ie: no DOS.
> And Immediate mode sux... ;)
>  
> > I don't suppose there's any way one could somehow detect that the program
> > is being run in an NT environment, then somehow access the system supplied
> > DLLs for getting this info?  I don't really know what the pieces/players
> > are here and how they relate to each other (so I'm probably not the right
> > person to be finding/implementing this :-)).
> 
> Check the archives. Eli came up with a solution to get the DOS version
> which uses 5.x (5.5? I can't remember), which was never used from normal
> DOS. If you run something like the WarcraftII setup, or write your own
> program to get the DOS version, you will see that it reports DOS as
> being
> 5.0, not 6.22 or 7.0 etc...
>  
> > I've considered switching to the Cygnus gnu-win32 stuff, but from what I
> > remember, they require POSIX style directory paths (using forward slashes,
> > etc) and I need to use some DOS tools (e.g. MS C, et al) that probably
> > wouldn't care much for filenames like //c/directory/file.c.
> 
> Write a simple parser... :)
>  
> > Hmmm...have the GNU make sources made it to a point where they just build
> > (and work) using native MS tools?
> 
> Ouch, I would consider that a backward step to say the least... *GRIN*
> 
> Leathal.
>