mem: report DPMI memory

[claude]

Before: mem said nothing about DPMI memory. So there was no way to see that the shell already holds about 19 MB of the DPMI pool before any program runs.

After: under the EMS lines, mem prints the total, used and free DPMI memory and the largest free DPMI block:

Total DPMI memory                   131,072K (134,217,728 bytes)
Used DPMI memory                     19,192K (19,652,608 bytes)
Free DPMI memory                    111,880K (114,565,120 bytes)
Largest free DPMI block             111,880K (114,565,120 bytes)

That output is from dosemu2 with the current stub. The stub's SmallerC DPMI loader keeps its default 16 MB -maxheap for the whole session. When the same comcom64 is relinked with a stub built with -maxheap 0x80000, Used DPMI memory drops to 3,320K.

How: the numbers come from __dpmi_get_free_memory_information() (int 31h AX=0500h). A field the host reports as -1 is skipped. These are separate lines, not a table row. Some hosts take DPMI memory out of XMS and others (dosemu2) keep a separate pool, so adding it to the totals could count the same memory twice. The labels don't collide with the ones test/func_comcom_internal.py in dosemu2 parses.

🤖 Generated with Claude Code

[claude]

build is red because of the environment, not this diff. comcom64 builds fine, and both debs are produced. The failure is in ci_test_prereq.sh: apt install ../comcom*.deb dosemu2 fdpp cannot install dosemu2 from ppa:dosemu2/ppa:

dosemu2 : Depends: libdjdev64-0 (>= 0.5) but it is not going to be installed
          Depends: libdjstub64-0 (>= 0.5) but it is not going to be installed

As a result, /usr/share/comcom32/comcom32.exe never gets installed and the test fails in setUpClass.

Cause: djdev64 is packaged with debhelper-compat (= 12), so dh_makeshlibs defaults to -VUpstream-Version and its shlibs say libdjdev64-0 (>= 0.5). The PPA snapshots are versioned 0.5-0~<date>, and dpkg --compare-versions 0.5-0~202609230803~ubuntu24.04.1 ge 0.5 is false. This reproduces locally with apt-get -s install dosemu2. It will fail the same way on master: the last green master run is from 19.09, before djdev64 was split out.

The fix belongs in djdev64 packaging (e.g. override_dh_makeshlibs: dh_makeshlibs -VNone in debian/rules), followed by a PPA rebuild of djdev64 and then dosemu2. Nothing in this PR can fix it. I'm not re-running the job, because the failure is deterministic.

[stsp]

Why rebuild dosemu2?

[claude]

Because the (>= 0.5) is baked into the already built dosemu2 package. dosemu2's debian/control only has ${shlibs:Depends}, and dpkg-shlibdeps filled it at build time from the shlibs file of the libdjdev64-0 that was installed then. The current PPA dosemu2 (2.0~pre9-10330-5fd658996+202609230943) carries Depends: libdjdev64-0 (>= 0.5), libdjstub64-0 (>= 0.5). A djdev64 rebuild with -VNone changes the shlibs of future builds only; this dosemu2 deb would stay uninstallable until it is rebuilt (the next nightly would do it anyway).

The one way to avoid touching dosemu2 is to make djdev64's version sort above 0.5, e.g. 0.5+git<date> instead of 0.5-0~<date>. Then the existing dependency is satisfied as is.

[stsp]

Thanks!