Sender: nate AT cartsys DOT com Message-ID: <36392AB8.58927E36@cartsys.com> Date: Thu, 29 Oct 1998 18:55:52 -0800 From: Nate Eldredge X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i486) MIME-Version: 1.0 To: djgpp AT delorie DOT com Subject: Re: C++ with DJGPP References: <363532BA DOT 6FA0626F AT erols DOT com> <7144gm$i1n$1 AT star DOT cs DOT vu DOT nl> <36365A5B DOT D92F78D7 AT cartsys DOT com> <3637F2A9 DOT 97A150DA AT cartsys DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com Mike Ruskai wrote: > No, in fact it does not require an extra installation step. It is already > the case that someone using long filenames will have to take an extra step to > configure the compiler for that circumstance. I am merely stating that said > extra step should also remove from the archiver the role of ensuring the > correct filenames for compiler components. See below. > Unzipping the package in a fashion that breaks its functionality does not > result in such an obvious malfunction as you seem to imply. In fact, the > problem is quite subtle indeed, only showing up when certain includes are > required (such as streambuf.h, itself included from iostream.h). On reflection, you're right. > Packaging the program as I've suggested would provide complete functionality > for normal use. Someone who for some reason includes streambuf.h directly > would surely realize that long filenames are required, and take the step > necessary to enable them (ideally, simply running a supplied program). A moderately naive Windows user would have no reason to expect that they would not be enabled, and simply become confused when it didn't work. RTFM'ing might help, but then, if people would RTFM, we'd be out of a job :) > This happens to be the exact method employed by the EMX development package, > which is an OS/2 port of GCC. While DJGPP is hampered by the fact that there > is no script language in DOS or Win95, it is a fairly trivial matter to write > a simple program to perform the task. A program which, properly written, > could be easily modified to reflect the current package contents; ideally > written, it would operate entirely based on a configuration file. > > >I don't see why you should need to change the headers at all, actually; > >#include will work equally well on vanilla 8+3 and > >Windows/LFN=Y. OTOH, people who leave LFN=N would have to set it =Y > >when they run the script, or else they lose, so it might not gain all > >that much. > > What possessed you to make such a claim. This very thread was begun because > of the fact that '#include ' does not in fact work equally well > with or without long filenames. > > Perhaps it is best demonstrated thusly: > > 1-s > 2-t > 3-r > 4-e > 5-a > 6-m > 7-b > 8-u > 9-f It works on a completely non-LFN system (MS-DOS < 7): when opening "streambuf.h", the extra character is dropped and you get "streambu.h". Since the same thing happened when unzipping, it's found. Try it and see. On an LFN system where LFNs are enabled, it also works, provided the long name was used in creating the file. I think we've established that. The cases that don't work are: 1. LFN platform/LFN's disabled in DJGPP/File created with Winzip or similar/NameNumericTail=1 2. LFN platform/LFN's enabled in DJGPP/File created with PKUNZIP 1 will go away when LFN=Y is the default, and 2 seems empirically to be very uncommon. Most newbies use Winzip. > >I suppose the other tricky bit is that the people creating the package > >have to generate the script. But it could presumably be somehow > >automated. > > I very much doubt that someone who can write a compiler is incapable of > writing a program to correct include files. I can't do the former, but can > easily do the latter. The person packaging the compiler for DJGPP is not necessarily the person who wrote said compiler. But I agree it's not a horrendously difficult task. OTOH, I believe Eli's point is well made that much of this complexity will soon be unneeded, when LFN=Y. People who want or need to use Windows without LFNs can find, with minimal RTFM'ing, that PKUNZIP will solve their problems. Same goes for OS/2 and so on. -- Nate Eldredge nate AT cartsys DOT com