mem: fix XMS totals, conventional-memory fallback, and UMB strategy r… - #129
mem: fix XMS totals, conventional-memory fallback, and UMB strategy r…#129stuaxo wants to merge 2 commits into
Conversation
…eset - Query the true installed extended memory via INT 15h (E801h/88h) instead of showing XMS free as both total and free - the old code always reported "Used: 0" for XMS. Clamp total to at least what XMS reports free, since under dosemu2 the virtual XMS pool can exceed what the legacy BIOS call reports (verified: BIOS said 8MB, XMS said 16MB free). - Always prefer the INT 12h conventional memory total over the walked MCB arena sum, instead of only when it happened to fall under a hardcoded 640K - the arena sum practically never reaches that anyway since it excludes the resident kernel/IVT/BDA. - Stop going through link_umb()/unlink_umb(), which reset the DOS allocation strategy to 0 on exit instead of restoring whatever it was before MEM ran. Do the UMB link/unlink directly so MEM never touches allocation strategy at all. - Drop xms_largest_free_kb, which was written but never used. Verified by building via dj64 and running `mem`, `mem /free`, and `mem /classify` under dosemu2. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LXhmrYNJuXB2yoWRAkQAd7
|
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. |
|
Also please compare to the |
Downloads (and caches) the real FreeDOS 1.4 MEM.EXE, drops it into an isolated dosemu2 sandbox alongside a freshly built comcom64.exe as command.com, and runs both /debug, /free, and /classify in the same session for side-by-side comparison. Automatically asserts EMS total/free match exactly between the two, since those are independent of which shell loaded the tool. Verified against this by hand: conventional/upper block boundaries and sizes agree once accounting for FDMEM.EXE's own PSP/environment/program footprint (it's a real loaded .EXE; comcom64's MEM is built into the shell). The one structural difference - FreeDOS shows an extra "IO system data" block at segment 0070 that comcom64 doesn't - is not a bug: FDPP's own kernel header (hdr/lol.h) documents the list-of-lists pointer we use as "Start of user memory", i.e. it's meant to exclude the kernel's own resident footprint. FreeDOS's MEM.EXE shows it via kernel-internal knowledge that isn't part of the portable INT 21h/52h API comcom64 relies on (comcom32 needs to work under other DOS kernels too, not just FDPP). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LXhmrYNJuXB2yoWRAkQAd7
7efab84 to
e7eef55
Compare
|
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. |
|
Actually his test is still here: |
I'm working on it today. |
|
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. |
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. |
3 participants
I need to test this, though in the meantime -claude said this: