Mail Archives: djgpp/1998/10/29/03:00:28
On Wed, 28 Oct 1998 20:44:25 -0800, Nate Eldredge wrote:
>Mike Ruskai wrote:
>
>> >I personally agree that editing a text file is a trivial thing to get
>> >right, but there are total newbies out there. Someone is sure to edit
>> >it with Microsloth Word, and then complain that DJGPP doesn't work. And
>> >if the user uses something like RHIDE, they don't even need to know how
>> >to write/edit a text file.
>>
>> I submit that someone so ignorant is best prevented from inflicting upon the
>> world any prorams which by luck alone are compiled.
>
>Okay, I see your point, but I think it's probably a good thing to
>minimize the additional knowledge/skills prerequisite to DJGPP. Some
>computer-illiterate people will probably learn as they go, if only they
>can get started. Your statement comes across as somewhat elitist.
I don't think I'm the least bit aristocratic when I hold that someone should
be expected to know what it means to edit and save a text file, if they are
to perform that task prior to instructing a compiler to turn said text file
into an executable program.
I'll grant you the possibility that someone may be able to compose a trivial
program within an IDE, and compile it. But to go beyond that point, basic
skills would be required; skills that, when tallied, would certainly qualify
the prospective programmer in question to edit text files.
>> No, you're still missing the point entirely.
>
>Oh, wait. So your solution is something like having the zip contain
>short names, and then running a script when installing which renames
>them all to their long names? Okay, *that* makes more sense. Sorry, I
>think I'm slow today.
>
>That has the slight disadvantage that it requires an extra installation
>step which might be forgotten. On the other hand, if missed, it could
>be done when you notice that things don't work. Bad unzipping requires
>that you nuke the installed package and try again. And, yes, I see it
>would work on non-LFN platforms as well, it just wouldn't have any
>effect, since the names are truncated. People who didn't RTFM might be
>more likely to lose, though that might be a good thing, and save them
>from subtler problems later on.
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.
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).
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).
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 <streambuf.h> 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 <streambuf.h>' 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
>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.
>Yes, I think that makes quite a lot of sense, though I'm not entirely
>sure how the newbie factor would affect it. What do others think?
>
>If I've misunderstood your proposal yet again, sorry.
I think you've got the idea quite well now, even if you've stumbled on a few
of the details.
--
- Mike
Remove 'spambegone' to send e-mail.
- Raw text -