That's what I expected. This is unfinished. Not so long ago I wrote to another user:

eM-!3 wrote on 2026-06-29, 08:34:

Nice hobby project but it's not ready. I am trying to use Gemini & Claude for ASM and it's really hit & miss. I am trying to make something much easier (more.com replacement) and still I see how many bugs it can put inside. It makes totally wrong assumptions all the time (from modern computers, modern OSes, modern programming), it needs to be controlled and tested after every single change. 5% time is getting first version that looks like it's working but then 95% is looking for edge cases when it isn't, preparing tests and so on. You can't trust AI to have a tiny little feature working until you really put it to hard tests and it takes time.

Your project is in better shape and it looks like one that might become useful but you need to put more effort in testing part.

eM-!3 wrote on 2026-08-07, 06:37:

That's what I expected. This is unfinished. Not so long ago I wrote to another user:

eM-!3 wrote on 2026-06-29, 08:34:

Nice hobby project but it's not ready. I am trying to use Gemini & Claude for ASM and it's really hit & miss. I am trying to make something much easier (more.com replacement) and still I see how many bugs it can put inside. It makes totally wrong assumptions all the time (from modern computers, modern OSes, modern programming), it needs to be controlled and tested after every single change. 5% time is getting first version that looks like it's working but then 95% is looking for edge cases when it isn't, preparing tests and so on. You can't trust AI to have a tiny little feature working until you really put it to hard tests and it takes time.

Your project is in better shape and it looks like one that might become useful but you need to put more effort in testing part.

Hi, I appreciate your feedback. Can you please tell me what parts are unfinished? Did you run into any particular bugs so I can reproduce and fix them?

OzzFan wrote on 2026-08-07, 00:33:

As a heavy user of 7Zip, I wanted to see if I could make a file extractor for DOS ...

Looke like a useful project.

FWIW, there was an actual DOS edition of 7zip:

17-Zip (A) 4.61 beta  Copyright (c) 1999-2008 Igor Pavlov  2008-11-23
2p7zip Version 4.61 (locale=C,Utf16=off,HugeFiles=off,1 CPU)
3
4Usage: 7za <command> [<switches>...] <archive_name> [<file_names>...]
5       [<@listfiles...>]
6
7<Commands>
8  a: Add files to archive
9  b: Benchmark
10  d: Delete files from archive
11  e: Extract files from archive (without using directory names)
12  l: List contents of archive
13  t: Test integrity of archive
14  u: Update files to archive
15  x: eXtract files with full paths
16<Switches>
17  -ai[r[-|0]]{@listfile|!wildcard}: Include archives
18  -ax[r[-|0]]{@listfile|!wildcard}: eXclude archives
19  -bd: Disable percentage indicator
20  -i[r[-|0]]{@listfile|!wildcard}: Include filenames
21  -m{Parameters}: set compression Method (see the manual)
22  -o{Directory}: set Output directory
23  -p{Password}: set Password
24  -r[-|0]: Recurse subdirectories
25  (CAUTION: this flag does not do what you think, avoid using it)
26  -sfx[{name}]: Create SFX archive
27  -si[{name}]: read data from stdin
28  -slt: show technical information for l (List) command
29  -so: write data to stdout (eg: 7z a dummy -tgzip -so Doc.txt > archive.gz)
30  -ssc[-]: set sensitive case mode
31  -t{Type}: Set type of archive
32  -v{Size}[b|k|m|g]: Create volumes
33  -u[-][p#][q#][r#][x#][y#][z#][!newArchiveName]: Update options
34  -w[path]: assign Work directory. Empty path means a temporary directory
35  -x[r[-|0]]]{@listfile|!wildcard}: eXclude filenames
36  -y: assume Yes on all queries

DaveDDS wrote on 2026-08-07, 10:45:

OzzFan wrote on 2026-08-07, 00:33:

As a heavy user of 7Zip, I wanted to see if I could make a file extractor for DOS ...

Looke like a useful project.

FWIW, there was an actual DOS edition of 7zip:

Thanks! I wasn't aware of this since I didn't see it on their https://www.7-zip.org/download.html download page. Seems like it makes my project superfluous.

OzzFan wrote on 2026-08-07, 10:04:

Hi, I appreciate your feedback. Can you please tell me what parts are unfinished? Did you run into any particular bugs so I can reproduce and fix them?

Clicking some buttons with mouse didn't work. I don't have WinRAR right now so the only RAR archive that I tested was one that I downloaded from this forum recently. It wasn't able to unpack it but RAR 2.50 for DOS also failed with the same archive. But Retro7Zip is extracting files without problems.

