Date: Mon, 1 Dec 1997 14:05:35 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: djgpp-workers AT delorie DOT com
cc: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject: Re: Possible enhancements on v2.02
In-Reply-To: <Pine.SUN.3.91.971124134758.23713f-100000@is>
Message-ID: <Pine.SUN.3.91.971201135645.8493B-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Mon, 24 Nov 1997, I wrote:

>      1) Is it a good idea to turn LFN support on Windows 95 *before*
>         DJGPP.ENV is read.  (It will be turned off if DJGPP.ENV says
>         so.)  This should take care of those who set
> 	  DJGPP=c:/FubaricallyLongName/djgpp.env.

Well, I looked into the current sources, and it seems that this should
mostly work.  The startup code calls _USE_LFN forcefully *before* loading
the environment file (and again after it is loaded).  This has been so 
since v2.01 release.  I made some test runs and saw that the long names 
in the DJGPP variable are recognized even if LFN is set to N.

So it seems that the usual advice to users not to set DJGPP to a 
long-named directory is no longer valid, at least not in the usual case 
(where LFN=y).

I can think of only a couple of complications related to this; they all 
happen if DJGPP.ENV sets LFN=n and the environment doesn't override 
it:

	1) The command-line globbing will yield long names, and then the
app could fail when it looks for them, if the 8+3 aliases have numeric
tails. 

	2) GCC might fail to find its programs, again if the short 
aliases have numeric tails.  The same with Info and other programs who 
look for files in %DJDIR%-related directories.

Can anybody come up with other examples?