Another witness against WordStar

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 publisher 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.

This entry was posted in DOS, PC history, WordStar. Bookmark the permalink.

17 Responses to Another witness against WordStar

  1. Yuhong Bao says:

    “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.

  2. michaln says:

    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.

  3. John Elliott says:

    “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.

  4. michaln says:

    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.

  5. John Elliott says:

    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.

  6. michaln says:

    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.

  7. Richard Wells says:

    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.

  8. sillyluis says:

    A little late, I know, but …. I think you’re wrong. A call 5, let’s remember, is an *intra-segment* call which in most cases ends up in the PSP’s “int 21h / ret” combo. It has nothing to do with address wraparound, which occurs only at the very end of the 1st Mb.

  9. Michal Necasek says:

    Oh, it has everything to do with address wraparound. Because the code at offset 5 in the PSP is something like “CALL FEF0, F01D” (DOS 2.0) or “CALL F01D:FEEE” (PC DOS 2000).

  10. MiaM says:

    But why did the code look like that, and why couldn’t IBM and Microsoft have changed DOS?

  11. Michal Necasek says:

    They could have changed DOS, but they couldn’t change CP/M. Remember, the PSP was meant to be compatible with CP/M (that is CP/M-80 of course, as the non-existence of CP/M-86 was the reason QDOS was written in the first place!). The short story is that there wasn’t enough space for a far call in the PSP. If you look for example here (see Figure 1 on page 6), you will see that the “syscall” jump is at offset 5 but the word at offset 6 gives the number of bytes available (because in CP/M-80, the jump target was right after the memory available to the program).

    So you have one byte for a far jump opcode and the next word needs to indicate the number of bytes free in the segment, what do you do? If you’re Tim Paterson (and yes, he invented the mechanism), you take advantage of the address wraparound so that the offset (typically) points at the end of a 64K segment but the segment portion of the far jump is chosen such that the address wraps back around to the beginning of the address space where the DOS system call entry point lives. All this is necessary so that CP/M-80 programs (written in assembler) can be mechanically translated to run on 8086 + DOS.

    It’s really a very clever idea on the 8086. Sadly falls apart on a 286 (but you can’t blame Tim Paterson for that). IBM enters the scene and chaos ensues.

    Note that the oldest WordStar PC binaries are still missing to my knowledge, so I don’t think anyone has been able to undeniably confirm that WordStar for the IBM PC really used the CALL 5 interface. The newer WS binaries are different, but that’s not surprising. There is a non-zero chance that there were applications/utilities other than WordStar which used CALL 5.

  12. MiaM says:

    Oh!

    But what was in location 8,9,A e.t.c?

    I don’t know that much about x86 assembly, but if there is some instruction that has a one byte op code and takes two bytes as operand(s) and doesen’t perform any function that could mess upp with the call to call 5, you could perhaps have had that instruction at byte 5, any two bytes you would want at byte 6 and 7, and have the actual jump at byte 8.

    As far as I can see from here it seems like byte 8 and onwards is free to use:
    http://www.gaby.de/cpm/manuals/archive/cpm22htm/ch6.htm#Section_6.9

    If it were a 6502 system you could have used the BIT instruction which is meant to be used to test bits in any memory location, but the wanted effect is that it only affects the flags and “consumes”. I don’t know if this is possible on x86. (As the contents of location 6 and 7 should point to a specific location in memory you might be able to use an instruction where byte 6 or byte 6+7 is part of the opcode together with byte 5).

  13. Michal Necasek says:

    “Free to use” might just mean “users can write whatever they like in there”, although I don’t think that was a real concern. DOS 1.0 had termination address at offset 10 in the PSP I believe, so there wasn’t enough room left. But putting some “harmless” 3-byte instruction at offset 5 might have been a possibility, if the termination address were shifted. Perhaps.

  14. MiaM says:

    The question is then: is there any such harmless instructions?

    The problem with not being able to touch adress 10 might had been solveable in two ways. One is if it would be possible to use a two byte jump at adress 8 and 9 (is there any such jumps in x86?) and another would be to put a two byte store to memory instruction in those bytes (if there is any such instruction) and let the termination code check if a certain adress has been written to, i.e. detect call 5, or if not written to just run the exit code.

    The more I read and discuss such topics the more I think I should learn x86 assembler πŸ™‚

    (I always avoided x86 assembler back in the days because I got the impression that people who actually were writing some x86 assembler code didn’t really understand everything but just used some standard startup code that someone else had written e.t.c.. That was probably fine for just writing applications or more likely parts of applications, but for me who were more interested in system programming that weren’t good enough)

  15. Pingback: The A20-Gate: It Wasn’t WordStar | OS/2 Museum

  17. Michal Necasek says:

    I must have the recalled edition with flowcharts… it actually contains significantly more historical information than other sources. As a technical reference it’s less valuable.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.