I didn't see any warning about overwriting files. I didn't see option to select files/dirs to unpack and from my point of view this is starting point which would make this program useful as right now it adds additional layer with no benefit over command line tools.

I also wonder did you project UI or leave it all to AI: menu options, look of windows, shadows, placement, colors used, descriptions etc. Was it part of your plan to have all drives listed every time in open file window?

I know this one is for DOS but did you test it with long names? Did you test it with names using uncommon chars etc.

OzzFan wrote on 2026-08-07, 12:20:

Thanks! I wasn't aware of this since I didn't see it on their download page. Seems like it makes my project superfluous.

I've not actually used it in many years (but used to use it a LOT "back in the day"), and I have no idea how compatible it is with "modern" 7ZIP.

I've PMed it to you so you can check it out.

eM-!3 wrote on 2026-08-07, 12:57:

OzzFan wrote on 2026-08-07, 10:04:

Hi, I appreciate your feedback. Can you please tell me what parts are unfinished? Did you run into any particular bugs so I can reproduce and fix them?

Clicking some buttons with mouse didn't work. I don't have WinRAR right now so the only RAR archive that I tested was one that I downloaded from this forum recently. It wasn't able to unpack it but RAR 2.50 for DOS also failed with the same archive. But Retro7Zip is extracting files without problems.

Once again, I appreciate the feedback. I tested mouse under NT 3.51 as well as real hardware 486 DOS 6.22 and it worked in all cases. The fact that you had a mouse cursor tells me the mouse functionality was there, so what buttons were you clicking in the app that didn't work?

I tested on sample .IMG, .IMA, .RAR 3/4, ZIP, and 7Z on the above platforms on files up to 8MB and all extracted fine. I also have a 3GB .7z archive that it couldn't open, but that was expected.

I can certainly do more testing and throw some more archives at it, but that was kind of the purpose of me posting this. In my test cases everything worked. In order to make this more well-rounded, I asked for feedback.

eM-!3 wrote on 2026-08-07, 12:57:

I didn't see any warning about overwriting files. I didn't see option to select files/dirs to unpack and from my point of view this is starting point which would make this program useful as right now it adds additional layer with no benefit over command line tools.

That's a legit oversight on my part with the file overwriting prompt. I'll have to address that. The default is to extract files + dirs always.

eM-!3 wrote on 2026-08-07, 12:57:

I also wonder did you project UI or leave it all to AI: menu options, look of windows, shadows, placement, colors used, descriptions etc. Was it part of your plan to have all drives listed every time in open file window?

Yes, the UI was designed by me using my custom DOSForms framework also used in my Dobson Utilities.

eM-!3 wrote on 2026-08-07, 12:57:

I know this one is for DOS but did you test it with long names? Did you test it with names using uncommon chars etc.

I wasn't sure about adding LFN support as of yet since my intention was that this would only run under DOS 6.x and older (down to 3.3). I did not test with names using uncommon chars. Again, that's an oversight on my part.

I found the mouse problem and was able to fix it. I added the overwrite prompt with Yes/No/Yes to All/No to All. And I think I got the uncommon character checker working. I updated the release in my original post.

OzzFan wrote on 2026-08-07, 12:20:

Thanks! I wasn't aware of this since I didn't see it on their https://www.7-zip.org/download.html download page. Seems like it makes my project superfluous.

There is also a modern port of 7-Zip for DOS:
https://github.com/dajhorn/retro7zip

Your project could be interesting if you add support to select which files you want to extract and manage conflicts extracting long file names in MS-DOS 6.22 without any LFN support.

Ok, I've added those features to XArc and released the new version in the original post, and this is my 1.0 version.

Long file names in an archive extracted under DOS uses the truncate method. So "Long file name.txt" becomes "LONGFILE.TXT". A file name like "Long file name.tar.gz" becomes "LONGFILE.GZ". Truncation also applies to extensions, so "myapp.config" becomes "MYAPP.CON".

Truncated file names are run through the overwrite protector after truncation so if the file already exists, you will get prompted.

I've also added the ability to selected which files to extract using the spacebar or the Select menu option.

Thank you everyone for your feedback.

I like your UI, and the fact that you may now individually extract files. And scroll through them with pgdn / pgup.

I've run into memory problems attempting to extract larger .7z files. As in a 24 mb 7z file, so not HUGE files. Theoretically, you should be able to allocate up to 2GB memory for extraction if need be, since you're using the dos/32 extender.

