Ok, here's version 1.2 with caps removed. I don't have an 8GB DOS machine available to test that kind of configuration, but on my existing DOS systems I'm able to open larger files now. Hopefully this works better for all of you.

OzzFan wrote on 2026-08-27, 21:31:

Ok, here's version 1.2 with caps removed. I don't have an 8GB DOS machine available to test ...

WOW - that's a LOT of memory for a DOS system. I think of the 6 or so "real" ones I have now, the most RAM in one is .5G (and at least one has a LOT less 😀 )
(how much can DOS actually support?)

You could use a virtual machine... I don't know all of them, PCem seems to be limited to 512m (might be more in a different config)
VMWARE player will let you configure up to 64g - and it CAN boot DOS!

DaveDDS wrote on 2026-08-27, 23:13:

OzzFan wrote on 2026-08-27, 21:31:

Ok, here's version 1.2 with caps removed. I don't have an 8GB DOS machine available to test ...

(how much can DOS actually support?)

DOS itself is real mode and only supports 1MB. It's the XMS driver that's important. DOS 6.22's HIMEM driver supports up to 64MB. Win9x's HIMEM driver supports up to 512MB. QEMM 7.x and higher support 256MB.

Or I suppose you could just write for raw extended memory, but that would require the machine to not be booted with a memory manager to work.

With DOS32/A there are some practical limits. If run under no memory manager at all, DOS32/A is limited to 64MB. If run under VCPI, most VCPI servers only expose up to 64MB, but JEMM386 can expose up to 256MB. If run under a DPMI server, DOS32/A is limited to the loaded DPMI driver's limits. Win9x DPMI is around 64-128MB. CWSDPMI r7 supports up to 256MB.

So realistically the limit is around 256MB.

DaveDDS wrote on 2026-08-27, 23:13:

You could use a virtual machine... I don't know all of them, PCem seems to be limited to 512m (might be more in a different config)
VMWARE player will let you configure up to 64g - and it CAN boot DOS!

I use 86Box for some testing before I do it on real hardware. I personally don't see a need to test above 256MB given the limitations I outlined above.

OzzFan wrote on Yesterday, 00:09:

...vSo realistically the limit is around 256MB.

This sounds about right in my limited experience - the .5G system mentioned has swappable drives - and I recall that I also ram some editions of Win32 on it.
I don't think I was ever ab;e tp use more than about 256m in DOS (mostly as a RamDisk 😀 )

I agree completely with no need to test beyond 256... It's a very rare system that can access more than that!

so.. exactly how do you support 8G?

Microsoft Win98SE supports up to 4GB of XMS.
EMS64 by CandyMan supports memory beyond 4GB in unreal mode. Requires a 64-bit CPU.
JEMMEX supports up to 4GB. Its optional extension, HimemSX extend XMS and supports 1TB.

Most common use of such big memory sizes is for RAM drives.

DaveDDS wrote on Yesterday, 02:30:

so.. exactly how do you support 8G?

On a 32bit addressing scheme? You don't. 32bits can only address 4GB, and that's typically separated as 2GB user space and 2GB system space. If a 64bit processor is used, there are some compiler flags in modern compilers that will let you use all 4GB in 32bit addressing as user space.

To support 8GB you'd have to explicitly target the Pentium Pro and above since 80686 CPUs actually support 36bit memory addressing for a total of 64GB of RAM. This is not my target system though.

igully wrote on Yesterday, 03:01:

Microsoft Win98SE supports up to 4GB of XMS.

Microsoft officially only supports up to 512MB on Win98 SE. With VCACHE tuning you can reach a practical limit of around 1GB. Absolute upper bound with hacks is around 2GB but is unstable and not guaranteed. Many hardware drivers do not like when more than 1GB is used.

igully wrote on Yesterday, 03:01:

JEMMEX supports up to 4GB. Its optional extension, HimemSX extend XMS and supports 1TB.

Note that HimemSX requires 36bit addressing and PSE-36 paging to support 1TB. No 32bit addressing scheme can utilize that much RAM.

OzzFan wrote on 2026-08-27, 21:31:

Ok, here's version 1.2 with caps removed. I don't have an 8GB DOS machine available to test that kind of configuration, but on my existing DOS systems I'm able to open larger files now. Hopefully this works better for all of you.

Thanks for the new release. Some comments, I'm using a 3M 7Zip file compressed with method LZMA:26 with all the files and folders inside a folder:

