DOS ain't dead

david 21.07.2010, 21:20	cdrtools_from_Schily (Announce) Post reply
	I have just upload cdrtools-2.01.01a80 before final 2 version on server http://perotti.ic.cz/cdrecord/cdrtool-a80.7z You can test it, I think that something is improved. My ask, Does somebody can rewrite script from Linux Perl to DOS? Partly works but I haven`t free time to continue David

Arjay 21.07.2010, 21:59 @ david	cdrtools_from_Schily Post reply
	> My ask, Does somebody can rewrite script from Linux Perl to DOS? inf2cdtext.pl ? tracknames.pl ? or something else? > Partly works but I haven`t free time to continue Common problem :( P.S Any specific reason for the 7z (7-Zip) archive instead of a more common DOS world format?

Rugxulo Usono, 21.07.2010, 22:32 @ Arjay	cdrtools_from_Schily Post reply
	> P.S Any specific reason for the 7z (7-Zip) archive instead of a more > common DOS world format? Better compression, what else? 7zdec912.zip p7zip 4.65 (DJGPP .EXE) p7zip 4.65 sources (later p7zip versions don't compile anymore or don't work in FreeDOS)

Arjay 21.07.2010, 23:13 @ Rugxulo	cdrtools_from_Schily Post reply
	> Better compression, what else? I asked for that! Ok, I suggest we don't go over this one again ;) > 7zdec912.zip Thanks, forgot about your good work there. > (later p7zip versions don't compile anymore or don't work in FreeDOS) Ah yes something to do with your old hack not working anymore / LFN issues with HX?

Rugxulo

Usono,
22.07.2010, 01:04

@ Arjay

cdrtools_from_Schily

Post reply

> > Better compression, what else? :lol:
> :lol: I asked for that! Ok, I suggest we don't go over this one again ;)

Seriously, that's the only real reason to use it, for LZMA or PPMD (instead of Deflate or Bzip2, which are supported in latest Info-Zip).

> 7zdec912.zip
> Thanks, forgot about your good work there.

Note that I doubt I really did anything useful there, mostly just some (very) small tweaks. My package really needs a (minor) refresh anyways one of these days.

> > (later p7zip versions don't compile anymore or don't work in FreeDOS)
> Ah yes something to do with your
> old
> hack not working anymore /
> LFN issues
> with HX?

The "hack" was something really goofy, and I was surprised it worked. Then again, DR-DOS etc. didn't need it at all! I never understood that. 9.04 compiles for and works there fine. p7zip 9.13 was finally (!) released recently after a long wait, but my attempt to compile it ran into a bunch of incompatibilities (probably something silly at heart, but it seemed like a lot at the time, e.g. Unicode widechar crud). In short, it's not a very friendly app to port to DOS. Safe to say that I'm just glad to unpack .7z files now. :-/

I forget exactly, but I presume the HX issue was that you needed LFN in order to use temporary file names (e.g. blah.7z.tmp), which I thought was unwieldy.

DOS386

23.07.2010, 07:19

@ Rugxulo

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

> P.S Any specific reason for the 7z (7-Zip) archive
> instead of a more common DOS world format?

Better compression. Also this "BUG" had been already pointed 5 months ago :-)

+ 1 for 7-ZIP :-)

But please make sure that extract requirements are not higher than run requirements (dict size, no 7-ZIP for 8086-stuff).

> Ah yes something to do with your old hack not working anymore / LFN issues with HX?

Don't use NTLFN :-)

> I forget exactly, but I presume the HX issue was that you needed
> LFN in order to use temporary file names (e.g. blah.7z.tmp)

> (tries to make "blah.zip.tmp" or something dumb like that).

0. Indeed DUMB
1. Only when updating archives
2. I had fixed this over 1 year ago download it and RTFM UIEXAMPL.TXT

> Is there a possible way to make HXRT translate filenames like this
> (which seem fairly common in the Windows world) to 8.3 ?

+ 1

> It was compressed by 7zr 7-zip (A) 4.58 BETA on Deb

Better use 4.65 :-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

david

23.07.2010, 21:10

@ DOS386

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

> But please make sure that extract requirements are not higher than run
> requirements (dict size, no 7-ZIP for 8086-stuff).
>

The p7zip can`t work on DOS due to lack of memory,
You can try
http://perotti.ic.cz/p7zip/7za.exe

where is version 9.13 for DOSes

>
> > It was compressed by 7zr 7-zip (A) 4.58 BETA on Deb
Yes, because of stable Debian Lenny!

> Better use 4.65 :-)

Maybe, try version 9.13 from Roberto url and You will
get in compress large files "Cannot alocate memory!!"

I think that it is impossible to use 7-zip in pure DOS.

DOS386

24.07.2010, 12:06

@ david

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

> The p7zip can`t work on DOS due to lack of memory

WtF ???

> You can try http://perotti.ic.cz/p7zip/7za.exe where is version 9.13 for DOSes

COOL :-|

> Maybe, try version 9.13 from Roberto url and You will
> get in compress large files "Cannot alocate memory!!"

Please reveal how much memory you have and what compression settings (+ possible faulty memory managers). I'm not aware of this problem. But I'm using usually Win32 7-ZIP via HX, my tests of p7-ZIP DGJPP ports were limited.

> I think that it is impossible to use 7-zip in pure DOS

It works for me :-) If it was impossible to use 7-zip in pure DOS then your 7-ZIP'ped "DOS" packages would be invalid :clap:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

david

24.07.2010, 15:28

@ DOS386

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

> Please reveal how much memory you have and what compression settings (+
> possible faulty memory managers). I'm not aware of this problem. But I'm
> using usually Win32 7-ZIP via HX, my tests of p7-ZIP DGJPP ports
> were limited.
>

7-zip is terminated by SIGSEV on error=0006, I think that point on
JEMMEX.EXE EMX memory manager in EDR-DOS 7.01.08 WIP 23.7.2009
in command line after severall added huge files to archive.

> It works for me :-) If it was impossible to use 7-zip in pure DOS then your
> 7-ZIP'ped "DOS" packages would be invalid :clap:

If You have working DOSe`s You test this binary? but I have never use
p7-zip in pure DOS

DOS386

24.07.2010, 15:34

@ david

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

> JEMMEX.EXE EMX memory manager in EDR-DOS 7.01.08 WIP 23.7.2009

Removing JEMMEX and EMX is the ZERO'th thing to try :-)

> You have working DOSe`s

YES

> You test this binary?

I will (typical 2 options choice: either [0] I will test it ... or ... [1] it never happens at all)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo

Usono,
24.07.2010, 19:56

@ david

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

> The p7zip can`t work on DOS due to lack of memory,

p7zip in general or just this version?

> You can try
> http://perotti.ic.cz/p7zip/7za.exe
>
> where is version 9.13 for DOSes

Strange, it IS a DJGPP compile. I got errors when trying to make it myself. Somebody must've tweaked it on their end as the pre-made makefiles don't work.

> > > It was compressed by 7zr 7-zip (A) 4.58 BETA on Deb
> Yes, because of stable Debian Lenny!
>
> > Better use 4.65 :-)

Obviously he means 4.65 is the "stable" version, i.e. more reliable and bugfixed than 4.58 (see changelog).

> Maybe, try version 9.13 from Roberto url and You will
> get in compress large files "Cannot alocate memory!!"

2.04 stub, so it has the 4 GB fixes. If it can't allocate memory, either you don't have enough, your memory manager is eating (or hiding) it, or you should use CWSDPMI (esp. latest r7) with swapping enabled.

> I think that it is impossible to use 7-zip in pure DOS.

At first I thought you meant HX + Win32's 7ZA, but apparently not. Sure, that way is great but lacks swapping (but much easier to upgrade). Default is -mx=5, which is normal compression. Anything higher uses more memory. You might have to use -ms=8m -m0d=8m to force it to only use 8 MB dictionary (or whatever).

Zyzzle

24.07.2010, 22:51

@ Rugxulo

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

Strange, but I get the message "out of swap space" with 4.65 and 9.13. I am using CWSDPMI r7. My settings are -mx9 and md=32m. It even comes up at mx5 and -md=32m. I'm using a RAM disk as TEMP. The error occurs on all my systems -- it even occurs on a DOS system with >2GB free XMS memory! Could be some >2Gb bug, but it also happens on other systems with 1GB and 2GB total system RAM. It is strange, as some files compress fine, but at 80% - 99% complete the error comes up.

