zyzzle wrote on 2025-01-12, 05:17:

Why didn't you make it possible ... just like in every other version of 7zip I've ever used?

You're a complainer, and you didn't provide enough information to fix anything, which makes you a time waster.

Open a bug report at Github with enough detail to reproduce the problem.

7-Zip is complex enough that it expresses bugs in the OWC toolchain and runtime for DOS.

Thanks for making this available. Tried 7zm.exe on my lowest 386 I have (386SX 25Mhz/4Mb). First time I tried it I interrupted the creation of a zip file (supplied the wrong parameters). Rerunning it with the right parameters after that somehow hung my pc. After a reboot I tried it again but creating a zip file takes at least 10 times more time then with pkzip. I used the default setting for both and it seems to use the same compression as the zip files were almost identical in size.

My test case was zipping a Norton Commander directory btw. Didn't measure it exactly but it was around 2 minutes with pkzip and I think 20 minutes for 7zm.exe.

Yoghoo wrote on 2025-01-12, 20:22:

My test case was zipping a Norton Commander directory btw. Didn't measure it exactly but it was around 2 minutes with pkzip and I think 20 minutes for 7zm.exe.

What commandline options did you use to get 7zm to add a full directory to the archive? As stated above, I can't get it to add anything but a single file in an archive.

dajhorn wrote on 2025-01-12, 14:31:

You're a complainer, and you didn't provide enough information to fix anything, which makes you a time waster. […]
Show full quote

zyzzle wrote on 2025-01-12, 05:17:

Why didn't you make it possible ... just like in every other version of 7zip I've ever used?

You're a complainer, and you didn't provide enough information to fix anything, which makes you a time waster.

Open a bug report at Github with enough detail to reproduce the problem.

7-Zip is complex enough that it expresses bugs in the OWC toolchain and runtime for DOS.

