OTOH, Micropro had 8080 originated Wordstar running on the 5150 in weeks.
It took them longer to edit the manuals than to port the code.
Likewise Supercalc, etc.
On Tue, 17 Apr 2018, Warner Losh wrote:
Part of that too was because MS-DOS provided CP/M programming interfaces,
so in many ways it was CP/M with a bag on the side...

Certainly.

But, Q-DOS didn't have much of a bag. It was mostly a rewritten copy of CP/M with a different data structure for disk directory.

LATER, starting with MS-DOS 2.00, there was a major bag of sub-directories and "unix style" file handling (file handles V File-Control-Block)

And much later, for "long filenames" (Win95), MICROS~1 used a kludge bag, keeping the old 8.3 Directory structure and using "excess" directory entries for storage of the long nicknames. HINT: do NOT use "long filenames" for anything in the root directory.

WINDOWS itself started as a bag hanging off of the side. Originally, MS-DOS clearly documented what was needed for a replacement command processor. (Was it 2.11? or 3.00? when IBM removed the appendix from the PC-DOS manual, and started marketing it as "PC-DOS Technical Reference Manual" (still with "appendix" page numbering))


I always found it amusing that many programs (even FORMAT!) would fail with the wrong error message if their internal DMA buffers happened to straddle a 64K block boundary. THAT was a direct result of failure to adequately integrate, or at least ERROR-CHECK!, the segment-offset kludge bag. Different device drivers and TSRs could affect at 16 byte intervals where the segment of a program ended up loading. It was NOT hard to normalize the Segment:Offset address and MOVE the buffer to another location if it happened to be straddling.

--
Grumpy Ol' Fred                 ci...@xenosoft.com

Reply via email to