Previous posts examined the question why IBM implemented the A20 hardware in the PC/AT, causing endless headaches to future PC hardware and software developers. WordStar emerged as a possible culprit, but no one would quite point the finger at it.
The OS/2 Museum is now in possession of the original MS-DOS Encyclopedia (1986) which identifies WordStar in print. This is the same book that Larry Osterman claimed to have been subject to a published recall; either Microsoft Press didn’t do a very good job of pulling the book from the shelves or Larry Osterman’s recollection is inaccurate, but the book isn’t very difficult to find. (However, at about 8 pounds, or nearly 4 kilograms, it is quite difficult to carry around!)
On page 34, the MS-DOS Encyclopedia says: “For example, in CP/M-80, programmers would call address 5 in order to request a function. In MS-DOS, Interrupt 21 was the function call. But to support old programs, the first version of MS-DOS also allowed a program to request functions by calling address 5. Although this feature was not documented, a number of existing programs continued to use it when they were converted to MS-DOS. One of these programs was WordStar. Microsoft could not afford to make changes in the operating system that would make it impossible to run a program as popular as WordStar. So each new version had to continue supporting CALL 5, even though it was never documented.”
It is worth pointing out that the Encyclopedia contradicts itself somewhat. On page 14, it talks about how one of the objectives of MS-DOS (or 86-DOS) was to support mechanical translation of CP/M-80 programs. Such programs naturally used the CALL 5 interface and of course DOS had to support that, officially documented or not. It is sufficiently different from the INT 21h interface that automatic translation would be likely to fail.
In the second edition of the MS-DOS Encyclopedia, CP/M compatibility and WordStar are mentioned, but without explicitly naming the CALL 5 interface. At any rate, if the early WordStar editions for the PC used the CALL 5 interface, they would have certainly (indirectly) required address wraparound. WordStar may well have been enough reason for IBM to worry about backwards compatibility in the PC/AT. Examining a copy of WordStar for the IBM PC from 1982-1983 would be the only way to tell with 100% certainty, but at this point it seems beyond reasonable doubt that WordStar did use the CALL 5 interface.
It should be noted that years later, when DOS 5.0 might run with the A20 line permanently enabled, the most common source of problems related to address wraparound was Microsoft’s EXEPACK utility (later built into Microsoft’s LINK), or rather executables processed with EXEPACK. The problem manifested itself with the infamous “Packed file corrupt” message. However, there is no evidence that EXEPACK was available before the release of the IBM PC/AT in August 1984; the first known EXEPACK version is from early 1985 (shipped with Microsoft C 3.0). On the other hand, WordStar most certainly predated the PC/AT and was quite popular at the time.
“It is sufficiently different from the INT 21h interface that automatic translation would be likely to fail.”
Yep, the problems with A20 makes the CP/M-86 solution of doing 8080 to 8086 translation then replace all CALL 5s with INT E0s look much better IMO.
If you are willing to ignore the possibility that a program might make indirect calls to offset 5, or that it uses the interrupt vector E0h for its own purposes.
“or that it uses the interrupt vector E0h for its own purposes.”
Given that the program’s just been translated from 8080 source, that’s just as unlikely as it using INT 30h for its own purposes and thereby breaking CALL 5.
That’s a good point, but let me rephrase that – “or that interrupt vector E0h might be used for some other purpose”. Interrupt 30h was reserved for DOS, interrupt E0h was in the “used by BASIC interpreter while BASIC is running” range and conceivably could used by something else as well. Not an issue for CP/M-86 per se, but an issue for any software running on the PC platform.
I wonder if there were any CP/M programs which patched the code at offset 5, diverting system calls to some custom handler. Although those would probably fail either way.
There were CP/M programs that hooked CALL 5 — for example, the Graphics System eXtension worked by attaching a loader to .COM files, and this loader would relocate itself to the top of memory, hook CALL 5, and load the appropriate graphics driver. But the moment you start doing things like that, mechanical translation isn’t going to cut it. Likewise with any program that tries to hook CALL 5 and go resident, or any program that assumes the word at 0001h is the address of a BIOS jumpblock, or any program which assumes system calls 7 / 8 / 12 have the same semantics in CP/M and DOS.
Really, translating CALL 5 to CALL 5 doesn’t get you much, if anything over translating it to MOV AH,CL ! INT 21h. It does make life easier for the author of the translation program, because it removes the requirement to parse all the symbols and work out which ones evaluate to 5.
If the translation program is written in 8-bit assembler and runs on some Z-80, that may well be an important consideration. Also, in a project like that, it’s a sound engineering practice to make only changes that are unavoidable… and replacing CALL 5 with some other means of invoking system calls was not.
The translation program is documented in the 86-DOS User manual (pages 47-49) at the Paterson Tech website. It is a simple general purpose 8080 to 8086 converter not a CP/M-80 to 86-DOS converter. Everything I have read indicates that SCP did not want to be an OS manufacturer so constraining the translator to only one OS would be less than helpful. I suspect that SCP anticpated that the converter would mostly be used for companies to get their own self-booting software including OSes quickly ported over to use the expensive SCP hardware.
I always thought that the CALL 5 interface in DOS and the little used DOS 2 stack frame interface at PSP 50h were clever ways of getting programmers to support DOS with minimal effort. Considering how only little of the CP/M-80 software got ported to CP/M-86, there might be something to making programmers lives easier.