I do *not* get that message with the SAME settings with 4.58! So, for now I am sticking with 4.58 unless someone can give me a compelling reason to switch. It seems the 9.13 version is 5-10% slower while still giving exact same file sizes as 4.65 (with same commandline options ex, -mx5... So I see no compelling reason to switch to 9.13 at all.

Rugxulo

Usono,
24.07.2010, 23:44

@ Zyzzle

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

> Strange, but I get the message "out of swap space" with 4.65 and 9.13. I am
> using CWSDPMI r7. My settings are -mx9 and md=32m. It even comes up at mx5
> and -md=32m. I'm using a RAM disk as TEMP.

What are you trying to compress? How big is it?

CWSDPMI defaults to c:\cwsdpmi.swp so you have to use -p -sd:\cwsdpmi.swp temporarily or CWSPARAM.EXE to change this permanently. r7 works fine with 1 GB of RAM or greater, but r5 and buggy r6 both have issues. Try again with HDPMI32 if you're really curious. Also set TMPDIR just in case (some DJGPP tools like GCC use it, not sure about p7zip specifically).

BTW, check again, I can't remember exactly, but I think you may have to use both of these: -ms=32m -m0d=32m

> The error occurs on all my
> systems -- it even occurs on a DOS system with >2GB free XMS memory! Could
> be some >2Gb bug, but it also happens on other systems with 1GB and 2GB
> total system RAM. It is strange, as some files compress fine, but at 80% -
> 99% complete the error comes up.

Do you have JEMM386 loaded? By default I think it limits EMS to 120 MB, which CWSDPMI seems to run up against unless you tell it otherwise. The latest CWSDPMI.DOC suggests "MAX=0".

> I do *not* get that message with the SAME settings with 4.58! So, for now I
> am sticking with 4.58 unless someone can give me a compelling reason to
> switch.

Even 4.61 beta has a bug with AES encryption and probably some others (PPMD in .ZIP). Also, I suspect 4.58 was compiled by Kostylev with FSU Pthreads (and nobody can reproduce it). Yes, there are some obscure issues with p7zip and DJGPP not working well together. Blame it on the heavily *nix-oriented port and multithreading.

> It seems the 9.13 version is 5-10% slower while still giving exact
> same file sizes as 4.65 (with same commandline options ex, -mx5... So I
> see no compelling reason to switch to 9.13 at all.

9.04 was buggy, but it was the first to support LZMA2, which is really only useful for better multi-threaded compression, delta (.WAV) file compression, and better handling of uncompressable streams. Oh, and .xz format, but if you don't care about any of that, I'd stick to 4.65 "stable", personally (unless you can 100% prove it's buggy somehow).

DOS386

25.07.2010, 06:33

@ Rugxulo

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

> Sure, that way is great but lacks swapping

and this is evil because ??? :confused:

> Strange, but I get the message "out of swap space" with 4.65
> and 9.13. I am using CWSDPMI r7. My settings are -mx9 and md=32m.
> It even comes up at mx5 and -md=32m. I'm using a RAM disk as TEMP.
> The error occurs on all my systems -- it even occurs on a DOS
> system with >2GB free XMS memory!

Most likely all your memory is hogged away by your RAMDISK + UIDE :-)

> Could be some >2Gb bug, but it also happens on other systems
> with 1GB and 2GB total system RAM. It is strange, as some
> files compress fine, but at 80% - 99% complete the error comes up.

Try to reduce dict size :-)

> I do *not* get that message with the SAME settings with 4.58!

Strange :confused:

> CWSDPMI defaults to c:\cwsdpmi.swp so you have to
> use -p -sd:\cwsdpmi.swp temporarily or CWSPARAM.EXE to
> change this permanently.

Or don't use CWSDPMI.

> Try again with HDPMI32 if you're really curious.

Right :-)

> Do you have JEMM386 loaded? By default I think it
> limits EMS to 120 MB, which CWSDPMI seems to run up against

Remove any EMM386 :-)

> 9.04 was buggy, but it was the first to support LZMA2,
> which is really only useful for better multi-threaded compression

Does it work for you (in DOS) ??? :confused:

> delta (.WAV) file compression

Where did you pick this "information" ???

> and better handling of uncompressable streams.

:-)

Well, my test:

[image]

in both FreeDOS and EDR-DOS, YES, the archive exists both in "C:\" and "." :-|

sorry to the person who compiled it but this binary is CRAP :crying:

oops, didn't test with CWSDPMI ;-)

> You can try http://perotti.ic.cz/p7zip/7za.exe

Who is the owner of this ? david ? Roberto perotti AKA Iw2evk ?

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Zyzzle

25.07.2010, 12:26

@ DOS386

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

Alright, I fixed my swap / memory error problems in 4.65 / 9.13 p7zip. The hint about CWSDPMI made me go check & I actually was running r5! A switch to r7 provided the fix, now I get all methods except -mx9 and md=64m to work in a 1 GB system. Of course I never run EMS memory, and the free XMS on this machine is ~850MB, and the files I was compressing were just under 100 MB total.

Now another unrelated mystery comes up, only to be seen on the DOS compiles of p7zip. When creating a simple Deflate .ZIP file, the normal PKWARE PKUNZIP utility refuses to extract the .ZIP archives because they have been 'tagged' as created on a UNIX system (0x03 identifier the .ZIP file header, when it *should be* 0x00 for true DOS! Manually modifying the headers make them extract fine)

So, the UNIX-y nature of the p7za compilations is somehow "embedded" in the ZIP files it creates. Is there any way short of a complete recompile to modify the 7za.exe binary to make it "know" that it is running on a true MS-DOS System? Somehow we must modify the HostOS flag in the binary, but WHERE is it located?

Rugxulo

Usono,
27.07.2010, 01:59

@ Zyzzle

fixing p7zip 4.65 to make .ZIP use DOS, not Unix, as host OS

Post reply

> Alright, I fixed my swap / memory error problems in 4.65 / 9.13 p7zip. The
> hint about CWSDPMI made me go check & I actually was running r5! A switch
> to r7 provided the fix, now I get all methods except -mx9 and md=64m to
> work in a 1 GB system. Of course I never run EMS memory, and the free XMS
> on this machine is ~850MB, and the files I was compressing were just under
> 100 MB total.

In other words, it should work but doesn't. Maybe DJGPP or p7zip is allocating extra RAM for just general use. I dunno. :-/

> Now another unrelated mystery comes up, only to be seen on the DOS compiles
> of p7zip. When creating a simple Deflate .ZIP file, the normal PKWARE
> PKUNZIP utility refuses to extract the .ZIP archives because they have been
> 'tagged' as created on a UNIX system (0x03 identifier the .ZIP file header,
> when it *should be* 0x00 for true DOS! Manually modifying the headers make
> them extract fine)

What version? That would be a bug on their end, IMHO. But obviously hacking every .ZIP created is less than ideal. And I guess suggesting you use a different unzipper (Info-Zip, djtar, Doszip, p7zip) is out too. However, I think BE has a good front-end to ZIP file viewing / hacking, if you're curious (even in DOS).

> So, the UNIX-y nature of the p7za compilations is somehow "embedded" in the
> ZIP files it creates. Is there any way short of a complete recompile to
> modify the 7za.exe binary to make it "know" that it is running on a true
> MS-DOS System? Somehow we must modify the HostOS flag in the binary, but
> WHERE is it located?

Impossible without exact same compiler setup or knowing intricately something which I don't (and GDB is a pain). So, long story short, yes, you'll probably have to recompile. Heck, I just did it (again) with p7zip 4.65, took approx. 12 mins. after making WATT-32 and using pre-built GNU pth 2.07 (/current/ only) on this lame P4 2.4 Ghz Celeron (128 MB RAM ftw!).

// inside \p7zip_4.65\CPP\7zip\Archive\Zip\ZipUpdate.cpp // line 33 #if defined(_WIN32) || defined(DJGPP) // was only #ifdef _WIN32 NFileHeader::NHostOS::kFAT; #else NFileHeader::NHostOS::kUnix; #endif

First I built without that patch (using G++ 4.4.4, DJDEV 2.04). Then I patched it. I confirmed it works via "unzip -Zlv". So this hopefully fixes it for you (although other formats, e.g. Gzip, I didn't mess with, but PKZIP doesn't handle that does it??)

fc /b old7za.exe 7za.exe Comparing files old7za.exe and 7ZA.EXE 0004C66B: 03 00 0004C679: 03 00

No guarantees (and I highly doubt it) that it matches your binary's offsets. But just FYI! If you really want, I'll upload a p7zip 4.65 build for you (is -mtune=i686 -Os okay or what would you prefer??). I could also (weakly) try again for 9.13 is you want. I can do all that later tonight.

