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 Organization: Telecommunication Systems Support Centre MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp-workers AT delorie DOT com Subject: Re: Possible enhancements on v2.02 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Precedence: bulk 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