Mail Archives: djgpp/1998/10/30/01:35:19
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.
- Raw text -