But at the very least, this should let you (or someone) rebuild by themselves. Grab my 7zip465s.zip "stable" sources (still not on FreeDOS' iBiblio section, ugh, they never updated past 4.61 "beta").

DOS386

27.07.2010, 02:38

@ Rugxulo

fixing p7zip 4.65 to make .ZIP use DOS, not Unix, as host OS

Post reply

> Alright, I fixed my swap / memory error problems in 4.65 / 9.13 p7zip. The hint
> about CWSDPMI made me go check & I actually was running r5! A switch to
> r7 provided the fix, now I get all methods except -mx9 and md=64m to
> work in a 1 GB system.

heh, so it fails with HDPMI32 only ??? :confused:

> Now another unrelated mystery comes up, only to be seen on the DOS
> compiles of p7zip. When creating a simple Deflate .ZIP file, the normal
> PKWARE PKUNZIP utility refuses to extract the .ZIP archives because they
> have been 'tagged' as created on a UNIX system (0x03 identifier the .ZIP
> file header, when it *should be* 0x00 for true DOS! Manually modifying
> the headers make them extract fine)

So a ZIP brewed on Linux (since nobody does, they have TAR.GZ and TAR.BZ2 ;-) ) is supposed to REFUSE extraction on DOS ? This really sucks if true :-(

So, the UNIX-y nature of the p7za compilations is somehow "embedded" in the ZIP files it creates. Is there any way short of a complete recompile to modify the 7za.exe binary to make it "know" that it is running on a true MS-DOS System?

I use none of those 2 ;-)

> every .ZIP created is less than ideal. And I guess suggesting you use a
> different unzipper (Info-Zip, djtar, Doszip, p7zip) is out too.

So only PKUNZIP looks at this stupid "flag" ???

> However, I think BE has a good front-end to ZIP

To BE or not to BE ...

> #if defined(_WIN32) || defined(DJGPP) // was only #ifdef _WIN32
> NFileHeader::NHostOS::kFAT;
> #else
> NFileHeader::NHostOS::kUnix;
> #endif

Seems Mr. Katz missed something ...

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Zyzzle

27.07.2010, 03:40

@ Rugxulo

fixing p7zip 4.65 to make .ZIP use DOS, not Unix, as host OS

Post reply