OzzFan wrote on 2026-08-15, 18:53:

Ok, I've added those features to XArc and released the new version in the original post, and this is my 1.0 version.

Tested the new release. With a 7Zip file with long file names including long file paths, it's not possible to see the contents of the compressed file and it's not possible to extract anything. I get the error: Extraction failed: Archive exceeds a configured size limit.

Using Retro7zip I get this file contents:

17-Zip 24.09 aggregated for DOS : 0xcc14b9c @ 2024-11-29
2Scanning the drive for archives:
31 file, 2279760 bytes (2227 KiB)
4
5Listing archive: 3DFLOOR.7Z
6
7
8Open: 3DFLOOR.7Z--
9Path = 3DFLOOR.7Z
10Type = 7z
11Physical Size = 2279760
12Headers Size = 500
13Method = LZMA:26
14Solid = +
15Blocks = 1
16
17   Date      Time    Attr         Size   Compressed  Name
18------------------- ----- ------------ ------------  ------------------------
192023-05-21 15:45:52 D....            0            0  3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)
202023-05-21 15:45:52 D....            0            0  3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\3.5
212023-05-21 15:45:52 D....            0            0  3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\5.25
222023-05-21 15:45:52 D....            0            0  3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\Artwork Reference
232014-11-01 00:52:16 ....A       737280      2279260  3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\3.5\DISK01.IMG
242023-03-09 08:57:38 ....A       368640               3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\5.25\DISK01.IMG
252023-03-09 09:00:20 ....A       368640               3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\5.25\DISK02.IMG
262023-05-21 15:34:42 ....A       300094               3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\Artwork Reference\3D Floorplan Designer - Box Back.jpg
272023-05-21 15:38:18 ....A       207999               3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\Artwork Reference\3D Floorplan Designer - Box.jpg
282023-05-21 15:35:18 ....A       348515               3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\Artwork Reference\3D Floorplan Designer - Disk 1.jpg
292023-05-21 15:35:24 ....A       326809               3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\Artwork Reference\3D Floorplan Designer - Disk 2.jpg
302023-05-21 15:35:32 ....A       199430               3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\Artwork Reference\3D Floorplan Designer - Disk 3.jpg
312023-05-21 15:35:42 ....A       229646               3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\Artwork Reference\3D Floorplan Designer - Manual.jpg
322023-05-21 16:45:26 ....A          385               3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\3D FloorPlan Designer 2.0 for DOS.txt
332015-01-03 23:27:08 ....A          737               3D FloorPlan Designer 2.0 for DOS (1993) (3.5-720k) (5.25-360k)\winworldpc.com.txt
34------------------- ----- ------------ ------------  ------------------------
352023-05-21 16:45:26            3088175      2279260  11 files, 4 folders

Besides this, it seems that XArc separates the folders from the files (which Retro7zip does when listing contents) instead of including the files inside the folders.Also, Return key does not enter in any folder to see the contents but tries to extract what's selected.

Could be reduced the column Attr to view more characters in Name? It's possible to add an option to see the full path and name of the file? Could be added an option to extract a file with and without path (parent(s) folder(s))?.

zyzzle wrote on 2026-08-15, 21:59:

I like your UI, and the fact that you may now individually extract files. And scroll through them with pgdn / pgup.

Thanks! I appreciate hearing it.

zyzzle wrote on 2026-08-15, 21:59:

I've run into memory problems attempting to extract larger .7z files. As in a 24 mb 7z file, so not HUGE files. Theoretically, you should be able to allocate up to 2GB memory for extraction if need be, since you're using the dos/32 extender.

I didn't want to enable virtual memory and cause a bunch of disk thrashing on slower hard drives. I did a little bit of memory optimization so maybe this will help. It seemed to work well for me.

ntalaec wrote on 2026-08-16, 08:43:

Tested the new release. With a 7Zip file with long file names including long file paths, it's not possible to see the contents of the compressed file and it's not possible to extract anything. I get the error: Extraction failed: Archive exceeds a configured size limit.

I performed some memory optimizations. I hope this might fix your problems.

ntalaec wrote on 2026-08-16, 08:43:

Besides this, it seems that XArc separates the folders from the files (which Retro7zip does when listing contents) instead of including the files inside the folders.Also, Return key does not enter in any folder to see the contents but tries to extract what's selected.

Still working on this. It's been a bit trickier than I thought to get this working.

