While trying to work on my DOS 5.0 article, I looked at DOS 5.0 build 224 from June 1990, which is the oldest surviving beta of DOS 5.0. And the README contains the following intriguing text, which reminded me of previous WordStar ruminations:
DOS 5.0 and WORDSTAR Due to a known problem, some older versions of WORDSTAR don't work correctly with this pre-release version DOS 5.0. We know what the problem is, but the fix was not incorporated in time for this beta release. WORDSTAR 2000 seems to work fine with DOS 5.0.
This is of course maddening because it does not mention which version of WordStar might have trouble. Version 3.x? Version 4.x, which is in fact newer than WordStar 2000? Some other version? There were more than a few. Well, let’s try WordStar 3.24 (early 1983) since that’s what I happen to have on hand:
WS 3.24 does not like DOS 5.0 build 224
Yep, there certainly is some kind of problem. But lack of memory? Unlikely. So what is it then?
Maybe my CALL5 utility might shed some light on the problem? Let’s see…
This PSP is not right
Lucky guess, indeed it did. Notice that in this beta of DOS 5.0, the CALL 5 interface still works (otherwise CALL5.COM wouldn’t produce any output), but the CALL 5 destination is 0000:00C0 (i.e. the INT 30h vector) instead of the usual F01D:FEF0 or so. The upshot is that the reported program segment size is 0C0h (192 bytes) and not the usual 0FEF0h (65,264 bytes). That might conceivably cause problems, and it certainly upsets old WordStar 3.24 because it thinks there isn’t enough memory.
So what does that tell us? I’m not sure. WordStar 3.24 clearly uses the CP/M-compatible information in the word at offset 6 in the PSP, but I see no evidence that it uses CALL 5 (I put a breakpoint on the entry point, and it never triggered while running WS). So if the goal was just to keep WordStar 3.2x going, it would be enough to put the right information into the PSP at offset 6 and forget about the CALL 5 interface. So who needs the CALL 5 interface which requires the address wraparound shenanigans? The mystery remains.
To recap the current knowledge: WordStar 3.24 (released around February 1983) is the oldest surviving version for the IBM PC that could be thoroughly examined. It was found to rely on the word at offset 6 in the PSP, but not use the CALL 5 interface. So this version of WordStar alone cannot explain the need for address wraparound and A20 line control.
There were earlier versions of WordStar. Version 3.20 is known to have existed, and 3.21 also existed. Currently there is no reason to believe that those were substantially different from version 3.24.
It is known that WordStar 3.02 was the earliest version for the IBM PC, and it was potentially significantly different from version 3.20. The reason to suspect such difference is that version 3.2x also supported CP/M-86 (the overlays are identical between DOS and CP/M-86, only the main executable is different), but 3.02 predates the appearance of CP/M-86.
So maybe WordStar 3.02 is the culprit? Well, no, it isn’t. WordStar 3.02 (released in April 1982 or so) didn’t even work with PC DOS 1.1, so it’s extremely difficult to believe that it would have been a concern by the time the PC/AT came out in 1984. So many question marks.
2022 Update: Although WordStar 3.02 for PC DOS is yet to be found, the WordStar history is now somewhat clearer. Sometime in late 1981, WordStar was ported to the 8086, targeting CP/M-86, perhaps even before CP/M-86 was released to the public. In April 1982, the CP/M-86 version of WordStar was lightly modified to run on top of PC DOS, and the first DOS version of WordStar was probably released around May 1982.
Version 3.20 of PC DOS WordStar has turned up in the meantime, and indeed it’s not substantially different from 3.24. There is good reason to believe that there never was a version of WordStar for DOS that used the CALL 5 interface, since it was derived from the CP/M-86 version using INT E0h, not from the 8080 CP/M version. It’s not clear when WordStar 3.20 for PC DOS was released, but it was probably in July 1982.
As detailed above, WordStar did depend on word at offset 6 in the PSP, which requires A20 wraparound if CALL 5 is to be supported as well. To put it differently, without A20 wraparound, DOS can either break programs that use CALL 5, or programs that use the segment size at offset 6 in the PSP (WordStar 3.x is in the latter category). With A20 wraparound, DOS can satisfy both classes of programs.
Finally, in the meantime, other programs that rely on A20 wraparound for reasons entirely unrelated to CP/M compatibility and the PSP have come to light.
The fun thing is that they no longer adjust the CALL 5 address with DOS 5.0.
Not sure what you mean. In that particular beta they didn’t, and that broke WordStar 3.24. The actual DOS 5.0 release behaves just like other DOS versions.
The only thing that’s different is that in DOS 5.0, the CALL 5 interface works even with the A20 on, because (at least when DOS=HIGH) the far jump is replicated at physical addresses 0C0h and 10000C0h. That is not the case in earlier DOS versions.
I am talking about the value always being F01D:FEF0 instead of being adjusted according to available memory.
And mealways though that ‘enuf’ was spelled with 2 ‘f’s…
,s/CALL 5/CALL 5WRAP/g is not a very big change, especially since a
routine ‘5WRAP’ AFAICS wouldn’t be that difficult to write. So it might
just’ve appeared in a minor release…
Mewonders if there *was* actually a common piece of software that didn’t
work w/o wraparound, or if perhaps the fear of such was enough to
justify backwards combat. We all know what happened when PC-DOS 4
‘broke’ some existing stuff: perhaps, someone feared a diff backlash if
the wraparound were broken.
That still leaves open the possiblity that indeed, it was decided to
make it possible to re-enable the wraparound, out of good engineering
practice. But the latter is scarce in the IBM pee-cee world especially,
so me’s not so sure about that…
,s/diff backlash/similar backlash/. Still waking up…
The spelling depends on how badly you want to save a few bytes of memory. MicroPro clearly thought saving two bytes was worth it 🙂 In the era of 8-bit systems that doesn’t sound completely crazy.
The common software which depended on address wraparound is something that’s been suspected all along, but no one has been able to identify such a thing to date. It’s possible that it never existed, or that people thought it existed (say WordStar 3.2x) but never verified the assumption.
Then they could’ve saved 2 more bytes *and* be more correct by saying the
classic ‘out of memory’ instead.
What if M$ warned MicroPro, MicroPro complained to M$, causing a stir
there, only for MicroPro to quietly fix it on their end? The stir itself
might well be where the story comes from, in that case…
But yeah, this is all suspicion and speculation. Just like w/ the 69h
opcode. Which inspires me…
There is no CALL5 in WS 3.20
That’s what I would expect. So where might one find the IBM PC version of WordStar 3.20? 🙂
Undocumented DOS (at least the 1st edition) describes PSP offset 5 as “CP/M entry point (FAR jump to 000C0h)” in the “INT 21h Function 26h DOS 1+” entry.
That is not wrong. But the way it gets there is using address wrap-around. Except in that one DOS 5.0 beta.
Mecan be asssured that all installers, side-programs, etc., have been
checked, as well?
(just trying to be thorough…)
To the extent that they are available. Many are not.
That’s brilliant. The start of BDOS in CP/M is higher than the highest address that any program can talk to. The address that shows in Call 5 under CP/M would indicate the total amount of free memory so CP/M programs would spelunk the Zero Page because CP/M didn’t have any API call to determine free memory except for CP/M 1.3 function 6 which reports the same value. By doing the wrap around, DOS lies to converted CP/M program to fool it into believing that there is almost 64kB of unused memory and still manages to send Call 5 to Int 21h.
Andy Johnson Laird looks to use a variation on the technique on page 65 (Programmers CP/M Handbook) and only most significant byte is needed since CP/M starts on page boundary.
Or maybe, given WordStar’s use of PSP offset 6 you uncovered, Microsoft only assumed, mistakenly so, that WordStar uses the value at PSP 6-9 as a DOS call interface (directly or indirectly through CALL 5)?
The wrap-around is Tim Paterson’s invention, that much is known. It was his creative solution to replacing a near call with a far call and still keeping everything at the same offsets and working. I don’t see any other solution given that putting OS stuff at the top of the PSP segment was probably highly undesirable, because it would fragment the address space.
Actually I take that back. One alternative solution would place INT3 in the byte at offset 5 and just write the appropriate quantity into the word at offset 6. It would end up being more complex due to possible undesired interaction with debuggers, but wouldn’t abuse the architecture. Or use a two-byte INT instruction with the (IMO slight) restriction that the reported segment size isn’t entirely accurate and can only change in multiples of 256.
That’s a very plausible possibility. Because it’s impossible to prove that no relevant applications use the CALL 5 interface, just keep it working forever. And it is possible that while applications do look at the word at offset 6, they don’t actually call offset 5, but no one made the distinction (the DOS 5 beta broke the ‘word 6’ value, but not the CALL 5 interface).
Plenty of DOS 1 programs used Call 5 interface; it was often recommended by programming magazines back in 1981. The problem is some of the programs using Call 5 were mechanically converted from CP/M 2.2 which means the logic was unchanged. DOS needs to offer the expected 16-bit values to the CP/M program and then magically adjust to the actual addresses that DOS needs to work.
The wrap around technique probably will fail in a real mode multi-tasker with an unusually small memory partition or on a 64kB machine with a bigger DOS. DOS will tell the CP/M application that the TPA will be 60+kB so the CP/M program might try to access all that memory. Fortunately, most CP/M programs did not try to use more than the standard 56kB TPA so under DOS 1 the program won’t step beyond the installed memory. Some memory will never be accessed under this scheme; can’t have everything.
I honestly don’t know what magazines suggested in ’81, but the CALL 5 interface certainly was in place precisely for that reason, so that existing CP/M software could be machine translated, reassembled, and executed on DOS. That was one of the objectives of QDOS, so there should have been software using it. The question is how much such software was still relevant in 1984 when the PC/AT came out, and what was left by 1990 when DOS 5.0 was in development.
The CALL 5 interface supports only the CP/M compatible calls, so no handle-based I/O, no directories, etc.
“The wrap around technique probably will fail in a real mode multi-tasker with an unusually small memory partition or on a 64kB machine with a bigger DOS.”
That is what I was talking about when I mentioned that older versions of DOS automatically adjusted the CALL 5 value.
Wordstar is rather a special case. It was ported from CP/M-80 to CP/M-86 and then to DOS. Changing to CP/M-86 replaced all the Call 5 instances with Int E0h calls which became Int 21h under DOS. Call 5 was gone replaced by a special flag to show if the program used 8080 memory model but bytes 6 and 7 showed the length of the segment. Wordstar under DOS needed those same bytes for the same reason matching up with the CP/M-80 TPA logic.
Programs that only use Call 5 but never check TPA size could work with jumps that did not rely on address wrap around. Programs that checked TPA size but never used Call 5 needed a large value in byte 6 but the jump in byte 5 could be discarded. Only a Jump using wrap around could work with both sets of programs.
How many programs using Call 5 were available in 1990? Consider the number of complaints that FAT 32 would not work with FCB programs. That seems like a reliable estimate of the number of DOS 1 era programs still in service in 1997, of which some portion would be using Call 5. Expect even more in 1990.
I have a system that used to belong to Micropro – a Data General One that was used as a testing system – and i’ve been going through the diskettes i got with it to see if anything pertinent might come up, but unfortunately most are blank, bitrot has claimed a few of ’em and what’s left mostly just contains ordinary copies of WS2000.
I can still likely get in touch with the dude i bought it from, a former product lead, if you think he might know something!
I’ve played a little with 3.20 in ida.
There is no special memory flag in this version, it’s just retrieving word from PSP:6 and comparing its high byte with (0x98 + 0x13), requiring 0xAB00 (43776) bytes of available memory.
There is runtime check for DOS/CPM-86 though. It would be interesting to change that flag and try to run it on CP/M-86.
In general, there are only 3 call to int 0x21/0xE0. First is a common syscall function, second is in get_input_status routine: int 0x21/0x0B for DOS and int 0xE0/0x32 for CPM-86 (plus BIOS int 0x16/1 version that can be enabled with another flag), last is exit().
What I know is that the .OVR files are 100% identical between DOS and CP/M-86, with a flag (clearly shown in the WordStar 3.20 manual) switching between them at runtime. There also ought to be some INT 17h invocations for printing, but really the OS interface in WordStar is quite narrow and well abstracted.
Do you have some reference for WS being ported to CP/M-86 first and to DOS later? My best guess based on the timeline is that WordStar was first ported to DOS (WS 3.02) and then to CP/M-86 (WS 3.20). The main problem is that WordStar 3.02 is not available for analysis. The other problem is that CP/M-86 did not support the CALL 5 interface.
FCBs are really not the same thing. FCBs are a well documented programming interface available in all versions of DOS. For example the MS-DOS 3.2 programming reference (which I used because I happen to have a machine readable version) does not document the CALL 5 interface at all, and neither does it document the FAR CALL PSP:50h interface. Both are mentioned in a way that likely only makes sense to someone who already knows about them. Only INT 21h is presented as a way to invoke DOS function calls in that manual.
The IBM DOS 1.1 reference (for example) did document the CALL 5 interface, so it wasn’t a secret. It’s hard to think that its use was encouraged though.
If you know what the problematic FCB-using apps were, it should be possible to examine them and see how they behave.
He might know something. The problem (as mentioned elsewhere) is that the first version of WordStar for the IBM PC (that is, version 3.02) has not surfaced after all those years, so no one can say for certain what it did or didn’t do. Someone who was there at the time (1982) might remember what was done how and when in terms of supporting DOS and CP/M-86. Internal documentation and/or source code might also shed some light on the matter.
One problem is that MicroPro apparently had a policy of sending out upgrades on the condition of the users mailing the old disks to them. So basically a lot of the old versions of WordStar were out of circulation back in the early 1980s already.
The Potted History of Wordstar mentions that WordStar DOS was ported from WordStar CP/M-86. http://www.wordstar.org/index.php/wordstar-history The May 17, 1982 issue of Infoworld has a news blurb indicating that the first showing of the prototype Wordstar for DOS occurred then while the same issue has an ad for Wordstar for IBM PC running CP/M. I think Rob Barnaby included a similar story in his interview with Digibarn.
There is a long published article that included discussion of Call 5 in the October 1990 Doctor Dobbs called “Closing DOS’s Backdoor.” Two articles discussing Call 5 as the interface would be comparisons of DOS with CP/M. Both mention “Int 33” as an alternative interface. See July 1982 Byte pages 342 – 256 and DDJ July 1982 page 14 – 24. Interestingly, the Cortesi article in DDJ catches the use of Byte 6 to show segment size and sees the byte 5 far jump but doesn’t notice that the address needed to wrap around.
There are probably other articles on the subject but indexes don’t mention Call 5 for MS-DOS and it takes a long time to search through paper issues. Plus I don’t have any issues of the more obscure programming magazines.
There is a lot of unverifiable information about WordStar. Some say it was ported from CP/M-86 to DOS, some say it was ported from CP/M to DOS, some say it was ported from CP/M to CP/M-86 and DOS. There’s this one which is not credible, and may be mixing up CP/M with CP/M-86.
There are nonsensical claims like the one that the “first DOS version [of WordStar] was a port of the CP/M-86 version, and therefore could only address 64k of RAM, even though DOS supported up to 640k” on Wikipedia — obviously CP/M-86 was not limited to 64K, only CP/M was.
Anyway, CP/M-86 does not support the CALL 5 interface at all, so if WordStar for DOS was truly ported from CP/M-86 (as opposed to CP/M), there is absolutely no reason to think it ever used the CALL 5 style of system call invocation.
More importantly, the initial IBM release of WordStar 3.02 did not work on PC DOS 1.1 and presumably later versions. WS 3.20 did, and WS 3.20 definitely does not use the CALL 5 interface.
CP/M-86 1.0 programs were limited in memory addressing because DRI ASM86 could not relocate calls and that in turn limits programs to 64kB maximums*. I think what was known as Small Model (64k Code; 64k Data) was possible but Wordstar was stuck in 8080 Compact Model. Wordstar lacked source code which also explains why the changes up to WS 3.4 were so minor and New Word got purchased. Five years of patches on top of patches while changing the OS underneath is a nightmarish production environment.
* Absolute addressing could be done to make larger programs but that was rather impractical for commercial software. Add a drive or load a second program and all the jumps will be going to the wrong addresses.
Exactly, 64K + 64K is not 64K. If an application was ported from CP/M-86, it does not follow that it was limited to 64K. If it was ported from CP/M-80 then it does follow that it can only address 64K of code + data + stack.
I wonder when exactly they lost the source code (such an amazing story).
“I wonder when exactly they lost the source code (such an amazing story).”
Who knows how reliable is but John C Dvorak has a history of WordStar: http://www.dvorak.org/blog/whatever-happened-to-wordstar-2/
It occurred to me that two programs that are similar to WordStar are Turbo Pascal and Business Basic. (Made for CP/M and DOS, widely used and with good probability that are still used at the DOS 5 time).
For the moment I can’t make direct research in my software archive and what I found was that almost all the information about Business Basic has disappeared from the web, Turbo Pascal used FCB’s in their first versions but didn’t find if used CALL 5 or not.
What I found was this Byte Magazine Article that recommends using CALL 5 in DOS under the heading “Access to Functions of CP/M-80, CP/M-86, and MS-DOS”:
http://tech-insider.org/personal-computers/research/acrobat/8207.pdf
Note:
If you want to amuse yourself read the heading “MS-DOS 2.0” about the rumors? Microsoft information? About what will have MS-DOS 2.0 new.
(Wouldn’t be funny that the software that used CALL 5 was Microsoft Mbasic?)
Another DOS product that came from CP/M was Microsoft’s own Multiplan. As with other software packages, the difficulty lies in getting hold of the earliest IBM PC versions.
Merrill Chapman, who worked for MicroPro for a time, wrote, in the MicroPro section of his book “In Search of Stupidity: Over Twenty Years of High Tech Marketing Disasters”, a note about the source code.
Page 54:
“In any event, at just about the exact moment that MicroPro needed to ship and update to WordStar, it had lost the ability to do so.(2)
(2) One of the difficulties in upgrading Wordstar lay in the practice, common at the time, of implementing bug fixes by directly modifying the binary executable rather than updating the source code and reassembling the program (reassembling was a lengthy process). When the development teams working on WordStar examined the original 8080 source code, they found it didn’t match the Wordstar.exe files being shipped in the latest product. The lack of documentation on what the fixes had been implemented made working with the Wordstar code base very difficult. ”
I remember there being a lot of direct memory patching for various options with the retail copies back then. Thinking back on it, that was a weird way to run an airline. New versions if reassembled would easily break the locations and code modifications.
I think, but can’t swear to it that the manual I had for the CP/M-86 version there were short assembly listings for parts of the program involved with custom patching. I had a program named “POPCORN” that fell into my briefcase at Canon that was used to do OEM patching of the serial number and possibly other settings for their non-IBM compatible 8086 PC. I don’t know if it was specific to a WordStar version.
Ah, so the reality again did not match the stories. It’s not that MicroPro lost the source code, it’s that due to the practice of patching binaries, the source code they had did not in fact correspond to the shipping product. And they didn’t keep track of what had been patched and why. Thanks for the exact quote.
The WordStar 3.20 manual on bitsavers does include the assembly listing of two data areas which were intended for customizing console and printer support. It was mostly data, but bits of code too. I believe those areas were at least somewhat stable across multiple WS versions.
‘Or use a two-byte INT instruction with the (IMO slight) restriction that the reported segment size isn’t entirely accurate and can only change in multiples of 256.’
On a stock CP/M-80 system the byte at 6 is always 6 (because the BDOS sits on a page boundary and the first 6 bytes are the serial number). So I don’t think there’d have been any compatibility issue in having a value that could only change in multiples of 256.
Or take a few more bytes of the PSP and populate the bytes from PSP:5 with MOV BX,0FEF0h ! INT 30h ! RET (making INT 30h a proper vector rather than an entry point). CP/M doesn’t take parameters in BX , but always sets it on return.
Even though it would be much work, I can’t see how they couldn’t diff the output from a compile of the sources with the binaries they were shipping, and altering the sources until they did match.
It would take a lot of time and be cumbersome on a floppy based CP/M-80 system or similar, but at that point they could afford a bigger computer and whatever it would require to do the work there. Compare with Microsoft writing their basic for 8080, 6502 and similar on a bigger DEC machine (some PDP iirc) earlier than that.
Something that seems more likely is that the single person who wrote all of Wordstar had written code that would take a lot of time to understand for someone less skilled and not familiar with the code.
Sidetrack:
How about patching a CP/M-80 emulator to profile loaded programs by feeding them all kinds of random and predefined key sequences and see what parts of the binary are code and what are data. Then run the code parts in a disassembler, translate to 8088 code and what minor stuff that would be needed to use MS-DOS CALL 5, and see if it works. Kind of useless result but perhaps an interesting retro/vintage computing thing to do 🙂
P.S. the patching a single byte seems a bit strange. Would that had been the wording for changing a single character in the source code? We can assume that it’s not the binary they were refering to, as the actual op codes of 8088 differs from 8080.
Christian Masloch when the FreeDOS Call 5 handler was modified pointed out a C library that used Call 5. That was about 8 years ago and the specific library was not mentioned. I have not checked if FreeDOS correctly sets up byte 6 to meet Wordstar’s memory capacity check.
A second iteration of wrap around problems including Call 5 can be seen in the Letwin patent http://www.google.com.gi/patents/US4825358
One problem with replacing Call 5 with direct Int calls is that the Call 5 handlers massage the stack into the correct order.
Patching a single byte may make sense if converting from CP/M-86 to MS-DOS. If the Interrupt number was kept in a variable, changing EOh to 21h will do the job.
And I found a library that relied on Call 5. It was for Small C
https://web.archive.org/web/20160311022119/http://www.project-fbin.hostoi.com/Proj_SmC/RT_SmallC.htm
Patching from CP/M to DOS makes zero sense; as you noted, the instruction set is different. But as Richard says, patching from CP/M-86 to DOS might be doable, or at least it’s not complete nonsense. Machine-translating 8080 CP/M source code to 8086 source code was also doable, but it’s unclear if that is what they did.
As I mentioned elsewhere, the WordStar 3.2x overlays are 100% identical between the DOS and CP/M-86 versions. There is a runtime switch which chooses between calling INT 21h (DOS) and INT E0h (CP/M-86). WS.COM is not the same between DOS and CP/M-86, although it’s probably not very different either.
Apropos patching, I believe Microsoft’s BASIC interpreter was at least to some extent also managed as a binary blob with occasional handmade patches.
It’s from 2008 though, so not something historically relevant.
The Letwin patent is interesting, and I previously missed the bit about the A20 handling. Thanks for pointing that out. So now there is another clue — “programs including those written in MicroSoft PASCAL”. I wonder why there is no example given of a program which uses the CALL 5 interface. Is that because it wasn’t considered relevant, or because they didn’t have one?
The Pascal clue is promising though, and fortunately I have MS Pascal versions going back to late 1981 at hand.
If it’s in their own product{,s}, M$ might’ve been trying to deflect
attention by blaming WordStar. That’s just speculation, of course, but
it wouldn’t be contrary to their modus operandi.
I don’t think Microsoft actually ever blamed WordStar or any other specific product. That would make it easy to verify whether a given software package causes trouble or not. But there is something to that Microsoft Pascal thing (also sold as IBM Pascal). I’m currently investigating. A notable fact is that the MS/IBM Pascal compiler was part of the initial set of software available when the IBM PC was first introduced. It’s more than half a year older than the PC version of WordStar!
Wasn’t the UCSD p-System offered as an IBM pee-cee OS at some point? not
that there’s necessarily much of a relation…
It’s indeed starting to look like that, while people have been screaming
‘WordStar’ all along (whether M$ was involved in that or not is a
seperate issue), while the real culprit may have predated it!
Me’s staying tuned…
Yes, UCSD p-System was offered, and no, there was no real relation. For one thing, the MS Pascal compiler didn’t use p-code, and from what I read, it was actually a surprisingly good compiler in terms of the code it generated. It was even itself written in Pascal.
A compiler written in Pascal? That sounds like a rather masochistic
exercise.
Then again, the term ‘B&D language’ didn’t come from nowhere .
Most Pascal compilers, including the original, were compiled by themselves (see Pascal P5). It was designed to be a fast, single-pass language with that in mind. Even MASM v1 was supposedly written in Pascal. Also, FreePascal is written in itself.
“B&D” is referenced from the Jargon File, and frankly, *nix nerds don’t know anything about Pascal derivatives and offshoots, and thus they never even used them. Some few complaints are fair, but only barely. Most complaints, even from BWK, are spurious.