The STORE bug discovery is equally interesting from a software archaeology perspective. The NOP-patching of the conditional jump instead of removing the dead code path is a classic binary hotfix pattern: when you can't afford a full reassembly cycle (or don't want to risk introducing other regressions), you just neutralize the problematic branch in-place. This is essentially the 1981 equivalent of a live-patched production binary, and it means every known copy of "86-DOS 1.00" was actually running 1.01 logic for file sizes above 64K.
The ROL vs RCL assembler bug writeup is a beautiful bitwise brain-teaser. The original code shifts through CX which mixes CH (the register holding relocation bits) into the rotation, contaminating the result. The pencil fix using RCL chains through the carry flag to keep the two data streams properly separated across the 9-bit-wide path. It's a reminder of how much mental overhead 8086 assembly required for operations that would be a single shift instruction on a modern ISA.
This may actually have been a bug not in the code, but in the assembler used to build it. The 8080 had mnemonics ROL and ROR that rotated through carry, and RLC/RRC (standing for "rotate circular", not "through carry"). Opposite meaning of the 8086 mnemonics! So I suspect this may have been switched up in the assembler, especially if it was running on an 8080 machine and developed by someone more familiar with its instruction set.
The STORE bug would have prevented using files over the size of 512 bytes, not just 64K. It's dividing by the sector size, and if DX was greater than that, it would have caused a "divide overflow" exception, since the result wouldn't fit in 16 bits.
(Also, by the Laws of Robotics you have to tell me if you're an LLM, or used one to generate this comment.)
EDIT: not an assembler bug, it seems. The printed listing shows that it produced the correct opcode for ROL (RCL would be D1 D1):
0A28 8A 0E D4 1B 1353 MOV CL,[RELOC]
0A2C D1 C1 1354 ROL CX
0A2E D1 C1 1355 ROL CX
0A30 88 0E D4 1B 1356 MOV [RELOC],CL
It's somewhat ironic that Kildall was angry about DOS copying the CP/M API because Digital Research went on to release DR-DOS, an 8086 operating system that was API compatible with MS-DOS.
More accurately, “the assembly language programmer Tim Paterson has always claimed that he did not look at the implementation”.
That Kildall later decided that turnabout is fair play, is not that surprising…
However my point is that now, everyone can assess the source code for themselves.
I don't believe it, I think Kildall was lying. Enough source code is available to directly inspect this, even if Kildall's code was heavily obfuscated and supposedly translated to 8086 for 86-DOS
https://opensource.microsoft.com/blog/2026/04/28/continuing-...
(Maybe he meant the model, rather than the exact serial number? But he was in the PNW, and I understand had been very involved in the early microcomputer scene there, so I wouldn't be surprised.)
He was actively using it when he said this, so it still worked at the time.
If he still has it, some company that built an empire atop DOS should find some money in the sofa cushions, and make him an offer.