If it will run, even if badly under a Win 3.x session, then maybe windows tools will tell you

In the DOSBox debugger, there is a "DOS MCBS" command which should show you information like the DOS "MEM" command since it's looking at the same data structures. I can't remember exactly how it works even though I wrote it, as I don't have a compiled version of the debugger around 😁

A TSR sounds nice. I found http://cd.textfiles.com/simtel/simtel9703/dis … /DISC2/MEMUTIL/ which contains TRKMEM10.ZIP which can either write output to the screen while the program is running (not great if the program wants to control the screen) or write to a second monitor (do any emulators support a second, MDA adapter?). Also it's shareware and you should only use it for 30 days unless you can track down the author and register it or get them to change the license. Looking through old memory utilities on Simtel, etc. CDs on that site might be useful.

BitWrangler wrote on 2023-03-13, 16:42:

If it will run, even if badly under a Win 3.x session, then maybe windows tools will tell you

I have no proper experience with Win 3.x. Doesn't it use a lot of conventional memory? Some of the games I aim to test require upwards of 600 KB and more.

doshea wrote on 2023-03-15, 10:55:

In the DOSBox debugger, there is a "DOS MCBS" command which should show you information like the DOS "MEM" command since it's looking at the same data structures. I can't remember exactly how it works even though I wrote it, as I don't have a compiled version of the debugger around 😁

A TSR sounds nice. I found http://cd.textfiles.com/simtel/simtel9703/dis … /DISC2/MEMUTIL/ which contains TRKMEM10.ZIP which can either write output to the screen while the program is running (not great if the program wants to control the screen) or write to a second monitor (do any emulators support a second, MDA adapter?). Also it's shareware and you should only use it for 30 days unless you can track down the author and register it or get them to change the license. Looking through old memory utilities on Simtel, etc. CDs on that site might be useful.

I don't really use Dosbox. A proper DOS method would be much better.

I don't even know how you found that TSR program. 😁 I tried it but either get a black screen, or the keyboard indicator just keeps blinking, as if it's loading something, but nothing happens. As you pointed out, it probably only works with programs that don't use the screen.

eddman wrote on 2023-03-16, 22:13:

I have no proper experience with Win 3.x. Doesn't it use a lot of conventional memory? Some of the games I aim to test require upwards of 600 KB and more.

I did a quick test and Windows for Workgroups 3.11 used 13.2KiB of conventional memory when started under MS-DOS 6.22 with QEMM, 4DOS and various TSRs loaded:

MEM output in DOS:

