DOS/4GW Fatal Error (1307): not enough memory

Question

I'm trying to run a dos/4gw application in Win7 32 bit OS. I'm getting the following error message, DOS/4GW fatal error (1307): not enough memory

When I run the same application in WinXP 32 bit OS, it works fine and no issues.

The dos/4gw application was built using the Watcom C compiler.

The mem command shows the following avaiable memory,

655360 bytes total conventional memory 655360 bytes available to MS-DOS 580640 largest executable program size 16777216 bytes total EMS memory 16777216 bytes free EMS memory 32505856 bytes total contiguous extended memory 0 bytes available contiguous extended memory 15580160 bytes available XMS memory MS-DOS resident in High Memory Area

From the above it is clear that the memory is less than 1MB. However my program needs more than that. Basically I need to extend my DOS memory to get more than 1MB of memory for running my dos/4gw application.

Could any one please help in resolving this memory issue?

Thanks!

-Anand

Answer 1

The answer to the question is the reply sent by doynax:

"I believe there is a shim in recent versions of Windows limiting the available DPMI memory to 32 MB, for yet more ancient software incapable of unprepared such wast quantities of RAM. You may try creating a DpmiLimit key under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW in the registry to adjust this with the limit in bytes as a DWORD"

Answer 2

I wanted to help preserve why this setting exists, before it's lost to history.

Short Version: Broken DOS extenders used 16-bit signed integers. Anything larger than 32,768 bytes (32 MB) will cause them to fail.

---

Thomas R. Nicely had a post in 2007 that points out the problem:

Windows Vista restricts non-Win32 apps to 32 MB of memory (archive)

And then there's a 2010 usenet post that reminds us that an operating system limiting the amount of memory available to DPMI:

• has existed since the beginning of virtual memory (e.g. OS/2)
• exists to prevent misbehaving DPMI applications from trying to allocate 2 GB of memory (because memory is virtual)
• for old games you can find FAQs that give the DPMIs you should apply

---

I recently came across Thomas R. Nicely's WWW page on Windows Vista's DPMI server. It's pretty confused. (These people have some quite sensible things to say on the matter of M. Nicely's page.) And no wonder that it is, if this was how you explained things to M. Nicely, as xe claims you did. (-:

This DPMI server limit is another case in point, as a matter of fact. M. Nicely presents this as some sort of mysterious conspiracy against gcc. In actual fact, as pointed out by M. bwakaz, it's simple defence against all of the stupid and broken things that DPMI-based extended DOS applications are known to do, such as allocating all of the memory that is available at program startup, because they are badly written. M. bwakaz points to an article by Raymond Chen that anyone wanting to understand this should read.

This DpmiLimit setting that you mentioned is in fact nothing new. It's simply undocumented on Windows NT 6. OS/2 VDM's have had a documented DPMI memory limit setting for almost two decades. The setting is DPMI_MEMORY_LIMIT. You can read on Usenet and the WWW hundreds of discussions of this, going back to about 1994, and the reasons for tweaking it up and down. On an OS/2 system one can open up a VDM settings notebook, and obtain on-line help describing the setting.

Raymond Chen singles out DOS games as some of the particular offenders when it comes to abusing DPMI, and there's a whole FAQ for running DOS games under OS/2 that lists the various different DPMI_MEMORY_LIMIT (and other) settings for getting such games to play nicely with the operating system and not chew up memory unnecessarily, just because the DPMI server in the VDM would otherwuse allow them to.

Again, NTVDM isn't being "weird", at all. It's implementing a setting, and a limit, that is par for the course in Virtual DOS Machines. Even the default of 32MiB isn't unusual. The default for DPMI_MEMORY_LIMIT in OS/2 VDMs was (in recent versions of OS/2, if memory serves) 64MiB. If you read Raymond Chen's article all of the way to the end, there's even an explanation of why such values are the defaults: It's to cope with the broken extended DOS programs that measure available DPMI memory in KiB using 16-bit integers. (NTVDM's default assumes signed 16-bit integers. OS/2's VDM default assumes unsigned 16-bit integers.)

All of these things — be they traps into the VM monitor from inside the VDM, or DPMI server limits to control badly written DOS programs — aren't NTVDM being "weird" or unusual, or secret conspiracies by Microsoft against people who think that compiling with gcc means that one is compiling extended DOS programs. They're simple long-standing practice for VDMs, and run-of-the-mill stuff for virtual machine technology that goes back for decades.