Mail Archives: djgpp/1997/01/15/18:08:59
> > > I wrote a quicky
> > > little program to use the DOS _findfirst() function and IT returns the
> > > LFNs for me on both Win95 and NT 4.0.
> > Did you compile it with DJGPP? If so, please post the code here.
> Nope - it was MSVC compiled.
Ummm... hello? Anybody home? ;) If your using a true DOS app, not one
created
from the MSVC AppWizard, (true being with a DOS compiler, such as DJGPP,
or
TC, etc etc), you can't use LFN because NT effectively uses DOS 5, which
doesn't support LFN. DOS 7 is the only DOS that does, ie: Win95...
> > If NT 4.0 supports Int 21h function 71A0h (Get Volume Info), then programs
> > compiled with DJGPP v2.01 will support LFN there automagically.
> In my case, I'm just taking the v2.01 binaries and trying to run them on
> NT4.0. What I've been doing is connecting to a share exported from a
> samba-running Unix box and using the DJGPP 'find' command to list the
> files there to see if I'm getting LFNs or not. Under NT4 I get the 8.3
> mangled names that samba produces for me. Under Win95, I get the actual
> LFNs as I see them from Unix land.
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? 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?
> > 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.
- Raw text -