Mail Archives: djgpp/1998/10/29/15:21:46
On Thu, 29 Oct 1998 19:29:11 +0200 (IST), Eli Zaretskii wrote:
>
>On Thu, 29 Oct 1998, 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.
>
>This extra step goes away in DJGPP v2.02. There, LFN=y by default, which
>as far as I know should close this problem for good.
Unless long filenames are not supported.
>The reason the nuisance of having to set LFN=y is still with us is that
>v2.01 was the first version to fix several subtle bugs in LFN support,
>and it seemed a prudent thing at the time to disable it by default. Add
>to that the relatively long time that passed since v2.01 was released,
>during which many people switched to Windows 9X, and you will see why we
>are where we are now.
Some of us have not switch to Win95, nor will we.
>But there's no reason to treat that nuisance as something that should
>stay with us. It won't.
>
>When v2.02 is out, unzipping an archive will produce desired results on
>both LFN and non-LFN platforms automatically. For that, you must have
>long file names in the zip file, or else you will need to force people to
>use specific unzippers (or risk that they fail to run some script and
>then come back crying).
The program does not work after just unzipping. One still has to set the
environment variable, and amend the system path. Writing a program that
performed that task as well as doing any required renames/source patches
would be the best way to go.
With the method you state, the person must be careful which archiver is used.
If I unzip it with the OS/2 version of UNZIP, the long filenames are
expanded (because it's on an HPFS drive), which leaves the program
non-functional, due to the fact that DOS sessions can not see long filenames.
>> I am merely stating that said
>> extra step should also remove from the archiver the role of ensuring the
>> correct filenames for compiler components.
>
>It's not the unzipper that does that, it's the OS. DOS itself truncates
>the file names to 8+3 limits when you unzip, and that's how it's supposed
>to work.
Try to imagine a non-DOS operating system that supports DOS sessions, but is
not itself built upon a DOS session.
At the very least, the installation should note that one should unzip the
package inside the DOS session that the compiler will be run in, to avoid
problems with archive extraction.
>> Packaging the program as I've suggested would provide complete functionality
>> for normal use.
>
>I'm sorry, I don't see the message with your suggestion, but if LFN is
>enabled by default, what other problems are there that require a
>different method of packaging?
See above.
And another example:
The program is installed on a Win95 machine that is part of a network.
Another machine that doesn't support long filenames can't use it over the
network because of the packaging method.
Since there's no way to unzip the package with short filenames to ensure
compatibility in Win95, the above setup would require gymnastics to work.
If, however, the archive had short names, period, and a program to enable
long filenames (which would also set the environment variable and modify the
path; two extra steps that can be combined into one), functionality would not
be impeded by situations that escape the imagination of those who package the
program.
--
- Mike
Remove 'spambegone' to send e-mail.
- Raw text -