2024-03-10

This week I modified inicomp and lDebug, and finished another lDebug release.

The changes primarily involved adding the lCFG block to the inicomp stage. This block is stored within the first 256 Bytes of the stage in order to support the use of ldosboot's checkpl checksumming stage.

The latter assumes that configuration blocks like lCFG or FreeDOS's CONFIG are found within the first 256 Bytes of the checkpl payload. To support this, that range is not checksummed by checkpl.

I did not implement the FreeDOS CONFIG block for any other stages yet, that is inicomp and fdkernpl. When this is added, however, the block should also live within the 256 Bytes area set aside for non-checksummed data in checkpl.

The only options implemented with the lCFG block yet are for choosing the default progress display of inicomp. This can be overridden by two DOS environment variables for a DOS device driver or DOS application mode, but this is not so for the bootloaded mode.

The current defaults are to use the progress display number 1 (dots) for bootloaded mode and none otherwise (corresponding to 0).

Because the progress display choice is set up before depacking, the lCFG block is not yet passed to the subsequent stage in any way. In the future, both an lCFG block or a FreeDOS CONFIG block likely may be passed to the next stage on the stack.

This is a new repo with two separate patch utilities. The patchpro application finds, displays, and optionally patches the progress display fields in the inicomp lCFG block. The other one, patchqry, instead can be used to access the query patch that's lived in the ldosboot iniload boot stage for a while now.

The advantage of the patchqry tool over the prior Script for lDebug shipped with ldosboot is twofold: As a C program, it can be built for any host system with a standard C compiler and libraries. And it can operate on files with arbitrary appended data as it does not need to load the entire file.

The patchini repo is actually a fork of the inicomp repo, as I started the two patch utilities in the inicomp repo. While patchpro only can be used on inicomp stages with an lCFG block, patchqry is for ldosboot's iniload so didn't fit into the inicomp repo. However, I wanted to keep both programs in the same repo as they are fairly similar and some of the changesets affected both source files in the same way.

The checkpl stage (as well as nullpl) was modified to put part of the device entrypoint into the alignment to offset 64 that is added for the application entrypoint. This would help to use less space for the ENTRY section. While no use is supported yet that requires the payload_first slice to stay near the beginning of the checkpl stage, I consider this desirable.

(As yet checkpl and nullpl are the only stages that slice the next payload in this way. Only checkpl is really supported for wrapping inicomp with an lCFG block.)

The debugger was updated to prepare for the new release.

• The doc mak script allows to skip the creation of svrevid.src (to enable building from the FreeDOS package)
• Update fdbuild.txt
• eldcomp.eld: Avoid different offset in XLD and ELD command line
• dpb.eld: Fix two wrong relocations
• test.py: Allow for DCO7 and DIF7 variables
• test.py: Allow displacement display in S command search results
• test.py: Fix DTOP command test displaying part of the debugger entry at 60h:0 rather than the intended data at 60h:100h
• test.py: Allow lCDebug executable and SLD filenames in BOOT DIR test
• boot.asm: Fix Y :label commands in bootloaded mode
• Support blanks after label colons everywhere
• Regular release changes

After the release, a bug was reported on the forum. The Protected Mode interrupt 21h handler for function 4Ch assumed that a 16-bit stack is in use. (Either the ss B bit or the esph word must be zero.)

The handler did switch stacks just after the transfer function that made this assumption, so the fix was simple: Switch stacks first, then do the transfer.

A different use of the transfer function occurs in the pmentry.asm source file if the _PM_ENTRY_SECTION build option is disabled. This may also involve a 32-bit stack and would fail then. A small debugging aid revealed that as expected dosemu2 and HDPMI both call exception handlers with a "16-bit stack". That is, albeit their ss B bit is set, the esph word always seems to be zero, so the stack operations assuming a 16-bit stack happen to work.

The easiest solution to this would be to disable or remove the option for _PM_ENTRY_SECTION=0 for these handlers. No other use of the transfer function appears to have a need for supporting 32-bit stacks so I'm unlikely to add this for this single optional use.