With MemoryLimitMB=0 detects 46 MB in my machine, which has 1 GB of RAM but I'm using HIMEM.SYS which leaves 65.083K free. With 46 MB I get the following error trying to extract:
Not enough memory for this archive.
It needs more than the 46 MB this machine can spare in one block.
If I change to MemoryLimitMB=64 (more than available using HIMEM.SYS) I can extract any file or folder without issues.
I get random crashes with MemoryLimitMB=64 and Screen Thief 2.04. I don't have problems with Screen Thief in any other program.

Loading the file by command line, the status bar only shows information after I enter the main folder.

If I try to extract to root folder of any drive I get this error:
Extraction failed:
Cannot create or write an output file.
I have no issues extracting to a subfolder.

If the name of current folder is too long, text about keyboard shortcuts is not visible in the status bar.

If the name of current file/folder is too long is not possible to see it complete. It's possible to add an option to show a window with the full name of file/folder?

These are suggestions:
Show a mark (maybe an asterisk?) to the left of the options in Options menu to show which options are active.
Show File menu when pressing Alt. Or include in status bar "Alt Menu". Or show a help window when pressing F1.
Show the name of current file being extracted. I can only see it using DOSBox.
Option to extract without path names (don't create folders when extracting). Available using option.
Show a window to change file/folder name when extracting a long file name and renaming to short file name.

OzzFan wrote on Yesterday, 10:17:

On a 32bit addressing scheme? You don't. 32bits can only address 4GB, and that's typically separated as 2GB user space and 2GB system space. If a 64bit processor is used, there are some compiler flags in modern compilers that will let you use all 4GB in 32bit addressing as user space.

Yes, I'm well aware of the 4G limitation of true 32bit systems.
I was assuming it required a 64bit processor (which almost everything "new" is these days).

But DOS (and W9xDOS) were never designed for 64bit processors, hence I've never seen "expanded" memory ability above 4G in these systems (and most often it's 2G)
so ... you must be ignoring OS memory config and accessing the super-high memory directly with 64bit addressing instructions?

If so, I commend you - I'm often called a "DOShead" because I still create and use a lot of stuff under DOS ... but I've never had any desire to go to such extents (and to be completely honest, I don't really see much of a use/need for it)

OzzFan wrote on Yesterday, 10:24:

igully wrote on Yesterday, 03:01:

Microsoft Win98SE supports up to 4GB of XMS.

Microsoft officially only supports up to 512MB on Win98 SE. With VCACHE tuning you can reach a practical limit of around 1GB. Absolute upper bound with hacks is around 2GB but is unstable and not guaranteed. Many hardware drivers do not like when more than 1GB is used.

I am talking of full dos mode, not running under a Windows box.

igully wrote on Yesterday, 17:10:

OzzFan wrote on Yesterday, 10:24:

igully wrote on Yesterday, 03:01:

Microsoft Win98SE supports up to 4GB of XMS.

Microsoft officially only supports up to 512MB on Win98 SE. With VCACHE tuning you can reach a practical limit of around 1GB. Absolute upper bound with hacks is around 2GB but is unstable and not guaranteed. Many hardware drivers do not like when more than 1GB is used.

I am talking of full dos mode, not running under a Windows box.

In that case it's still incorrect. The HIMEM.SYS driver that comes with Win98SE only supports up to 512MB of RAM. You can have 4GB installed, but the XMS driver will only use and provide up to 512MB.

I know some people disable booting to the GUI and run DOS 7.10 and use third party XMS drivers, but again, that's not "Win98SE", you're essentially booting real mode DOS which only supports 1MB. It's the third party drivers or the built in HIMEM.SYS that provides access to memory above 1MB. So we're back to what the memory manager supports, not the OS. Yes, it's possible to boot DOS 7.10, load JEMM386 or HIMEMSX and gain access to large amounts of RAM, but it's JEMM or HIMEMSX that is providing the memory, not DOS; not Windows 98SE. It's an important distinction, IMHO.

Just curious what you know about these capabilities in IBM PCDOS 7.1 - IBM gave this away as part of the "anyos" version of "Serverguide scripting toolkit" which they made available for free.

This was before DOS was generally available "free". I used it for a few things (Like the ImageDisk stand-alone boot diskette), and it always seemed a bit more capable/refined that MS-DOS .. but I've never tested "extremes".

OzzFan wrote on Yesterday, 20:05:

In that case it's still incorrect. The HIMEM.SYS driver that comes with Win98SE only supports up to 512MB of RAM. You can have 4GB installed, but the XMS driver will only use and provide up to 512MB.

Images attached show a WIN98SE boot disk reporting about 4GB free and actually working with a 2GB ram disk.
Using Microsoft HIMEM.SYS version 3.95 that comes by default on this default WIN98SE.

DaveDDS wrote on Yesterday, 14:17:

OzzFan wrote on Yesterday, 10:17:

On a 32bit addressing scheme? You don't. 32bits can only address 4GB, and that's typically separated as 2GB user space and 2GB system space. If a 64bit processor is used, there are some compiler flags in modern compilers that will let you use all 4GB in 32bit addressing as user space.

But DOS (and W9xDOS) were never designed for 64bit processors, hence I've never seen "expanded" memory ability above 4G in these systems (and most often it's 2G)
so ... you must be ignoring OS memory config and accessing the super-high memory directly with 64bit addressing instructions?

