Newsgroups: comp.os.msdos.djgpp
From: "Mike Ruskai" <thanny AT spambegone DOT home DOT com>
Message-ID: <gunaalubzrpbz.f1mm91a.pminews@news.avnl1.nj.home.com>
References: <363532BA DOT 6FA0626F AT erols DOT com> <gunaalubzrpbz DOT f1gwzw0 DOT pminews AT news DOT avnl1 DOT nj DOT home DOT com> <7144gm$i1n$1 AT star DOT cs DOT vu DOT nl> <gunaalubzrpbz DOT f1hyic2 DOT pminews AT news DOT avnl1 DOT nj DOT home DOT com> <36365A5B DOT D92F78D7 AT cartsys DOT com> <gunaalubzrpbz DOT f1if2m0 DOT pminews AT news DOT avnl1 DOT nj DOT home DOT com> <3637F2A9 DOT 97A150DA AT cartsys DOT com> <gunaalubzrpbz DOT f1kwom2 DOT pminews AT news DOT avnl1 DOT nj DOT home DOT com> <36392AB8 DOT 58927E36 AT cartsys DOT com>
X-Newsreader: PMINews 2.00.1201 For OS/2
Organization: TLF
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: C++ with DJGPP
Date: Fri, 30 Oct 1998 06:05:27 GMT
NNTP-Posting-Host: 24.3.130.120
NNTP-Posting-Date: Thu, 29 Oct 1998 22:05:27 PDT
Lines: 89
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

On Thu, 29 Oct 1998 18:55:52 -0800, Nate Eldredge wrote:

>Mike Ruskai wrote:
>
>> 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 :)

I humbly submit that the world has been a service when such a user is denied
the opportunity to infect humanity with object code created from his/her
source.

Maybe this seems elitist to some, but I think it's entirely reasonable to
expect that a person a computer literate before attempting to become a
computer programmer.

I don't sense you disagree, just that you're not as brash about it.  I feel
no compunction about being direct in my opinions on this matter, because it's
doubtful that those who take offense would have the skills necessary to
figure out my e-mail address ;)

>> What possessed you to make such a claim.  This very thread was begun because
>> of the fact that '#include  <streambuf.h>' does not in fact work equally well
>> with or without long filenames.
[snip]

>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.

The same thing did *not* happen when unzipping for me, and for the person who
began this thread.  

The basic point here is that the package relies on identical conditions when
unarchiving and compiling.  This presents a problem for individuals like
myself who habitually use a native interface for manipulating files
(including archives), and for any individual who may wish to involve a
network that makes using long filenames impossible.

>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.

3.  LFN platform/no LFN in DOS mode/file unzipped natively.

4.  LFN installation system/non-LFN system on network.

That's just what I can think of off hand.  I don't doubt that my imagination
has missed many circumstances where failure would result.

>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.

I disagree on the "solution" chosen, but it's not my show.  

FWIW, I never found anything in any documentation indicating that the archive
was packaged in such a way as to make these problems possible.  It may very
well be in the documentation somewhere, but it would take less time to figure
the problem out than find it, if my experience is any indication.  

Of course, I only downloaded the damn thing to make a DPMI executable for a
silly little program I wrote, to escape segmentation problems with a 16-bit
DOS executable (I wrote it for a flat memory model).  So, I'm not preventing
any wars with my little cause here.  Use a level of sobriety appropriate to
these circumstances when considering any responses <g>.

--
 - Mike

Remove 'spambegone' to send e-mail.