Mail Archives: djgpp/1998/11/01/07:07:39
On Thu, 29 Oct 1998, Mike Ruskai wrote:
> >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.
Non-LFN platforms will also work automatically (as they do now) if
they NEVER support long names, like in plain DOS. In these cases, the
OS automatically truncates the names to 8+3 limits, both when you
unzip files and when the binaries which access those files run, and
everything works.
> 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.
Ah, you are talking about an installer.
I agree that an installer would be nice to have, but it turns out that
it is a non-trivial task to write one, which is probably one reason
why nobody has done so yet.
Discussing why is this non-trivial probably deserves another thread
(or you could search for past discussions of this in the DJGPP forum
archives at http://www.delorie.com/djgpp/mail-archives/). But in a
nutshell, the hard problem is to support all the environments that
DJGPP can be run on, each one with its own peculiar way of setting
PATH and environment variables. Since an installer must be very
reliable to be used by everyone, it has to be able to detect the
particular operating system it runs on, and change its configuration
in a way that doesn't break the system setup. Among other problems,
it has to deal with multi-configuration CONFIG.SYS and AUTOEXEC.BAT
files, it needs to know about registry and multiple AUTOEXEC.* files
on NT and OS/2, etc. None of these is rocket science, of course, but
it just makes the task non-trivial.
Without a full-blown installer that everybody uses, a program that
does only part of a job, like unzipping the package and/or renaming
the files appropriately, will have the same effect as asking people to
use specific unzippers, which you (quite justifiably) regard as a
problematic solution.
> 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.
Systems which support long file names natively, but not in DOS
sessions, are indeed those where the problem will remain even in
v2.02. Barring an installer that can handle these cases as well, I
don't think there can be any automatic solution. Fortunately, such
systems are relatively rare, at least among DJGPP users. Please feel
free to suggest a reliable way to solve this, if you can.
> 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.
Some packages do that (see the emacs.README file, for example), but
many people don't read the docs :-(.
> >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.
I don't see how these problems could be solved by repackaging the .zip
files.
> 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.
These gymnastics are described in section 22.18 of the DJGPP FAQ
list. The description there is based on the way I set up my own
system, where I must be able to run both under Windows and under plain
DOS. I believe the same setup will work in the case you described;
but if not, please tell here about any problems you have.
> 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.
This assumes implicitly that the probability of people to run the
program which does that magic is very high. Unfortunately, my bitter
experience from helping people on this forum for several years
indicates the opposite (many don't even read the README, and where
else would you tell them to run this program?).
Since most of those who don't read the docs are also running DJGPP on
Windows 9X, making the archives with short names seems to me like
favoring a minority. I also believe that people who stay away from
Windows 9X by choice generally know what they are doing and why, and
so stand a better chance of getting this right when they install
DJGPP.
Of course, if some addition to the installation instructions will help
users of such systems to set up DJGPP correctly, please spell out what
do you suggest to add there.
- Raw text -