2026-01-25

This week a little work happened. The MCP and CLU also got alternative backronyms to describe what they do: Multiple Command Payload and Comspec Load Utility.

• Try to enlarge CLU's environment if insertion of the COMSPEC variable fails. Due to a hack, this is likely only needed when the CLUMCPFLAG indicates that CLU shouldn't relocate its process. (The hack is that if the process is relocated, CLU will usually enlarge the environment block by 32 bytes to anticipate the insertion.)
• Bugfix, when inserting the COMSPEC variable avoid an off-by-one error. The bx register already points behind the NUL of the pathname to insert, so bx - pathname gives the full length - the spurious +1 was under the assumption that bx pointed at the NUL. In practice this could truncate the environment or corrupt the name of the next environment variable.

• For disassembling mov with CR, DR, or TR registers, always treat the ModR/M byte as if Mod=3 was encoded. This is a documented quirk, which I was made aware of by a stackoverflow question.
• Update to the debug tables include file from prior changeset.

In the exec.nas source text file, add a comment on the MZ .exe image read loop. In particular, if the file is >= 512 bytes short for the given exePages size, the exec call errors out. exeExtraBytes is never read. Due to the choice of boundaries for the loop, a non-last read being 1 to 511 bytes short will always lead to the subsequent read to be at least 512 bytes short, so the desired invariant is upheld.

I suspected that there may be a bug in this loop because I reviewed it for the report to the repo of "the list", in which I suggested possible additions to the interrupt list.

In the forum, I asked what happens if a DOS extender changes the PSP environment word from a segment to a selector, and then an exec runs with a zero-value for the source environment. Two replies by tkchia indicate the DOS extender will simply handle the exec as well, so it can intercept attempts to run exec that would read from the PSP.