Sender:	bcurrie AT tssc DOT co DOT nz
Message-ID:	<348C443C.1198@tssc.co.nz>
Date:	Tue, 09 Dec 1997 08:02:20 +1300
From:	Bill Currie <bcurrie AT tssc DOT co DOT nz>
Organization:	Telecommunication Systems Support Centre
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	djgpp-workers AT delorie DOT com
Subject:	Re: Possible enhancements on v2.02
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 971208154322 DOT 4200H-100000 AT is>

Eli Zaretskii wrote:
> Another, more subtle, problem is with the command-line globbing in the
> startup code, since the LFN usage may change half-way through the
> startup.  See the other thread on djgpp-workers.

Hmmm, hadn't thought of that. However, two things: I got the impression
that wouldn't happen (unless the main program changed the lfn handling;
and IMHO, such a program is broken as designed.  The only programs that
should be changing the way they handle LFN/SFN are low-level stuff and
then they should use the SFN->LFN and LFN->SFN conversion routines that
are part of the LFN truename api.

> > IMHO, W95 screwed up. I've found the W95 method more trouble than it's
> > worth.
> 
> Please tell more about the trouble you get with what Windows 95 does.

The biggest one I had was with in the po directory of gnu tar with the
Makefile.in.in (I had numeric tails off at the time). Others involve
case sensitivity, but it's mostly that first problem that really got up
my nose.

> Anyway, being compatible sometimes means you need to emulate the bugs
> as well.

Oh, they'll be there, as options that are disabled by default (and when
I release the thing, well documented as to the diferences between my lfn
driver and W95, and how to go from one to the other).

Bill
-- 
Leave others their otherness

- Raw text -