Well, again, remember that DOS only supports up to 1MB, so there's no OS memory config to bypass. What you're doing is making standard XMS 3.0 calls with 32bit pointers for large allocations of RAM (up to 4GB). There's no such thing as 36bit pointers, or even 40bit pointers. Those are just memory manager tricks and they work similar to the segment:offset of DOS 16bit memory techniques.

DaveDDS wrote on Yesterday, 14:17:

If so, I commend you - I'm often called a "DOShead" because I still create and use a lot of stuff under DOS ... but I've never had any desire to go to such extents (and to be completely honest, I don't really see much of a use/need for it)

I love DOS. It's what I broke my teeth on back in the day when I first started playing with computers.

DaveDDS wrote on Yesterday, 20:43:

Just curious what you know about these capabilities in IBM PCDOS 7.1 - IBM gave this away as part of the "anyos" version of "Serverguide scripting toolkit" which they made available for free.

This was before DOS was generally available "free". I used it for a few things (Like the ImageDisk stand-alone boot diskette), and it always seemed a bit more capable/refined that MS-DOS .. but I've never tested "extremes".

About the only thing I'm aware of with the IBM PC DOS 7..x series is that they improved the command shell so a large portion of it could be loaded high, thus freeing up more conventional memory. They were pushing REXX scripting back then so I know it has REXX support. And they threw in a few new utilities. But beyond that I'm not sure. I have a copy of IBM PC DOS 7.0 and it seems solid and compatible. I know a lot of people don't like IBM's E editor, but the E editor in 7 is far better than it was in 6.x.

igully wrote on Yesterday, 21:38:

OzzFan wrote on Yesterday, 20:05:

In that case it's still incorrect. The HIMEM.SYS driver that comes with Win98SE only supports up to 512MB of RAM. You can have 4GB installed, but the XMS driver will only use and provide up to 512MB.

Images attached show a WIN98SE boot disk reporting about 4GB free and actually working with a 2GB ram disk.
Using Microsoft HIMEM.SYS version 3.95 that comes by default on this default WIN98SE.

Ok. I stand corrected.

OzzFan wrote on Yesterday, 21:46:

Well, again, remember that DOS only supports up to 1MB, so there's no OS memory config to bypass. What you're doing is making standard XMS 3.0 calls with 32bit pointers for large allocations of RAM (up to 4GB). There's no such thing as 36bit pointers, or even 40bit pointers. Those are just memory manager tricks and they work similar to the segment:offset of DOS 16bit memory techniques.

Oh, believe it or not, i'm well aware that we've not been talking about DOS conventional memory. Wether or not you consider XMS as part of DOS (it's an add-ons shipped with DOS) is a matter of opinion (I don't particularly - but many people disagree) - but even with "normal" XMS you can'y go beyond 4G (and even >2G is tough) - hence my assumption that you are "going above and beyond" with 64bit, or using some other extension I haven't seen.

I am also guessing that if you are going 64-bit "on your own", you're not really worrying about "conflicting" allocation in that area, simple because any use of above 4G in DOS is something you never find "in the wild", and in the very rare cases where it might happen - there are no recognized standards on how to allocate from that area.

Fun stuff to think about!

Thanks very much for releasing v. 1.2. Wonderful that you no longer have any memory limits!

With this version, I'm able to extract all my .7zip archives.

When I go to "About" I get "This archive supports up to 1536 MB", which is plenty of memory.

I've extracted archives with up to a 256mb dictionary perfectly.