1Memory Type        Total  =   Used  +   Free
2----------------  -------   -------   -------
3Conventional         640K      117K      523K
4Upper                  0K        0K        0K
5Reserved             384K      384K        0K
6Extended (XMS)    64,512K    2,912K   61,600K
7----------------  -------   -------   -------
8Total memory      65,536K    3,413K   62,123K
9
10Total under 1 MB     640K      117K      523K
11
12Total Expanded (EMS)                64,784 (66,338,816 bytes
13Free Expanded (EMS)                 61,664 (63,143,936 bytes
14
15Largest executable program size       523K (535,056 bytes)
16Largest free upper memory block         0K       (0 bytes)
17The high memory area is available.

DOS prompt in Windows:

1Memory Type        Total  =   Used  +   Free
2----------------  -------   -------   -------
3Conventional         640K      131K      509K
4Upper                  0K        0K        0K
5Reserved             384K      384K        0K
6Extended (XMS)    64,512K   63,488K    1,024K
7----------------  -------   -------   -------
8Total memory      65,536K   64,003K    1,533K
9
10Total under 1 MB     640K      131K      509K
11
12Total Expanded (EMS)                1,024K (1,048,576 bytes)
13Free Expanded (EMS)                 1,024K (1,048,576 bytes)
14
15Largest executable program size       509K (521,520 bytes)
16Largest free upper memory block         0K       (0 bytes)
17The high memory area is available.

I'm pretty sure that there is only 1MiB each of EMS and XMS free because that's all the .PIF file specifies.

There are probably opportunities to optimise that. Windows does require HIMEM and maybe EMM386, or at least some equivalents, so that might limit how much conventional memory you can free, but I haven't tried in this particular VM. I probably haven't tried since 1995 😁

I don't even know how you found that TSR program. 😁 I tried it but either get a black screen, or the keyboard indicator just keeps blinking, as if it's loading something, but nothing happens. As you pointed out, it probably only works with programs that don't use the screen.

Fair point regarding finding it! I just knew to look in the directories for a simtel CD for a directory called "MEM" something and then took a look in the 00INDEX.TXT file or whatever it is called for the descriptions. Sometimes a Google search using "site:cd.textfiles.com" in the query can be useful to only search that site.

It looks like 86Box supports emulating a second display in the way that program wanted: https://86box.readthedocs.io/en/latest/settings/display.html I've never used 86Box though.

The DOSBox solution is probably a lot simpler though. DOSBox can sneakily look at memory without having to have anything loaded which your program can see.

Alternatively if you like Bochs I have a solution like DOSBox's "DOS MBCS" for that as part of a debugger GUI I'm writing for it, but it's not in a state where I'd really like to release it yet and I haven't worked on it for quite a while.

I'm trying Win 3.1 now and it shows 609 KB of free memory, which is quite enough. The MEM command under windows says the entire upper memory is used up, although it doesn't seem to be affecting games.

The issue is that after I minimize the game and run the MEM command from another DOS prompt window, it still shows 609 KB free and doesn't see the game.

eddman wrote on 2023-03-17, 14:27:

The issue is that after I minimize the game and run the MEM command from another DOS prompt window, it still shows 609 KB free and doesn't see the game.

If one DOS prompt could see what was running in the other DOS prompt, it wouldn't be great for running multiple DOS programs at once, because they couldn't see each other without actually being in the same memory space. The fact that they can't see each other is a great feature!

I think the only way you could possibly do it is with some Windows tool that can see the memory usage inside the virtual DOS machine. I suspect that it isn't something the Windows API allows though. I tried the "Hogs" program I mentioned in this thread but it didn't show what was running in the DOS prompt, it just showed WINOLDAP or whatever it is, and its memory usage didn't change based on what I did inside the DOS prompt.

I had a quick look at some old shovelware CDs of Windows software for utilities mentioning "DOS" but there was hardly anything and certainly nothing that mentioned it could find out about memory usage.

My recollection from some reading I did last year is that a Windows application can't even capture the text from a DOS prompt except by sending the keystrokes necessary to copy it to the clipboard, so I think visibility into DOS prompts just isn't something that Microsoft cared to support so it might not be possible.

I wonder if more modern versions of Windows (9x or later) plus Process Explorer would be any more effective, but I suspect not. I think from Windows's perspective, a DOS prompt running in Windows isn't much different from a more full-featured emulator like PCem, Bochs, Qemu, etc. - it's just an application containing a virtual machine and it would be difficult and generally not very useful for Windows to know what is inside the virtual machine, except to the extent that for a virtual DOS machine Windows has to know for input and output, e.g. for clipboard support.

One other thought: if all you want to know is the peak memory usage - or better "is the peak memory usage no greater than X" - perhaps you could use the Windows 3.x PIF Editor (look in Program Manager's Main group) to make a .PIF file which restricts the available memory and then see if the game still runs. Of course if you want to find the actual peak it might be really annoying to have to keep running lots of tests in a binary search, e.g.:

640K - ok
500K - bad
570K - bad
605K - ok
588K - bad
597K - bad
601K - ok
599K - ok
598K - bad - so it's 599K

I'd want to automate it if I was going to do a lot of this!

Are you looking for ways to estimate memory requirements for the game (some fixed minimum that would be always enough), or ways to look into the dynamics/statistics of memory allocations throughout the game?
I'm looking for topics for my DOS programming exercises, this could be both fun and useful.

doshea wrote on 2023-03-18, 00:32:

One other thought: if all you want to know is the peak memory usage - or better "is the peak memory usage no greater than X" - […]
Show full quote

One other thought: if all you want to know is the peak memory usage - or better "is the peak memory usage no greater than X" - perhaps you could use the Windows 3.x PIF Editor (look in Program Manager's Main group) to make a .PIF file which restricts the available memory and then see if the game still runs. Of course if you want to find the actual peak it might be really annoying to have to keep running lots of tests in a binary search, e.g.:

640K - ok
500K - bad
570K - bad
605K - ok
588K - bad
597K - bad
601K - ok
599K - ok
598K - bad - so it's 599K

I'd want to automate it if I was going to do a lot of this!

That's what I do usually by manipulating the available memory, although under DOS. It's rather cumbersome and time consuming. A solution to directly see the memory usage of a game would make it very straightforward.

vstrakh wrote on 2023-03-18, 07:49:

Are you looking for ways to estimate memory requirements for the game (some fixed minimum that would be always enough), or ways to look into the dynamics/statistics of memory allocations throughout the game?
I'm looking for topics for my DOS programming exercises, this could be both fun and useful.

I've made a setup with HIMEM, EMM386, CD, mouse and Smartdrv and 618 KB of free conventional memory. I intend to test different games, check the exact amount of conventional memory they use, and make a list of them. I'd then potentially post it on vogons.

Some games mention the exact conventional memory they need in the requirements or the readme file, but many don't.

There might be no clear ways to "see" the actual needs of the app.
When the DOS application is started the DOS will check the EXE file header for a bare minimum requirements - the size of the code, stack, uninitialized data segments. If it fits - the DOS will launch the EXE, but that's still not an indication if dynamic needs of the app is satisfied. The app might not even bother to call DOS for memory allocations because everything above the app's required minimum is already allocated to the app. The app will perform it's own checks, and might fail with error at some point in time later.

Here's the app to report memory needs as stated in EXE header. This could be a starting point for more detailed tests.

To catch the app's dynamic consumption it would be required to make it fail, and this is also not clearly defined. How do you know if the app is running ok or bailing out with error message? By the time it took for you to exit? What if it fails much later? If the app is leaking resources (memory/files) when not terminating cleanly - then restarts will require DOS reboot to cleanup all the mess.

vstrakh wrote on 2023-03-19, 13:18:

Here's the app to report memory needs as stated in EXE header. This could be a starting point for more detailed tests.
min_memory_required.zip

Unfortunately it isn't useful for this purpose. The values it reports are very off compared to what the games actually need to launch.

I understand that programs dynamically use the memory. I was thinking of some kind of a TSR program, where a game's exe is launched through it, and it constantly monitors the peak memory usage, and when the game is exited after say 2 minutes, it reports the highest usage it recorded.

Only the early memory usage of games are important for what I have in mind, which includes launching them and entering the first mission.

eddman wrote on 2023-03-19, 17:49:

I was thinking of some kind of a TSR program, where the games' exe are launched through it, and it constantly monitors the peak memory usage

There is no such thing, simply because the whole conventional memory is always allocated to the application, and it's free to do whatever it needs within that area.
The way the applications are launched by DOS - there's simply no defined ways to know what's app actually using.
If it was the other way around (only minimum given), and the app was required to ask some memory from dos - then it would be possible to log things by hooking the int 21h functions. Some applications may actually do that - shrink their allocation to minimum, and then delegate dynamic memory handling to the dos, because they don't have their own memory management features. But that's rather exception, not the rule. The norm would be to grab everything, and then use only some part of it.
So the only more or less practical way - is to limit the available ram, and see if the app runs ok through the whole expected process.

I think the same, more or less.

Though maybe some of the multi-tasking "DOSes" can help. PC-MOS/386, Concurrent DOS, Real/32..

They don't magically list the amount of memory perhaps, either, but allow limiting RAM more fine.

Alternatively, DesqView can be used to create DOS "VMs" with a limited amount of memory.

vstrakh wrote on 2023-03-19, 18:15:

There is no such thing, simply because the whole conventional memory is always allocated to the application, and it's free to do whatever it needs within that area.
The norm would be to grab everything, and then use only some part of it.

Everything?! So if I have, say, 610 KB of free memory, and launch a game that needs only 570 KB, it would still take the entire 610 KB?

That's not good. I suppose I'd have to artificially limit the memory for every game then. I'm not sure I even want to do that with dozens of games.

eddman wrote on 2023-03-19, 18:41:

Everything?! So if I have, say, 610 KB of free memory, and launch a game that needs only 570 KB, it would still take the entire 610 KB?

Even if your app requires 10KB, the DOS allocates for it all 610KB you have 😀

Another issue to consider - the dynamic memory needs will depend on the app configuration. It needs more for sound, and how much more depends on the hw being selected. It needs something more if optional XMS use is enabled, etc. You get the idea. You can't just say "this app needs XXX KB", that one number can't cover all possible configurations.

It should be quite easy to make the app that cuts away the conventional ram and retries to launch the game, doing binary search for the app's reaction. But you have to define the ways to let that app know how the game reacted, how to determine if the launch was successful or not. And be prepared that the app might screw up the whole testbench because it exited abnormally and didn't release some resources properly.

Oops, I forgot that that is how memory is allocated in DOS, thanks vstrakh!

While I mentioned that Windows .PIF files can be used to limit the available RAM, and other options have also been suggested, a simpler option is probably just a simple DOS tool like EATMEM: Dos command to allocate memory

vstrakh wrote on 2023-03-19, 18:56:

It should be quite easy to make the app that cuts away the conventional ram and retries to launch the game, doing binary search for the app's reaction. But you have to define the ways to let that app know how the game reacted, how to determine if the launch was successful or not. And be prepared that the app might screw up the whole testbench because it exited abnormally and didn't release some resources properly.

I certainly seem to recall games which, if they failed to start, would corrupt memory so that you got an error loading COMMAND.COM or something after they exited.

If I was going to do it, I think I'd write a script which:
- did the binary search, picking available RAM amounts and then calculating how much memory would need to be wasted to make that much RAM available
- ran the game under DOSBox, e.g. 'dosbox -c "eatmem 99" -c "rungame"' (assuming dosbox.conf already does the mounting)
- when DOSBox exited, asked me if the result was good or bad so it could pick the next binary search size
- restored the game directory from a backup in case of any corruption then went back to the step where it ran DOSBox with the new size

Then as soon as I'm happy with the result or the game as died I can just close the DOSBox window rather than go through the process of exiting, although once I'd settled on a number, I'd re-test it and go through the exiting process just in case that required more memory than the rest of the game.

I might make a .BAT file to run the game which used SCANCODE from https://bretjohnson.us/ to send some keystrokes to the game to automate some of the process of starting it if possible. I think it can only read text screens but if it can be told to just wait for a few seconds before sending the key that might still be helpful.