delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/08/30/10:38:13

Date: Sun, 30 Aug 1998 17:37:27 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: taupin <taupin AT lps DOT u-psud DOT fr>
cc: Latex2html list <latex2html AT mcs DOT anl DOT gov>, DJGPP List <djgpp AT delorie DOT com>,
Sibastien QUERCIOLI <s DOT quercioli AT ffme DOT fr>
Subject: Re: Serious Perl broblems with DJGPP+Win NT
In-Reply-To: <35E5F231.6083F283@lps.u-psud.fr>
Message-ID: <Pine.SUN.3.91.980830173704.20257e-100000@is>
MIME-Version: 1.0

On Thu, 27 Aug 1998, taupin wrote:

>  1. This was tried with LFN=y (both set as environment variable AND in
> djgpp.env). Can this setting (which does not work in WinNT (even with
> djgpp version 2) be the cause of the memory crash?

No, the setting of LFN should have no effect whatsoever on NT.

What do you mean by saying that ``this setting (that does not work in
WinNT''?  Are you just saying that the long file names aren't
accessible on NT (a known fact), or did you see some other problems
which disappear if you don't set LFN=y?

>  2. Subsidiary questions: when LFN is set to y as environment variable
> and to n in djgpp.env, which statement overrides the other? Or is it
> understood as any "y" overrides the "n" or missing value assignment?

There are actually two questions here.

First, for every variable set by DJGPP.ENV, if the line which sets it
begins with a `+', that line only takes effect if the variable is NOT
set already in the environment.  If the line does NOT begin with a
`+', DJGPP.ENV setting is always done.

Second, specifically for LFN, only LFN=n has the effect of changing
the DJGPP behavior: it unconditionally disables long file name
support.  In contrast, either LFN=y or LFN that is not set at all mean
the same: support long names, if the OS allows that.

> Last remark: WinNT is very tricky, since djgpp cannot handle long names
> in DJGPP (this confirms what has been said by Eli Zaretski) and
> truncates the names (when not crashing as presently), but the COPY
> command handles long names. Therefore, "cp.exe" behaves differently of
> the dos command "COPY" (terrible!).

What's terrible is Microsoft's policy that wants DOS programs to go
away and thus deliberately doesn't support the LFN API on NT.
Microsoft is who you should be yelling at.

If you are so bothered by that, why don't you try Andrew Crabtree's
LFN driver for NT?  It's in alpha, but it does work for me when I'm
coerced to work on NT.

And btw, who in their right mind would need to use COPY instead of
cp.exe?? ;-)

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019