Date: Sat, 13 Oct 2001 00:44:19 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: sandmann AT clio DOT rice DOT edu
Message-Id: <1483-Sat13Oct2001004418+0200-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com, tim DOT van DOT holder AT pandora DOT be, acottrel AT ihug DOT com DOT au
In-reply-to: <10110121958.AA13790@clio.rice.edu> (sandmann@clio.rice.edu)
Subject: Re: W2K/XP fncase [was Re: New perl package]
References:  <10110121958 DOT AA13790 AT clio DOT rice DOT edu>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> Date: Fri, 12 Oct 2001 14:58:19 -0500 (CDT)
> > 
> > If this happens on W2K as well, I'd say, let's set FNCASE=y in the
> > startup code if it sees W2K/XP.  (By ``setting FNCASE=y'' I mean to
> > set the appropriate bit in the startup flags.)  If it only happens on
> > XP, perhaps we could report this as a bug and hope they fix this
> > before the final release?
> 
> If we don't do anything, we get the fncase=y behavior today (since
> the short name never matches).  Just wasted processing time.

That's why I suggested to set the FNCASE bit in the startup flags: it
will save the needless interrupts.

> > Alternatively, we could code the case of DH=1 (in a W2K/XP-special
> > branch) and leave the probably rare cases such as !.cvs to be treated
> > case-sensitively, like they are today.
> 
> Coding dh=1 would be better than just fncase=y, but I still want to take
> a crack at a 10-20 line alternative which will work better than even 
> that does.

Is it really worth the hassle to introduce new code and then debug it?
I can hardly believe that _lfn_gen_short_name is a real processing
bottleneck, since it doesn't even hit the disk.

> Worse case might be a 256 byte table with valid DOS characters;
> with that I don't see how you couldn't easily duplicate the Windows
> behavior.

That assumes we actually know how 71A8h works, which is what we need
to duplicate.  I have some idea about that, but since it's nowehere
documented, I cannot say if it's 100% true, since I never tested my
hypothesis on too many files.