> > // inside \p7zip_4.65\CPP\7zip\Archive\Zip\ZipUpdate.cpp > // line 33 > #if defined(_WIN32) || defined(DJGPP) // was only #ifdef _WIN32 > NFileHeader::NHostOS::kFAT; > #else > NFileHeader::NHostOS::kUnix; > #endif >
>
> First I built without that patch (using G++ 4.4.4, DJDEV 2.04). Then I
> patched it. I confirmed it works via "unzip -Zlv". So this hopefully fixes
> it for you (although other formats, e.g. Gzip, I didn't mess with, but
> PKZIP doesn't handle that does it??)
>
> > fc /b old7za.exe 7za.exe > > Comparing files old7za.exe and 7ZA.EXE > 0004C66B: 03 00 > 0004C679: 03 00 >
>
> No guarantees (and I highly doubt it) that it matches your binary's
> offsets. But just FYI! If you really want, I'll upload a p7zip 4.65 build
> for you (is -mtune=i686 -Os okay or what would you prefer??). I could also
> (weakly) try again for 9.13 is you want. I can do all that later tonight.
>
> But at the very least, this should let you (or someone) rebuild by
> themselves. Grab my
> 7zip465s.zip
> "stable" sources (still not on FreeDOS' iBiblio section, ugh, they never
> updated past 4.61 "beta").

The "extraction" problem only appears on PKWare's DOS versions of Pkunzip (2.04g and 2.50), and Win32 PKzipw 2.50. They both crap out on reading the 0x03 "UNIX" identifier in the header, and refuse to extract, saying "You need PKUNZIP Version 8.8 to extract". All other UNZIP utilities ignore the UNIX flag, and extract correctly. I should add that all the DOS versions of p7zip that I tried produced these "rogue" .ZIP headers -- even Michael Kostylev's 4.58 and 4.61.

The 4.65 I'm using is the one hosted at your site, Rugxulo! I think your patch posted above would work, but the 7ZA.EXE is UPX'd and decompressing it yields slightly different offsets than a fresh compile would! I would greatly appreciate if you'd upload the patched recompiled version. However, I think the -O2 and -mtunei686 flags bloat the compiled binary (mik's version of 4.61 is ~100k shorter in its UPX'd version than your build of 4.61. So, hopefully recompiling without those two flags will unbloat the generated binary somewhat! Thanks kindly for your help & troubleshooting expertise!

Incidently, the binary of mik's 4.61 hosted on your site 7za461mk.zip does not function AT ALL with -mx9 settings and using filters - give SIGSERV dump, but WILL work well with -mx7. This goes for any dictionary settings, so it seems to not be a memory problem, but a bug with how Kostylev implemented/built the filtering code into his compile.

DOS386

27.07.2010, 03:49

@ Zyzzle

fixing p7zip 4.65 to make .ZIP use DOS, not Unix, as host OS

Post reply

> The "extraction" problem only appears on PKWare's DOS versions of Pkunzip
> (2.04g and 2.50), and Win32 PKzipw 2.50. They both crap out on reading the
> 0x03 "UNIX" identifier in the header, and refuse to extract, saying "You
> need PKUNZIP Version 8.8 to extract". All other UNZIP utilities ignore the
> UNIX flag, and extract correctly.

The truth is out.

// inside \p7zip_4.65\CPP\7zip\Archive\Zip\ZipUpdate.cpp // line 33 #if defined(_WIN32) || defined(DJGPP) // was only #ifdef _WIN32 NFileHeader::NHostOS::kFAT; #else NFileHeader::NHostOS::kUnix; #endif

the fix:

// inside \p7zip_4.65\CPP\7zip\Archive\Zip\ZipUpdate.cpp // line 33 NFileHeader::NHostOS::kFAT; // Do NOT set "kLoonix" as it causes nothing but trouble !!! PKUNZIP for DOS and // Win32 refuse extract !!! 7-ZIP should be functionally equivalent on all host platforms !!!

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Zyzzle

27.07.2010, 07:23

@ Rugxulo

fixing p7zip 4.65 to make .ZIP use DOS, not Unix, as host OS

Post reply

> fc /b old7za.exe 7za.exe
>
> Comparing files old7za.exe and 7ZA.EXE
> 0004C66B: 03 00
> 0004C679: 03 00
> [/code]
>
> No guarantees (and I highly doubt it) that it matches your binary's
> offsets. But just FYI! If you really want, I'll upload a p7zip 4.65 build
> for you (is -mtune=i686 -Os okay or what would you prefer??). I could also
> (weakly) try again for 9.13 is you want. I can do all that later tonight.

FIXED!! At least, for me, no recompile was necessary based on the tip, I found the offending 0x03 bytes at offset 0x004c7a7 and 0x004c7cc in my P7ZIP.EXE binary. Saved the time of a recompile, Thanks!

Arjay

27.07.2010, 14:31

@ Zyzzle

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

> When creating a simple Deflate .ZIP file, the normal PKWARE
> PKUNZIP utility refuses to extract the .ZIP archives because they have been
> 'tagged' as created on a UNIX system (0x03 identifier the .ZIP file header,
> when it *should be* 0x00 for true DOS!
Sounds like you are using a version earlier than 2.50 which in its SHAREWARE incarnation was released as a SFX called PK250DOS.EXE

PKWARE appear to have now removed their own public download copy (which lived here: ftp://ftp.pkware.com/PK250DOS.EXE ) and I also noted that DOS as an option has also now been dropped off their contact sales page but as per this page it appears to still be available to buy/register.

> Manually modifying the headers make them extract fine)
I seem to remember seeing some tools in my BBS days to modify these fields.

david

27.07.2010, 08:10

@ Rugxulo

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

> Strange, it IS a DJGPP compile. I got errors when trying to make it myself.
> Somebody must've tweaked it on their end as the pre-made makefiles don't
> work.

You can compile 9.13 ver by machine.djgpp-watt > it works

it need hack in ../windows/FileDir.cpp !!

wcslen, wcscpy, wcscat "was not declared in this scope"

according to man wcslen > should add include <wchar.h> on linux machine!

here doesn`t work, so it is in DWORD in FileDir.cpp

and this is only one err! on my DJGPP env. Otherwise You can compile!

> 2.04 stub, so it has the 4 GB fixes. If it can't allocate memory, either
> you don't have enough, your memory manager is eating (or hiding) it, or you
> should use CWSDPMI (esp. latest r7) with swapping enabled.

Yes it is work better on my machine than r5 :-)

> At first I thought you meant HX + Win32's 7ZA, but apparently not. Sure,
> that way is great but lacks swapping (but much easier to upgrade). Default
> is -mx=5, which is normal compression. Anything higher uses more memory.
> You might have to use -ms=8m -m0d=8m to force it to only use 8 MB
> dictionary (or whatever).

7za now compress and add to archive, but I can`t open archive!
So hack on FileDir.cpp is needed!

I will try -mx=5 option ... my cmd was

7za a c:/p1/test.7z c:/p2/*.*

Thank You for help, I don`t use p7zip in command line
because of using FileRoller on Debian

david

27.07.2010, 14:34

@ Rugxulo

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

Post reply

http://perotti.ic.cz/p7zip/7za.exe is changed !

> > > Better use 4.65 :-)

I think that is 4.61 version, I can`t sources for 4.65

>
> Obviously he means 4.65 is the "stable" version, i.e. more reliable and
> bugfixed than 4.58 (see changelog).
>
this works for me,

can I compile with this p7zip next cdrtools?? to be everyone happy :-)

so If You can write me command line 7za for best performances!

David

david 22.07.2010, 07:48 @ Rugxulo	cdrtools_from_Schily Post reply
	> > P.S Any specific reason for the 7z (7-Zip) archive instead of a more > > common DOS world format? > > Better compression, what else? > It was compressed by 7zr 7-zip (A) 4.58 BETA on Debian Lenny!

david 22.07.2010, 07:52 @ Arjay	cdrtools_from_Schily Post reply
	> > inf2cdtext.pl ? > tracknames.pl ? > > or something else? > cdrx.pl originaly by Jason Dixon 2002, or burncenter or something else

Arjay

27.07.2010, 15:54

@ david

cdrtools_from_Schily

Post reply

> > or something else?
> >
> cdrx.pl originaly by Jason Dixon 2002, or burncenter or something
> else :-)

Additional background links for anyone interested in picking this request up:
CDRX.pl
burncenter
CPAN ports: DOS binaries
CPAN DOS tips & tricks

If I was going to pickup this request (which I'm not) then I'd probably port burncenter (or possibly just rewrite it). Burncenter is very readable and should be straight forward to port as it shouldn't need that many changes.

For anyone interested in picking up this request but who may be unfamiliar with Perl (I am), this is good short high level overview of a key Perl watch out.

The JaPH examples here help demo how unreadable some Perl is in comparison! Over to someone else to pickup.

Rugxulo

Usono,
27.07.2010, 16:46

@ Arjay

p7zip p7zip p7zip ...

Post reply

(I'm pretty much replying to everyone here):

> DOS386: heh, so it fails with HDPMI32 only ???

I doubt it, I didn't see him mention that. We'd all need better examples of what cmdline he used, what files, his system setup (free RAM), exact error message, DPMI host + version used, etc. It may be a bug in p7zip or maybe something on his end.

> DOS386: So only PKUNZIP looks at this stupid "flag" ???

Dunno. There are a lot of silly flags in there (binary or text? host OS? extract version? compressor version?) that may or may not be handled differently by different tools. Plus don't forget all the extra fields! Yeah, .ZIP's got a few "dark corners", as they say.

> DOS386: 7-ZIP should be functionally equivalent on all host platforms !!!

I agree ... almost. Sure, I think this is a PKUNZIP bug, but we don't know what other tools will do if they always see "made on FAT". A better solution (just in case!) would be a "feature request" that 7-Zip let you manually override such miscella at compression time. Or else somebody needs a good hack tool (e.g. BE, as mentioned, may work, but I haven't tested it recently).

> Zyzzle: The "extraction" problem only appears on PKWare's DOS versions
> of Pkunzip (2.04g and 2.50), and Win32 PKzipw 2.50.

In other words, very common but (admittedly) old versions. I have PKZIP 2.50 and never use it. I'm surprised this didn't bite anyone before. Honestly I never thought it would be an issue. But I'm very glad to know about it!

> Zyzzle: I should add that all the DOS versions of p7zip that I tried produced
> these "rogue" .ZIP headers -- even Michael Kostylev's 4.58 and 4.61.

Right, that's because p7zip is basically a big hack of a Win32 project to support *nix. And on top of that kludge was another kludge that somehow (mostly) worked in DOS. ;-) Needs better defines than just #ifdef _WIN32 obviously. (There are other problems, e.g. forward slashes, dots in filenames, reserved names [CON, AUX, PRN], that are only handled by default if _WIN32 is defined. However, p7zip is very annoying, kinda unwieldly, I blame C++ or too many defines or Unicode support or *nix code or my own incompetence or ....)

> Zyzzle: However, I think the -O2 and -mtunei686 flags bloat the compiled
> binary (mik's version of 4.61 is ~100k shorter in its UPX'd version
> than your build of 4.61. So, hopefully recompiling without those two
> flags will unbloat the generated binary somewhat!

No, I cannot figure out how to compile with FSU Pthreads. That's why his is smaller, it doesn't need GNU pth 2.07 or WATT-32. He never shared his patches, or nobody still has 'em, and I have no idea.

> Zyzzle: the binary of mik's 4.61 hosted on your site 7za461mk.zip does
> not function AT ALL with -mx9 settings and using filters - give
> SIGSERV dump, but WILL work well with -mx7.

I only kept it around for comparison, just in case somebody wanted to test against it. It does work on my 486 Sx (whereas other p7zip versions don't), but I think HX + (Win32) 7ZA.EXE does also. But I'm unable to rebuild it his way.

> Zyzzle: FIXED!! At least, for me, no recompile was necessary based on
> the tip, I found the offending 0x03 bytes at offset 0x004c7a7 and
> 0x004c7cc in my P7ZIP.EXE binary. Saved the time of a recompile.

Okay, so I won't bother uploading a new binary for you then. I mean, I could, but if you don't really want it, I won't. I'm torn between 1). not doing anything, 2). nagging FreeDOS again to upload 4.65 to iBiblio, 3). hacking 4.65 to work better (above patch plus similar fixes for other _WIN32 things we also need, e.g. reserved file names, default extensions), 4). ignoring 4.65 in lieu of 9.13 (which I'm still unable to compile fully). I spent a few hours today, but I neither understand C++ nor (unsurprisingly) like it very much. Frustrating.

> david: You can compile 9.13 ver by machine.djgpp-watt, it works.
> it need hack in ../windows/FileDir.cpp !!
> and this is only one err! on my DJGPP env. Otherwise You can compile!

How??? I can't seem to figure it out. Too many dumb defines, lots of Win32-specific crud hidden, too much Unicode bullcrap. Please post a patch if you have one.

> david: 7za now compress and add to archive, but I can`t open archive!
> 7za a c:/p1/test.7z c:/p2/*.*

Yes, I think it handles backslashes incorrectly or something similar. I don't know, it's a heavy *nix port originally from (ugly) Win32-centric land. There is no real maintainer for DJGPP p7zip, so it has a few bugs.

> david: http://perotti.ic.cz/p7zip/7za.exe is changed !
> I think that is 4.61 version, I can`t sources for 4.65

Okay, "sources" isn't a verb, sorry, no comprende! ;-)
You can get the 4.61 sources at iBiblio. 4.65 is on my site (see links above). Yes, I see you uploaded old "beta" (buggy) 4.61 there instead of 9.13, why?? Does it work better? Did you at least try 4.65??

> Arjay: PKWARE appear to have now removed their own public download copy
> (which lived here: ftp://ftp.pkware.com/PK250DOS.EXE ) and I also
> noted that DOS as an option has also now been dropped off their
> contact sales page but as per this page it appears to still be
> available to buy/register.

*sigh* I have no idea why some companies do the things they do. At one time 2.04g or 2.50 was free for personal use (or so I thought), but later (after Phil died) they stopped "sharing" the shareware version (go figure). And of course the DOS version is more expensive than others to register ... again, go figure. Their Win32 extractor is free. Anyways, PKZIP 2.50 is mostly unnecessary unless you like ye olde "reduce" method (which Info-Zip avoids for "copyright reasons" [eh???]).

I guess I could rhetorically wonder why anybody bothers with .ZIP when .7Z is so superior, but I like .ZIP too! It is indeed universal (although 7-Zip/.xz/lzip/LZMA has gained a lot of traction lately, see latest FreeBSD for example).

Arjay

27.07.2010, 18:09

@ Rugxulo

p7zip p7zip p7zip ...

Post reply

> Dunno. There are a lot of silly flags in there (binary or text? host OS?
Well having used ZIP across multiple platforms I know those flags aren't silly, the problem with PKunzip is it's erring too much on the side of safety.
This may not matter to most people but when your dealing with $$$$'s worth of data moving around; having "extra" validation like this is can be very useful.

> I agree ... almost. Sure, I think this is a PKUNZIP bug,
As above NOT a bug just extra validation required by some end users.

> I'm surprised this didn't bite anyone before.
It has, me - when I was doing a lot of work to move data across platforms.

> *sigh* I have no idea why some companies do the things they do.
The people who knew about them retire/move on. Bottom line: support costs.

> At one time
> 2.04g or 2.50 was free for personal use (or so I thought),
No, not as far as I remember from when I started with the BETA versions (moving over from PKARC). The only exception was BBS SYSOP's who were granted a free license to use PK shareware as we were distributing it. We could fill in a form to receive a AV version but to be honest I never bothered at the time I ran my BBS's - but regretted later when I had to pay!

> but later (after
> Phil died) they stopped "sharing" the shareware version (go figure).
Thom Henderson's comments make interesting reading.

> And of course the DOS version is more expensive than others to register ...
Well you get the AV signature option. However even around 10 years ago PKWare were already struggling trying to track down the person who knew how to build a registered DOS version; as several DOS experts had all moved on.
Note: Apart from leaving sometimes moving on might be to move into management.

> again, go figure.
Basically to them DOS support costs are higher as the usage is less. As time progresses current knowledge/familiarity with an older technology becomes less thus costs go up trying to support that technology. For example imagine trying to recruit and train a fresh graduate to support a DOS system now.

> PKZIP 2.50 is mostly unnecessary
It can be useful if you are dealing with other PK tools on multiple platforms.

> unless you like ye olde "reduce" method (which Info-Zip avoids
> for "copyright reasons" [eh???]).
And for that reason as well :)

> I guess I could rhetorically wonder why anybody bothers with .ZIP when .7Z
> is so superior, but I like .ZIP too!
Well to be honest I am NOT planning to release anything in the .7Z or .RAR formats for DOS. Why? Well in my book like AMIS these things came about "after" things had already moved on. Thus from a standards and compatibility aspect IMHO .ZIP is still a good choice to make software accessible to all in a format that is widely understood. Yes, I agree RAR and .7Z are excellent but the problem is the majority of people even in the days when DOS was popular were already widely using .ZIP which remains common to this day. However note if I release something for Linux I would use gzip.

> It is indeed universal
> (although 7-Zip/.xz/lzip/LZMA has gained a lot of traction lately,
> see latest FreeBSD for example).
Thanks. I'll remember this if and when I release anything for FreeBSD :)

Rugxulo

Usono,
28.07.2010, 02:28

@ Arjay

p7zip p7zip p7zip ...

Post reply

> > I agree ... almost. Sure, I think this is a PKUNZIP bug,
> As above NOT a bug just extra validation required by some end users.

Then it should ask if you want to ignore and proceed anyways.

> > *sigh* I have no idea why some companies do the things they do.
> The people who knew about them retire/move on. Bottom line: support
> costs.

I heavily doubt they "support" it at all. In fact, I'm pretty sure they don't. I've noticed other companies charging more for DOS tools also. Strange that a "dead, useless" OS is so lucrative. ;-)

> Yes, I agree RAR and .7Z are excellent but the the majority of people
> even in the days when DOS was popular were already widely using .ZIP which
> remains common to this day. However note if I release something for Linux
> I would use gzip.

Jim Leonard loved RAR for a while (probably still does), esp. old 16-bit version (3.50 ??). RAR is good and still supported, but I've never used it. At least UNRAR exists (which, dare I say it, should be a prerequisite for any new formats ... must be able to unpack!).

Don't use .gz just because of Linux. Or if you do, use 7-Zip's improved Deflate (directly or via AdvanceComp's advdef), it gets better results. ;-)
Besides, at least official "GNU" gzip can handle a .tar.zip file if it's renamed to .gz. And most (all?) Linux / *BSD distros support bzip2, which is superior compression. The Elvis text editor dude hacked up a portable, "public domain" UNTAR.C program that will unpack .tar or .gz, which is cool. *BSD tar uses its own gzip.

But anyways, yes, *nix doesn't usually include Info-Zip, which is annoying. (It really shouldn't be hard to make a small tool to convert a file from inside a .ZIP <-> .GZ, and I've honestly been wanting to write one for some time. Bah, too lazy.)

Arjay

28.07.2010, 08:02

@ Rugxulo

p7zip p7zip p7zip ...

Post reply

> I heavily doubt they "support" it at all.
I suspect that they will happily do support it but for large organizations with a/c managers who sometimes need to pay for extended life cycles.

> I've noticed other companies charging more for DOS tools also.
Demand and supply

> Strange that a "dead, useless" OS is so lucrative. ;-)
Same is true of other "legacy" (current) systems such as MVS, VMS etc.

> Jim Leonard loved RAR for a while (probably still does),
Interesting, Jim may still be using for his own stuff 2008 but in all the last 10 years or so all of his releases have always been in ZIP, e.g. [links=http://www.oldskool.org/pc/MONOTONE]MONOTONE[/link] (2009).

> At least UNRAR exists (which, dare I say it, should be a prerequisite for
> any new formats ... must be able to unpack!).
Indeed.

> Don't use .gz just because of Linux. Or if you do, use 7-Zip's improved
> Deflate (directly or via AdvanceComp's advdef), it gets better results.
> ;-)
Ok, ok! If and when I release some of my nix stuff I'll release in several formats. e.g. I been thinking of open sourcing a very large Perl unix project

> *BSD tar uses its own gzip.
fyi, I know gzip has also been ported to games consoles by games developers.

DOS386

28.07.2010, 03:23

@ Arjay

p7zip pp7zipp ppp7zippp ... stupidity goes on

Post reply

> > I agree ... almost. Sure, I think this is a PKUNZIP bug
> As above NOT a bug just extra validation required by some end users

Heh ??? Failure to extract is a feature ??? :confused: Or do you expect your PKUNZIP to "protect" you from "LF-only" Linux texts this way ???

> as several DOS experts had all moved on

They f***ed off. Where ? To DOG-BOX , DOG-EMU & Co :-(

> Well to be honest I am NOT planning to release anything in the .7Z or
> .RAR formats for DOS. Why?

Pure inertia :clap:

> Thus from a standards and compatibility aspect IMHO .ZIP is still a good
> choice to make software accessible to all in a format that is widely understood.

Especially "good" choice if you fill your ZIP with NTLFN crap :clap:

> agree RAR and .7Z are excellent but the problem is

that RAR is proprietary.

> the majority of people even in the days when DOS was popular were
> already widely using .ZIP which remains common to this day.

Because ARC had got assassinated before :clap:

> However note if I release something for Linux I would use gzip.

:clap:

FYI, my releases are either TAR inside ZIP (8086-compatible) or TAR inside 7-ZIP. If someone can't extract it, it's his fault, not mine :-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Arjay

28.07.2010, 08:07

@ DOS386

p7zip pp7zipp ppp7zippp ... stupidity goes on

Post reply

> > > I agree ... almost. Sure, I think this is a PKUNZIP bug
> > As above NOT a bug just extra validation required by some end users
>
> Heh ??? Failure to extract is a feature ??? :confused: Or do you expect
> your PKUNZIP to "protect" you from "LF-only" Linux texts this way ???
>
> Especially "good" choice if you fill your ZIP with NTLFN crap :clap:

Note: when I said cross platform I was also referring to EBCDIC based systems etc, rather than DOS/NT based systems which many are only familiar with.

> Because ARC had got assassinated before :clap:
correct.

> FYI, my releases are either TAR inside ZIP (8086-compatible) or TAR
> inside 7-ZIP. If someone can't extract it, it's his fault, not mine :-)
lol

Rugxulo

Usono,
28.07.2010, 21:27

@ Arjay

.ARC compression format

Post reply

> > Because ARC had got assassinated before :clap:
> correct.

Here's what I know (from reading about it):

Originally IBM PCs were heavily underpowered. But the popular methods to compress stuff (on the non-*nix side) were .LBR ("library", uncompressed archive like tar) and .Q ("squeeze", single-file compressor like gzip). Hence if you look hard enough you'll find .LQR (.LBR + .?Q?) files.

When ARC came around, it was both in one util. It was better compression too (I think??), using LZW (probably inspired from Welch's 1984? Byte magazine article, which neglected to mention patent issues). Well, some people say it crashed occasionally. (I think latest was 6.0 or 7.0, can't rememeber. Sac.sk still has some recent-ish version.) So a fair amount of people used it.

Thom explicitly said (at least later) that ARC was free for personal use. He was a small company, so he had the source open for anyone to port to non-DOS OSes. It was only DOS, commercially, that he wanted to protect. Phil Katz, out of principle, probably thought he shouldn't have to license it. He fought it to court and lost (I think). His main claim to fame was speeding it up with some assembly (PKARC). After that, he made PKPAK and later PKZIP (new format).

Only in PKZIP 0.90 beta (?? or 2.0 ??) did Deflate get supported. Apparently, he dedicated the "new" .ZIP format to the public domain, and he was always open to the Info-Zip group creating their own portable .ZIP rewrite. Most of the later .ZIP enhancements came after he died from PKWARE Inc. and competitor WinZIP (e.g. competing encryption methods, Bzip2 or PPMD or LZMA methods, Zip64, see latest AppNote).

P.S. Note that there is DEARC (written in Turbo Pascal) that will unpack .ARC files, even Katz's "Squash"'d files. (There's also an unpacker in Forth somewhere, but I never tried too hard to get it working.) Vernon Buerg (sadly recently deceased, according to Eric Auer) wrote ARCE, which is a very tiny tool that many enjoyed over the years too.

P.P.S. Bah, I could point to links for a lot of these, but I guess nobody cares or else you can figure it out yourselves. ;-)

DOS386

29.07.2010, 05:56
(edited by DOS386, 29.07.2010, 06:07)

@ Arjay

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

Post reply

> If and when I release some of my nix stuff I'll release in several formats

Absurd. :confused: New formats being invented to save space, and what do some people do ? They release in both new and obsolete format, wasting more space than the obsolete format alone would. You know, there is no bloat

> I wonder why mik isn't active anymore in this forum.

He never was.

> He was an exceptional programmer and I absolutely loved
> his other DOS ports (MPLAYER, etc) which have gone missing since 2008.

Right, but ask Khusraw - he is Mik's spokesperson :hungry:

> PKUNZJR (4 kb .COM) is still probably the smallest unpacker, but it
> doesn't support directories. Lucho hacked it to support it (TUNZ)

So you say TUNZ is not original work ??? :-(

> but he never provided sources either. However, in fairness, there are
> a lot more third-party "inflaters" these days that would probably be a
> good starting point (e.g. zlib's puff) if anybody ever wanted to re-implement it.

All C, all bloated and messy.

[image]

Does the 9.13 p-DGJPP port really work for someone ???

For me NOT. Both HDPMI32 (disable DPMI 1.0 hack doesn't help either) and CWSDPMI, both FreeDOS and EDR-DOS, both brew and extract (see shot).

(see post below)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

29.07.2010, 05:58
(edited by DOS386, 29.07.2010, 06:10)

@ DOS386

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

Post reply

UI21DEB 2009-05-02 CFG: sel=<> hcb=$0400 ver=$3205 dcm=$02FB fif=$0000 APP: ree=1 psp=$2208 nam=<IP7X913> N/A * AX=$3000 | C=0 AX=$0A07 * AX=$3D00 <E:\IP7X913.EXE> | C=0 AX=$0005 * AX=$4200 Seek: orig=0 dist=$0800 | C=0 AX=$0800 * AX=$3C00 <c:\cwsdpmi.swp> | C=0 AX=$0006 ; SWAP CRAP, and lowercase * AX=$3603 GetDFSObsolete [C] DL=$0003 | C=0 AX=$0010 BX=$9331 CX=$0200 DX=$F9E2 * AX=$4200 Seek: orig=0 dist=$1800 | C=0 AX=$1800 * AX=$4200 Seek: orig=0 dist=$0015'6400 | C=0 AX=$6400 * AX=$3000 | C=0 AX=$0A07 ; NO NTVDM, sorry * AX=$3306 | C=0 AX=$3306 BX=$0A07 ; NO NTVDM, sorry * AX=$71A0 <E:\> | C=1 AX=$7100 ; NO NTLFN, sorry * AX=$71A0 <E:\> | C=1 AX=$7100 ; NO NTLFN, why ask again, stupid guy * AX=$4300 <x> | C=1 AX=$0002 ; This was the command "extract", it does NOT have file attributes, stupid guy * AX=$71A0 <E:\> | C=1 AX=$7100 ; NO NTLFN, why ask again, stupid guy * AX=$4300 <NTOS.ZIP> | C=0 AX=$4300 ; Found him * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % This "path" * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % is that obviously * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % INVALID that there * AX=$6C00 </etc/localtime> | C=1 AX=$0003 ; % would be no * AX=$4300 </etc/localtime> | C=1 AX=$0003 ; % reason to access * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % it one time, * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % and even less * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % incredible * AX=$4300 </etc/localtime> | C=1 AX=$0003 ; % 9 times !!! * AX=$71A0 <E:\> | C=1 AX=$7100 ; NO NTLFN, why ask again, stupid guy * AX=$4E83 </etc/localtime> | C=1 AX=$0003 ; Not enough stupidity ??? * AX=$4E00 <./GMT> | C=1 AX=$0012 ; Another invalid request ??? * AX=$4E00 <.> | C=1 AX=$0012 ; NOT FOUND ... but what were you searching for at all ??? * AX=$4E00 <./GMT> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$6C00 <./GMT> | C=1 AX=$0002 ; Recidivity goes on ... * AX=$4300 <./GMT> | C=1 AX=$0002 ; Recidivity goes on ... * AX=$4E00 <./GMT> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <.> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <./GMT> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4300 <./GMT> | C=1 AX=$0002 ; Recidivity goes on ... * AX=$71A0 <E:\> | C=1 AX=$7100 ; Recidivity goes on ... * AX=$4700 [E] DL=$0005 | C=0 AX=$0100 ; Useful ??? * AX=$4E03 <./GMT> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <.> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <.> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$71A0 <E:\> | C=1 AX=$7100 ; Recidivity goes on ... * AX=$4700 [E] DL=$0005 | C=0 AX=$0100 ; Why the same request again ??? * AX=$4E00 <e:/> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <e:> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4300 <e:/> | C=0 AX=$4300 ; Dummy call ... what did you except ??? * AX=$4E12 <e:/*.*> | C=0 AX=$0000 ; Bugger * AX=$4E12 <e:/*.*> | C=0 AX=$0000 ; Bugger * AX=$4EB3 <e:/*.*> | C=0 AX=$0000 ; Bugger * AX=$5008 SetPSP | C=0 AX=$5008 * AX=$5008 SetPSP | C=0 AX=$5008 * AX=$4108 <c:\cwsdpmi.swp> | C=0 AX=$4108 ; Kick empty file, WtF ??? * AX=$4C02 PANIC !!! (just exit) | NO RETURN APP: ree=1 psp=$2208 nam=<IP7X913> N/A * AX=$3000 | C=0 AX=$0A07 * AX=$3D00 <E:\IP7X913.EXE> | C=0 AX=$0005 * AX=$4200 Seek: orig=0 dist=$0800 | C=0 AX=$0800 * AX=$3C00 <c:\cwsdpmi.swp> | C=0 AX=$0006 ; SWAP CRAP, and lowercase * AX=$3603 GetDFSObsolete [C] DL=$0003 | C=0 AX=$0010 BX=$9331 CX=$0200 DX=$F9E2 * AX=$4200 Seek: orig=0 dist=$1800 | C=0 AX=$1800 * AX=$4200 Seek: orig=0 dist=$0015'6400 | C=0 AX=$6400 * AX=$3000 | C=0 AX=$0A07 ; NO NTVDM, sorry * AX=$3306 | C=0 AX=$3306 BX=$0A07 ; NO NTVDM, sorry * AX=$71A0 <E:\> | C=1 AX=$7100 ; NO NTLFN, sorry * AX=$71A0 <E:\> | C=1 AX=$7100 ; NO NTLFN, why ask again, stupid guy * AX=$4300 <a> | C=1 AX=$0002 ; This was the "add" command , it does NOT have file attributes, stupid guy * AX=$71A0 <E:\> | C=1 AX=$7100 ; NO NTLFN, why ask again, stupid guy * AX=$4300 <-tzip> | C=1 AX=$0002 ; This was the "type ZIP" switch , it does NOT have file attributes, stupid guy * AX=$71A0 <E:\> | C=1 AX=$7100 ; NO NTLFN, why ask again, stupid guy * AX=$4300 <NTOS13.ZIP> | C=1 AX=$0002 ; Brew new ZIP archive * AX=$71A0 <E:\> | C=1 AX=$7100 ; NO NTLFN, why ask again, stupid guy * AX=$4300 <NTOS.EXE> | C=0 AX=$4300 ; Found him * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % This "path" * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % is that obviously * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % INVALID that there * AX=$6C00 </etc/localtime> | C=1 AX=$0003 ; % would be no * AX=$4300 </etc/localtime> | C=1 AX=$0003 ; % reason to access * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % it one time, * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % and even less * AX=$4E00 </etc/localtime> | C=1 AX=$0003 ; % incredible * AX=$4300 </etc/localtime> | C=1 AX=$0003 ; % 9 times !!! * AX=$71A0 <E:\> | C=1 AX=$7100 ; NO NTLFN, why ask again, stupid guy * AX=$4E28 </etc/localtime> | C=1 AX=$0003 ; Not enough stupidity ??? * AX=$4E00 <./GMT> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <.> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <./GMT> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$6C00 <./GMT> | C=1 AX=$0002 ; Recidivity goes on ... * AX=$4300 <./GMT> | C=1 AX=$0002 ; Recidivity goes on ... * AX=$4E00 <./GMT> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <.> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <./GMT> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4300 <./GMT> | C=1 AX=$0002 ; Recidivity goes on ... * AX=$71A0 <E:\> | C=1 AX=$7100 ; Recidivity goes on ... * AX=$4700 [E] DL=$0005 | C=0 AX=$0100 ; Useful ??? * AX=$4E03 <./GMT> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <.> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <.> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$71A0 <E:\> | C=1 AX=$7100 ; Recidivity goes on ... * AX=$4700 [E] DL=$0005 | C=0 AX=$0100 ; Why the same request again ??? * AX=$4E00 <e:/> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <e:> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4300 <e:/> | C=0 AX=$4300 ; Dummy call ... what did you except ??? * AX=$4E12 <e:/*.*> | C=0 AX=$0000 ; Bugger * AX=$4E12 <e:/*.*> | C=0 AX=$0000 ; Bugger * AX=$4EB3 <e:/*.*> | C=0 AX=$0000 ; Bugger * AX=$4E00 <.> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <.> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$71A0 <E:\> | C=1 AX=$7100 ; Still no NTLFN support, surprised ??? * AX=$4700 [E] DL=$0005 | C=0 AX=$0100 ; Why the same request again ??? * AX=$4E00 <e:/> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4E00 <e:> | C=1 AX=$0012 ; Recidivity goes on ... * AX=$4300 <e:/> | C=0 AX=$4300 ; Recidivity goes on ... * AX=$4E38 <e:/*.*> | C=0 AX=$0000 ; Bugger * AX=$4E38 <e:/*.*> | C=0 AX=$0000 ; Bugger * AX=$4EAF <e:/*.*> | C=0 AX=$0000 ; Bugger * AX=$4E00 <NTOS13.ZIP> | C=1 AX=$0012 ; The file still doesn't exist so it's safe to create it * AX=$4E00 <NTOS13.ZIP> | C=1 AX=$0012 ; Forgot result again ??? * AX=$71A0 <E:\> | C=1 AX=$7100 ; The hope never dies, you know, there still is hope for NTLFN * AX=$4700 [E] DL=$0005 | C=0 AX=$0100 ; You did this already 3 times moron * AX=$3000 | C=0 AX=$0A07 ; We already know that there is no NTVDM, so what * AX=$3306 | C=0 AX=$3306 BX=$0A07 ; And again the same answer: NO NTVDM !!! * AX=$7303 GetDFSEx <e:/ntos13.zip> | C=0 AX=$7303 ; This is INVALID again, ; there is no free space ; per file in DOS * AX=$6000 <NTOS13.ZIP> | C=0 AX=$0000 ; Heh * AX=$4E00 <e:/ntos13.zip> | C=1 AX=$0012 ; Didn't we already know that we ; we can create it ??? Besides of ; this, the name was UPPERCASE on ; commandline, so why do you ; NTLFN-ize it ??? F**K it !!! * AX=$4E12 <e:/ntos13.zip> | C=0 AX=$0000 ; ??? FreeDOS BUG ??? * AX=$4E00 <NTOS13.ZIP> | C=1 AX=$0012 ; Nope ... * AX=$4E00 <NTOS13.ZIP> | C=1 AX=$0012 ; Nope ... * AX=$71A0 <E:\> | C=1 AX=$7100 ; NO NTLFN !!! * AX=$4700 [E] DL=$0005 | C=0 AX=$0100 ; Again ... * AX=$6000 <NTOS13.ZIP> | C=0 AX=$0000 ; Again ... * AX=$4E00 <e:/ntos13.zip> | C=1 AX=$0012 ; See above ??? * AX=$4E12 <e:/ntos13.zip> | C=0 AX=$0000 ; See above ??? * AX=$4E00 <NTOS13.ZIP> | C=1 AX=$0012 ; Nope ... * AX=$4E00 <NTOS13.ZIP> | C=1 AX=$0012 ; Nope ... * AX=$4E00 <NTOS13.ZIP> | C=1 AX=$0012 ; Nope ... * AX=$4300 <NTOS13.ZIP> | C=1 AX=$0002 ; Nope ... * AX=$6C00 <NTOS13.ZIP> | C=0 AX=$0005 ; YOU brewed it finally !!! * AX=$6000 <NTOS13.ZIP> | C=0 AX=$0000 ; Why this ??? * AX=$4200 Seek: orig=0 dist=0 | C=0 AX=$0000 * AX=$5008 SetPSP | C=0 AX=$5008 * AX=$5008 SetPSP | C=0 AX=$5008 * AX=$4108 <c:\cwsdpmi.swp> | C=0 AX=$4108 ; Kick empty file, WtF ??? * AX=$4C01 PANIC !!! (just exit) | NO RETURN

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386

29.07.2010, 06:05
(edited by DOS386, 29.07.2010, 06:18)

@ DOS386

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

Post reply

(split it since this forum has a 10'000 Byte's per post limit ???)

OK, we see the well known DGJPP garbage IO activity.

Anyone has access to DGJPP BUGzilla or maintainers so this can get finally reported or is this maybe already Closed: INVALID ???

There is DGJPP garbage I/O but maybe also a FreeDOS BUG. On FreeDOS it hangs (see shot) leaving an empty file (ZERO Byte's), on EDR-DOS it brews an empty ZIP (22 Byte's).

I wonder how those who got it "working" actually did. Loaded DOGNTLFN TSR ??? I didn't. Used NTVDM (hint: CWSDPMI is ignored inside NTVDM ;-) ) ??? I did't. Used genuine MS-DOG ? I didn't. Got a better PC ??? Yeah ... mine is CRAP :crying:

The "worm" (one of many worm's ...) is here:

* AX=$4E00 <e:/ntos13.zip> | C=1 AX=$0012
* AX=$4E12 <e:/ntos13.zip> | C=0 AX=$0000 ; ??? FreeDOS BUG ???

The lower call pretends success, while it should fail (in EDR-DOS it does fail too). FreeDOS getting confused by the $12 in AL ??? (Error code from above !!!).

Anyone knows what the AL in "SFN FIFI" (AH=$4E) should do ???

http://www.ctyme.com/intr/rb-2977.htm

> AH = 4Eh
> AL = special flag for use by APPEND (refer to note below)

:confused:

In any case, there is a feature request for UI21DEB: improve "SFN FIFI" and "SFN FINE" :hungry:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo

Usono,
29.07.2010, 08:37

@ DOS386

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

Post reply

> OK, we see the well known DGJPP garbage IO activity.
>
> Anyone has access to DGJPP BUGzilla or maintainers so this can get
> finally reported or is this maybe already Closed: INVALID ???

Report it on comp.os.msdos.djgpp , but also be aware that DJGPP is seriously low on maintainers. (And p7zip for DOS has absolutely none, and I haven't tested 9.13 nor been able to successfully compile it either.)

> There is DGJPP garbage I/O but maybe also a FreeDOS BUG. On FreeDOS it
> hangs (see shot) leaving an empty file (ZERO Byte's), on EDR-DOS it brews
> an empty ZIP (22 Byte's).

Report the bug to Eric Auer and/or Bart Oldemann or maybe even Pat Villani himself. I don't know of anyone else who would care, know how, or have access rights to the kernel tree. (I'm told that Pat is swamped with work and Jim even got promoted/moved recently. Haven't been in contact with Eric as much since he moved to NL a year or two ago, but he did cc me and Misha recently. BTW, in case it isn't obvious, I am not a kernel hacker, don't have write access, nor for DJGPP either, just FYI.)

DOS386

31.07.2010, 07:53

@ DOS386

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

Post reply

Also the binary crashes on Pentium 1 SIGSILLY (or similar), regrettably DGJPP thinks to be smart by catching exceptions preventing HDPMI32 to brew a useful crash report (most likely CMOVNTQ, heh ...).

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Khusraw

Bucharest, Romania,
29.07.2010, 09:21

@ DOS386

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

Post reply

> > He was an exceptional programmer and I absolutely loved
> > his other DOS ports (MPLAYER, etc) which have gone missing since 2008.
>
> Right, but ask Khusraw - he is Mik's spokesperson :hungry:

This is another nonsense you wrote here. I don't see how the fact that I shared with you the information "Mik" provided during a couple of e-mail exchanges makes me his "spokesperson", as you inadvertently said. On the other hand "Mik"'s e-mail address is public and anyone interested in his ports can contact him without problems. But he prefers to reply on "technical" issues, and the "dummies" (as he called them) who annoyed him shouldn't expect any answer I think. By the way, AFAIK "Mik" is still active, but calling him "an exceptional programmer" is an exaggeration, he has just very good knowledge on GNU tools, better than anyone's in this forum.

---
Glory to God for all things

Zyzzle

28.07.2010, 08:22

@ Rugxulo

p7zip p7zip p7zip ...

Post reply

> Okay, so I won't bother uploading a new binary for you then. I mean, I
> could, but if you don't really want it, I won't. I'm torn between 1). not
> doing anything, 2). nagging FreeDOS again to upload 4.65 to iBiblio, 3).
> hacking 4.65 to work better (above patch plus similar fixes for other
> _WIN32 things we also need, e.g. reserved file names, default extensions),
> 4). ignoring 4.65 in lieu of 9.13 (which I'm still unable to compile
> fully). I spent a few hours today, but I neither understand C++ nor
> (unsurprisingly) like it very much. Frustrating.
>

Understood. I thought mik's version of 4.61 was built with pthreads, it sure reduces the bloat. If you are able to get a leaner compile of 4.65 with the mentioned patches and / or less bloat, it would come much appreciated to all. I wonder why mik isn't active anymore in this forum. He was an exceptional programmer and I absolutely loved his other DOS ports (MPLAYER, etc) which have gone missing since 2008.

david,
I can't get your binary of 9.13 working with the Delta (.wav) filter, or xz file types. Am I doing something wrong, using commandline 7za -mx5 -m0=Delta:4 -md=32m I get an "Unknown Error" returned.

The "bug" in PKWAre's DOS utilities is unforgivable, at least there is no way to over-ride it. I often use the 16-bit PKUNZIP because it is tiny, and fast. I had ZIPed many smaller files with 7ZIP's -mx9 option, only to find once I transfered the files, that they wouldn't decompress with PKUNZIP, nor is there any program that I know which will regenerate PKZIP headers... So I'm probably stuck with manually recompressing all those small .ZIP files with my patched version of 4.65

Rugxulo

Usono,
28.07.2010, 21:14

@ Zyzzle

p7zip p7zip p7zip ...

Post reply

> Understood. I thought mik's version of 4.61 was built with pthreads, it
> sure reduces the bloat.

FSU pthreads is stand-alone, but hasn't been updated since 2000 (and hasn't worked in DJGPP out-of-the-box since mid-90s). Unlike GNU pth, it doesn't need a socket lib (e.g. libsocket or WATT-32). Older versions of p7zip worked with Dawe's libsocket, which was smaller, but later versions only seemed to work with WATT-32. C/C++ are a pain, and I'm no guru in them, hence I have (so far, in limited attempts) been unable to recompile either FSU pthreads or GNU pth for DJGPP.

> If you are able to get a leaner compile of 4.65
> with the mentioned patches and / or less bloat, it would come much
> appreciated to all.

Yes, of course. However, I feel the ghost of marcov asking why it matters. ;-) But yes, p7zip is a bloated bastard (but much less so than GNU Emacs, heh).

> I wonder why mik isn't active anymore in this forum. He
> was an exceptional programmer and I absolutely loved his other DOS ports
> (MPLAYER, etc) which have gone missing since 2008.

Dunno, apparently some n00bs inadvertently annoyed him (according to Khusraw). Either that or he was never interested in sharing much anyways.

> david,
> I can't get your binary of 9.13 working with the Delta (.wav) filter, or xz
> file types. Am I doing something wrong, using commandline 7za -mx5
> -m0=Delta:4 -md=32m I get an "Unknown Error" returned.

I'm going to have to try again to get 9.13 to compile, but all those stupid overrides (LPCSTR, TCHAR) are very confusing. Stupid Unicode. ;-)

> The "bug" in PKWAre's DOS utilities is unforgivable, at least there is no
> way to over-ride it. I often use the 16-bit PKUNZIP because it is tiny, and
> fast.

PKUNZJR (4 kb .COM) is still probably the smallest unpacker, but it doesn't support directories. Lucho hacked it to support it (TUNZ), but he never provided sources either. However, in fairness, there are a lot more third-party "inflaters" these days that would probably be a good starting point (e.g. zlib's puff) if anybody ever wanted to re-implement it.

> I had ZIPed many smaller files with 7ZIP's -mx9 option, only to find
> once I transfered the files, that they wouldn't decompress with PKUNZIP,
> nor is there any program that I know which will regenerate PKZIP headers...
> So I'm probably stuck with manually recompressing all those small .ZIP
> files with my patched version of 4.65

No, remember I mentioned BE ("binary editor"), you should try that since it has a ZIP viewer add-on mode. At worst, somebody (me? Arjay?) could hack up a quick fix util for you. ;-)

Arjay

01.08.2010, 12:05

@ Rugxulo

p7zip p7zip p7zip ...

Post reply

> No, remember I mentioned BE ("binary editor"), you should try that since it
> has a ZIP viewer add-on mode.

As mentioned earlier I do vaguely remember seeing a low level ZIP editing DOS util which would allow editing of these types of fields. As I use to use a lot of ZIP/BBS utils that were hosted on Simtel, I did a quick check though via Jason's copy here: http://cd.textfiles.com/simtel/

Couldn't spot anything (on a quick look) but would suggest that anyone needing such a util has a good look through fileutil, sysutil, archive util, bbs util on the above. Thank you Jason for providing that good online archive.

> At worst, somebody (me? Arjay?) could hack up a quick fix util for you. ;-)
:) Thanks but I am trying to *reduce* my todo list and get some more free DOS stuff out the door (carefully balanced against life/other stuff as is always the way). So sorry, no plans to even re-investigate my old work in this area.

PKWare have moved things around since last time I referenced/coded for the ZIP format but I have confirmed that they still have the ZIP application note (file structure) available online here:
http://www.pkware.com/documents/casestudies/APPNOTE.TXT

cdrtools_from_Schily (Announce)

cdrtools_from_Schily

cdrtools_from_Schily

cdrtools_from_Schily

cdrtools_from_Schily

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

fixing p7zip 4.65 to make .ZIP use DOS, not Unix, as host OS

fixing p7zip 4.65 to make .ZIP use DOS, not Unix, as host OS

fixing p7zip 4.65 to make .ZIP use DOS, not Unix, as host OS

fixing p7zip 4.65 to make .ZIP use DOS, not Unix, as host OS

fixing p7zip 4.65 to make .ZIP use DOS, not Unix, as host OS

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily | NTLFN problem of 7-ZIP | 7-ZIP vs ZIP

cdrtools_from_Schily

cdrtools_from_Schily

cdrtools_from_Schily

p7zip p7zip p7zip ...

p7zip p7zip p7zip ...

p7zip p7zip p7zip ...

p7zip p7zip p7zip ...

p7zip pp7zipp ppp7zippp ... stupidity goes on

p7zip pp7zipp ppp7zippp ... stupidity goes on

.ARC compression format

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

p7zip pp7zipp ppp7zippp ... stupidity goes on | UI21DEB used

p7zip p7zip p7zip ...

p7zip p7zip p7zip ...

p7zip p7zip p7zip ...