Message-ID: <387297B4.4555B526@adtran.com>
From: ron flory <ron DOT flory AT adtran DOT com>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.14pre17 i586)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: djgpp: gnu make ver 3.77 (long file names in 'include' directive) under 
 NT 4.0
References: <Pine DOT SUN DOT 3 DOT 91 DOT 991215091233 DOT 18491K-100000 AT is> <Pine DOT GSO DOT 4 DOT 05 DOT 9912151520280 DOT 14690-100000 AT sol DOT sun DOT csd DOT unb DOT ca> <knS54.830$CW3 DOT 12591 AT dfiatx1-snr1 DOT gtei DOT net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 45
NNTP-Posting-Host: 206.166.249.100
X-Trace: tw11.nn.bcandid.com 947030424 206.166.249.100 (Tue, 04 Jan 2000 17:00:24 MST)
NNTP-Posting-Date: Tue, 04 Jan 2000 17:00:24 MST
Organization: bCandid - Powering the world's discussions - http://bCandid.com
Date: Wed, 05 Jan 2000 00:00:24 GMT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Damian Yerrick wrote:
> 
> "Pinliang Dong" <y16y AT unb DOT ca> wrote:
> >   "Note that long filename API ... for DOS box is not supported by current
> >    version of Windows/NT, so you cannot have long filenames here
> >    from DJGPP programs..."
> >
> > So I cannot use DJGPP for long filenames in Windows NT?
> 
> You can if you upgrade to Windows 2000 or if you
> get one of those really buggy LFN drivers.

 Ouch.

 I've just joined this newsgroup, and have at least taken the time to
read previous posts on this subject.

 I'm starting a project at work, and am trying to wean these guys away
from M$ tools towards GNU stuff, but I've hit a nasty problem when
'including' a makefile whose path is a 'long' filename, for example:

in makefile:

   include c:\jasper_bootrom\test\test2\common.mak

 I am using 4NT version 3.02B.

 Are you saying that NT4.0 DosBox API cannot accept a long filename for
input?  I thought that only old-old-style MsDos FCB's were limited to
8.3 format, wheras ascii-z input strings were essentially free-form.  I
know that path/file strings -returned- by several calls may be mangled
to the name~1 format, but I thought full-length input strings were
acceptable and automatically converted to the mangled form when the call
was made.  Once you have the handle of the opened file, who cares what
its mangled form is?   Do these same limitations apply to 4NT, or is
this irrelevant due to where the open request is actually handled?

 Now I may be very wrong here, its been a long while since I made any
INT21 calls (this is meant to be a joke, OK)....

 I just want to make sure we are all saying the same thing here-

 Thanks-

ron