In both DOS and Win32c ports, the README.TXT file uses LF as EOL.

Many programs for these platforms only support CRLF - I noticed it when trying to view it in Volkov Commander...

Hi, LFN -> Long File Name. Supported by DOS 7.x, but needs a driver in plain DOS (not run on Windows 9x).
Opposite is SFN -> Short File Name (8.3), I think. Speaking under correction.

Testing the 7zip-24.09+3_dos version now, in pure MS-DOS 6.20...

The problem with finding only "*" files, instead of "*.*", seems gone indeed.

But I've found a problem with memory requirements...

There's 16 MB total:

1Memory Type        Total  =   Used  +   Free
2----------------  -------   -------   -------
3Conventional         640K      175K      465K
4Upper                  0K        0K        0K
5Reserved             384K      384K        0K
6Extended (XMS)    15,360K    2,112K   13,248K
7----------------  -------   -------   -------
8Total memory      16,384K    2,671K   13,713K
9
10Total under 1 MB     640K      175K      465K
11
12Largest executable program size       465K (475,744 bytes)
13Largest free upper memory block         0K       (0 bytes)
14MS-DOS is resident in the high memory area.

Should be enough, right?

First, I try zero-compression:
7za a -mx0 e:\backup1

It finds 300+ directories, 6000+ files, 200+ MB - and happily completes the task.

Now, let it actually compress stuff:
7za a e:\backup2

It works hard for a long time, nearly to the very end - but then it aborts with "ERROR: Can't allocate required memory!", and the "BACKUP2.7Z" file gets deleted.

Grzyb wrote on 2025-01-25, 09:54:

In both DOS and Win32c ports, the README.TXT file uses LF as EOL.

Many programs for these platforms only support CRLF - I noticed it when trying to view it in Volkov Commander...

This is fixed in the 7zip-24.09+4 package. Thanks for the report.

Grzyb wrote on 2025-01-26, 08:14:

Should be enough, right?

No, 13 megabytes of memory is not always enough to create a large archive with 7za.exe, which can use up to 8 megabytes to get off the ground.

Run 7zr.exe and look at the top-right corner of the console. You should see something like this:
LFN=0 SWITCHES=-md19

Subtract one or two from the automatic dictionary size and create the archive like this:
7zr a -md17 e:\backup1.7z

If this succeeds, then you were indeed running out of memory. Each file added to an archive uses a few hundred bytes of heap space during compression.

If this fails, then the stack is probably exhausted, which you can't easily fix. Add fewer files to backup1.7z and update it with more files in a second run.

You didn't mention what kind of DOS you are using, which matters.

• Don't omit the .7z file extension. Implicit names sometimes cause problems in DOSBox and with LFN drivers.
• Delete the 7z temp file in the working directory if it exists.
• Ensure that %TEMP% exists and is writable.

dajhorn wrote on 2025-01-27, 12:32:

No, 13 megabytes of memory is not always enough to create a large archive with 7za.exe, which can use up to 8 megabytes to get off the ground.

Ah, the README.TXT needs clarification:
"Requires more than 8 megabytes of memory to unpack some complex files."

I assumed that >8 MB would be enough for packing, too...

You didn't mention what kind of DOS you are using, which matters.

I did:

Grzyb wrote on 2025-01-26, 08:14:

pure MS-DOS 6.20

"pure" means no Windows, no LFN.

[*] Ensure that %TEMP% exists and is writable.

What does it write to %TEMP% ?
I saw it writing stuff to the .7Z file on E: - a network share, so I could watch the file growing on the server.

Grzyb wrote on 2025-01-27, 15:26:

What does it write to %TEMP% ?
I saw it writing stuff to the .7Z file on E: - a network share, so I could watch the file growing on the server.

Retro7zip uses the Causeway extender for DOS, which will write a swap file to %TEMP% if it runs out of physical memory.

7-Zip itself also uses %TEMP% for some operations, but the code for DOS isn't robust.

I've done zero testing with network redirectors; please create an issue ticket with a reproducer if you find bugs.

SILENT DATA CORRUPTION WARNING!!!

7zip-24.09+4_dos
MS-DOS 6.20
16 MB RAM

I did the following:

7zm a -mx0 e:\mmm
7zr a -mx0 e:\rrr
7za a -mx0 e:\aaa

3 x "Everything is Ok"

But then I tested the created archives using Linux and Windows versions of 7-Zip:

MMM.7Z is OK
RRR.7Z is OK
AAA.7Z, however:

1$ 7za t AAA.7Z 
2
37-Zip (a) [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
4p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,4 CPUs Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz (806E9),ASM,AES-NI)
5
6Scanning the drive for archives:
71 file, 214883817 bytes (205 MiB)
8
9Testing archive: AAA.7Z
10--
11Path = AAA.7Z
12Type = 7z
13Physical Size = 214883817
14Headers Size = 76591
15Method = Copy
16Solid = -
17Blocks = 6137
18
19ERROR: CRC Failed : INST/WFW311/NE2000.DO_
20                                  
21Sub items Errors: 1
22
23Archives with Errors: 1
24
25Sub items Errors: 1

Very bad, even if I'm not supposed to use 7ZA with 16 MB of RAM.

The docs seriously need clarification:
- with aaa..bbb MB of RAM, use 7ZM
- with bbb..ccc MB of RAM, use 7ZR
- with ccc+ MB of RAM, use 7ZA

All three versions should check for available memory, and display a warning if it may be insufficient.
But even if it's really insufficient, it should exit with an error, rather than create a corrupt archive...

Please create an issue ticket with enough information to recreate the bug. Things like:

• The network server, name and version.
• The network client, name and version.
• The corrupt 7z file as an attachment.

Additionally:

• Check whether the retro7zip programs detect the same error as p7zip or any other utility when testing the archive.
• If you know how, then check whether the bad 7z file is truncated or contains corrupt members.
• SET CAUSEWAY=NOVM and run 7za again. Does it fail in the same way?

dajhorn wrote on 2025-02-02, 00:00:

Please create an issue ticket with enough information to recreate the bug.

I don't feel like registering at GitHub anytime soon.
Meanwhile, if you want me to report problems, I can only do it where I already have an account - on this forum.

CauseWay DOS extender is updated by JEMM386's author:
https://github.com/Baron-von-Riedesel/CauseWay/releases

roytam1 wrote on 2025-02-26, 01:05:

CauseWay DOS extender is updated by JEMM386's author:
https://github.com/Baron-von-Riedesel/CauseWay/releases

Open Watcom is merging these updates, so Retro7zip will get them with the next upstream release.

zyzzle wrote on 2025-01-14, 03:07:

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.

For completeness, I will check MS-DOS 7.1 when I get around to updating the test matrix for PMODE/W.

Using CWSDPMI with Open Watcom requires a linker bodge, which means that CWSDPMI is incompatible with Retro7zip for the purpose of coverage testing.