|
|
|
|
— |
blog:pushbx:2026:0125_late_mid_january_work [2026-01-25 16:28:11 +0100 Jan Sun] (current) ecm created |
| | ====== Late mid January work ====== |
| | |
| | **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. |
| | |
| | |
| | ===== MCP/CLU ===== |
| | |
| | * [[https://hg.pushbx.org/ecm/mcp/rev/14327bfa3d5b|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, [[https://hg.pushbx.org/ecm/mcp/file/f885328d4bdf/clu.asm#l146|CLU will usually enlarge the environment block by 32 bytes]] to anticipate the insertion.) |
| | * Bugfix, when inserting the COMSPEC variable [[https://hg.pushbx.org/ecm/mcp/rev/f885328d4bdf|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. |
| | |
| | |
| | ===== lDebug ===== |
| | |
| | * For disassembling mov with CR, DR, or TR registers, [[https://hg.pushbx.org/ecm/ldebug/rev/6114c3e73628|always treat the ModR/M byte as if Mod=3 was encoded]]. This is a documented quirk, which [[https://stackoverflow.com/questions/79870726/does-move-to-from-control-debug-registers-ignore-the-mod-field|I was made aware of by a stackoverflow question]]. |
| | * [[https://hg.pushbx.org/ecm/ldebug/rev/952433a1600d|Update to the debug tables include file]] from prior changeset. |
| | |
| | |
| | ===== lDOS kernel ===== |
| | |
| | In the exec.nas source text file, [[https://hg.pushbx.org/ecm/msdos4/rev/766df35bd8d7|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 [[https://github.com/LoopZ/TheList/issues/1#issuecomment-3780971188|I reviewed it for the report]] to the repo of "the list", in which [[https://github.com/LoopZ/TheList/issues/1|I suggested possible additions to the interrupt list]]. |
| | |
| | |
| | ===== Question on the PSP environment field for DOS extenders ===== |
| | |
| | In the forum, I asked [[https://www.bttr-software.de/forum/forum_entry.php?id=23105|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. |
| | |
| | {{tag>mcp clu ldebug ldos msdos4 thelist forum}} |
| | |
| | |
| | ~~DISCUSSION~~ |
| |