ntalaec wrote on 2026-08-16, 08:43:

Could be reduced the column Attr to view more characters in Name? It's possible to add an option to see the full path and name of the file? Could be added an option to extract a file with and without path (parent(s) folder(s))?.

Yes. Both are implemented in this release. Preference is saved to an .INI file that lives in the same directory as the executable.

Version 1.1 attached.

OzzFan wrote on 2026-08-15, 18:53:

Ok, I've added those features to XArc and released the new version in the original post, and this is my 1.0 version. […]
Show full quote

Ok, I've added those features to XArc and released the new version in the original post, and this is my 1.0 version.

Long file names in an archive extracted under DOS uses the truncate method. So "Long file name.txt" becomes "LONGFILE.TXT". A file name like "Long file name.tar.gz" becomes "LONGFILE.GZ". Truncation also applies to extensions, so "myapp.config" becomes "MYAPP.CON".

Truncated file names are run through the overwrite protector after truncation so if the file already exists, you will get prompted.

I've also added the ability to selected which files to extract using the spacebar or the Select menu option.

Thank you everyone for your feedback.

Does this mean that if an archive contains two files where the first 8 characters and the truncated extension are the same, it wouldn't be able to extract the files? The first file would be overwritten or the second file would be skipped

I guess this is the reason DOS 7 LFN trucation uses numbers on the end

OzzFan wrote on 2026-08-18, 22:30:

I didn't want to enable virtual memory and cause a bunch of disk thrashing on slower hard drives. I did a little bit of memory optimization so maybe this will help. It seemed to work well for me.

You may test or find out how much memory the system has. If system has enough memory (most have 2gb or more), VM is simply not necessary.

I'm getting a message about unable to extract due to a "preconfigured memory limit" even though my DOS system has 8gb of RAM. If a particular system doesn't have enough physical memory to extract a file or an archive, it would be better to just say "insufficient memory for extraction." rather than hard-code any hard memory limit which would universally prevent all systems from extracting, even if those systems have enough RAM to do so.

Maybe I misunderstood something, but how this truncate long names method should work properly, if for example there are files named like "Long file name 1.txt", "Long file name 1 copy.txt" and "Long file name new.txt" inside the archive?

OzzFan wrote on 2026-08-18, 22:30:

Version 1.1 attached.

Tried v1.1. It's not possible to see the full name of the files in browser or when trying to extract. So it's not possible to know what is being extracted. Also, I can't extract anything from file, an error message appears about dictionary size larger than 32 MB.

NeoG_ wrote on 2026-08-18, 23:52:

Does this mean that if an archive contains two files where the first 8 characters and the truncated extension are the same, it wouldn't be able to extract the files? The first file would be overwritten or the second file would be skipped

I guess this is the reason DOS 7 LFN trucation uses numbers on the end

aVd wrote on 2026-08-19, 02:23:

Maybe I misunderstood something, but how this truncate long names method should work properly, if for example there are files named like "Long file name 1.txt", "Long file name 1 copy.txt" and "Long file name new.txt" inside the archive?

You're both making the same point. I concede I hadn't really thought of that scenario. I'll have to look into implementing it the DOS 7 way of using ~? (where ? = next integer on the file system).

zyzzle wrote on 2026-08-19, 01:56:

You may test or find out how much memory the system has. If system has enough memory (most have 2gb or more), VM is simply not necessary.

I'm getting a message about unable to extract due to a "preconfigured memory limit" even though my DOS system has 8gb of RAM. If a particular system doesn't have enough physical memory to extract a file or an archive, it would be better to just say "insufficient memory for extraction." rather than hard-code any hard memory limit which would universally prevent all systems from extracting, even if those systems have enough RAM to do so.

You're right. To be fair, my target system was not a DOS system with 8GB of memory. I was targeting systems with constrained environments like the typical DOS machine of 1993. But, again, point taken. As a programmer I should try to program for more scenarios.

ntalaec wrote on 2026-08-19, 11:19:

Tried v1.1. It's not possible to see the full name of the files in browser or when trying to extract. So it's not possible to know what is being extracted. Also, I can't extract anything from file, an error message appears about dictionary size larger than 32 MB.

I see I also have some text formatting issues to address as well.

With v. 1.1 I am able to extract more files - and you do print a message saying max dictionary size is 32mb. So, this is better than just saying "preconfigured memory limit." However, I think you should be able to allow 256mb dictionary or even 512mb for decompression, in large memory systems, since you're using a dos extender with XArc.