Mail Archives: djgpp/2008/10/09/16:46:13
"DJ Delorie" <dj AT delorie DOT com> wrote in message
news:200810080226 DOT m982QgOe025692 AT envy DOT delorie DOT com...
> but if you want to try to figure out
> the install without reading and following the instructions we spent
> years ironing out, go ahead.
>
Years? I don't doubt you had problems in the early '90's with long
filenames on DOS... Are you referring to a recent timeframe?
Well, if you're so aware of the issues w/zip, tell me how I managed to
install both v2.03 and v2.04 correctly using Winzip without any problems...
> > Isn't DOS the reason you're using .zip format instead of .tgz or
> > .bz2 or .rpm?!?!
>
> Er, no.
It offers no other advantage. All store long filenames. bzip2 uses less
space. tgz uses standard *nix utils: tar and gzip. rpm uses standard *nix
utils: cpio and gzip with an addition of a header.
> > Aren't your files in .zip format?
>
> Since you know so much about zip files, why don't you tell me why it's
> important to NOT use pkunzip or WinZip.
No reason AFAICT. As I told you already, I used Winzip to install v2.03 and
v2.04... That was over five years ago for this system. It might've been
'98 on a prior system...
> > Why would anyone do that with when they likely already have pkzip,
> > winzip, 7-zip, installed?
>
> Because it "just works", which is more than I can say for the other
> unzip programs, at least, if you're not aware of the non-obvious way
> the other programs need to be invoked to get them to work right.
And, you think using unzip32.exe (or pkunzip as your README.1st says) under
DOS when there is no mention of the required DOS LFN tsr to write LFNs is
"obvious" to the user who *needs* the README to install DJGPP?
> We've often said that if you can't get djgpp working, you probably are
> going to have a hard time with programming too.
I'm sure you do say that alot. It doesn't mean that it is true. I.e., how
do you explain my install?
> > *Both* DJGPP's unzip32.exe (v5.50) and pkunzip.exe (v2.50) require a
> > DOS LFN driver like DOSLFN to write LFN's under RM DOS.
>
> Close, but not quite right.
Confirmed to be true for v7.10 in RM. So, how is it "not quite right"?
> > I see no mention of and LFN driver within DJGPP doc's.
>
> And you won't.
But, you should. At least, there should be a mention that a LFN tsr is
required for DOS in RM (real mode). It seems you are avoiding the issue
willfully. For a person who has "been doing this for nearly twenty years, I
don't need your help figuring out how to install it", it seems like a
blatant oversight. Everything can't be GPL'd...
> The whole point of using unzip32 is that is uses the
> SAME lfn logic as every djgpp program you'll be installing, so it
> always does the right thing as far as lfn vs sfn vs numeric tails as
> the other djgpp programs will be expecting.
If it doesn't do the exact same things with LFNs and SFNs as Windows, then
it's broken and utilities like Norton and Windows scandisk will delete or
modify the files dates, times, and SFNs thereby breaking DJGPP. If it does
do the exact same things as Windows, then using another DOS util in RM DOS
with a properly written LFN TSR, such as DOSLFN, will work identically also.
Your point is mute.
> pkzip doesn't.
I already told you PKZIP v2.50 does. Why are you telling me it doesn't?
Which version are you talking about that doesn't? 2.04g?
> > In fact, your doc's tell how to install DJGPP on just about every
> > other system, *except* DOS!!!!
>
> Could you be more specific? The web site points everyone at the zip
> picker, which includes DOS as the first option. The READMEs assume
> DOS, and call out exceptions for everything else.
Your README.1st v2.03 has *no* DOS install information. It tells how to
install for Windows 98, Windows ME, Windows NT, Windows 2k or XP, but not
DOS. It says to use pkunzip.exe (yeah, exactly what you've been
complainging about...) or unzip32.exe and make sure you have a utility that
supports LFN... But, doesn't explain that if you're installing in RM DOS
that an LFN tsr is required to write LFN's for that utility that supports
LFN.
> > But, then since DJGPP's for DOS, it shouldn't have long filenames
> > anyway, should it?
>
> We have LFN drivers for plain DOS also,
Wrong. You have built in code to call LFN api functions. But, DJGPP
doesn't implement the LFN api functions. DOS in RM (real mode) doesn't
supply the LFN api functions. This means a LFN TSR is required for LFNs in
DOS. The LFN TSR implements SFNs from the LFNs for DOS.
> but DOS 7 (aka "windows") has
> LFN built-in.
False, DOS 7 doesn't have LFN built-in.
True, Windows 98/SE do have LFN built-in for DOS boxes.
> The DOS API certainly does have support for long file names, else
> djgpp wouldn't be able to use them at all.
Under RM DOS, only two LFN calls are supported. These aren't part of the
normal LFN api. I.e., the LFN api isn't implemented by DOS. It's
implemented by Windows or by a DOS LFN tsr.
> pkunzip gets LFN vs SFN wrong. WinZip tends to put each package in
> its own subdirectory. Either results in an unusable installation.
I'm not sure where you get this incorrect information. Pkunzip can't get
LFN vs. SFN wrong, since it doesn't implement the SFN filename. It's the
DOS LFN tsr that creates the SFNs from the LFNs... DOSLFN implements SFN's
using the same method as Windows. And, I've never seen Winzip put files in
the wrong directory. The only problem I've ever experienced with Winzip is
that it won't allow you to rename files with the same name but differences
in capitalization which happen to be in the same directory. E.g., README
and Readme in the same directory in a .zip from a *NIX system.
Rod Pemberton
- Raw text -