The very first revision of iniload was checked into the repo on 2017-10-03 (the annual Tag der deutschen Einheit "day of german unity", a public holiday).
It only supported MS-DOS v6 / IBM-DOS, MS-DOS v7, and lDOS load (all the ones requiring subsequent loading by the "msload" stage). The latter, lDOS load, still without the "lDXX" signature. (The signature was added on 2020-01-22 and first checked the same day in boot.asm and likewise in boot32.asm and by lDebug's loader. The signature was first set, to "lDeb" or "lDDb", for lDebug again the same day.) So loading it with boot protocol ldos
in recent lDebug requires specifying checkvalue=0
.
The structure is mostly the same as in the current revision, except for a few points. Of course, the FreeDOS (as of 2018-01-21) and Enhanced DR-DOS entrypoints (as of 2024-01-02) aren't there yet. An MS-DOS v1 (flat-format) application entrypoint (as of 2020-04-01) is also not yet included. The LBA check still occurs in read_sector for every call, rather than having it moved into query_geometry. (The move was initially (on 2018-01-13), I presume, for performance of not calling 13.41 repeatedly, as well as to allow its results be manipulated with the query patch, which also only was added later.) Also, query_geometry is called in two spots, depending on whether the FS is FAT12 (which needs it called before reading the FAT) or not. (That was changed in this largely unrelated 2019-12-27 change.)
FAT32 support was there from the very beginning. However, if we try to boot this earliest revision off a FAT16 or FAT32 file system, one particularly critical bug rears its head. The FAT access didn't set es if the current FAT sector is already buffered. The fix followed on the same day.
(As an aside, the first revision of bootimg was only created on 2019-07-26 so testing was more complicated back when iniload was first created. Likewise, the initial commit of instsect is only from 2018-02-24.)
RPL memory size adjustment was supported, albeit it expected ds to equal zero on entry, which was fixed the same day too.
The sector segment buffer was supported already, a good thing as even the early lDOS load protocol was expected to load the file at 00700h (with entry at 70h:400h). So with a file >= 64 KiB the 64 KiB ISA DMA boundary would be crossed by one of the reads. The sector segment buffer was only used upon detecting an error 09h from int 13h (which was changed on 2025-10-12).
Many of the error messages known from the modern iniload were already present, in ASCIZ format. (The change to dot-terminated messages occurred only very recently, on 2025-10-12, in the experimental lDOS boot repo.)
The skip_next_clust + skip_next_sect loop was still mirrored by load_next_clust + load_next_sect, which still lived next to the former within the 1536 bytes loaded by MS-DOS v6 / IBM-DOS load. The loaded_all entry was minimal: It only transfered control to the payload, not even cleaning the stack of the load next loop. (The stack cleaning was added on 2017-10-12.)
A multi-mode (_IMAGE_EXE) or second payload wasn't supported yet, the file was supposed to encode an invalid MZ header so it wouldn't be loaded. This had exePages = exeHeaderSize = exeMinAlloc = -1. Notably, the current iniload has exeHeaderSize = 0 instead (since 2018-10-18) when building without an application or device driver entry.
There are three main incompatibilities with modern payloads: The kernel mode entrypoint is fixed at +0:0 (rather than being configurable to alternatives like +0:32 as of 2017-10-08), the query patch value isn't passed to the kernel (like as of 2022-12-29) instead retaining the ldLoadingSeg value, and a kernel command line isn't passed (like it is as of 2020-01-01) leading the payload to access memory in unclaimed stack space. Both of the first ones are irrelevant for the current lDOS kernel but will affect the bootloaded lDebug as a kernel mode payload.
The original iniload can be used to load a current lDDebug payload by patching ddebug.big to start with EB 1E
, disabling the checksum, and fixing the FAT buffer bug manually as in the following log:
boot protocol ldos checkvalue=0 oldini.sys -e ss:bp-C as words (-1) (-1) 0 400 -g 2D3 3D6 AX=000A BX=00A2 CX=0000 DX=0000 SP=01FC BP=0220 SI=0000 DI=0008 DS=7255 ES=727C SS=7255 CS=0200 IP=02D3 NV UP DI PL NZ NA PE NC 0200:02D3 31D2 xor dx, dx -r es = word [ss:bp - 8] -g 2D3 3D6 AX=0008 BX=00A4 CX=0000 DX=0000 SP=01FC BP=0220 SI=0000 DI=0008 DS=7255 ES=11E0 SS=7255 CS=0200 IP=02D3 NV UP DI PL ZR NA PE NC 0200:02D3 31D2 xor dx, dx -r es = word [ss:bp - 8] -g 2D3 3D6 AX=0008 BX=00A6 CX=0000 DX=0000 SP=01FC BP=0220 SI=0000 DI=0008 DS=7255 ES=19E0 SS=7255 CS=0200 IP=02D3 NV UP DI PL ZR NA PE NC 0200:02D3 31D2 xor dx, dx -r es = word [ss:bp - 8] -g 2D3 3D6 AX=16CC BX=20A0 CX=000B DX=0002 SP=01FA BP=0220 SI=0000 DI=0008 DS=7255 ES=2080 SS=7255 CS=0200 IP=03D6 NV UP DI PL ZR NA PE NC 0200:03D6 8CC8 mov ax, cs -g ~-q Boot load called -
The initial Enter command, e ss:bp-C as words (-1) (-1) 0 400
, delays the FAT buffer bug by one clust_next call as it invalidates the buffer passed to the iniload lDOS entrypoint, so the first call will actually read from the FAT and set es in the process, but doesn't ultimately help fix things if clust_next is called multiple times during the load (which it is most likely). The bug doesn't occur on FAT12 file systems.
On 2017-10-05 the three size warning messages were added (for "ms7_entry", "ldos_entry", and "end"), as well as the final ("end") fill mmacro use to ensure the loader doesn't overflow 1536 bytes. The very first revision weighs in at 1524 bytes, as displayed by the original size warning message ("Loader ends at 1524").
The remaining iniload bugfixes in 2017 October:
Discussion
The read_sector function didn't reset lpCount yet: https://hg.pushbx.org/ecm/ldosboot.exp/file/36de8307b26a/iniload.asm#l265
The file walk code still used cx for determining the subsequent => past next read sector, necessitating it be preserved to use as sector-in-cluster counter: https://hg.pushbx.org/ecm/ldosboot.exp/file/36de8307b26a/iniload.asm#l723
The FAT12 was already loaded in full: https://hg.pushbx.org/ecm/ldosboot.exp/file/36de8307b26a/iniload.asm#l1000
It was already intended to allow relocation down to 00610h at the lowest: https://hg.pushbx.org/ecm/ldosboot.exp/file/36de8307b26a/iniload.asm#l1056
The MS-DOS v7 "BJ" signature (
inc dx
thendec dx
) was still commented as being related to FAT32: https://hg.pushbx.org/ecm/ldosboot.exp/file/36de8307b26a/iniload.asm#l473 Fixed on 2017-12-12: https://hg.pushbx.org/ecm/ldosboot.exp/rev/98e2e08add67finish_load didn't have a shortcut for the file/payload already being fully loaded, so it had to walk the entire file even then: https://hg.pushbx.org/ecm/ldosboot.exp/file/36de8307b26a/iniload.asm#l693 (FreeDOS/EDR-DOS load necessitated this check because it doesn't pass a starting cluster number.)
skipped_all label was placed directly in the load loop, as the check before it didn't modify bx (using cx instead) so it didn't need to be restored: https://hg.pushbx.org/ecm/ldosboot.exp/file/36de8307b26a/iniload.asm#l738
256 sectors per cluster was supported already: https://hg.pushbx.org/ecm/ldosboot.exp/file/36de8307b26a/iniload.asm#l912
Your link https://hg.pushbx.org/ecm/ldosboot.exp/file/36de8307b26a/iniload.asm#l473 requires sign-in.
That's intended. While the prompt unfortunately doesn't (yet?) indicate how to sign in, it is described on the website:
With that it's fine, thanks!