Thanks for your helpful reply, but I couldn't be any more clear: this DOS version of 7za 24.09 isn't able to add multiple files using wildcards to an archive in my case. When attempting to do so, it merely creates a 32-byte empty .7z file. This behavior also persists on .zip files created. (In the case where I use wilcards to attempt to add multiple files to a newly-created .zip archive, 7za.exe just produces an empty 22-byte .zip file and doesn't recognize the commandline wildcard argument.) Adding files *singly* on the commandline to archives works.

My system is nothing unusual, bare-metal MS-DOS 7.1 with Himem.sys loaded and FILES=30 and BUFFERS=30 in config.sys. The working directory for 7za is a ramdrive and is in the path. Using FreeDOS instead also produces the same behavior. It isn't a memory problem, as artificially limiting memory to only 64M produces the same result as with allowing the full 4 GiB to be made available in DOS.

My best guess is this bug is somehow related to how this was compiled. I wonder if it could compile with gcc instead of Watcom C.

Are others here able to create archives with multiple files added - in bare metal DOS? How?

so globbing function in OWCC DOS runtime library is broken.

Indeed, there's some problem with the 7ZA 24.09 for DOS when running in pure DOS...

I'm trying to archive the entire C: drive:
c:
cd \
7za a f:\testfile

When running in the VDM under Windows 98 SE, it scans the drive, finds 500+ directories, 8000+ files, 1100+ MB; and happily archives everything, except for a few files used by another process, or with weird characters in filenames.

But when running in pure MS-DOS 7.10 (BootGUI=0), scanning the drive still finds 500+ directories, but only 69 files, 3+ MB...
It only finds files with names without extensions!

I guess that in a system with LFN support, "*" is enough to match all files, but in pure DOS, "*.*" is necessary...

After using this version of 7-Zip for some time, I found that it is problematic, and it isn't just limited to wildcards on an environment without LFN support.

With the DOS version, one can get "ERROR: Cannot set file attribute: errno=6 : Permission denied" message with extracted files lacking any attributes and 7ZA.EXE crashes with RAR file extraction.

Grzyb wrote on 2025-01-13, 03:32:

I guess that in a system with LFN support, "*" is enough to match all files, but in pure DOS, "*.*" is necessary...

Yes, this is a non-obvious behavior in the DOS runtime, but it seems to be correct for most kinds of DOS. A double *.* is the best way to match all files on DOS, and a single * matches all files on all other platforms.

This also applies to Windows 95/98/Me. System behavior in a MS-DOS window is different than in real mode. If you want similar filesystem semantics outside of Win9x, then something like DOSLFN.COM must be running, which is where the glob happens.

The pertinent code in 7-Zip is here:

• https://github.com/dajhorn/retro7zip/commit/8 … 7ec9431d5db7d22

And a list of DOS versions that I've checked is here:

• https://github.com/dajhorn/retro7zip/wiki/DOS … der-Test-Matrix

Gmlb256 wrote on 2025-01-13, 04:51:

With the DOS version, one can get "ERROR: Cannot set file attribute: errno=6 : Permission denied" message with extracted files lacking any attributes and 7ZA.EXE crashes with RAR file extraction.

Tracked here:

• https://github.com/dajhorn/retro7zip/issues/2

Thanks for the report. The 7za build needs coverage testing.

Yoghoo wrote on 2025-01-12, 20:22:

Thanks for making this available.

Welcome.

Yoghoo wrote on 2025-01-12, 20:22:

Rerunning it with the right parameters after that somehow hung my pc. After a reboot I tried it again but creating a zip file takes at least 10 times more time then with pkzip. I used the default setting for both and it seems to use the same compression as the zip files were almost identical in size.

This indicates memory pressure. 7zr for DOS starts at 3MB of memory and goes up, so my guess is that 7zr is using a swap file on this 4MB computer, which would explain a 20x slowdown.

Past that, the deflate implementation in 7-Zip is much more aggressive than the deflate implementation in PKZip, but it will do 10% better on many datasets.

Try the -mx1 or -mx2 switch and you might get comparable performance if this job is CPU-bound and not RAM-bound.

dajhorn wrote on 2025-01-13, 14:34:

a single * matches all files on all other platforms

Not on Unix, including Linux - if you want to catch them all, you need two wildcards, at least at the shell level:
*
.*

...and keep in mind that it will also match the "." and ".." entries, probably not quite what we want.

This also applies to Windows 95/98/Me. System behavior in a MS-DOS window is different than in real mode. If you want similar […]
Show full quote

This also applies to Windows 95/98/Me. System behavior in a MS-DOS window is different than in real mode. If you want similar filesystem semantics outside of Win9x, then something like DOSLFN.COM must be running, which is where the glob happens.

The pertinent code in 7-Zip is here:

• https://github.com/dajhorn/retro7zip/commit/8 … 7ec9431d5db7d22

So, there is some code to handle that, but... it doesn't seem to work as expected!

Note that in my command, I didn't use any wildcards explicite - instead, I relied on the traditional behavior of (almost) all archivers: if no files are specified, archive ALL the files in the current working directory, and (optionally) below the current working directory...
7-Zip for Linux does it right
7-Zip for Windows does it right
7-Zip for DOS - if run under LFN environment - does it right
7-Zip for DOS - if run under pure DOS - behaves differently, OOPS!

Its not 7-zip, but i have used doszip for file manager, it has zip and unzip integrated.

https://archive.org/details/doszip-2.66-dos16

Grzyb wrote on 2025-01-13, 17:28:

7-Zip for DOS - if run under pure DOS - behaves differently, OOPS!

Ticketed here:

• https://github.com/dajhorn/retro7zip/issues/7

The same bug happens on DOSBox.

Gmlb256 wrote on 2025-01-13, 04:51:

7ZA.EXE crashes with RAR file extraction.

Yes, I noticed that as well. And in pure DOS (with no LFN support loaded), either * or *.* does not work to add all files.

This version seems borked.

dajhorn wrote on 2025-01-13, 14:34:

And a list of DOS versions that I've checked is here:

• https://github.com/dajhorn/retro7zip/wiki/DOS … der-Test-Matrix

This list is very useful, however omissions include MS-DOS 7.1 (ie, the command.com included in Windows 95b, booted on bare metal machines), and the Himem.sys included in that version. As well, the CWSDPMI DOS extender is missing.

The MS-DOS 7.1 Himem.sys and version 5 of the CWSDPMI extender recognize a full 2 GiB of XMS memory and 4 GiB in version 7 of CWSDPMI.exe - at least on my main laptop system which has a total of 8 GiB of dual-channel DDR3 RAM installed. With JEMM 5.88 loaded, the system sees 128 MB of EMS memory.

dajhorn wrote on 2025-01-13, 14:51:

Tracked here: […]
Show full quote

Tracked here:

• https://github.com/dajhorn/retro7zip/issues/2

Thanks for the report. The 7za build needs coverage testing.

I saw a commit today in the GitHub repository fixing the issue with RAR file extraction. I then built a 7za executable with that fix and it no longer crashes! 😁

Gmlb256 wrote on 2025-01-17, 00:04:

I saw a commit today in the GitHub repository fixing the issue with RAR file extraction. I then built a 7za executable with that fix and it no longer crashes! 😁

Thanks for testing; that one was caused by a wcc386 compiler defect.

The globbing / implicit arguments bug is fixed too and will be in the next point release.

Hi cant run this with 386 cpu and 4 mb ram. Using freedos

Tested the latest DOS release of 24.09 (third revision on github) and all problems seem happily resolved in bare metal DOS 7.1 with no LFN loaded. *.* works, wildcards work, RAR files decompress with 7za.exe. Performance is generally excellent. Compression and decompression times are ~10% faster than with the previous DOS version of 7zip, v. 16.02.

Thanks for getting these bugs worked out. Very much appreciated.

zyzzle wrote on 2025-01-23, 06:39:

Tested the latest DOS release of 24.09 (third revision on github) and all problems seem happily resolved in bare metal DOS 7.1 with no LFN loaded. *.* works, wildcards work, RAR files decompress with 7za.exe. Performance is generally excellent. Compression and decompression times are ~10% faster than with the previous DOS version of 7zip, v. 16.02.

Thanks for getting these bugs worked out. Very much appreciated.

Thanks for this report. The 10% performance improvement happened because Open Watcom v2 has smaller runtime overheads than other toolchains.

7-Zip could be even faster on DOS if the ASM routines are implemented for the 386 CPU family like they are for AMD64 and ARM64.