Microsoft’s founders Paul Allen and Bill Gates were also getting ready for 16-bit microprocessors. Unsurprisingly, they decided to bet on a system popular on 16-bit minicomputers: UNIX, developed by AT&T’s Bell Labs in the early 1970s and freely distributed to universities. In February 1980, Microsoft licensed UNIX V7 source code from Western Electric (AT&T’s manufacturing arm). The name was not licensed, so on August 25, 1980, Microsoft announced its own UNIX-based product named XENIX.

Initially, Allen and Gates had a lot of confidence that the portability and flexibility of UNIX would make XENIX the standard operating system on 16-bit microcomputers. Once they actually had the UNIX source code, it turned out it was a poor fit for the current generation of microprocessors, especially the Intel 8086. Worse, it was a memory hog; it grew a lot since Ken Thompson developed the first version in 1969 on a PDP-7 minicomputer. Soon, Microsoft made an arrangement with SCO, a small company specialized in UNIX consulting, to take over most of the work on porting XENIX to target platforms.

When IBM revealed its plan to develop an Intel 8088 based personal computer that would start with only 16 KB of RAM, it was obvious that there was no way XENIX could be squeezed into such a constrained environment. Like it or not, IBM needed something like CP/M, and after an unsuccessful attempt to license it from Digital Research, they went back to Microsoft, which in turn acquired 86-DOS from SCP. The operating system was adjusted for the IBM PC, somewhat polished, renamed PC-DOS and shipped in August 1981. Microsoft retained the rights to sell it to other customers under the name MS-DOS.

Yet, there was a nagging feeling that a single-tasking CP/M clone was inadequate for the new generation of personal computers. Digital Research released multi-user, multitasking MP/M-86 in September 1981 and announced the single‑user multitasking Concurrent CP/M in early 1982. In response, Microsoft came up with a plan for tiered approach to its operating systems: single-user/single-tasking MS-DOS at the bottom; multi-user/multitasking XENIX at the top; and in the middle, something called XEDOS: a single-user version of XENIX. This “pyramid of upward-compatible operating systems” was announced in a Byte Magazine editorial in January 1982.

XEDOS was apparently more than a marketing ploy; Microsoft and SCO had tried to remove features from XENIX until it could be usable on the PCs of the era, but with little success. In his 2011 book Idea Man, Paul Allen wrote: “Even a scaled-down version of Unix was too demanding for the 8086 chip”.

In the July 1982 edition of Byte, the second part of an article comparing MS-DOS and CP/M-86 analyzed, among other aspects, the future prospects of the two leading 16-bit operating systems. For CP/M-86, the path was obvious - the next generation Concurrent CP/M-86 had been introduced at the West Coast Computer Faire in March. As for Microsoft, its representatives talked about MS-DOS 2.0 without mentioning XEDOS. It was clear the plan was to extend MS-DOS with new features and “a number of Xenix-derived utilities” rather than scale down XENIX. The upward path from MS-DOS to XENIX was not clear.

The change in plans happened sometime in early 1982, after IBM requested a new version of DOS to ship with its upcoming IBM PC XT model. The XT was a modest incremental improvement over the original PC, and IBM clearly communicated that it expected MS-DOS 2.0 to have similarly restricted scope: supporting the new built-in hard disk was all they really wanted. Keeping the operating system small was much more important to IBM than adding new features. Bill Gates was happy to oblige, but Paul Allen would have none of it: after consulting with lead DOS developers Mark Zbikowski and Aaron Reynolds, Allen became convinced that DOS needed a clean rewrite to support features he felt were essential to keep MS‑DOS relevant.

The first and most important feature was extending the FAT file system to better support hard disks. Allen wanted to replace the flat file system with a hierarchical structure, similar to UNIX, with a root directory and nested sub-directories as the way to organize files on a disk. One of the consequences would be introducing file handlers instead of the CP/M-like File Control Blocks, although the latter were kept for compatibility.

The second feature was dynamically loadable drivers. MS DOS 1.x, used the monolithic BIOS module to access all hardware. Any changes, including new peripherals, required recompiling or at least patching the BIOS. In MS-DOS 2.0, BIOS was to be expanded to read installable drivers without modification. A configuration file would be introduced to point BIOS to installed drivers, and it would load them as needed.

The third major feature was a limited support for background print spooling. The idea was to provide a small utility that would run in the background and take over printer output so applications would no longer have to block while sending data to the printer. Full multitasking, as implemented by UNIX or MP/M was not considered for MS-DOS 2.0.

In addition, a number of features directly inspired by XENIX were added, including find, more, sort and fc, along with utilities needed to support the new hierarchical file system, such as chdir and mkdir. Some form of IO redirection was also to be included, but obviously not in-memory pipes, given the single-tasking nature of MS-DOS.

IBM was not happy with Allen’s ambitious plans:

But it soon became clear that IBM was committed to keeping DOS 2.0 as close as possible to the eight thousand bytes used by DOS 1.1, so as not to disrupt their existing user base. If our new DOS was too memory hungry, IBM feared that smaller PC systems would run out of room for some popular applications. And they weren’t accustomed to contractors going beyond their specs, even if it meant they were getting more for their money.

Paul Allen: Idea Man

Bill Gates was very reluctant to alienate IBM, which he internally called “the customer”. After receiving complaints from Boca Raton, he had a shouting match with Paul Allen (who called IBM “the idiots”) in front of a terrified Mark Zbikowski. Eventually, Gates gave in and let Allen’s team implement the features they wanted, as long as the delivery date was met.

The MS DOS 2.0 team consisted of only six people: Paul Allen, Mark Zbikowski, Aaron Reynolds, Nancy Panners, Chris Peters, and Mani Ulloa2. Neither of the MS-DOS 1.0 developers (Tim Paterson and Bob O’Rear) was involved in the 2.0 development.

The first version of MS-DOS 2.0 shipped with IBM PC XT as PC-DOS 2.0 on March 8, 1983. It required about 20 KB of RAM, far more than MS DOS 1.0, so both versions continued to be sold simultaneously for a while.

To understand the scale of the rewrite, we can compare the sources for MS-DOS 1.25 and 2.0 in the GitHub repository for MS-DOS. Unfortunately, the comparison is not completely straightforward, as some utilities such as chkdsk and sys are available in binary form only in 1.25 but also with source in 2.0. That said, in the 1.25 source tree, we find only 7 files, including tools such the assembler (ASM.ASM), hex2bin (HEX2BIN.ASM) and a Z80 to 8086 translator (TRANS.ASM). Entire DOS kernel source was in a single file (MSDOS.ASM); ditto for BIOS (IO.ASM) and COMMAND.COM (COMMAND.ASM).

The 2.0 source directory (still a single directory) contains 118 ASM files, plus documentation. The kernel, BIOS and COMMAND.COM are split among many files, trying to reflect their structure. Still, some code was directly transferred: routines like FNDCLUS, BUFSEC, BUFRD, BUFWRT, DATE16, and READTIME from the original MSDOS.ASM appear with the same names, same comments, and nearly the same code in other files.

Files called XENIX.ASM and XENIX2.ASM contain implementation of some of the new commands ported from UNIX.

Not all DOS 1.25 functionality was carried on to 2.0. The assembler, the Z80 to 8086 translator and HEX2BIN are present only in the original MS-DOS.

Recently, as I started writing about UTF-8 decoding, I spent more time revisiting the internals of the library. The function I decided to optimize decodes a UTF-8 encoded code point:

    template <typename octet_iterator>
    utf_error validate_next(octet_iterator& it, octet_iterator end, utfchar32_t& code_point)
    {
        if (it == end)
            return NOT_ENOUGH_ROOM;

        // Save the original value of it so we can go back in case of failure
        // Of course, it does not make much sense with i.e. stream iterators
        octet_iterator original_it = it;

        utfchar32_t cp = 0;
        // Determine the sequence length based on the lead octet
        const int length = utf8::internal::sequence_length(it);

        // Get trail octets and calculate the code point
        utf_error err = UTF8_OK;
        switch (length) {
            case 0:
                return INVALID_LEAD;
            case 1:
                err = utf8::internal::get_sequence_1(it, end, cp);
                break;
            case 2:
                err = utf8::internal::get_sequence_2(it, end, cp);
            break;
            case 3:
                err = utf8::internal::get_sequence_3(it, end, cp);
            break;
            case 4:
                err = utf8::internal::get_sequence_4(it, end, cp);
            break;
        }

        if (err == UTF8_OK) {
            // Decoding succeeded. Now, security checks...
            if (utf8::internal::is_code_point_valid(cp)) {
                if (!utf8::internal::is_overlong_sequence(cp, length)){
                    // Passed! Return here.
                    code_point = cp;
                    ++it;
                    return UTF8_OK;
                }
                else
                    err = OVERLONG_SEQUENCE;
            }
            else
                err = INVALID_CODE_POINT;
        }

        // Failure branch - restore the original value of the iterator
        it = original_it;
        return err;
    }

Pretty straightforward: based on the value of the lead byte, determine the length of the sequence, and then depending on the length, construct the value of the code point by extracting appropriate bit fields from the bytes. After the code point is successfully decoded, perform two more checks: one for validity of the code point, and another for an overlong UTF-8 sequence. If both checks pass, return the success status, and the iterator is moved to the next sequence.

An opportunity to optimization was the fact that ASCII trivially satisfies all UTF‑8 validity requirements. If it turns out the high bit of the lead byte is zero, we have an “ASCII character” - a value in the range of [U+0000, U+007F] which is always valid. All we need to do is zero-extend it and we have our code point.

Something like this:

  template <typename octet_iterator>
    utf_error validate_next(octet_iterator& it, octet_iterator end, utfchar32_t& code_point)
    {
        if (it == end)
            return NOT_ENOUGH_ROOM;

        // Save the original value of it so we can go back in case of failure
        // Of course, it does not make much sense with i.e. stream iterators
        octet_iterator original_it = it;

        utfchar32_t cp = 0;
        // Determine the sequence length based on the lead octet
        const int length = utf8::internal::sequence_length(it);

        // Get trail octets and calculate the code point
        utf_error err = UTF8_OK;
        switch (length) {
            case 0:
                return INVALID_LEAD;
            case 1:
                err = utf8::internal::get_sequence_1(it, end, cp);
                // No need for further validations
                if (err == UTF8_OK) {
                    code_point = cp;
                    ++it;
                    return UTF8_OK;
                } else {
                    it = original_it;
                    return err;
                }
                break; // just to make sure there are no warnings
            case 2:
                err = utf8::internal::get_sequence_2(it, end, cp);
            break;
            case 3:
                err = utf8::internal::get_sequence_3(it, end, cp);
            break;
            case 4:
                err = utf8::internal::get_sequence_4(it, end, cp);
            break;
        }

        if (err == UTF8_OK) {
            // Decoding succeeded. Now, security checks...
            if (utf8::internal::is_code_point_valid(cp)) {
                if (!utf8::internal::is_overlong_sequence(cp, length)){
                    // Passed! Return here.
                    code_point = cp;
                    ++it;
                    return UTF8_OK;
                }
                else
                    err = OVERLONG_SEQUENCE;
            }
            else
                err = INVALID_CODE_POINT;
        }

        // Failure branch - restore the original value of the iterator
        it = original_it;
        return err;
    }

My expectation was to see a visible improvement in handling of sequences of ASCII-only strings, with a minor impact on mixed ASCII/non-ASCII strings. Testing with clang 18.1.3 beat my expectations: For pure ASCII text, UTF-8 decoding throughput tripled, and even for mixed text, the improvement was substantial: around 34%.

I actually submitted the change to GitHub, but then at some point decided to test with gcc. Compilers just never stop surprising me: this time there was no difference for the ASCII text at all! Zero!

For heavily mixed text the throughput was consistently worse by 3-4%, which was not that surprising.

Time to get our hands dirty and look at the generated assembly code. Here is what happens for an ASCII code point with original version compiled with g++:

15e0: ldrb w0, [x22]        ; load byte
15e4: tbz  w0, #7, 1700     ; if bit 7 == 0 (ASCII) return immediately
...
1700: add   x22, x22, #1    ; consume 1 byte
1704: cmp   x2, x22         ; check end-of-buffer
1708: b.ne  15e0            ; loop if more input

This is an optimized, heavily inlined build and the last two instructions come from a function calling validate_next in a loop. But it is pretty clear that there are no validation checks in the ASCII branch: the compiler was able to figure out the checks always pass and simply removed them. My optimization did not change a thing - generated code for the ASCII branch remains the same.

Now clang:

1870: ldrsb w13, [x20]        ; load byte, sign-extended
1874: and   w12, w13, #0xff   ; w12 = unsigned version
1878: tbnz  w13, #31, 1890    ; if sign bit set, jump to non-ASCII path
187c: mov   w14, wzr          ; no continuation bytes
1880: mov   w15, #1           ; sequence length = 1 byte
1884: mov   x13, x20          ; x13 = pointer to lead byte
1888: mov   w16, w12          ; decoded code point = byte value
188c: b     19ac              ; go to generic validity checks
...
19ac: lsr   w17, w16, #16
19b0: and   w18, w16, #0x1ff800
19b4: cmp   w17, #0x10
19b8: ccmp  w18, w11, #4, ls
19bc: b.eq  2300                 ; invalid code point
19c0: cmp   w16, #0x7f
19c4: b.ls  1860                 ; valid ASCII: advance iterator

Obviously, clang did not eliminate code point validity checks. With my optimization, the code becomes:

15e0: ldrb w0, [x22]
15e4: tbz  w0, #7, 16c8        # ASCII
...
# ASCII early-return completion
16c8: add   x22, x22, #1
16cc: cmp   x2, x22
16d0: b.ne  15e0

That certainly explains the huge performance improvement with clang.

What I ended up with was a somewhat bigger change that satisfied both compilers. Instead of checking for code point validity and overlong sequences after decoding is done, I enhanced the get_sequence_* functions to perform validation inline. That preserved all performance gains on clang and led to 15-20% of improvement with gcc and mixed text (no difference for pure ASCII).

Moral of the story? Compilers are tricky, but spending some time on optimizations can be rewarding.

The basic idea was to use the multitasking capabilities of Concurrent DOS and replace multiple personal computers with one powerful machine and several “dumb” and hopefully inexpensive terminals.

DRI had supported this model for a while. Its MP/M operating system introduced in 1979, was designed specifically for multiuser 8‑bit computers, and Concurrent DOS was the latest evolution of that technology on the Intel 8086 architecture. So why was additional hardware needed in the first place?

MP/M ran on machines built for multiple users. One example was the 8-bit Altos ACS8000-12A, released in 1981. It had all necessary hardware to support multiple users, including six serial ports, four of which could be used to connect terminals. Later models, such as Altos 586 used the Intel 8086 and could run MP/M-86 or Microsoft XENIX. They were not compatible with IBM PC but, like their predecessors, they provided built-in hardware support for multiple users.

The IBM PC and XT were designed to be single user personal computers. Turning them into multiuser servers required additional hardware. StarLink came with the board that contained the necessary serial ports, and also an additional CPU and RAM to boost the performance of the system. Without StarLink, a PC running Concurrent DOS could still support terminals connected to its two standard COM ports, but StarLink increased the number to four, plus the comm ports would remain free.

StarLink was produced by DRI’s hardware group, formed sometime in 1983 and managed by John Meyer4 . The group’s first product was the CP/M Gold Card, which allowed Apple II computers to run CP/M software. These expansion cards had been popular since 1980 when Microsoft released its SoftCard, but by 1984, both Apple II and CP/M were losing ground in business computing.

StarLink was priced at $1695. The hope was that it would be an attractive option to Altos and similar multiuser systems which started around $8000. However, StarLink required a PC with at least 512KB of RAM and a “recommended” 5MB hard disk. These machines were not cheap - an IBM PC XT with 512 KB RAM cost roughly $5000 in 1984. Adding StarLink pushed the total close to the price of an Altos system.

Then again, unlike Altos, a PC with StarLink could run “such applications programs as WordStar, MBA Accounting, and Multiplan”. Yes it could, and also others, like SuperCalc and dBase II. What it could not run was the application that made the IBM PC dominant: Lotus 1-2-3. Yes, this was Lotus’s fault, but it did not matter. People wanted all software developed for IBM PC and PC-DOS to run unmodified on their machines and Concurrent DOS did not provide that level of compatibility.

One way or another, as with other DRI hardware products, StarLink was not a commercial success and was abandoned sometime in 1985 after the bad times hit DRI hard. John Meyer left the company in September 1985, and together with Don Heiskell and Lee Jay Lorenzen started Ventura Software.

The name StarLink got reused. Something called StarLink Plus was advertised in 1987 as a part of ViaNet, by Western Digital. In a Byte Magazine advertisement from January 1990, StarLink is a “service by Galaxy Telecom International in Albuquerque, NM”.

It was IBM, looking for a disk operating system for their upcoming IBM PC.

Legacy of DRI

Digital Research Incorporated (DRI) was one of the most innovative software companies of the late 1970s and early 1980s. CP/M was first implemented by the DRI founder Dr Gary Kildall in 1973/74 - before any commercial microcomputers even existed. The company’s next operating system MP/M, released in 1979, brought multi-tasking, multi-user support, and built-in networking to eight-bit machines - features that became common on personal computers only in the mid-1990s. Some of the best compilers of the early 1980s were developed by DRI, including PL/I-80, Pascal/MT+, CBASIC, DR FORTRAN and DR C. Graphics were another area where DRI left a significant mark: the GSX graphics library, developed from 1982, was a foundation not only for the GEM desktop environment but for many other graphic applications, including the Ventura Publisher.

DRI could be described as a “big fish in a little pond.” At its peak it employed just over 500 people and generated roughly $55 million in revenue, yet it was the fourth‑largest micro‑software company of the era and held a virtual monopoly on disk operating systems for business microcomputers. By mid‑1991, when Novell acquired the company, it was perhaps two‑thirds of that size in both revenue and headcount; but by then the industry had grown so much that DRI had become almost insignificant.

The history of the company can be divided into the following periods:

• Early days (1976-1980): organic growth from a family shop to an organization with about 40 employees and $6 million in revenue.

• Rapid growth (1981-1983): venture‑capital investment.

• Decline (1984-1986): as the market standardized on IBM PC‑compatible machines running MS‑DOS, pushing DRI to the brink of bankruptcy.

• Survival (1987-1991): reduced in size, the company barely managed to stay in business until it was acquired by Novell.

The first period is relatively well covered in various sources, including Kildall’s own writings and interviews with his friends and co-workers. The last one, on another hand, is much harder to research; the company was largely forgotten and received little press coverage. Its most successful product from that period was an MS-DOS compatible product called DR DOS. Eventually, Novell acquired DRI as part of a misguided attempt to compete with Microsoft by spending obscene amounts of money on various obsolete technologies.

This text is focused on the period from 1980 to 1986 starting with the negotiations with IBM and ending with the change in leadership that resulted in prolonged existence of the company, if not in return to relevance.

If you are looking for a biography of Gary Kildall, this is not it. The closest thing to a biography that I am aware of is the chapter on him in They Made America: From the Steam Engine to the Search Engine: Two Centuries of Innovators by Harold Evans, Gail Buckland and David Lefer. Kildall is probably the person I mention most in this article, but the story is really about his company, not his personal life.

While this article is less technical than most of my writing, it is still written by a techie for techies. I assume readers’ familiarity with computer concepts. I focus primarily on engineers at DRI, even though I recognize that many people in non‑technical roles also deserve credit.

I did not have the opportunity to speak with any former DRI employees1 and instead relied on various sources: DRI publications (DR News and Digital Dialog); various interviews with Tom Rolander, Gordon Eubanks, Alan Cooper, Lee Lorenzen, Kathy Strutynsky, Dick Williams, Frank Holsworth; archives of old computer magazines; and a few books, including the above mentioned They Made America and Gates by Stephen Manes and Paul Andrews. No AI tools were used for research and writing, except for spell-checking and grammar2. The photos were taken from old magazines and DRI publications.

Background - Rise of DRI

Digital Research Incorporated was officially founded in June 1976 by Dr Gary Kildall and his wife Dorothy McEwen, with assistance of their family lawyer, Gerry Davis, who served on the board for the entire existence of the company. The goal was to commercialize CP/M, which Kildall had developed in 1974. He had hoped to sell CP/M to Intel, just as he had sold them PL/M - the first high-level programming language specifically aimed at Intel-based microcomputers. Kildall was happy with his job at Naval Postgraduate School in Monterey CA and occasional consulting gigs for various high-tech companies based in Silicon Valley. The idea to start a company came from McEwen, who took on the operations while leaving the technical work to Kildall. They placed an ad at Dr Dobbs’ Journal and started selling CP/M 1.3 to hobbyists for $70 via mail order.

In the beginning, the business brought barely enough revenue to sustain the small software shop. The deal with IMSAI in 1977 established CP/M as a viable operating system, and from that point the company began to grow. A merger with Microsoft was discussed late that year, but nothing came of it.

In early 1978, they hired their first full-time employee, John Pierce. By the end of the year the headcount had reached nine and the company moved into a new building - a Victorian house converted into office space. CP/M 1.4 was released the same year and sold for $100 per copy. Sales reached $100K a month with a 57 percent profit margin. Kildall started working on a PL/I compiler.

The year 1979 was marked by the release of CP/M 2.2 which was a significant re-design of the operating system and the most commercially successful CP/M ever. Also, MP/M 1.0 - a multi-user, multitasking operating system compatible with CP/M was developed and released.

By August 1980, DRI had expanded into another building and employed 24 full-time staff. The flagship product - CP/M 2.2 was by then the industry standard, but the company was looking toward the 16-bit future: CP/M-86 was being developed as an upgrade path for the existing CP/M customers, while the multi-tasking MP/M was seen as the real future: MP/M-86 was under development by Frank Holsworth who was hired earlier that year. Kildall himself was busy wrapping up the PL/I compiler which he saw as a useful tool for developing both system and business applications for microcomputers.

All this success does not mean Kildall was happy with the situation. A brilliant computer scientist, he never had much patience for mundane aspects of running a business; he would much rather work on things that interested him than worry about customer satisfaction. Early on, he offered to sell DRI to the Oakland-based Structured Systems Group, led by Alan Cooper for $70K, but they could not afford it, and Gary Kildall reluctantly carried on, leaving the business operations to his wife as much as possible.

The arrangement worked, at least while CP/M was generating strong revenue, but the problems became obvious early. Gordon Eubanks later described the organization as very dysfunctional: “Gary was very laid-back. He didn’t care that much. Dorothy ran the business and he ran the technical side, and they did not get on.”

End of the Beginning and Beginning of the End

By the summer of 1980, 16‑bit microprocessors had been available for some time: Intel’s 8086 was released in 1978, followed by the Zilog Z8000 in early 1979 and Motorola’s 68000 later that year. Computer manufacturers (“OEMs”) were in no hurry to adopt them, though. Virtually all business microcomputers at that time were based on Zilog Z80 CPU and S-100 bus and ran CP/M.

The change came from a direction few expected. IBM CEO Frank Cary was so frustrated with his company’s inability to develop a successful personal computer that he allowed the Entry Level Systems department in Boca Raton, Florida, to bypass the IBM’s development process and build a computer in a year using of-the-shelf components (including the Intel 8088) and third-party software. The software lead for the project, Jack Sams, immediately contacted Microsoft for a BASIC interpreter. He also hoped to license a disk operating system from Microsoft, but there were none at the time. Instead, Bill Gates directed him to Digital Research.

The initial meeting between the IBM and DRI took place on Friday, August 22, 1980, at DRI’s headquarters in Pacific Grove, CA. What exactly happened is impossible to establish, given the widely different accounts from the people who were there3. According to Jack Sams, the DRI representatives refused to sign the NDA, and the IBM delegation left without even meeting Kildall or starting discussions about licensing of CP/M. The DRI side maintains that Kildall returned from a business trip in the afternoon, signed the NDA, and reached “an understanding” with IBM to license CP/M.

Descriptions of the aftermath also differ: Kildall said he repeatedly tried to contact Sams without success. Sams recalled having phone conversations in which he asked DRI to commit to IBM’s deadline for delivering CP/M-86 and was turned down.

Interestingly, there is no controversy about Bill Gates’ role in these early negotiations. All sides agree that he sent the IBM team to Digital Research. Furthermore, after the meeting broke down, he called Kildall to urge him to restart the talks. It was not until a month later that he got convinced by Paul Allen and Kay Nishi that Microsoft should offer an operating system to IBM to save the project.

Details aside, IBM and DRI were not able to reach the agreement for multiple reasons:

First, there was DRI’s attitude toward the opportunity. Claims that Gary Kildall went flying for fun that day are not fair, but Jack Sams and his team had reason to be frustrated. Gates had rescheduled an important meeting with the Atari’s CEO to meet Sams, personally greeted the IBM visitors in a suit, and even sent a thank‑you note after the meeting. By contrast, Kildall flew off to deliver documentation to a client and left the IBM delegation with his wife and lawyer for the entire morning. Microsoft was eager to put all other projects on hold to help IBM meet its schedule. DRI had no interest in doing such a thing. Kildall had little faith that a big and slow company like IBM could succeed in the fast-moving microcomputer market.

Second, there was a fundamental technical disagreement. In Kildall’s view, CP/M was adequate for 8-bit computers with 64 KB of address space, but the new generation of personal computers built around 16-bit processors was ready for multi-tasking operating systems. DRI had already built one - MP/M, and was porting it to the Intel 8086 as MP/M-864. CP/M-86’ s role was merely an upgrade path for the existing CP/M users. IBM was not interested in multi-tasking capabilities of the operating system; they wanted something familiar to existing personal computer users, not to go overboard with innovation.

Finally, IBM asked to pay one-time fee for CP/M-86 and market it as PC-DOS. DRI insisted on per-copy royalties and keeping the CP/M name. Apparently, they felt caving to IBM’s requests would cause displeasure from the existing customers and maybe even lawsuits. Interestingly, the important IMSAI deal of 1977 had included both a flat fee and a name change. More recent agreements with Osborne Computer and Microsoft involved one‑time payments without name changes. Kildall later regretted both arrangements and did not want to repeat the mistake.

One way or another, at some point Jack Sams had had enough and went back to Bill Gates who was much more enthusiastic about participating in the IBM project. Microsoft agreed to provide an operating system. Instead of developing it from scratch, they licensed, and later bought, 86-DOS, recently developed by Seattle Computer Products. 86-DOS implemented the CP/M application interface to ease transition of existing software from the popular 8-bit operating system. Microsoft generously offered the OS to IBM with no per-copy fee but kept the right to license it to other OEMs as MS-DOS.

The contract between IBM and Microsoft remained secret, and DRI was initially kept in the dark. Eventually, as the release date approached, IBM started sending the API specification to software developers to ensure support for its new machine. It was pretty obvious the API was a copy of CP/M’s, and Kildall notified IBM of his intention to sue SCP for copyright infringement.

That caused immediate reaction in Boca Raton. Regardless of the outcome, a lawsuit would have delayed the release of PC-DOS, and that was the last thing IBM wanted to happen. IBM’s Don Estridge invited Kildall to his headquarters, and on July 21, 1981, the two sides reached an agreement: IBM would market CP/M-86 alongside PC-DOS and pay a per-copy fee, just as DRI had originally asked. There was no agreement on the retail pricing at that time, though.

On August 12, 1981, Estridge presented the IBM PC at the Waldorf-Astoria in New York City. The only available operating system for the new computer was IBM PC-DOS, priced at $40. Two alternate operating systems were announced for a future date: DRI’s CP/M-86, at $240 and the UCSD p-System from the Lowel, MA based company SofTech at $260. According to Estridge, it was research conducted by SofTech that determined the pricing for both systems5. Other sources from IBM mentioned the per-copy fee as the reason for the difference, though the fee was nowhere near large enough to justify it.

The price came as a shock for DRI - it was similar to the retail price of CP/M-86 for direct sales ($250), but was not what they expected from an OEM, especially given the six-to-one difference from PC-DOS. Tom Rolander described it as the biggest shock of his life and “the loss of innocence”.

Interestingly, in November 1984 interview with Computer Language Magazine, Gary Kildall downplayed pricing as the reason for losing to PC-DOS. In his words: “If we had been prepared with a CP/M-86 strategy we would have been able to do the pricing right, and we would have been prepared for the IBM phenomenon. We were prepared for a multitasking phenomenon”.

Timing was another major problem. CP/M-86 was first released in January 1981, more than a year late. Then it took another eight months after the agreement with IBM to release a version for the IBM PC. For the first six months IBM PC was shipping with PC-DOS as the only option.

Perhaps it did not matter. It was clear that IBM really wanted PC-DOS as the operating system for its new microcomputer. CP/M-86 was a distraction to be handled without going to court and UCSD p-System wasn’t seen as a viable operating system, but as a runtime for the UCSD Pascal compiler which was popular in education.

CP/M-86 1.1 for IBM PC was released on April 5. 1982 and by that time over 60,000 IBM PC computers were sold with PC-DOS. The game was over. It would take time to understand just how important that game had been.

Venture Capital Arrives

In October 1980, Jacqueline “Jaqui” Morby6, a vice president at the venture capital firm T.A. Associates, began exploring the possibility of investing in software companies. As she later put it: “I started simply by browsing through computer trade magazines and paying attention to the largest ads - I said to myself, this must be more than just a garage type operation if it could afford to place a $4,000 ad in a magazine”.

Venture capitalists wanted a piece of the microcomputer software market, which in 1981 was estimated at $300 million in annual sales and projected to grow to more than $5 billion by 1985.

For their part, the Kildalls wanted additional investment to help the company grow and diversify. They had become painfully aware of their shortcomings as business leaders and felt it was time to bring in professional management.

Morby met Gary Kildall at the San Jose airport. He flew her in his plane to Sacramento and, over lunch, explained his views on the software industry. Kildall strongly believed that a systems software company should stay out of applications to avoid competing with its customers. “It was a fatal mistake,” Morby said in 1995. “One of the fatal mistakes…,” she added.

The project took a few months to complete, but by August 1981 four venture capital firms, led by T.A. Associates had invested in DRI. Morby and another representative of venture capital companies, Larry Mohr, joined DRI’s board alongside the Kildalls and Davis.

In November 1981, at Morby’s recommendation, John Rowley, who had previously worked at Intel, was hired as COO and took over day‑to‑day management, to the great relief of the Kildalls who were struggling to manage 82 people. Rowley did his best to turn the fast-growing startup into a proper corporation by introducing a management hierarchy, ranking systems and stock options.

Alan Cooper described Rowley as optimistic and enthusiastic, but unfocused and disorganized. Eubanks called him “an interesting guy” but added that he was a not a good choice for DRI.

Some of the old-timers did not appreciate the changes. DRI was quickly shifting from a small business that felt like loving, albeit dysfunctional family into a soulless corporation. Others welcomed the new order. Kathy Strutynsky had been hired by Gary Kildall who stormed into her office at Naval Postgraduate School and with the words “I can finally afford you”, grabbed her bag and took her to DRI without even discussing salary. When pay grades were introduced, she got a raise. She never accused her friend of exploiting her: “Gary only understood whether you liked what you were doing in programming” she explained many years later. On the other hand, when Frank Holsworth was hired, he boldly asked for a salary almost 40 percent higher than what he was earning at the University of California, and Kildall agreed on the spot. “Damn!”, Holsworth thought, “I should have asked for more”.

The company expanded from its two Victorian-style houses into modern office space at 160 Central Ave, Pacific Grove.

The Industry Standard

By the end of the 1970s, the business microcomputer world had settled on a de facto standard: hardware built around the S‑100 bus and an Intel 8080‑compatible CPU (usually the Z80), running CP/M. There were thousands of different computer models7 that adhered to this standard and could share both software and peripherals.

Writing portable software for an 8-bit CP/M machine was straightforward as long as only the documented calls were used to interact with the hardware. That meant no graphics, sound or anything else CP/M did not directly support, and it supported very little. Still, the existing software covered word processing, spreadsheet, databases, development tools. Obviously, almost no games.

When the IBM PC appeared, it quickly became popular enough that many applications (most notably Lotus 1-2-3, released in January 1983) were written specifically for that model and accessed its hardware directly for graphics and performance.

Unlike Apple, IBM was not able to stop other manufacturers from cloning its flagship microcomputer and soon “compatibles” appeared - the first probably being Columbia Data Products’ MPC 1600, released in June 1982. Buyers of these machines expected to run IBM PC applications unmodified, and MS‑DOS compatibility alone was not enough; the hardware had to behave like IBM’s as well.

By early 1984, there was consensus about the new “industry standard” for business microcomputers: software compatibility with PC-DOS (in other words, MS-DOS) and hardware compatibility with the IBM PC.

Quest for Concurrency

The first multitasking operating system DRI produced was MP/M. Developed in 1979, it was written single‑handedly by Tom Rolander and ran on 8‑bit Intel 8080‑compatible computers. The following year, Frank Holsworth was hired to write the 16-bit version, and MP/M-86 2.0 for Intel 8086 processors was released in September of 1981.

MP/M would nowadays probably be described as a “server” operating system. It supported multiple users connected to a central machine via dumb terminals. This usage model was common among minicomputers running UNIX or some other timesharing operating system. Several microcomputer manufacturers, such as Altos Computer Systems, followed the same model and largely adopted MP/M.

It was not necessarily well-suited to personal computers where a single user had a machine for himself. In that world, a user needed to run multiple applications at the same time and easily switch between them as needed. DRI decided to introduce a single-user multitasking version of MP/M, where a user could run multiple programs in virtual consoles on a single screen.

The new product ended up being named Concurrent CP/M-86. As Tom Rolander, then head of the Operating Systems Division, explained: “Concurrency is a better word than multi-tasking. It is friendlier. It means that now you can do more things with your microcomputer at the same time”8.

Concurrent CP/M-86 was announced at the West Coast Computer Faire in March 1982 and released in September for the IBM PC. The minimum system configuration required two floppy disk drives and at least 256 KB of RAM, which was a very high requirement for 1982. The base IBM PC came with only 16 KB of RAM, though 64 KB configurations were more common.

In February 1984, Concurrent CP/M Release 3.1 shipped. Multi-user mode was re-introduced and MP/M was retired as a separate product line. It contained some rudimentary support for character-mode windows. An interesting optional feature was the PC-Mode - a compatibility layer that enabled CCP/M users to run “most” PC-DOS applications. In reality, it was somewhat compatible with PC-DOS 1.1. It did not support hierarchical file system and other advancements that came with version 2.

In May, the entire product line was renamed Concurrent PC-DOS and the new version was released in the fall. From that point on, there would be no more new operating systems with CP/M or MP/M in its name.

Now that DRI had a clearly superior operating system, all it took was to convince people of its value on personal computers. That proved difficult. Users wanted something inexpensive that would run any IBM PC program while taking as little precious memory as possible. Concurrent DOS was none of these things. Peter Norton commented: “It’s like turning a passenger car into a dump truck”.

Frustrated, Gary Kildall spent years trying to explain why modern hardware deserves better than the simplistic single-tasking MS-DOS. But the time for multitasking on PCs had not yet come. A true visionary, Kildall saw “what”, but not “when”. In his memoires written a decade later he noted: “I was competing with an operating system clone, MS-DOS, of my original design, and both operating systems were by this time completely out of date.”.

Concurrent DOS never became a dominant OS on personal computers but was not necessarily a failure either. It found use in office environments to run small servers, much like the original MP/M and later Xenix even after DRI was acquired by Novell.

Rise of Languages

DRI started and ended as an operating systems company. That said, CP/M itself was developed almost accidentally, to host a compiler for a programming language called PL/M that Gary Kildall had previously created. Kildall’s core expertise were programming languages, and he kept returning to them even after CP/M made him famous.

Apart from Kildall, the most important person for starting the DRI Language Division was his friend and former student Gordon Eubanks who had developed a popular BASIC compiler, CBASIC. In June 1981, DRI acquired his company Compiler Systems Inc for $1M. Eubanks felt the amount was very generous: “all this because Gary was pissed at Microsoft”.

Before the acquisition, DRI already produced some programming languages and tools. Kildall’s PL/I-G compiler was released in December 1980 as PL/I-80. The XLT86 assembly code translator was offered to ease migration from 8-bit platforms. Other programming tools included a macro-assembler, linker, and an indexing library for PL/I called BT-80.

Over the summer, Eubanks and Kildall approached Mchael “Mike” Lehman of MT Microsystems, producers of the excellent Pascal/MT+ compiler. In November, DRI acquired the company. Interestingly, Lehman did not join the Language Division, but the small R&D group recently started by Alan Cooper. He soon got busy developing a C compiler for CP/M, code named MCC (Mike’s C Compiler). It was released as “DR C” in July 1983 and priced at $600. Around that time, Kildall announced internally that all future operating systems would be developed in C; until then, they had been coded in a mix of assembly and Kildall’s PL/M.

Within the Languages Divisions, engineers were assigned to specific products. Rick Rosenbaum was in charge of Pascal and led the ports of Pascal MT/+ compiler to the 16-bit Intel 8086 and Motorola 68000 architectures. Charles “Chuck” Spitz took over PL/I from Gary Kildall and Dan Davis, and developed a new compiler back-end for the 8086. Paul Lancaster worked on CBASIC products, and Bob Silberstein on assemblers and linkers for new target architectures.

By July 1982 the Languages SBC released Pascal/MT+86 for Intel 8086 compatible systems ($600), and two programmer productivity tools: Access Manager - a generic file indexing library ($300) that replaced BT-80, and Display Manager ($400) - a tool for designing input and output forms. One of the main strengths of Access Manager was that it was, unlike its predecessor BT-80, accessible from other programming languages released by DRI, and in a sense could serve as a common file format. Display Manager included both an editor and a runtime for accessing screens in device-independent way.

Around that time, a deal was made with Micro Focus to market and sell their COBOL compilers: CIS COBOL and Level II COBOL.

In late 1982 Allen Beebe was hired as director of engineering for the Languages SBC. In the beginning he focused on porting DRI languages to 16-bit platforms.

Eubanks and Beebe defined “three charters” for the DRI Languages SBC: programming languages, development tools and products for learning programming.

The languages were being ported from 8-bit Intel 8080 compatible platforms to 16-bit Intel 8086 family and Motorola 68000. They were being extended to work not only on CP/M but also on MP/M, UNIX and “other operating systems”.

Sometime that spring, Allen Beebe was promoted to director of the Language SBC, and Eubanks started a new Commercial Systems Division.

Soon, two “beginners” programming languages were announced. In February, DR Logo, a port of Logo programming language which was designed as a learning tool. Gary Kildall had coded it himself to give his son a good language for learning programming. On May 27, DRI shipped Personal BASIC, an inexpensive interpreter bundled with an editor, debugger and syntax checker also aimed at beginners.

In March 1984 DR FORTRAN-77 was scheduled to be released. It was based on the new compiler back-end and compatible with Access Manager, Display Manager and other DRI programming tools.

Graphics

Early DRI operating systems were graphics-agnostic. It was probably the release of Xerox Star in 1981 that pushed the company to explore the potential of adding graphics to the existing products or even adding new ones. The task fell to Fred Langhorst who joined the R&D group in early 1982.

The initial plan for entering the graphics field relied on collaboration with the Oregon‑based company Graphic Software Systems Inc. (GSS), which provided a library for drawing graphics primitives called GSS-CORE9 and on top of it GSS-PLOT for plotting data charts.

DRI formed a graphics group led by Langhorst that initially included a marketing manager, an administrative assistant and three engineers. The group started working on a library that would expose the functionality of the GSS libraries via an interface called Graphical Kernel Standard (GKS) that was standardized by ISO and ANSI. DRI’s implementation of GKS was named Graphics System Extension (GSX). The plan was to ship GSX with CP/M operating systems (and make it available on others) and to modify DRI programming tools to use it to gain graphics capabilities. Even end-user graphical applications were shyly mentioned - something that was generally against Gary Kildall’s principles.

On July 27 1982, Graphic products group was officially promoted to a Strategic Business Center (SBC) with Fred Langhorst as a director, reporting directly to John Rowley. Graphics were seen as a potential high-rate growth opportunity for the company.

A diagram published in DR News for Q1 1983 showed the architecture of the GSX library in parallel with the CP/M operating system. That was not an accident - GSX was supposed to help with portability for graphics applications just as CP/M had done with character-based business software.

On April 1, 1983, the agreement with GSS was revised: DRI acquired rights to use their libraries and renamed them accordingly, replacing “GSS-” prefix with “DR-”. More developers were hired, including the new engineering manager for the SBC Don Heiskell who brought industry experience with graphics software (Langhorst’s background was mostly in academia). Dana Firth came from DEC as products marketing manager for Graphics.

In the fall, first concrete results were ready to be announced: the popular CBASIC compiler was ready to use graphics - on either CP/M or MS-DOS as long as GSX was available.

Even bigger news was the release of the first DRI commercial application: it was DR Graph - a menu driven graphical program that could display or print graphs and charts based on data entered manually or imported from spreadsheets.

In December ‘83 an internal call went out for testing another GSX-based application: DR Draw. It was meant to be used to create presentation graphics for businesses.

The applications supported not only with printers and plotters, but also the Polaroid Palette - a digital film recorder popular in the 1980s. In May, DR Graph, DR Draw and Polaroid’s Palette driver were packed together as “Presentation Master” and marketed as a solution for creating slides for business presentations.

The big one had to wait until November: GEM Desktop was announced at COMDEX/Fall ‘84 and released on February 28, 1985.

I already wrote about the history of GEM10 and will not repeat it here. It was a fine piece of software, but the combination of Apple’s litigation threats and DRI’s half-hearted marketing efforts ensured it faded into obscurity.

Yet, a couple of GEM-based applications were developed and continued to be sold for a while. In the May 1989 issue of Byte, there were adds for Gem Desktop, Gem Draw Plus, Gem 1st World Plus, Presentation Team, Desktop Publisher and Gem Artline.

By March of 1990, only two survived: a Computerworld article from Mar 26, 1990: “New versions of Artline and Presentation Team” mentioned the last remnants of DRI graphics offerings, mostly criticizing them for not running natively under MS Windows.

Microsoft Windows 3.0 was released on May 22, 1990. DRI leaders saw the writing on the wall and closed the Graphics Unit.

The British are Coming

In 1982, DRI was quickly expanding: first into larger offices in Monterey area, then into several locations across the United States. In October, international expansion was officially announced. Paul Bailey was appointed Director of European Operations. His first task was to open a sales and support office in the U.K. and then in Germany and France. In January 1983, a small group from Monterey area travelled to England to help set up the office and train new employees. Frank Iveson, who would later become DRI’s vice president of marketing, was appointed Director of Northern European Operations at that time.

The U.K. office opened in Newbury, England. Initially it was a sales and support site, but soon the OEM Support Group was started there to help customers adapt DRI operating systems to their hardware. According to Joe Wein11 , the first new product that came from the group, DOS Plus, began as a support project for Philips Vienna. They took the abandoned CP/M-86 OS and added the Concurrent DOS PC-Mode emulator to it, imperfect as it was. DOS Plus turned out to be surprisingly successful in Europe; it was bundled not only with the Philips computer it was originally developed for, but also with popular models from Amstrad and Acorn.

In 1986, the OEM Support Group was renamed the European Development Centre (EDC) and moved to Hungerford, England. Concurrent DOS 4.1 was handed over to EDC, and development continued there, including all versions of Concurrent DOS XM and DR Concurrent DOS 386. The OS was commercially pretty successful in Europe, where customers were less obsessed with IBM than in the US12.

DOS Plus, with all its limitations, showed that there was real demand for a drop-in replacement for MS-DOS. In 1987, after receiving $1M investment from Kay Nishi, of all people13, DRI started planning a product that would be 100% compatible with MS-DOS while still offering technical improvements. The operating system was developed by the EDC, with Joe Wein as the chief architect. It was named DR DOS, and first announced on May 28, 1988, as DR DOS 3.31.

DR DOS turned out to be the most popular DRI product of its later years. Ironically, it abandoned concurrency that DRI had been so desperately trying to promote since 1979, but was truly compatible with MS-DOS and inexpensive. DR DOS 5.0, released in 1990, was sold as a retail product and caused genuine panic at Microsoft and, one hopes, a smile on Gary Kildall’s face.

At the Peak

In the first half of 1982, a major restructuring was implemented. The Operating Systems Division and the Languages Division were promoted to Strategic Business Centers (SBC) with their own independent development and marketing. The idea was to make these key divisions more responsive and allow them to operate almost as independent companies.

The new structure was described in detail in the first (August 1982) edition of Digital Dialog, the DRI employee newsletter. It included a complete list of DRI’s employees - some 200 of them, divided into divisions: R&D, Graphics, Operating Systems, Languages, Finance & Administration, Manufacturing, Operations and Sales. Gary Kildall was President and John Rowly the COO. The three Vice Presidents were: Dorothy McEwen (Operations), Tom Rolander (Operating Systems) and Gordon Eubanks (Languages).

In 1982, DRI did not appear to be much affected by the rising popularity of the IBM PC, and continued to grow in headcount, products lines and revenue.

Tom Rolander considered the CP/M ‘83 trade show, held Jan 21-23 at Moscone Center, San Francisco, to be the company’s peak moment. Financially, it was not; DRI’s revenue would continue to grow for another couple of years. But in terms of presence and visibility, it probably was. The speakers included Alan Kay, Adam Osborne, Dan Bricklin and Dan Fylstra. Among more than 400 exhibitors were companies like Altos, Commodore, DEC, Fujitsu, Hewlett-Packard, NEC, NCR, Osborne, Radio Shack/Tandy, Televideo, Vector, Xerox and Zilog. Some 50,000 people attended.

Early 1983 marked the beginning of international expansion. The first international office was established in Newbury, England. The Munich, Germany office was opened next, led by Dieter Kadach, director of Central European operations. On May 12, the Japan office was officially opened with John Rowley hosting the event. Masahiro Morimoto was appointed Director of Pacific Operations and Masaho Okabe President of DRI Japan.

In the summer of 1983, another reorganization introduced the Consumer Division and folded the former Strategic Business Centers into the Commercial Systems Division under Allen Beebe. It was renamed the Systems Software Division by early 1984.

In September, the plan to relocate the headquarters to Garden Court Office Complex in Monterey was announced. At that point, DRI had 427 employees. It would take a year to complete the move.

By 1983 revenue, DRI was estimated to be the fourth largest software company14, with sales around $45M. It trailed MicroPro ($60M), Microsoft ($55M), and Lotus ($53M) but was ahead of VisiCorp ($43M) and Ashton-Tate ($35M).

Home and Education

The Consumer Systems Division was created as a peer to the Commercial Systems Division. It was built from scratch by Ken Harkness, who came from Atari with the idea of producing home and educational software.

The first products from the new division were transplanted from the Languages group: Personal Basic and DR Logo. Then OWLCAT, Inc., a producer of S.A.T. preparation tutorials, was acquired and added to the Division. An operating system - Personal CP/M, a ROM-able menu-driven variant of 8-bit CP/M 3, was added to the product list as well.

Kildall and Rolander joined the Division from R&D (formally or not) and started exploring new optical-storage technologies, like video discs. They saw the new types of media as an opportunity to create new kinds of educational software, including electronic encyclopedias. When they suggested to add the technology to the existing product line, the idea was shut down. They then started a separate company, named Activenture Corporation to pursue it.

As early as April 1984, some analysts were warning that the Consumer Division was not producing the expected results and that growth opportunities in the home and educational market were limited.

By late 1984, it was clear the division was a failure. Kildall said in an interview: “The difficulty in concentrating in educational products— which I’d like to— is that there is a much larger margin in commercial software.”

The Consumer Division was likely shut down sometime in 1985, although ads for DR Logo continued to appear in computer magazines for a while.

Round Three

The February 20, 1984 issue of InfoWorld included an article titled “New developments may decide battle over Unix”. It quoted Gary Gysin, DRI’s product manager for operating systems: “Round one was the 8-bit processor. We provided the standard operating system, CP/M. Round two was the 8088; we lost that one. Round three is the 286 and the 68000. We’re winning that one.”

Back in April 1982, the famous Homebrew Computer Club had been shown the recently announced Intel’s 80286 CPU. At the same event, it was announced that DRI was developing a new operating system called MP/M-286 specifically for the new processor. DRI was working hard to position itself for the next generation of personal computers, and it was betting on its MP/M - based technology.

Then, in early 1984 three separate agreements with AT&T, Intel and Motorola marked DRI’s entry into the UNIX market.

The Motorola project was really more about porting Concurrent DOS to their VME/10 development system. It did include source-code portability with UNIX. The more interesting agreement was with Intel and AT&T to port UNIX System V to Intel 80286.

It made sense. AT&T was a technology giant and, after the breakup mandated by antitrust law, was finally allowed to sell computers. The company decided to make use of its popular UNIX operating system and saw DRI as a potential ally against IBM and Microsoft. The offer was hard to refuse - having AT&T in their corner for the “round three” sounded more promising than going alone with MP/M-286.

DRI and AT&T committed to developing something called the “UNIX System V Applications Library”. It was hard to pinpoint what exactly that “library” would contain: it seems the agreement was open-ended in that regard. Allen Beebe, at the time the director of the Systems Software Division, mentioned that DRI’s programming languages and tools would be ported to UNIX System V. The May issue of “Digital News” had an announcement about DRI and AT&T jointly evaluating third party applications for inclusion in the library.

By fall, all the hoopla about DRI and AT&T working together on UNIX suddenly stopped, and in November Kildall even admitted in an interview that he did not like UNIX, although he did like the C programming language and its runtime.

December issue of Digital Dialog included the photo of the “UNIX V Team” which was “nearing completion” of porting UNIX System V to the Intel 80286. Intel sent “formal congratulations”. Not a word about AT&T. One person in the photo was DRI’s program manager for the project, Chuck Hickey. In the end, DRI never released the port, but a few months later Hickey founded Microport Systems, and released Unix System V/AT15.

AT&T UNIX PC was introduced on March 26th 198516. It was based on the Motorola 68010 CPU. Available software included products from Microsoft (Word, Multiplan), Ashton-Tate and Language Processors. There was no mention of DRI or the “Applications Library”. The computer was a commercial failure - Unix personal computers would have to wait for the 21st century; Apple Power Mac G4 running Mac OS X arrived in 2001.

One way to explain what happened with the UNIX saga is that at some point (perhaps after IBM announced its 286-based AT model in August 1984) AT&T decided to abandon the idea of basing their UNIX PC on the 80286 and opted for Motorola 68000 instead. DRI was left behind.

That was the end of DRI’s big UNIX plans. Yet another expensive distraction.

At least MP/M-286 was still there. When Frank Holsworth was hired in 1980, he had half‑jokingly offered to develop a proper operating system, as he did not have a great opinion of CP/M, given his UNIX background. Instead, he first worked on MP/M-86, a port of Rolander’s MP/M to the 8086 CPU. Later, as engineering manager in the Operating Systems Division, he led the design of the first generation of Concurrent CP/M systems, based on MP/M-86.

Finally, with the arrival of the Intel 80286, Holsworth could design an operating system the way he felt it should be done. It was a masterpiece17 with modular design, dynamically loadable drivers instead of Kildall’s old BIOS, a brand-new hierarchical file system with support for file sharing and locking, built-in security mechanisms, support for internationalization, memory protection. It was written from ground-up in C with intent to be easily ported to other modern CPUs - specifically Motorola 68000. By the time it was ready for release, MP/M and CP/M brands were out of fashion, and it was confusingly named Concurrent DOS-286.

One feature meant to differentiate Concurrent DOS-286 from UNIX was its built-in compatibility layer with the “industry standard”; applications written for the IBM PC, both “well-behaved” and “poorly behaved”, including Lotus 1-2-3 were supposed to run within Concurrent DOS-286 virtual consoles.

The 80286 could operate in a compatibility mode (“real mode”) where it behaved just like 8086. Its native mode (“protected mode”) offered all the interesting new features, such as much larger address space, memory protection and support for multi-tasking. The problem was that the 80286 would start in real mode and could switch to protected mode, but once switched, it could not return without a reset18. Concurrent DOS-286 was designed to run in protected mode and emulate 8086 from there rather than relying on real mode.

Concurrent DOS-286 was already shipping to select customers, when a change in the Intel 80286 hardware broke the emulation and forced a postponement. Before Intel provided an acceptable fix, DRI decided to retarget Concurrent DOS-286 from a general-purpose DOS-compatible OS to a real-time system for manufacturing. It was renamed to FlexOS in October 1986, and a new Flexible Automation business unit was formed from the remnants of the Operating Systems department in the Monterey office to continue its development. FlexOS was successful in its niche but was never going to replace MS‑DOS.

As for the “bad guys”, they were not idle either, but saw even less success with multitasking than DRI. IBM refused to endorse Microsoft’s Xenix and instead started selling Interactive Systems' PC/IX. It also released a somewhat multitasking “operating environment” called TopView which was deemed both memory-hungry and hard to use and was eventually abandoned. Microsoft produced a multitasking MS-DOS 4.0, which IBM also rejected. Eventually, the two companies buried the hatchet and jointly began developing a next-generation operating system. That took a while…

In the end, there was no “round three”. Frustratingly, PCs continued running MS-DOS, with the 80826 used simply as a faster 8088/8086.

Fall of Languages

In May 1983, DRI announced ports of its development tools to PC-DOS. According to Carmen Governale, the Product Marketing Manager of the Languages SBC (PCMag July 1983), “The fact that CP/M-86 had not done as well as DRI had hoped has nothing to do with our decision to create more portability with our languages”. Ports to UNIX were also announced.

It made sense for the Languages SBC to want its products on as many platforms as possible. Unfortunately, by that time the competition started to overwhelm DRI’s development tools.

Some never got any real traction to begin with. The PL/I compiler, originally coded by Kildall himself, was praised for its quality but the language itself was (and still is) used almost exclusively on IBM mainframes.

DR Logo was another example. I remember Logo being mentioned as a good language for learning programming in the mid-1980s, but the schools used BASIC first and later Pascal much more than Logo.

Pascal/MT+ at first competed with similarly priced Microsoft Pascal and while I couldn’t find any actual numbers about its market share, seemed to be doing fine. Then Borland appeared out of nowhere: Turbo Pascal, designed by Anders Hejlsberg was released on 20 November 1983. Compared to Pascal/MT+ the compiler itself was nothing to write home about in terms of language features and optimization capabilities. But, at $49.95 it was more than ten times cheaper and contained an excellent IDE. It became an instant hit, and Pascal/MT+ was soon struggling. The last release I am aware of was 3.3; it came out in early 1985 with price reduced from $600 to $400. Too little, too late. If it was any consolation, Microsoft Pascal held on a bit longer but was eventually destroyed by Borland as well.

The most successful DRI language was Eubanks’ CBASIC. In the late 1970s and early 1980s, CBASIC was a popular tool for developing business software for microcomputers and was successfully competing with other BASIC compilers such as Microsoft’s BASCOM. But then unexpected competition appeared: Ashton-Tate’s dBASE II was one of the products IBM chose to be ported to the IBM PC in time of its release. As the platform picked up in popularity, dBASE started replacing BASIC dialects as the development platform for business applications. Ads for CBASIC became less frequent after late 1983, and by 1985 it had mostly disappeared. Interestingly, it was offered as an option for FlexOS 286, released in January 1987, which is the latest mention of CBASIC I could find.

The February 1985 issue of Digital Dialog includes a photo of the Languages Department, then led by John Yu. The team was much larger than the one listed in August 1982. Names that appear in both lists include Rick Rosenbaum, Nancy Zetner and Rich Bielsker.

The plan for 1985 was to complete 40 software development products. It is safe to assume this did not happen. The Languages Department was probably dismantled before the end of the year.

The “reorganization” of the Oct 1986 doesn’t even mention languages.

People of Stature

In the March 1985 edition of Byte Magazine, Jerry Pournelle casually remarked that “Many people of stature seem to have left or are leaving Digital Research”. By 1985 many of the DRI brightest minds were indeed on the way out, but the process had begun much earlier.

When Tom Rolander accepted Gary Kildall’s invitation in 1979 to join DRI, it was a very different place: Rolander worked hard and had a lot of fun at the same time. He and Kildall were both pilots and would often discuss software while flying together. Kildall later described him as his “copilot in flying and in life”. Rolander met his wife Lori at the office: “I don’t know where else I would’ve met a woman.” he said, laughing. When they married, Gary Kildall was the best man.

Rolander accepted a position of VP of engineering, and enjoyed it while DRI was small. After the VC came in, the organization grew rapidly, and by 1983 he was Director of Operating Systems Division, managing 150 people and having no time for the engineering work he loved so much. One day, he had enough; instead of going to the office, he relaxed drinking beer on a beach. The following day he presented his resignation to Kildall and Rowley. They managed to convince him to stay for a while in R&D - a much smaller group within DRI. In 1984, he and Kildall founded Activenture Corporation, and they both left DRI in June 1985.

Alan Cooper was a co-founder of Structured Systems Group, one of the first companies to develop business applications for microcomputers. In 1980, he left it to start another business that quickly folded, and in 1981 accepted Gary Kildall’s invitation to start an R&D department at DRI. He spent less than two years with the company and came up with a few proposals for new products that were never approved; apparently his relationship with John Rowly was not good. The June 1983 edition of Digital Dialog mentioned that he was transferred from R&D to the Graphics SBC as the “planner and strategist”. Soon after, he left.

One of Cooper’s unused ideas was a visual programming language which he named Ruby (unrelated to the popular web scripting language). He sold it to Microsoft in 1988. Microsoft adapted it and changed the name to Visual Basic; it became the most popular tool for developing business applications in the 1990s.

Gordon Eubanks had been Kildall’s student at the Naval Postgraduate School and created a BASIC compiler for CP/M as part of his master’s thesis. Kildall described him in his memoirs as: “a prime mover and often, but not always, my friend”. Eubanks had a great respect for Kildall as a programmer and liked him as a person but would often criticize his attitude towards business.

At DRI, Eubanks served as VP of the Language Division until promotion to head of Commercial Systems Division. In August 1983, he had enough: “It became clear to me that Digital Research did not have the will to win and they were losing opportunities. So I went off and did my own thing.”.

Eubanks had a very successful career after DRI. Among other things, he was a CEO of Symantec.

Mike Lehman founded MT Microsystems with his wife Nancy in 1979 in Solana Beach, California. He developed a Pascal compiler Pascal/MT+ which was considered superior to other offerings, including the popular UCSD Pascal. The Lehmans and their assistant Pattie McCracken19 became DRI employees 61, 62 and 63 in November 1981. Most of his time with DRI, Lehman spent at R&D, developing a C compiler, DR C.

Lehman left DRI probably in 1984, but definitely before March 1985 when he is mentioned in the Pournelle’s Byte Magazine article as the author of FastFinder for Macintosh. He must have coded it in Pascal.

In March 2005, Lehman posted a short text after Dorothy McEwen had died in which he called DRI “his family”.

Fred Langhorst earned a PhD in Computer Aided Design at Purdue University in 1977. At DRI, he started the Graphics Division and led it through various reorganizations through the company’s growth.

He left in late 1984 and joined (as the VP of Engineering) Lifetree Software which released GEM Write in 1985. Later he worked as a GM at various companies including Mentor Graphics and Intel.

Lee Jay Lorenzen started at Xerox (not PARC, but the Office Products Division in Dallas Texas) where he produced a prototype desktop graphical environment that ran on 8086 platform, called “Lone Star”. He was recruited to DRI in early 1983, by his former skip-level manager from Xerox, Jackie Pakarinen20 and led the development of GEM, from first prototype to release.

In September 1985, Lorenzen and his boss Don Heiskell resigned from DRI to start Ventura Publishing where they developed one of the most successful early desktop publishing applications: GEM-based Ventura Publisher.

Kathryn Strutynski worked with Gary Kildal at Naval Postgraduate School (NPS) in Monterey. He recruited her to DRI in early 1979 as employee number four. Strutynski helped Kildall release CP/M 2.2, then led the CP/M-86 development and later became a project manager overseeing Concurrent CP/M, CP/M Plus, and CP/M‑DOS.

In mid-1985, with mass layoffs hitting DRI, Strutynski returned to NPS. “Gary came to the Navy School and started to cry.”, she said two decades later21.

At the Bottom

In early 1984, DRI was financially at its peak, but the downturn was coming quickly. The company depended heavily on CP/M sales to OEMs, and that market was disappearing. As early as April of 1984, InfoWorld mentioned Digital Research’s upcoming “resurgence” as new products were being announced. In the same month, DRI received some $20M in investments - mostly from AT&T.

The first layoffs I can pinpoint occurred in early August 1984 during one of the many reorganizations Rowley seemed to be so fond of. The number of impacted employees was probably not large, as it was referred to “some cutbacks”, but morale suffered. The October issue of “Digital Dialog” included some tough questions from employees to the President. Rowley admitted the growth was slowing but remained characteristically upbeat about the future.

In December, he sounded openly pessimistic about the outlook for 1985: “The retail market is experiencing compression of revenues and a general slowdown in the sales of personal computers and related software”22, he said. The consumer market looked especially worrisome, but Rowley hoped GEM would be a commercial success.

By mid-1985, the situation had deteriorated23. After another round of layoffs, headcount fell below 300, but even that was not enough as revenues were expected to fall by at least one third from the previous year. Gary Kildall officially resigned as CEO on June 28, though he remained chairman of the board.

As bad as 1985 was, 1986 was worse. By the end of that year, annual revenue had fallen to $20M. In October, Rowley carried out yet another desperate reorganization; this time 30% of remaining employees were sacked. Only 140 remained in America and another 100 overseas.

Digital Research was on its last legs. It was $14M in debt and had $10M in cash reserves. Lenders were expected to call the debt at any moment. In November, the board finally fired John Rowley and asked Gary Kildall to find a buyer for the company. Kildall called Bill Gates. When they met in San Francisco, he asked $26M for DRI. Gates replied that the company was not worth more than $10M.

Kildall refused and bade Gates farewell amicably.

Another Call from IBM

In 1986, Dick Williams24 was a 23-year IBM veteran and Vice President of the General Products Division, headquartered in San Jose, CA. He was growing unhappy with how things were ran at IBM, and in November, while visiting the White Plains, NY office, he told his boss he would be leaving at the end of the year. That evening, while waiting to board a flight at JFK airport, he skimmed Electronic News magazine, and saw on the front page that Gary Kildall had fired John Rowley and was looking for a new CEO.

Williams did not know Kildall, but managed to locate and call him from a pay phone at the airport and offered to help. Kildall did not know him either but was desperate enough to agree to meet this random man who claimed to be an IBM vice president. Long story short, on January 8, 1987, Dick Williams started his new job as the CEO and President of Digital Research Inc, an experience he later described as the hardest five years of his life.

With the computer market downturn of 1985/86 finally over, and under the steady hand of the new CEO, DRI managed to reach calmer waters. In April 1988, Marketing Vice President Frank Iveson told Computer Business Review that DRI was not only profitable again but was also paying back the loans taken during the bad years. Annual revenue for fiscal 1987 was reportedly up to $35M.

FlexOS was being licensed to companies like IBM and Siemens and its development continued in Monterey. Concurrent DOS was developed in England, along with DR DOS which started to make Bill Gates increasingly nervous and forced Microsoft to re-invest in the mostly neglected MS-DOS.

But DRI never returned to its old days of glory. Even if (barely) profitable, its influence on the industry was gone forever. The company was largely forgotten by the press, and it gets increasingly difficult to find articles about it after 1985.

After Microsoft Windows finally started being widely adopted in 1990, Williams concluded DRI could not survive long on its own and started looking for a partner to acquire the company. After a year of searching, he finally found one: Novell.

Acquisition and Closure

On July 16, 1991, the definitive agreement to merge DRI into Novell was signed, and the announcement followed the next day. According to Business Wire on July 17: “Digital Research, with 273 employees, had revenue of $40.9 million in its fiscal year ended Sept. 30, 1990, up from $36.2 million in fiscal 1989”.

In November 1991, after the acquisition was completed, Novell was restructured into three “Systems Groups” and Digital Research became one of them.

Concurrent DOS, renamed to Multiuser DOS a couple of years prior, was sold off in 1992.

The latest mention of the Monterey offices I could find is a Computer Business Review article from March 8, 1993: “NOVELL FORMS A DEDICATED SYSTEMS BUSINESS UNIT” which notes that the new Dedicated Systems Business Unit was formed in the old DRI headquarters.

In July 1994, Novell sold FlexOS to Integrated Systems and relocated the remaining engineers to Novell’s headquarters at Provo, Utah25. It was roughly ten years after DRI moved into the Garden Court offices, so one can speculate that the lease expired around that time and Novell closed the site.

The EDC at Hungerford, England26 seems to have remained active into 1995.

A short Computer Business Review article from August 16, 1994, titled “NOVELL TO FADE OUT THEIR DOS 7 TO AVOID MICROSOFT” reported that new Novell CEO Robert Frankenberg had decided to abandon DR DOS: “a big round of lay-offs is in the wind, with some observers saying numbers could go as high as 2,000;”.

Gary Kildall did not live to read that article. He died of a cerebral hemorrhage on July 11, 1994, in Monterey.

At some point I decided to get a better understanding of MP/M’s internals - specifically the part that enables multitasking. The source code I examined is for MPM II and can be downloaded from the Digital Research Source Code web page. To make sense of the design, I also relied on the MP/M and MP/M II manuals from Tim Olmstead Memorial Digital Research CP/M Library.

This post is a summary of my findings.

Background and History

Tom Rolander1 completed his master’s degree at the University of Washington in 1976 and soon after was recruited by Intel. There he joined a team that designed and developed RMX/80, a real‑time multitasking operating system for process‑control systems. After leaving Intel and then spending some time consulting for National Semiconductors, Rolander accepted invitation from Gary Kildall to join his company Digital Research Inc. (DRI) in early 1979. Kildall himself had been consulting for Intel since 1972 and, among other things, created the programming language called PL/M.

At that time, DRI’s only product was an operating system for Intel 8080 compatible computers called CP/M. CP/M was very simple and flexible, which along with its low price made it the most popular OS for the 8-bit business microcomputers. By 1979, Kildall believed it was time to add support for multitasking and multiple users. One motivation was background printing; another was the fact that computer manufacturers like Altos started producing multiuser microcomputers. Adding a CP/M compatible operating system that would support them was a logical next step.

Tom Rolander coded MP/M 1.0 alone, including the core OS, utilities and documentation - he described the experience as “just a huge amount of fun”. Soon after, version 1.1 came out, and then in 1981 version 2.0 and finally 2.1 in early 1982.

The operating system was ported to 16-bit Intel architecture by another talented engineer Frank Holsworth in 1980/81 and named MP/M-86. It was followed by a line of “Concurrent” CP/M products which retained the MP/M core design and added features like MS-DOS compatibility. The last incarnation on MP/M family of operating systems was FlexOS which was designed for industrial and point-of-sale applications and outlived DRI by at least a decade.

Features

In the MP/M 1.0 User’s Guide, the system is described as “an upward compatible version of CP/M 2.0 with a number of added facilities”. The major additions include support for multiple users, each working on a separate terminal, and multiple tasks per user. For application programmers, MP/M introduced memory bank-switching, inter-process communication (including synchronization), and interrupts.

Another interesting feature not available in CP/M was resident system processes which remained in memory alongside the OS. MP/M shipped with several standard resident processes (such as the system status display), and users could write their own.

The system was described as providing “real-time” multitasking, which is misleading. MP/M is a cooperative multitasking system that switches tasks at system calls, interrupts, or clock‑tick events. It does not provide deterministic timing guarantees which we would expect from modern real-time systems.

Unlike Intel’s RMX which inspired it, MP/M was not intended for process control applications that would require real-time capabilities. It was an alternative to minicomputer time-sharing systems for use from multiple “dumb” terminals in business environment. Many of these time-sharing systems were also described as “real-time” without providing any real time guarantees, so we can assume it was just a difference in terminology.

Real-time definitions aside, building a preemptive multitasking system for the Intel 8080 compatible 8-bit CPUs was a real feat. The hardware offered no privilege levels, no memory protection, no thread-specific stacks, no trap instruction, no atomic primitives and only a 64‑kilobyte address space. Preemptive multitasking became a common feature on personal computers only in mid-1990s on Windows and in 2001 on Mac2.

As for CP/M compatibility, it was a goal that was only partially achieved. The user guide claims that only “correctly written” CP/M programs (i.e. the ones that use only officially documented system calls) would run under MP/M. In practice, programming 8-bit machines relied not only on using undocumented system routines, but even undocumented CPU instructions.

System Design

Like CP/M, MP/M is a modular system. The hardware-dependent layer is isolated in a separate module, called XIOS (Extended I/O System) which was implemented by computer manufacturers (OEMs). It is equivalent to the CP/M BIOS but extended to support multiple consoles.

BDOS (Basic Disc Operating System) is included for compatibility with CP/M; it provides the same system calls.

XDOS (Extended Disk Operating System) implements MP/M specific system calls including ones for managing tasks, memory and consoles. It contains the nucleus: the kernel that manages process dispatching, queue management, flag management, memory management and system timing.

Process Dispatcher

The process dispatcher (implemented in NUCLEUS/DISPTCH.ASM) is the heart of the nucleus. It is priority-based, which means that it selects a process with highest priority that is in ready state to transfer the CPU to it. As mentioned, it is not time-driven, but event driven. The events that cause the dispatcher to run are: system calls (BDOS or XDOS), queue operations that cause a process to block, flag wait and set operations, and hardware interrupts.

The clock interrupt does not directly preempt tasks; instead, it wakes the Tick Process, which then performs delay‑list maintenance and may cause a higher‑priority process to become ready.

A system process called IDLE with very low priority runs when no other process is ready.

Each process is associated with a process descriptor structure that contains its priority, status, stack pointer, memory segment, console, BDOS state, and saved CPU registers. The table of descriptors (PDTBL) is defined in NUCLEUS/DATAPG.ASM.

A process may be running, ready, or in one of several wait states (queue wait, flag wait, delay, poll, attach/detach, etc.).

Processes that become ready are first placed on the Dispatcher Ready List (DRL). The dispatcher then inserts them into the Ready List (RLR), which is ordered by priority. Processes with equal priority are scheduled in round‑robin fashion by reinserting the running process at the end of its priority group.

All that happens within the “dispatch” routine in NUCLEUS/DISPTCH.ASM:

1. Interrupts get disabled and a global flag is set to mark the dispatcher is running

2. The current process state is saved into its process descriptor

3. The current process is handled in accordance with its status

4. Devices are polled

5. Processes are moved from DLR to RLR

6. The next active process is selected and its context restored from the PD

7. Interrupts are re-enabled

The code was first written in PL/M, and the original source is (partially) preserved as comments, but the production MP/M II nucleus is written in Intel 8080 assembly. It is possible that MP/M 1.0 was written entirely in PL/M and ported to assembly for version 2.0.

Conclusion

This concludes my modest look inside the MP/M nucleus. Beyond the dispatcher, the system has other mechanisms worth exploring: queues, flags, resident processes, the delay list…

All packed into just a few kilobytes of assembly code.

Allen and Gates were childhood friends and co-founders of Microsoft. In 1975, after the first commercially successful microcomputer Altair 8800 was released, they wrote a BASIC interpreter for the new machine without even seeing it and then moved to Albuquerque to be close to MITS - the company that produced Altair.

By 1978, Microsoft was supplying BASIC for most early home computers. The relationship with MITS deteriorated and the founders decided to move the company to Seattle area.

Before the move, a young Japanese entrepreneur Kazuhiko “Key” Nishi, introduced himself to Bill Gates. The two quickly became friends and Nishi was appointed as Microsoft’s vice president for Far East, although he still kept running his own company - ASCII Corporation. In 1979 Nishi brought some major Japanese customers to Microsoft, starting with NEC which produced the popular NEC PC 8001 personal computer. Japanese market almost overnight became a major source of revenue for Microsoft.

I can’t celebrate our 50th anniversary without mentioning Kay Nishi, whose partnership and friendship were critical to Microsoft’s expansion internationally—in Japan and beyond. Not only is he an amazing thinker (and one of the most under-appreciated leaders in the company’s history), he’s also more like me than anybody I’ve ever met.

Bill Gates

After Microsoft relocated in early 1979, Nishi spent even more time with Gates and Allen. He helped recruit Steve Ballmer in June 1980. He was in the office when an IBM delegation first visited Microsoft on July 22nd, 1980, and demonstrated some of the Japanese computers that ran Microsoft BASIC.

During the early phase of IBM’s secret PC project (“Project Chess”), Nishi was involved in talks with IBM’s hardware engineers, trying to convince them to add more memory, a more powerful CPU and better graphics capabilities, with limited success.

Soon it became clear the biggest obstacle for the project was the lack of a suitable disk operating system. The obvious solution was Digital Research’s CP/M, but its port to the 16-bit Intel processors that IBM planned to use was late, and DR repeatedly refused to commit to IBM’s aggressive schedule. At last, IBM’s software lead for the project, Jack Sams, lost patience and asked Bill Gates to find an alternative.

On September 28th, Gates invited Allen and Nishi to his office to break the stalemate.

Microsoft at that point in time did not sell operating systems; in February 1980, it licensed UNIX source code from AT&T, and in August announced it was working on a UNIX-based operating system called XENIX. It was not a solution for the IBM PC which was too limited to run a real UNIX. Microsoft definitely had expertise to develop a simple operating system for the IBM PC, but the schedule was tight, and Gates was a pessimist by nature; Microsoft had already committed to deliver not only the BASIC interpreter, but also all the compilers they were selling at the time - adding an operating system to the list must have sounded scary.

It was Kay Nishi who put things in perspective: the amount of code for all the software Microsoft had already agreed to port was some 400 KB of assembly source. Nishi’s estimate was that the operating system would add no more than 20 KB. Then he jumped and yelled “Got to do it! Got to do it!”.

As it happened, Microsoft did not even have to develop the OS from scratch. Paul Allen knew of an existing operating system for Intel 8086, developed by an employee of Seattle Computer Products, Tim Paterson. The operating system was officially named 86-DOS but was also known by its code name: QDOS, which stood for “quick and dirty operating system”. Allen offered to call the SCP’s owner Rod Brock in the morning and ask to license 86-DOS. Again, Gates was hesitant: betting the critical IBM project on something called “quick & dirty”? In the end he agreed.

Microsoft finally had a plan for an operating system for IBM PC. On September 30th it was presented to IBM at a meeting in Boca Raton. On November 6th, the official contract was signed; Microsoft was the supplier for all system software for Project Chess.

As usual, to make an informed conclusion, some wider context is necessary…

Microsoft’s Monopoly on BASIC Interpreters

The critical thing to understand is that Microsoft was a monopoly even before IBM approached it. The market it dominated was small: BASIC interpreters for personal computers, but it was a monopoly, nevertheless.

Microsoft’s core product, the BASIC interpreter, ran on almost all popular personal computers at the time1, including various TRS models, the Commodore PET, Atari machines, and the Apple II.

The only theoretical alternative was Tiny Basic - a public domain interpreter developed in 1975 as a reaction to Microsoft BASIC which was considered too expensive. Tandy used Tiny Basic to develop the TRS-80’s Level I Basic, but even they switched to Microsoft’s Level II Basic soon after.

Some computer manufacturers opted to develop their own version of BASIC with varying success. The Apple II initially shipped with a BASIC written by Steve Wozniak (later named Integer BASIC as it supported only integer numbers), but it was replaced by Applesoft BASIC which was a derivative of Microsoft BASIC.

British home computer makers were more successful in creating their own versions of BASIC interpreters (Acorn’s excellent BBC BASIC is one such example) or outsourcing its development to local software companies rather than Microsoft (Sinclair contracted Nine Tiles; Amstrad used Locomotive Software). On another hand, Japanese manufacturers almost universally adopted Microsoft BASIC.

To cut a long story short: if a company wanted to enter a home computer market in late 1970s and early 1980s, it was expected to include a built-in BASIC interpreter. The realistic options were to either develop one specifically for the new machine or to license Microsoft’s. Most hardware producers chose latter, as it was less risky, faster and ultimately cheaper. IBM, however, was not only able to produce a BASIC for new hardware; it had already done so multiple times. Why did it end up going to Microsoft anyway?

IBM and Small Computers

In 1980, IBM was by far the largest computer company in the world, with $26.21 billion in gross income and more than 340,000 employees2. Its most important products at the time were the mainframe class computers of the IBM System/370 family which dominated the industry in the 1970s.

Yet, there were problems as well; the most pressing one was of legal nature: the antitrust lawsuit that was filed in 1969 and was not resolved until 1982 was hanging over the head of the mighty IBM and affected how it conducted business.

In addition, it became obvious IBM was slow to adopt to new trends in computing. The threat was coming from below: first from the minicomputers produced by companies such as Digital Equipment Corporation (DEC), Hewlett-Packard, Data General and Prime Computer Inc. Then, in 1975, the first commercially successful microcomputers appeared, developed mostly by small startups that operated very differently from IBM. In the beginning, they were used only by hobbyists. Then they spread into K-12 education and finally small businesses began noticing them after the first spreadsheet and text processing applications were released.

IBM did not ignore the “small” machines. It introduced a series of low-end business computers as early as 1969 with System/3. More interesting was the IBM 5100 Portable Computer first introduced in late 1975, based on the prototype called SCAMP from 1973. It was heralded by the “Byte” magazine as the first personal computer from IBM, despite its high price. Although very innovative, these machines failed to make much impact: they were too expensive and too unfamiliar to computer enthusiasts.

System/23 DataMaster

IBM’s first attempt to build a commercial microcomputer was the IBM System/23 DataMaster. Development began in February 1978 by the Entry Level Systems unit in Boca Raton, FL led by Bill Lowe. The computer used Intel’s 8085 CPU and was designed to be easy to operate in an office environment and to run applications written in BASIC3.

An interesting spin-off from the project was the 5100-based desktop computer IBM 5120, It was developed in only 90 days by a small team led by Bill Sydnes and released before the DataMaster - a true feat that convinced Lowe it was possible to have a successful fast-track project even inside IBM.

It was during the development of the DataMaster that IBM first contacted Microsoft to ask about its BASIC interpreter. The man who initiated the contact was the project’s software lead - Jack Sams. Sams had been with IBM for over two decades at that time; he was a member of the team that produced the IBM System/360. He was also disillusioned with IBM software development practices and proposed purchasing Microsoft BASIC for the DataMaster.

Instead, IBM higher-ups decided to make DataMaster BASIC compatible with IBM System/34 BASIC and that caused the delay of over a year. Sams decided to avoid making the same mistake again if at all possible.

Project Chess

The next opportunity came in early July 1980. IBM CEO Frank Cary summoned Lowe to a meeting of the Corporate Management Committee (CMC) in Armonk NY and asked why IBM could not produce something like Apple II. Lowe replied that it was not possible to develop a successful personal computer within the framework of IBM development processes. He suggested to either license an existing computer such as the Atari 800 or form an Independent Business Unit (IBU) within IBM and let it develop a personal computer in just one year but outside of IBM’s normal structure. Cary immediately rejected the idea of licensing Atari and asked Lowe to form a small task force and come back in a month with an official proposal for a “fast‑track” personal‑computer project.

The task force (internally known as “dirty dozen”) that Lowe assembled right after the July 4th weekend consisted largely of people from the DataMaster project, including Sydnes and Sams. They were determined to not repeat the mistakes which slowed down their previous assignment and decided to quickly develop an early prototype from off-the-shelf components. That prototype would then be given to the third-party software companies who would work on the software in parallel with the Boca Ratton group finishing the hardware.

While Sydnes was busy building the hardware proof of concept, Sams was collecting information about the possible software vendors. He knew the priority was software that would ship in the computer’s ROM - the BASIC interpreter. He also knew where to look for it. What he did not know was what kind of company Microsoft really was; he was wary of dealing with an unreliable group of West Coast hippies operating from a bedroom. There was only one way to find out: on Monday, July 21st, 1980, he called Bill Gates and asked to meet the next day.

The Initial Meeting - “Most likely, nothing will happen”

Gates had a meeting with Atari CEO Ray Kassar scheduled for July 22, but he did not want to miss the chance to talk to IBM, so he rescheduled it. He even dressed in a suit (unusual for him) and invited his old friend and new business associate, Steve Ballmer.

Jack Sams arrived accompanied by Pat Harrington who was in charge of contract administration in the Boca Raton office. After signing nondisclosure agreements, the meeting started. Sams could reveal only that IBM was considering a secret project that, if approved, would need to be completed under a very tight deadline. He made sure to set expectations low: most likely, nothing would come of it, as was often the case with IBM initiatives.

Gates spoke passionately about the microcomputer industry, the shift to 16‑bit processors, and Microsoft’s vision of the future. Sams listened attentively. Gates later came to believe that it was his arguments that influenced IBM to choose Intel 8088 for the PC. In fact, the decision had already been made; Sams simply did not want to reveal it.

On the surface, nothing substantial was decided during that first meeting. Gates later described it as “IBM asking lots of crazy questions”. But that was not the point. Sams was impressed both with Gates personally and with Microsoft as a company. Instead of the tiny, informal operation he had expected, he found a firm of roughly forty employees, with proper offices and a list of happy customers.

After returning to Boca Raton, Sams reported to Lowe that he felt comfortable putting the fate of the project in the hands of the small Bellevue, WA based software company.

The Second Meeting - “By the way, what about CP/M?”

Bill Lowe returned to Armonk on August 6th and presented his plan to the CMC. The committee gave him the approval to form an Independent Business Unit and proceed with the project which was code named “Chess”.

Soon after, Jack Sams called Bill Gates and scheduled a meeting for August 21st. This time the NDA was even thicker and scarier, but Gates again signed it without hesitation. Each side brought four people, including lawyers.

Sams could finally present IBM’s plan: a personal computer built around the Intel 8088, assembled from off‑the‑shelf components, and delivered within a year. He offered Microsoft the opportunity to supply not only the BASIC interpreter, but also all the other products they were selling at the time: compilers for FORTRAN, COBOL, Pascal and BASIC, plus a typing tutor and even a game.

Microsoft had started porting its software to Intel’s 16-bit platforms a few years earlier; now the bet was about to pay off. The company was ready to fully commit to Project Chess and help the Boca Raton team meet its deadline.

There was just one more thing to discuss: The IBM PC was supposed to support floppy disk drives, and for that it needed a disk operating system. Sams hoped Microsoft could sublicense Digital Research’s CP/M, the most popular OS of the time. Microsoft had recently introduced the SoftCard, which transformed an Apple II into a CP/M machine. But it turned out Microsoft could not sublicense CP/M for both legal and technical reasons. The port of CP/M to Intel 8086 was still in progress. However, Gates was happy to personally call Digital Research and help the IBM team arrange a meeting.

That meeting did not go well. But that’s a different story…

Conclusion

The main reason IBM came to Microsoft for a BASIC interpreter, and eventually the operating system, was the brutal deadline for delivering the new personal computer. IBM was obviously capable of developing system software, but not on such a schedule. Instead, they decided to use outside suppliers for the software, just as they did for the hardware, and once they came to that decision, Microsoft was realistically their only option, at least when it comes to BASIC.

Publicly, IBM offered another explanation. It was plausible, but not the primary driver:

Let’s take BASIC as an example. IBM has an excellent BASIC— it’s well received, runs fast on mainframe computers, and it’s a lot more functional than microcomputer BASICs were in 1980. But the number of users was infinitesimal compared to the number of Microsoft BASIC users. Microsoft BASIC had hundreds of thousands of users around the world. How are you going to argue with that?

IBM’s Philip D. Estridge

Another theory commonly mentioned is the alleged friendship between IBM’s president John Opel and Bill Gates’ mother Mary Gates who both served on the board of United Way. Obviously, we don’t know whether Mr. Opel ever discussed IBM’s plans for the ultra-secret personal computer project with Mrs. Gates. What we do know is that IBM wanted all software and almost all hardware developed by third-party suppliers. For a BASIC interpreter, Microsoft was simply the only game in town at the time.

To validate a UTF-8 string we have to perform the following three kinds of checks:

• The byte sequence is well-formed.

• Decoding results in a valid Unicode code point

• The code point is encoded in the minimal number of bytes (no overlong encoding).

Let’s look at them in some detail.

Validity of Bytes in the Sequence

As we have seen in the Part I, a valid UTF-8 encoding of a Unicode code point consists of a leading byte followed by a number of continuation bytes.

We start the check for validity of a byte sequence by looking at the lead byte. A valid lead byte has to start with one of the following bit fields:

• 0, in which case the lead byte alone encodes a code point.

• 110, which starts a two-byte sequence.

• 1110, which starts a three-byte sequence

• 11110, which starts a four-byte sequence.

Lead bytes that start with any other bit combination are invalid.

Once we establish the validity of the lead byte and compute the expected sequence length1, we can perform the next important check: ensure the expected number of valid continuation bytes. A valid continuation byte starts with bits 10 and therefore falls in the range 0x80-0xBF.

Depending on the value of the lead byte, we expect between 0 and 3 continuation bytes to follow. If there are fewer, it means we have an incomplete sequence; if there are more, we have detected unexpected continuation bytes.

Validity of Decoded Code Points

Some well-formed UTF-8 sequences are decoded into invalid Unicode code points:

• Values greater than U+10FFFF.

• UTF-16 surrogates.

Unicode 2.0 and later support code points in the range U+0000-U+10FFFF. A well-formed UTF-8 sequence can be used to encode values that fall outside the range and therefore must be detected and reported as invalid.

Code points in the range U+D800-U+DFFF are reserved for use by UTF-16 encoding scheme as surrogate pairs. They cannot be used as standalone code points, and any UTF-8 sequence that is decoded to that range is invalid.

An interesting category to consider is noncharacters. These code points are reserved for internal use but can be interchanged and do not cause ill-formed Unicode texts. Some validators still reject them: the current version of Markus Kuhn's UTF-8 decoder capability and stress test calls them “a potential security risk, depending on what use is made of these codes subsequently”. Yet, as they are explicitly called out as valid code points by the Unicode standard, we are not going to reject them.

Overlong Sequences

If a Unicode code point is encoded with more bytes than necessary, we have an overlong encoding. For instance, the code point value for ‘A’ (U+0041) could be encoded as:

• 0x41 (0[1000001])

• 0xC1 0x81 (110[00001] 10[000001])

• 0xE0 0x81 0x81 (1110[0000] 10[000001] 10[000001])

Only the one-byte version is legal - the other two are overlong sequences, constructed by padding zeroes and must be rejected by a validator.

An obvious way to check for an overlong sequence is to complete the decoding and then check that the decoded value corresponds to an expected sequence length. That’s what we would do in a validating decoder.

If we are interested in validating without decoding, the task is easier. Overlong sequences can happen in the following three cases:

• if a two-byte sequence starts with 0xC0 or 0xC1 it is overlong.

• if a three-byte sequence starts with 0xE0 and the first continuation byte is in range [0x80, 0x9F]

• if a four-byte sequence starts with 0xF0 and the first continuation byte is in range [0x80, 0x9F].

Algorithm for Validating UTF-8 Sequences

Validating UTF-8 can be performed as a part of decoding, or as a separate process. Here we examine a straightforward approach to validating without fully decoding. The algorithm:

• Lead starts with bit 0; valid sequence.

• Lead starts with bits 110: two-byte sequence

  • 0xC0 or 0xC1: overlong two-byte sequence; invalid sequence.

  • No continuation bytes: incomplete sequence; invalid sequence.

  • One continuation byte; valid sequence.

• Lead starts with 1110: three-byte sequence

  • If 0xE0

    • First continuation byte in range [0x80, 0x9F]: overlong three-byte sequence; invalid sequence.

  • If 0xED

    • First continuation byte in range [0xA0, 0xBF]: UTF-16 surrogate: invalid sequence.

  • Less than two continuation bytes: incomplete sequence; invalid sequence.

  • Two continuation bytes: valid sequence.

• Lead starts with 11110: four-byte sequence

  • If 0xF0

    • First continuation byte in range [0x80, 0x9F]: overlong four-byte sequence; invalid sequence.

  • If in range [0xF5, 0xF7] code points above U+10FFFF; invalid sequence.

  • Less than three continuation bytes: incomplete sequence; invalid sequence.

• Lead starts with invalid prefix: invalid sequence.

Code example

A C function that would implement the algorithm above could look like:

/* Returns 0 if invalid, or sequence length if valid */
int validate_utf8_sequence(const char *str)
{
    const unsigned char *s = (const unsigned char *)str;
    unsigned char c0 = s[0];

    /* Empty string: no code point */
    if (c0 == '\0')
        return 0;

    /* ASCII */
    if ((c0 & 0x80) == 0)
        return 1;

    /* Two‑byte: 110xxxxx */
    if ((c0 & 0xE0) == 0xC0) {
        if (s[1] == '\0')
            return 0; /* truncated */

        unsigned char c1 = s[1];

        if (c0 == 0xC0 || c0 == 0xC1)
            return 0; /* overlong */

        if ((c1 & 0xC0) != 0x80)
            return 0;

        return 2;
    }

    /* Three‑byte: 1110xxxx */
    if ((c0 & 0xF0) == 0xE0) {
        if (s[1] == '\0' || s[2] == '\0')
            return 0; /* truncated */

        unsigned char c1 = s[1];
        unsigned char c2 = s[2];

        if ((c1 & 0xC0) != 0x80)
            return 0;

        if (c0 == 0xE0) {
            if (c1 < 0xA0)
                return 0; /* overlong */
        } else if (c0 == 0xED) {
            if (c1 >= 0xA0)
                return 0; /* surrogate */
        }

        if ((c2 & 0xC0) != 0x80)
            return 0;

        return 3;
    }

    /* Four‑byte: 11110xxx */
    if ((c0 & 0xF8) == 0xF0) {
        if (s[1] == '\0' || s[2] == '\0' || s[3] == '\0')
            return 0; /* truncated */

        unsigned char c1 = s[1];
        unsigned char c2 = s[2];
        unsigned char c3 = s[3];

        if (c0 == 0xF0) {
            if (c1 < 0x90)
                return 0; /* overlong */
        } else if (c0 == 0xF4) {
            if (c1 > 0x8F)
                return 0; /* > U+10FFFF */
        } else if (c0 >= 0xF5) {
            return 0; /* invalid lead */
        }

        if ((c1 & 0xC0) != 0x80)
            return 0;
        if ((c2 & 0xC0) != 0x80)
            return 0;
        if ((c3 & 0xC0) != 0x80)
            return 0;

        return 4;
    }
    /* Invalid lead byte */
    return 0;
}

Inspecting assembly of the function does not show anything interesting. Lots of branches, but as we have seen, modern CPUs handle branches surprisingly well.

In the next post of the series, we’ll look at a validating decoder.

In fact, there was an unwritten agreement between Gates and Kildall that Microsoft would stay out of the operating system end of the business, and Kildall would not get into microcomputer languages, according to industry sources.

Hard Drive: Bill Gates and the Making of the Microsoft Empire

In 1980, the microcomputer software industry was tiny compared to today’s $824 billion global software market size - it was almost certainly under $100 million1. When it comes to application software, VisiCorp’s Visicalc led the new spreadsheet market and MicroPro’s WordStar was the most popular word-processing program. On the systems software side, the market was split between Microsoft and Digital Research Inc (DRI): the former focused on programming languages, and the latter on operating systems, including CP/M which became the standard for 8-bit business computers.

For a while, or at least until Microsoft released MS-DOS, there was a belief that the leaders of the two companies, Bill Gates and Gary Kildall, had agreed not to compete with each other. It was hearsay and nobody was actually able to point to a source for the claim - people were just passing rumors around:

David Kaplan, the author of the engaging Silicon Boys, says there seemed to be a gentleman’s agreement that neither would get involved in the other’s business. “DRI would stay away from languages, and Microsoft would leave operating systems alone.”

They Made America: From the Steam Engine to the Search Engine: Two Centuries of Innovators - Harold Evans, Gail Buckland, David Lefer

Was there anything more than gossip behind the agreement between Kildall and Gates?

Synergism and Talks about Merger

The entire concept of dividing the system software market into programming languages and operating systems sounds odd nowadays. In the early era of personal computers, disk drives were rare, and many machines booted straight into a BASIC interpreter stored in ROM. The language functioned somewhat like a command line shell in modern operating systems: it was the user interface through which most users interacted with the machine. Early computer culture even assumed that most users would learn at least some programming. In that sense, Microsoft BASIC was system software, if not a full-fledged operating system. It became even closer to that role when disk support was added - originally by Bill Gates himself, and later by Marc McDonald who developed a real file system, called FAT that was bundled with BASIC. As time went by, Microsoft also developed compilers for FORTRAN, COBOL and even announced APL, though it was never actually released.

On the other hand, as disk drives became more common, there was a need for a traditional operating system stored on a disk and loaded into RAM where it would provide system calls to applications. Several appeared very early on, including Intel’s ISIS, iCOMs FDOS and NorthStar DOS, but by late 1977 it became clear the winner was DRI’s CP/M: inexpensive, easily portable and very light on resources. Initially developed in 1973/742, before any commercial microcomputers even existed, CP/M was in the beginning used as a teaching tool at Naval Postgraduate School where Kildall taught. First commercial licenses were issued in 1975, and after the deal with IMSAI in 1976, CP/M became the de-facto standard for Intel 8080 based business computers. By 1979, Kildall felt it was time to move on to more capable systems that would support multitasking and networking, and DRI developed MP/M and CP/NET.

Both Microsoft and DRI recognized that their businesses complemented each other, and the word “synergy” started popping up on both sides:

At this time, I was quite friendly with Bill, and we always talked of the “synergism” of our two businesses.

Gary Kildall

It made our lives a lot easier if someone would just go license CP/M and get that up on their machines and then our stuff would pretty much run as is. And Gary would do likewise. If someone went to him to license CP/M and they were looking for languages, he would refer people to Microsoft. It was a very synergistic kind of thing.

Steve Wood, Microsoft’s early employee

At some point, there was even discussion of a merger between the two companies. According to Kildall3, “one day in 1977” Gates paid him a visit while traveling from Albuquerque to Seattle. The two pioneers of the microcomputer software industry bonded over a home-cooked dinner and complained about their numerous speeding tickets. After the meal, they discussed the possibility of combining their businesses. At that time, Microsoft’s contract with the original microcomputer maker MITS had dissolved and its founders were looking to leave Albuquerque. Gates preferred a move to California and a merger with DRI seemed like a plausible idea; Allen insisted on moving back to Seattle, which is what eventually happened.

It was a tantalizing “what-if” moment:

The combination of Kildall and Gates could have been a killer-deal in those days. I had the operating systems for the decade to come, and he had the opportunistic approach to garner business. But, our attitudes differed entirely, and that could also have been a disaster. I think we both realized this and simply let the “deal” die.

Gary Kildall

But all this talk of “synergy” did not mean there was a deal to stay out of each other’s business. Indeed, if we look at the early history of the two companies, there is plenty of evidence that both were interested in expanding on the other side of the fence.

Microsoft and Operating Systems

Even if we disregard the fact that Microsoft’s Standalone BASIC was almost an operating system, it is clear Microsoft considered building a “real” operating system from the very beginning:

Early on in New Mexico we talked about developing an operating system. We asked ourselves if we should really be referring all this business to Gary. We always came back with the same answer: We have all this other stuff to do.

Steve Wood

In 1979, Marc McDonald developed software that was without any doubt an operating system: it was called M-DOS or MIDAS4. M-DOS was based on the same FAT filesystem that was shipped with BASIC; it supported multitasking, but not multiple users and, like CP/M, was influenced by the TOPS-10 operating system that ran on DEC’s PDP-10 mainframes - Microsoft’s primary development environment in the 1970s. Before M-DOS was completed, though, Microsoft leaders decided to shelve it5.

In the meantime, in 1978, Intel released the first 16-bit microprocessor: the 8086. Microsoft was one of the few companies ready to bet on the new technology: they hired Jim Lane to write an 8086 simulator for the PDP‑10 and as soon as it was finished Bob O’Rear started porting the Standalone BASIC to 8086. The product was ready by early 1980 - just in time for one of the first 8086 based systems: Seattle Computer Product’s S-100 8086 board.

BASIC was, of course, the priority, but Gates saw the impending shift to 16-bits as a chance to gain a foothold in the operating systems market. In the late 1970s, UNIX was becoming popular at universities, which received not only binaries, but also source code from AT&T that at the time was prohibited from selling it commercially.

Gates and Allen decided to bet that UNIX would become the standard for 16-bit microprocessors. In February 1980 Microsoft licensed UNIX source code from Western Electric (the manufacturing arm of AT&T), and on August 25, 1980, announced its own product based on it: XENIX. The new operating system was first released for the DEC PDP-11 minicomputer - the model UNIX was developed on; later it was ported to 16-bit microcomputers.

One might expect that Microsoft licensing UNIX would have seemed like a serious threat to DRI. Gary Kildall did not see it that way:

UNIX was not in the marketplace we were into. It was mostly for scientific workstations, as it is now. It was never a threat to us in our business markets.

Gary Kildall

He was right. XENIX achieved some success during the 1980s, but it never came close to becoming the standard for 16-bit personal computers6. It was not a good fit for the 8088 CPU and required more memory than the personal computer models of the early 1980s could usually provide7.

But spending $2 million on a license for UNIX source code clearly showed that Microsoft was serious about the operating systems. There was no “agreement”, written or unwritten, that would keep them out of that market; they just picked the wrong product at first.

Digital Research and Programming Languages

Gary Kildall is mostly remembered as the author of the CP/M operating system. However, he was above all a programming language expert:

• In his PhD thesis A unified approach to global program optimization, he proposed a technique for global program‑structure analysis that allowed more effective optimization of generated object code.

• He designed and implemented PL/M - the first programming language aimed specifically at microcomputers.

• He implemented the first PL/I-G compiler for microcomputers, PL/I-80.

• He designed and implemented XLT86 8080 to 8086 Assembly Language Translator8

• He developed DR Logo - a Logo interpreter for personal computers.

There was never any chance Gary Kildall would abandon his work on languages. In fact, CP/M itself was created as a side effect of his PL/M work - only because he wanted to run the PL/M compiler on an Intellec-8 microcomputer development system rather than cross-compiling it on a PDP-10 mainframe.

That said, before 1980 Digital Research was not producing programming languages. PL/M was sold to Intel for $20k in 1974 and PL/I-80 was released only in late 1980. The compiler that apparently upset Gates the most was originally not even a DRI product - it was CBASIC, developed and sold by a former student of Gary Kildall - Gordon Eubanks. It seems that DRI started promoting CBASIC sometime in 19799, but did not acquire it until 1981.

Aftermath

Once IBM decided to license MS-DOS for its IBM PC computer, any semblance of the “synergy” between the two companies disappeared: they became fierce competitors.

Microsoft won decisively, and by 1985 DRI was on the brink of bankruptcy. The board authorized Gary Kildall to find a buyer for the company, and he went to Bill Gates, asking $26 million. Gates did not think the company was worth more than $10 million, and the second attempt to combine the two companies failed. Kildall hired a new CEO, IBM veteran Dick Williams, who managed to keep the company afloat and eventually sell it to Novell in 1991 for $120 million.

Gary Kildall died three years later at the age of fifty-two. His old friend and business rival had this to say about him:

Gary Kildall was one of the original pioneers of the PC revolution. He was a very creative computer scientist who did excellent work. Although we were competitors, I always had tremendous respect for his contributions to the PC industry. His untimely death was very unfortunate, and he and his work will be missed.

Bill Gates, Computer Chronicles - Gary Kildall Special

In the end, the supposed “gentleman’s agreement” between Kildall and Gates was really just an acknowledgment of the situation as it existed at the time. The two men respected each other’s work, and for a while their businesses were complementary. Neither believed that arrangement was permanent, and both were ready to cross the boundary when the opportunity presented itself.

A little history first (shocking, I know). Arm32 had the following instructions for moving bitfields: BFI, BFC, UBFX, and SBFX. Unlike their Arm64 namesakes, they are instructions on their own and not aliases of other instructions. The 64-bit Arm introduces three separate, but related instructions: BFM, UBFM and SBFM. There are a number of aliases that are easier to use and are implemented in terms of the three basic instructions.

If I really knew anything about chip design, I would probably speculate that all three core bitfield move instructions share most of the common implementation, but as a software person, I’ll leave the implementation details to the knowledgeable folks.

To keep the post relatively short, I’ll focus on the BFM instruction. Once we understand how it works, the rest of them will be easy enough to understand from the documentation.

BFM - Bitfield Move

The BFM instruction copies a bitfield (a collection of adjacent bits within a machine word) from the source register to a position in the destination register without changing any other bits.

According to the official documentation:

Bitfield Move copies any number of low-order bits from a source register into the same number of adjacent bits at any position in the destination register, leaving other bits unchanged.

BFM Rd, Rn, #immr, #imms

Where:

• Rd is the destination register (Xd for the 64-bit operation, Wd for the 32-bit variant).

• Rn is the source register (Xn for the 64-bit operation, Wn for the 32-bit variant).

• immr is the right rotate amount.

• imms is the leftmost bit number to be moved from the source.

The operation is described as a sequence of a rotation, masking and insertion, but I find the following explanation easier to understand:

Depending on the values of the immr and imms, the instruction does one of the two things:

• if immr <= imms, copies a bitfield [immr : imms] of the source register to the least significant bits of the destination register: [0 : imms - immr]

• if immr > imms, copies a bitfield [0 : imms] of the source register to [regsize − immr : (regsize − immr) + imms] of the destination register.

where regsize is the destination register size of 32 or 64 bits.

Let’s look at examples of these two cases2:

immr is less than or equal to imms

// ------------------------------------------------------------
// Load W0 = 0x55667788
// Binary: 0101 0101 0110 0110 0111 0111 1000 1000
// ------------------------------------------------------------
movz    w0, #0x7788
movk    w0, #0x5566, lsl #16

// Load W1 = 0xEEFF0011
// Binary: 1110 1110 1111 1111 0000 0000 0001 0001
movz    w1, #0x0011
movk    w1, #0xEEFF, lsl #16

// ------------------------------------------------------------
// Copy bits [8:23] of W1 into low bits of W0
// Bits 8:23 of W1 are: 1111 1111 0000 0000 (FF0)
// Expected result: 0101 0101 0110 0110 1111 1111 0000 0000
// ------------------------------------------------------------
bfm     w0, w1, #8, #23

// Result: w0 = 0x5566FF00

Here, immr=8, imms=23. Since imms-immr=15 we:

1. Take bits [8:23] of W1: 1110 1110 [1111 1111 0000 0000] 0001 0001

2. Copy them into [0:15] bits of W0: 0101 0101 0110 0110 [1111 1111 0000 0000]

The actual machine code generated for the BFM instruction in the example was:

sf |    opc   | N |  immr  |  imms  |  Wn   |  Wd
0  | 01100110 | 0 | 001000 | 010111 | 00001 | 00000

immr is greater than imms

Sample:

// ------------------------------------------------------------
// Load W0 = 0x55667788
// Binary: 0101 0101 0110 0110 0111 0111 1000 1000
// ------------------------------------------------------------
movz    w0, #0x7788
movk    w0, #0x5566, lsl #16

// Load W1 = 0xEEFF0011
// Binary: 1110 1110 1111 1111 0000 0000 0001 0001
movz    w1, #0x0011
movk    w1, #0xEEFF, lsl #16

// ------------------------------------------------------------
// Copy bits [0:7] of W1 to [12:19] bits of W0
// Bits 0:7 of W1 are: 0001 0001 (11)
// Expected result: 0101 0101 0110 0001 0001 0111 1000 1000
// ------------------------------------------------------------
bfm     w0, w1, #20, #7
// Result: w0 = 0x55611788

Here, immr=20, imms=7, regsize=32, regsize−immr=12,(regsize−immr)+imms=19 so we:

1. Take bits [0:7] of W1: 1110 1110 1111 1111 0000 0000 [0001 0001]

2. Copy them into [12:19] bits of W0: 0101 0101 0110 [0001 0001] 0111 1000 1000

BFM Aliases

The following instructions are aliases of BFM:

• BFC - Bitfield Clear. Clears a selected bitfield in the destination register.

• BFI - Bitfield Insert. Inserts the low bits of the source register into a bitfield of the destination register.

• BFXIL - Bitfield Extract and Insert Low. Extracts a bitfield from the source register and writes it into the low bits of the destination register.

UBFM - Unsigned Bitfield Move

As we have seen, BFM copies a bitfield to the destination register, but leaves the other bits unchanged. UBFM works exactly the same as BFM, but destination bits outside the bitfield are set to zero.

UBFM Aliases

Judging by the number of aliases, UBFM is the most popular bitfield move instruction:

• LSL (immediate) - Logical Shift Left (immediate). Shifts the source value left by an immediate amount and fills the new low bits with zeros.

• LSR (immediate) - Logical Shift Right (immediate). Shifts the source value right by an immediate amount and fills the new high bits with zeros.

• UBFIZ - Unsigned Bitfield Insert in Zeros. Extracts a bitfield from the low bits of the source register and inserts it into the destination at a specified position, with all other bits set to zero.

• UBFX - Unsigned Bitfield Extract. Extracts a bitfield from the source register, puts it in the low bits of the destination register, and zero‑extends the result.

• UXTB - Unsigned Extend Byte. Zero‑extends the low 8 bits of the source register and writes the result to the destination register.

• UXTH - Unsigned Extend Halfword. Zero‑extends the low 16 bits of the source register and writes the result to the destination register.

SBFM - Signed Bitfield Move

Unsurprisingly, SBFM works almost exactly the same as the other two bitfield move instructions. The difference is that it sets the destination bits below the bitfield to zero and the bits above the bitfield to the value of the most significant bit of the bitfield.

SBFM Aliases

• ASR (immediate) Arithmetic Shift Right (immediate). Shifts the source value right by an immediate amount and fills the high bits with the sign bit (sign-extends it).

• SBFIZ Signed Bitfield Insert in Zeros. Extracts a bitfield from the low bits of the source register, inserts it into the destination, clears the bits below it, and sign‑extends above it.

• SBFX Signed Bitfield Extract. Extracts a bitfield from the source register, places it in the low bits of the destination register, and sign‑extends the result.

• SXTB Signed Extend Byte. Extracts an 8-bit value from a register, sign-extends it, and writes the result to the destination register.

• SXTH Sign Extend Halfword extracts a 16-bit value, sign-extends it, and writes the result to the destination register.

• SXTW Sign Extend Word sign-extends a word and writes the result to the destination register.

I still think there is one piece of the puzzle that has received little attention: how much of the CP/M design beyond the API was adopted by MS-DOS? In this article, we will look at the design side of the controversy. As you will see, the most frustrating part was determining which design aspects were actually being disputed, despite years of vague accusations about copying “the internals”.

Readers of my earlier posts know I admire both Dr. Gary Kildall, the author of CP/M, and Tim Paterson, the author of 86‑DOS. It is unfortunate that two great programmers ended up on opposite sides of this argument, and I hope this post is a small step toward closing it for good.

Accusations

Gary Kildall was never very specific when he claimed that MS‑DOS borrowed CP/M’s internal design. For example, in his 1982 interview with PC Magazine he said:

Basically, you know the history of PC-DOS—where it came from, and so forth. It's one of the variety of operating systems we call CP/M lookalikes. It arrived on the scene between CP/M version 1.4 and CP/M 2.2, so it has characteristics of CP/M 1.4 and extensions toward the CP/M 2.2-style file system1, but with differences because they were kind of simultaneous in design. There are subtle differences but PC-DOS is fundamentally the same as the 8-bit version of CP/M as far as the user is concerned, and also as far as the program interface. Most of the interface differences between PC-DOS and CP/M are misunderstandings of the CP/M calls by the person who wrote the original PC-DOS implementation, simple things like returning FF rather than 1, things that are of no consequence but just weren’t done specifically the same.

This is mostly a complaint about PC-DOS appropriating CP/M’s interface and behavior. The only possible reference to the internal design is his mention of the file system, which I cannot explain, as 86-DOS/MS-DOS/PC-DOS used the FAT file system, which is very different from the CP/M’s.

Toward the end of his life, Kildall wrote a memoir: Computer Connections: People, Places, and Events in the Evolution of the Personal Computer Industry in which he was apparently much less diplomatic. Only the first part of the manuscript is publicly available2, and that portion contains nothing relevant to this investigation.

However, the book They Made America: From the Steam Engine to the Search Engine: Two Centuries of Innovators contains a chapter on Gary Kildall. The author Sir Harold Evans had access to the full memoir and interviewed some of the people close to Kildall. His coverage of the MS-DOS controversy can be described, to put it mildly, one-sided but still contains several quotes from the unpublished part of the memoir that matter for our purposes.

Most of these reiterate the API argument:

The first twenty-six function calls of the API in Gates’s PC-DOS are identical to and taken directly from the CP/M proprietary documents [CP/M manuals].”

…

If you think Bill Gates invented those function calls, ask him why print string (function 9) ends with a dollar sign. He will not know.”

There is one place where Kildall actually uses the word “design”:

Paterson’s Seattle DOS was yet another one of the rip-offs of the CP/M design. The CP/M machine code was taken apart, using CP/M’s own DDT [its debugger], to determine the internal workings of CP/M in order to make a clone of CP/M’s operation.

Here Kildall speculates that Paterson reverse-engineered CP/M using the DDT debugger to “determine the internal workings of CP/M". I wish he had been more specific, but it is clear he meant something other than the published system API.

To find some more concrete and still credible accusations, we will turn to one of Digital Research’s early leaders: Tom Rolander3. In 2007, Rolander spoke to Robert Scoble in the podcast episode The rest of the story: How Bill Gates beat Gary Kildall in OS war, Part 1. Among many topics, he offered some concrete claims about MS-DOS appropriating CP/M design. Let’s start with the most direct one:

Whether Tim Paterson ever looked at a line of code or copied the code is not the issue to me. What he really did is he took it as an architecture. In fact, Gary, if anything, the supreme accomplishment he made was to make it easy to be copied, because Gary used this INT 21 (sic), this interface from an application program through to the operating system that made it transparent. It basically made it so that you couldn't see the actual organization of the data on the disk itself physically. So whether it was a CP/M file system or whether it was a FAT file system, the application program at one level couldn't see that at all, because it just used the int to open a file, read and write a file, and so forth.

At first glance, this is yet another complaint about Paterson using the copyrighted API from Digital Research. But there is an internal architecture aspect of using a single entry for an API. From Evans’ book:

What Paterson essentially did was rewrite the bottom part of the software—improving the way files were stored and adapting the program to a 16-bit machine—while copying most of the top part of Kildall’s operating system interfacing mechanisms. Even if QDOS and CP/M were 80 percent different, as Paterson has insisted, he took almost unaltered Kildall’s interrupt mechanism—the key innovation.

The “interrupt mechanism” refers to the jump instruction into the BDOS dispatch table that made CP/M adaptable to computers with various amounts of memory.

There is another controversial aspect of the “architecture” we should not forget. In the same podcast, Tom Rolander said:

I think if there's anything that I really think Gary should be remembered for, is being creator, the originator of that layering of the software, so that you were able to take the application program and run it on any piece of hardware. I mean, we all take it for granted right now. At the time that Gary wrote CP/M, people that had little accounting packages or whatever, whether it was the mini-computers or certainly the mainframes at the time, you would have a box of your software that was to run on a Data General Eclipse. You had another box of the software to run on a DEC PDP-11, but the point was that every single application program was specific to a piece of hardware, a hardware vendor, and Gary removed that layer.

Here Rolander is clearly talking about the component layout of the CP/M, specifically the division of the “kernel” into the hardware-independent BDOS and hardware-specific BIOS. This separation allowed manufacturers to easily adapt CP/M to their hardware, as long as it was based on a supported CPU.

Both of these design elements are about internal workings of CP/M. We will discuss them in some depth after we look at Tim Paterson’s side of the story.

Paterson’s Responses

Tim Paterson defended his work on multiple occasions. Two of his texts that we are going to quote here are The Origins of DOS published in 1994 in response to accusations raised by John Wharton, and his 2007 blog entry Is DOS a Rip-Off of CP/M?

Let’s start with the blog post. In it, Paterson openly acknowledges that he intentionally implemented the CP/M API:

What may be most surprising about the issue is that there is no significant dispute on the actual relationship between DOS and CP/M. The relationship is simply this: DOS implements the same Application Program Interface (API) as CP/M. The API is how an application program (such as a word processor) asks the operating system to perform a task, such as to read or write a disk file.

Then he reiterates that no CP/M code was copied:

There is no suggestion that I copied any CP/M code when I wrote DOS. (To this day, I have never seen any CP/M code.) And the internal workings of DOS are quite different. For example, unlike CP/M, DOS used the FAT (File Allocation Table) system for organizing disk files, which made it much faster but meant floppy disks were not interchangeable between CP/M and DOS.

I have little to add here. There are no credible claims that Paterson actually copied any CP/M code or directly translated it. There were two $100K rewards for anyone who would prove the existence of copied code, and they remain uncollected. Nowadays, when the source code for both operating systems is available, this issue can safely be considered settled4.

Paterson also addresses the part most relevant to our investigation:

One point of disagreement: In his memoirs (quoted by Evans), Kildall claims that I dissected CP/M to learn how it worked. This is not true, and it doesn’t even make sense. Since DOS worked so differently, there would have been nothing I could learn from CP/M’s internal workings to help in writing DOS.

Based on the previous quote, it seems clear that by “internal workings” Paterson referred to the file systems of the two operating systems. They are indeed completely different and there was no reason for him to debug or disassemble CP/M to learn about them5. Then again, it is not obvious that Kildall wrote about the file systems when he accused Paterson of reverse-engineering CP/M “internals”.

Now, let’s turn to The Origins of DOS. Just as in the blog post, he acknowledges the API compatibility:

So 86-DOS generally had all the same application visible elements as CP/M—the function codes, the entry point address, part of the File Control Block layout, etc. I used the 1976 CP/M Interface Guide for my description of the requirements. I also provided some similar commands from the console—such as DIR, RENAME, ERASE—although any system would have such functions, regardless of name chosen.

The function codes were necessary for API compatibility. The entry point address (assuming he means the 0005h call) is related to the “interrupt design” we mentioned earlier - more on that shortly. File Control Blocks are part of the API, and Paterson openly acknowledged DOS took them (at least partially) from CP/M, so there is no purpose discussing them here. Console commands fall more under “look and feel” than software design.

In the same text, Paterson emphasizes that his file system (80% of the code) was completely different from CP/M’s and that he never used any CP/M source code or disassembly. Near the end of the article, he writes:

BIOS (for Basic Input/Output System) was the name given to CP/M’s hardware dependent layer so that the BDOS (Basic Disk Operating System) and all applications could be hardware independent.

…

I used the term I/O System (never abbreviated) to describe the hardware-dependent layer of 86 DOS, and Microsoft even keeps this layer in a separate file on the disk (IO.SYS) from the machine-independent code (MSDOS.SYS).

My interpretation is that Paterson implicitly acknowledges that his “I/O System” (later referred to as the “MS-DOS BIOS” in Microsoft documentation) was conceptually inspired by CP/M BIOS. He does not mention it in the paragraph where he lists the similarities between the two operating systems - perhaps because it is not an “application visible element”.

A Tale of Two Designs

Let’s have a closer look at the two design decisions that we identified as potentially controversial: the component layout (especially the BIOS) and the system call “interrupt” mechanism with a single-point entry.

Component Layout

Based on the CP/M 1.4 Interface Guide (which Paterson likely used as a reference) and a combination of the 86-DOS Programmer’s Manual and The MS-DOS Encyclopedia, the following diagram can be drawn to describe the major components of the operating systems:

In both cases:

• Applications, including command line shells, invoke a collection of system calls to talk to the operating system kernel.

• The hardware-independent part of the kernel contains the implementation of those system calls and the file system.

• The hardware-dependent part of the kernel isolates the hardware components, such as console, disk, serial I/O and printers from the rest of the system. This component is customized for a particular hardware configuration, but its interface to the rest of the kernel is fixed.

In very early versions of CP/M (before 1.3), the entire kernel was a single component. Kildall later split it into the hardware-independent part BDOS, written in PL/M until CP/M 2.0, and the hardware-specific BIOS, written in assembly for each computer model.

The division between BDOS and BIOS was one of the most important reasons for the popularity of CP/M. Kildall wrote:

I designed a general interface, which I called the BIOS (BASIC I/O System) that a good programmer could change on the spot for their hardware. This little BIOS arrangement was the secret to the success of CP/M.

In his blog post The Contributions of CP/M, Tim Paterson sounds a little dismissive of the novelty of the idea:

Certainly the idea of these layers of interfaces was not new to the computer industry. For example, UNIX (like all operating systems) provided an API for application programs, and connected to the hardware with an interface to low-level device driver software. These are equivalent layers to the CP/M’s BDOS and BIOS, but much more sophisticated. So I am a bit mystified as to what is so revolutionary about CP/M’s design.

I cannot agree with Paterson here: UNIX (at least the early versions that appeared around the same time or before CP/M) did include low‑level hardware‑interfacing code, but it was compiled directly into the kernel and did not expose a standardized interface. Adding new hardware required modifying the kernel source and recompiling it. Adapting CP/M to new hardware did not require any changes to either BDOS or CCP - only the BIOS had to be re-written and recompiled6.

Paterson’s argument about non-originality of BIOS would have been more convincing if he had compared it to the RT-11 operating system, which was obviously an inspiration for CP/M. Like CP/M, RT-11 separated the hardware-dependent parts into modules called device handlers. However, BIOS is not the same as RT-11 device handlers: it is a monolithic module that contains a static jump table with 16 entries that are directly called by BDOS. Device handlers were more similar to modern device drivers - they were device-specific, reloadable and relocatable. BIOS is intentionally simpler than the device handlers - it was designed for more primitive hardware and less memory.

86-DOS was initially developed for the SCP S-100 8086 board which could more accurately be described as a collection of S-100 plug in cards than an integrated computer. It is pretty clear how the operating system would benefit from clean separation of hardware-interfacing code. Therefore, the “I/O Section” - more or less the same thing as CP/M BIOS - was adapted. Their APIs are not identical but are very similar and the process of adapting 86-DOS to new hardware was not that different from CP/M’s.

In this respect, 86-DOS did adopt the CP/M internal design, and this decision was not driven by API compatibility.

System Calls Dispatch Mechanism

Now we will look at the “interrupt mechanism” that Paterson allegedly copied “almost unaltered”.

Advanced operating systems, including UNIX and nowadays Linux and Windows, run the kernel in a high-privilege mode. User‑mode code invokes system calls via a trap instruction, which raises a software exception and transfers control to a kernel handler. The term “interrupt” is usually associated with exceptions caused by hardware but sometimes is used for both hardware and software exceptions.

For example, UNIX on the DEC PDP-11 computer used the EMT (emulator trap) instruction to invoke system calls from user mode. That instruction caused a kernel-mode handler to run and execute a system call based on the current state of the CPU registers.

CP/M ran on the 8-bit Intel 8080 CPU which had neither privilege levels nor a trap instruction. The obvious way to implement system calls in such environment would have been to place the system routines at fixed memory addresses and call them directly from the application code. That’s for instance, how Apple DOS was implemented.

The problem was - CP/M had to run on systems with varying amounts on RAM and therefore be relocatable while still providing a fixed entry point for system calls, so that application software would not need to be recompiled for each hardware configuration.

To achieve this, Kildall introduced a “trap-like” mechanism. Instead of a software exception which did not exist on Intel 8080, he placed a fixed entry point at address 0005h. CP/M at boot time put the following instruction there:

0005: JMP FBASE

FBASE value was set by the BIOS boot routines (BOOT and WBOOT, “cold” and “warm” boot respectively) to the memory address of the BDOS entry. This way the application code did not need to know the actual address or size of BDOS which could be different on different machines - it just called 0005h with the system call number in register C. Within BDOS there was a simple dispatch table that called the appropriate system call.

A diagram from CP/M 1.4 Interface Guide gives some insight into this mechanism:

Obviously, CP/M still required the memory space from 0000h to 0100h to be available for its “low storage area” which prevented some computer models from running the operating system unmodified7. But overall, the solution was effective.

I think we can all wholeheartedly agree with Rolander and Evans that this design was smart and innovative. But did Paterson actually take it “almost unaltered”?

The Intel 8086 still did not provide privilege levels, but it did introduce the INT instruction which causes a software interrupt, like the above mentioned EMT on PDP-11 computers. This made Kildall’s smart design unnecessary, and Tim Paterson took advantage of the instruction: the entry point to 86-DOS and all of its descendants is INT 21h8. There was no need to patch the jump target at address 0006h from BIOS.

There is still a “compatibility” CALL 5 mechanism that was not recommended for new code and indeed pretty much was never used in DOS programming. The implementation of that compatibility shim is very different than the original CP/M one and perhaps even too clever9.

Unsurprisingly, the INT 21h handler within DOS kernel contains a dispatch table that is equivalent to the BDOS one, but this is simply the straightforward way to implement a system‑call dispatcher; there is no indication Paterson reverse‑engineered CP/M’s table10.

In short, while there is some similarity in design, the claim that Patterson “took almost unaltered Kildall’s interrupt mechanism” is not accurate. The 8086 provided a built‑in facility for software interrupts, and Paterson used it.

Conclusion

Our little investigation shows that MS‑DOS did adopt CP/M’s BIOS‑style component layout, but not the internals of CP/M’s system‑call mechanism. The 8086 made Kildall’s CALL 5 indirection unnecessary, and Paterson used the processor’s built‑in interrupt instruction instead.

Not that it really matters. Software designs get reused all the time and borrowing them is far less controversial than copying source code. CP/M itself took a lot from DEC operating systems such as TOPS-10 and especially RT-11. Tracing where the design ideas originate is interesting, but it should not be used to stir up old disputes.

At this point, CP/M and MS-DOS are part of computing history, and we should be able to compare them and give credit to both of their authors.

Validation is important. Not every stream of bytes is valid UTF-8, and assuming it is, leads not only to bugs in functionality, but also security problems. A UTF-8 decoder needs to operate under assumption that the input stream may not be valid UTF-8 and ready to abort decoding gracefully and report an error when it detects invalid encoding.

That said, there are some scenarios in which it is OK to skip validation and save some CPU cycles:

• The input has already been validated. It is OK to do validation once and then non-validated decoding if the input bytes are immutable.

• The input is produced by a trusted source. If you are processing strings that you generate internally - i.e. string literals and various resource files that you know are valid UTF-8, it is OK to skip validation.

Here is a minimal C function that performs UTF‑8 decoding without any validation:

/* A sequence length function we covered in previous posts */
int utf8_sequence_length(unsigned char lead_byte);

/* Returns the code point and advances *p by the number of bytes consumed. */
unsigned int utf8_decode(const unsigned char **p) {
    const unsigned char *s = *p;
    unsigned int cp;

    switch(utf8_sequence_length(s[0])) {
        case 1:
            cp = s[0];
            *p += 1;
            break;
        case 2:
            cp = ((s[0] & 0x1F) << 6) |
                  (s[1] & 0x3F);
            *p += 2;
            break;
        case 3:
            cp = ((s[0] & 0x0F) << 12) |
                 ((s[1] & 0x3F) << 6) |
                  (s[2] & 0x3F);
            *p += 3;
            break;
        default:
            cp = ((s[0] & 0x07) << 18) |
                 ((s[1] & 0x3F) << 12) |
                 ((s[2] & 0x3F) << 6) |
                  (s[3] & 0x3F);
            *p += 4;
            break;
    }

    return cp;
}

The function does what we described in: Decoding UTF-8. Part I: Manual Decoding.

• A one-byte sequence is decoded by taking the low 7 bits from the byte (simply casting the unsigned char to unsigned int).

• A two-byte sequence is decoded by laying out the five low bits from the first byte (s[0] & 0x1F) to bits 6-10 ( << 6) and the six low bits from the second byte (s[1] & 0x3F) to bits 0-5.

• For a three-byte sequence we lay out the four low bits from the first byte (s[0] & 0x0F) to bits 12-15 (<< 12), then the six low bits from the second byte (s[1] & 0x3F) to bits 6-11 ( << 6), and finally the six low bits from the third byte (s[2] & 0x3F) to bits 0-5.

• For a four-byte sequence we lay out the three low bits from the first byte (s[0] & 0x07) to bits 18-21 (<< 18), then the six low bits from the second byte (s[1] & 0x3F) to bits 12-17 ( << 12), then the six low bits from the third byte (s[2] & 0x3F) to bits 6-11 ( << 6), and finally the six low bits from the fourth byte (s[3] & 0x3F) to bits 0-5.

Assembly (clang 18.1 on aarch64 with -O2) for the three-byte sequence:

// The three-byte sequence: 1110fghi 10jklmno 10pqrstu
// Starts with: w0 - zero-extended first byte (1110fghi),
//              x20 - start of the sequence
// Ends with: w0 - final codepoint: 00000000 00000000 fghijklm nopqrstu

   and     w8, w0, #0xf              // Extract fghi bits from first byte
   lsl     w0, w8, #12               // Into bits 12-15

   ldrb    w8, [x20, #1]             // Load second byte
   bfi     w0, w8, #6, #6            // Insert jklmno bits into bits 6-11

   ldrb    w8, [x20, #2]             // Load third byte
   bfxil   w0, w8, #0, #6            // Insert pqrstu bits into bits 0-5

   mov     w8, #3                    // length = 3
   b       .utf8_decode_epilog       // go to the function epilog

Pretty much straightforward. Note how a different instruction is used for each byte:

• lsl: moves bits upward into an empty register.

• bfi: inserts bits into a middle part of the register

• bfxil: extracts low bits and inserts them into a low part of the register

One interesting thing I learned from inspecting this assembly snippet is that BFI and BFXIL instructions are aliases for BFM. The former inserts a bitfield into a destination register at a specified position, and the latter extracts a bitfield from the source and place it into low-order bits of the destination1.

In the next part, we’ll extend the simple decoder with validation.

Some of the more serious accounts mention one important detail of the story: DRI was late with the port of the CP/M to the Intel 8086. When IBM representatives visited in August of 1980, looking for an operating system for their upcoming PC, only the 8-bit version of CP/M could be demonstrated. IBM eventually turned to Microsoft and selected what became MS‑DOS.

In this article, we will examine why CP/M‑86 was delayed and, in the end, speculate how much that delay actually mattered.

PL/I Development

To understand why the CP/M port to the Intel 8086 was delayed, we need to go back to 1978. The current version of CP/M was 1.4, and it was already the industry standard as an operating system for 8-bit business microcomputers.

At the time, Digital Research founder Dr. Gary Kildall felt that microcomputers needed a high-level application language - something better suited to application development than his PL/M, which was essentially a systems language2. At first, he considered Pascal. Then he received a call from Boston‑based computer scientist Dr. Robert Freiburghouse, who invited him to join an ANSI standards committee working on the PL/I‑G dialect. Kildall was familiar with PL/I and did not have a good opinion of it, but after attending several committee meetings he realized he liked the “Subset G” proposal and decided to implement a compiler.

The plan was to complete the new compiler in nine months. Instead, development stretched to more than two years; the compiler was finally released in late 1980 under the name PL/I‑80.

DRI’s PL/I received praises for its quality3 - after all compilers were Gary Kildall’s core expertise - yet it saw little adoption and no real market success. Commercial applications for microcomputers continued to be written mostly in assembly languages for another decade. Kildall himself later described the PL/I project as a “huge diversion”.

Worse, prioritizing the PL/I-G project at the expense of CP/M led to a major crisis.

Kathryn Strutynski and Release of CP/M 2

Originally, CP/M was written as a monolithic piece of software. Once it began to be adopted to various Intel-based microcomputers, Kildall decomposed it into the part that was hardware-independent (BDOS) and the part that had to be re-written for each new machine (BIOS)4. In theory, a computer manufacturer (OEM) could implement its own BIOS using the documentation without any help from DRI. This modular design was another factor that helped CP/M gain popularity.

Unfortunately, certain assumptions about the disk geometry remained hard-coded into BDOS: the system assumed single‑sided, single‑density 8″ floppy disks with 77 tracks, 26 sectors per track and 128 bytes per sector. Then, larger disks appeared: double‑density 8″ disks, 5.25″ disks with capacities above 300 KB, and most importantly hard disks started to get used with microcomputers. CP/M 1.4 was quickly becoming inadequate.

Kildall realized that the solution required another redesign, with the disk characteristics moved from BDOS to BIOS so OEMs could define them. The actual implementation of the new design still required time and effort, and customers were growing impatient.

At that point, DRI had only one technical employee besides Gary Kildall: John Pierce5, whose main responsibility was customer support. Fortunately, the finances looked good, so Kildall went to his former employer, Naval Postgraduate School (NPS) and recruited an old friend: Kathryn “Kathy” Strutynski - in his words, “an astute programmer”. Strutynski became DRI’s fourth employee, and soon she was busy working on CP/M 26.

According to Strutynski, they had only one computer with a hard drive. She would work on it until 2 A.M., and then Kildall would take over. It took the two of them about six weeks to complete the 2.0 release. After that, Kildall went back to his PL/I project, and Strutynski wrote an improved version, CP/M 2.2, that became the most popular edition of the operating system ever released. She earned the nickname “Mother of CP/M 2”.

Struggles with CP/M-86

From that point on, Kathy Strutynski was in charge of CP/M, and the next step in its evolution was a port to Intel’s new 16-bit CPU, the 8086.

This was the first attempt to port CP/M to another microprocessor. The operating system had originally been developed for the 8-bit Intel 8080, and until then it had been released only for that instruction set architecture, even though most CP/M machines built after 1977 used the more advanced Zilog Z807.

The scope of the project was intentionally limited: CP/M-86 was envisioned as a pretty much direct translation of CP/M 2.2 to the 8086 architecture. The only significant new feature would be the use of the much larger address space of the 16‑bit processor. That allowed multiple programs to be loaded into memory simultaneously, even though they could not run concurrently. Major new features such as multitasking and networking were left to separate projects called MP/M and CP/NET, led by another of Kildall’s friends and new employee of DRI, Tom Rolander.

Given the modest project goals and the proven capabilities of its lead, the original estimate for its release (by the end of 1979) looked reasonable. The 8086 had been designed specifically to make the migration straightforward: translation tables were provided by the Intel manuals. In fact, DRI later released a source-to-source compiler from 8080 to 8086 assembly called XLT86.

Yet the deadline slipped by more than a year. Ironically, the main reason was the success of CP/M 2.2. Strutynski had to spend way too much time helping OEMs adapt CP/M to their hardware. Because of the modular design of the operating system, the manufacturers were in theory able to write their own BIOS. In practice, they needed a lot of handholding from DRI, and most of that work fell on Strutynski.

Among the multitude of customers that asked her for help was Microsoft. After seeing VisiCalc on an Apple II, Paul Allen realized the potential of the machine which was previously used mostly in education and by hobbyists. Instead of porting all existing Microsoft products8 to the 6502-based computer, Allen came to an idea to develop a hardware card that would contain a Z80 processor and turn the Apple II into a CP/M compatible computer. The device was named SoftCard and was initially prototyped by a small hardware manufacturer called Seattle Computer Products (SCP). CP/M was licensed from DRI and it was Strutynski who worked closely with Allen to adapt the operating system to the new card.

I went to Microsoft and my daughter went and we worked on the SoftCard and she slept on Paul Allen’s couch and I worked on trying to get the code tight enough to fit on the card.

Kathryn Strutynski

The SoftCard was a surprising success. For a time it was not only the major source of revenue for Microsoft, but (according to Bill Gates) the most popular hardware platform on which CP/M ran. In fact, many Apple II users believed CP/M was a Microsoft product (the copyright message displayed by the card mentioned Microsoft, but not DRI) which later caused confusion when IBM representatives began searching for an operating system for the IBM PC.

All these success stories helped establish CP/M 2.2 as the de-facto standard for the eight-bit business computers in the early 1980s. Unfortunately, they also drained DRI’s limited engineering resources, and CP/M‑86 slipped behind schedule.

In hindsight, it is easy to criticize DRI for investing effort on projects such as PL/I and MP/M instead of focusing on CP/M-86. However, in 1979/1980 it was not clear how close the shift to 16-bits was and which CPU was going to lead. Intel was the first to market with the 8086, but Zilog soon followed with the Z8000 architecture, and then in late 1979 Motorola released the excellent 68000, which IBM even considered for the PC.

Few OEMs were asking for an 8086 version of CP/M. One that did was SCP - the same company that helped Microsoft design SoftCard. They needed a disk operating system for their 8086 board released in November 1979. In April 1980, after CP/M-86 was still nowhere to be seen, they lost patience and asked their young engineer Tim Paterson to develop a “quick and dirty” OS similar to CP/M that would hopefully boost the sales of their board9. That little operating system, officially named 86-DOS, was eventually purchased by Microsoft and renamed MS-DOS. Paterson has stated on multiple occasions that he would never have begun developing it had CP/M‑86 been available on time.

When CP/M‑86 finally appeared in early 1981, it initially sold well. DRI’s newsletter “Digital Research News” for the fourth quarter of 1981 came with an article titled “CP/M-86 Captures Leading Share in 16-Bit World Market” which estimated that 25% of 16-bit microcomputers were using CP/M-86. The situation quickly changed after IBM PC was released with “IBM PC DOS” (rebranded MS-DOS) being offered for a fraction of the price of CP/M-86.

The Aftermath and What-Ifs

Although CP/M-86 was never given a fighting chance against PC DOS, the 8-bit versions of CP/M (renamed CP/M-80) continued to sell well for a while. DRI’s revenues were $6 million in 1981 and grew to $44.6 million in 1983. The company’s headcount peaked at over 500 employees, including staff in three international offices10.

However, by 1985 it was clear that MS-DOS on PC-compatible computers had won. DRI faced layoffs and the departure of many key employees, including Kathy Strutynski who returned to NPS seeking a more secure employment11. She passed away in 2010. Reduced in size, DRI remained in business until 1991 when it was acquired by Novell. The sale made Gary Kildall very rich, but not happy; he died in 1994 at the age of 52, embittered and struggling with alcoholism.

Some analysts believe that releasing CP/M-86 in December 1979 as planned would have forced IBM to strike a deal with DRI, preventing 86‑DOS from ever being created. In that scenario, DRI could have followed up with the multitasking Concurrent CP/M and with the addition of the GEM desktop environment, the PC industry would have had a true multitasking graphical OS by 1985.

In my opinion, a timely release of CP/M-86 would have changed little. The reasons DRI and IBM were not able to reach the deal were complex and the readiness of CP/M-86 would have done little to resolve them. Microsoft would simply have developed a new operating system from scratch to keep the IBM PC project alive - something they were perfectly capable of doing. They had already created (but never released) M-DOS for the 8-bit computers that was more advanced than CP/M, and their Standalone Basic, which included a FAT filesystem, had already been ported to the 8086. After all, the early disk operating systems consisted of just a few kilobytes of machine code.

Most texts on the subject look intimidating though, including some very well written ones, such as Eli Bendersky’s Position Independent Code (PIC) in shared libraries. The topic often appears complicated because it is usually explained in the context of building shared libraries for Linux; a domain that requires discussing linkers, loaders, the ELF format, and other complex mechanisms. I felt it would be easier to understand the core idea of position‑independent code by using a much simpler computer, so I went back to the dawn of personal computing and picked the original Apple II.

Some of the reasons I chose Apple II for this exercise are:

• It was built around the MOS 6502 - a very simple 8-bit CPU with a small address space, no virtual memory, one accumulator register. In one of my previous posts, I argued that 6502 is a Good Starting Point for Beginning Assembly Programming.

• It includes a built‑in machine‑code monitor and mini‑assembler which are handy for entering and testing machine code. Most other machines from that era would require to use BASIC commands like PEEK and POKE which is doable but less comfortable.

• I have never had a chance to work with an Apple II1 and this is my excuse to finally try it.

To be clear: in this article, mu goal is simply to describe the concept of position-independent code. I am not going to investigate techniques making full Apple II programs position‑independent2.

Setup

I do not have access to an actual Apple II computer. Instead, I used the AppleWin emulator in Apple ][ 48K mode which emulates the original Apple II from 1977 with 48 KB RAM and with Integer BASIC, Machine Language Monitor and Mini Assembler in ROM. I used APPLE II USER’S GUIDE by Lon Poole and Steven Cook to learn how to use the Monitor and Mini-Assembler; there was no need for BASIC.

To read this article, you don’t need any of that. What is needed is some basic understanding of computer architecture and assembly programming (with any instruction set). If you were never exposed to these topics but still have some programming experience, just spend half an hour playing with Easy 6502 web page, and you will be ready to follow the rest of this post.

An Obviously Position Independent Program

Let’s start with a minimal program that is position independent. It will first clear the screen and then print letter ‘A’ in the upper left corner.

I used the Mini-Assembler to enter the code. The listing is here:

*300L                                   
                                        
0300-   20 58 FC    JSR   $FC58
0303-   A9 C1       LDA   #$C1 
0305-   8D 00 04    STA   $0400
0308-   60          RTS        
...

• The JSR instruction at address 0300 calls the monitor routine at $FC58 (HOME) to clear the screen. The entry point of the routine is fixed, so it works regardless of where our program itself is loaded.

• LDA loads the accumulator with $C1, which is normal (i.e. not inverse or flashing) code for letter ‘A’ in Apple II character set. It is calculated as the ASCII code for the symbol ($41) + $80.

• STA stores the accumulator value (currently $C1) to memory location $400, the beginning of the text screen buffer. Again, this address is absolute and does not depend on our program’s position in memory.

• RTS returns to the caller - in our case the Apple Monitor.

Running the code produces the expected result:

To prove the code is truly position independent, we can copy it to address $320, erase the original program at $300 and run it:

*320<300.308M
*300:00 00 00 00 00 00 00 00 00
*320L
0320-   20 58 FC    JSR   $FC58         
0323-   A9 C1       LDA   #$C1          
0325-   8D 00 04    STA   $0400         
0328-   60          RTS
*320G

As expected, the result is exactly the same as above.

A Loop

Position Independent Loop

Let’s see whether a simple loop is position independent. In this example we’ll extend the program to write letters “ABCDEF” at the top left corner of the screen.

We’ll need to keep track of two “variables”: the current character to print (stored in register A, just as before), and the current screen position (stored as an offset in register X, counting from the beginning of the text screen area). We’ll loop until X reaches the value 6 while incrementing both A and X on each iteration.

*300L

0300-   20 58 FC    JSR   $FC58   
0303-   A2 00       LDX   #$00 
0305-   A9 C1       LDA   #$C1
0307-   9D 00 04    STA   $0400,X 
030A-   18          CLC  
030B-   69 01       ADC   #$01 
030D-   E8          INX    
030E-   E0 06       CPX   #$06 
0310-   D0 F5       BNE   $0307 
0312-   60          RTS    

*300G

• JSR clears the screen, just as above.

• LDX initializes register X to 0.

• LDA loads register A with the display code for the first character, ‘A’, just as before.

• STA stores the value of the accumulator to the screen memory. Note that we use a different opcode for STA here: 9D, vs 8D we used above. The difference is in the address mode: here the Absolute, X addressing mode adds value of X to the address specified in the operand. For instance, if the operand is $400 and X contains $01, the value of A will be stored at $401.

• CLC clears Carry flag, so it does not affect the following instruction.

• ADC increases the value in the accumulator which changes the value of the character we write on the screen.

• INX increases the value of the X register and points us to the next screen position.

• CPX compares the contents of register X to $06 and sets zero flag if they are equal.

• BNE branches back to the STA instruction at $0307 if the zero flag is not set.

• RTS returns to the caller.

The result is:

Most instructions are obviously position-independent, just as in the first example. The exception is BNE at address $310:

0310-   D0 F5       BNE   $0307

At first glance, the jump target looks absolute: $0307. If that was literally encoded in the instruction our program would not be position independent. But this is just the disassembler being smart: the BNE instruction takes relative offset as the operand. The actual machine code displayed in the same line shows the operand value of $F5. Why? The distance between the next instruction and the target address is $307 - $312 = $F5 (negative 11 decimal).

Again, let’s move the program from address $300 to $320, clear out the original copy and see whether it works:

*320L                                   
                                        
0320-   20 58 FC    JSR   $FC58         
0323-   A2 00       LDX   #$00          
0325-   A9 C1       LDA   #$C1          
0327-   9D 00 04    STA   $0400,X       
032A-   18          CLC                 
032B-   69 01       ADC   #$01          
032D-   E8          INX                 
032E-   E0 06       CPX   #$06          
0330-   D0 F5       BNE   $0327         
0332-   60          RTS 

*320G                

Yep, it’s the same. And if we look at the BNE line, we can see what the disassembler did: it updated the displayed target to $0327, but the actual operand, the relative offset, remains $F5.

0330-   D0 F5       BNE   $0327

Position Dependent Loop

As we have seen, BNE uses a one‑byte relative offset, which allows it to jump up to 127 bytes backward or 128 bytes forward from the current instruction. That works fine in our example, but if the body of the loop was large enough, we would need to use the JMP instruction instead:

*300L

0300-   20 58 FC    JSR   $FC58   
0303-   A2 00       LDX   #$00    
0305-   A9 C1       LDA   #$C1    
0307-   9D 00 04    STA   $0400,X  
030A-   18          CLC      
030B-   69 01       ADC   #$01 
030D-   E8          INX        
030E-   E0 06       CPX   #$06 
0310-   F0 03       BEQ   $0315 
0312-   4C 07 03    JMP   $0307 
0315-   60          RTS

*300G

The only difference from the position-independent loop is that we replaced the BNE instruction with BEQ + JMP pair. BEQ was necessary to exit the loop, as JMP is not conditionally executed. The important detail is that JMP uses an absolute address, and here it jumps to an address inside the program itself.

To prove the program is position dependent, we’ll move it to $320 and zero out the original copy at $300:

*320<300.315M
*300:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*320L
0320-   20 58 FC    JSR   $FC58         
0323-   A2 00       LDX   #$00          
0325-   A9 C1       LDA   #$C1          
0327-   9D 00 04    STA   $0400,X       
032A-   18          CLC                 
032B-   69 01       ADC   #$01          
032D-   E8          INX                 
032E-   E0 06       CPX   #$06          
0330-   F0 03       BEQ   $0335         
0332-   4C 07 03    JMP   $0307         
0335-   60          RTS                 
*320G

The program prints ‘A’ but then crashes, as expected. JMP still points to address $0307 which now contains zeroes.

Global Data

Now, we’ll try printing the word “HELLO” in the top-left corner of the screen. The main difference from the previous program is that the character values cannot be calculated - instead we read them from memory, and the memory is a part of the program, just as the instructions. On the Apple II there are no ELF sections to keep data separate from code, so we’ll just place the text immediately after the RTS instruction:

*300L

0300-   20 58 FC    JSR   $FC58   
0303-   A2 00       LDX   #$00    
0305-   BD 11 03    LDA   $0311,X 
0308-   9D 00 04    STA   $0400,X 
030B-   E8          INX           
030C-   E0 05       CPX   #$05    
030E-   D0 F5       BNE   $0305   
0310-   60          RTS
0311-   C8          INY                 
0312-   C5 CC       CMP   $CC           
0314-   CC CF 00    CPY   $00CF

*300G

• JSR calls HOME to clear the screen as always.

• LDX initializes X to 0. As before, we use X both to index into the screen buffer and to index into the message.

• LDA loads the current character from memory using absolute,X addressing. The message bytes are placed immediately after the RTS, so the base address is $0311. Note how using the same index for both the data and the screen position keeps the loop simple.

• STA writes the character to the appropriate location on the text screen.

• INX increases X to get the next character and move the position on the screen.

• CPX checks whether we’ve reached the end of the string (5 characters).

• BNE loops back if we have not.

• RTS returns to the monitor.

• The five bytes after RTS: C8 C5 CC CC CF correspond to characters ‘H’ ‘E’ ‘L’ ‘L’ ‘O’ in Apple II character set (ASCII codes + $80)

The result is as expected:

What happens if we move the program to $320?

*320<300.315M
*320L                                   
                                        
0320-   20 58 FC    JSR   $FC58     
0323-   A2 00       LDX   #$00     
0325-   BD 31 03    LDA   $0331,X
0328-   9D 00 04    STA   $0400,X
032B-   E8          INX          
032C-   E0 05       CPX   #$05
032E-   D0 F5       BNE   $0325 
0330-   60          RTS                 
0331-   C8          INY                 
0332-   C5 CC       CMP   $CC           
0334-   CC CF 00    CPY   $00CF         

As we can see, the LDA instruction at $0325 still loads from the absolute base address $0311. That address did not change when we moved the program.

Let’s erase the old program, and run the relocated one:

*300:00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00
*320G

Again, as expected, the result is not “HELLO”:

The program now reads whatever bytes happen to be at address $0311, which are zeros after we erased the old program. I miscalculated the size of the program by one when zeroing it out, so the final letter ‘O’ is still being printed.

Conclusion

For a program to be position independent, it must avoid absolute references to its own code and data. Any internal jump or data access has to be expressed through relative addressing so the program can run correctly no matter where it is loaded. Absolute addresses are safe only when they refer to external routines that live at fixed, well‑known locations, such as the Apple II’s ROM monitor, or an operating system.

Some important early microcomputer software products were developed or prototyped on the PDP-10:

• Digital Research’s CP/M - the first commercial operating system for microcomputers.

• Microsoft’s early products, including the Altair BASIC.

• VisiCalc - the first spreadsheet application for personal computers.

CP/M

In 1973, Dr. Gary Kildall worked full-time as an assistant professor at Naval Postgraduate School (NPS) at Monterey, California, and part-time as a consultant for Intel1. He wrote simulators and cross-assemblers for Intel’s early microprocessors: the 4004, 8008, and 8080.

Kildall proposed developing a high‑level language for those microprocessors, called PL/M. Convincing Intel took some effort as even Intel’s cofounder and coinventor of the integrated circuit Bob Noyce did not see microprocessors as viable general-purpose CPUs at that time.

The plan was to first develop a cross-compiler for Intel’s microprocessors on a PDP-10 mainframe in FORTRAN and then use it to bootstrap a compiler that would run on the Intellec-8 development system. The cross-compiler was done successfully, but hosting the compiler on the Intellec-8 faced a serious problem: lack of reliable and fast storage.

Fortunately, a new storage device called floppy disk was getting cheaper, and Shugart Associates donated one to Kildall. He still wasn’t able to actually use it, as he lacked a disk controller, so he returned to the PDP-10 and used his cross-compiler and simulators to develop a small operating system for 8080-based machines which he called CP/M.

CP/M was minimalistic, as it was designed to run with very limited amount of memory, but it is clear that it was influenced by the PDP-10 operating system TOPS-10. It used three-letter file extensions, including standard ones like EXE and TXT. Some CP/M commands were directly ported from TOPS-10.

Gary Kildall was a visionary, innovator, and educator, but not a businessman. He wanted to sell CP/M to Intel for $20,000 and continue teaching at NPS. Intel declined the offer, but soon the first commercial microcomputers appeared and they needed an operating system. Gary’s wife Dorothy saw a business opportunity and the Kildalls formed a company - Digital Research Inc. (DRI).

CP/M became an industry standard for 8-bit business computers. Although IBM PC clones that ran Microsoft’s MS DOS operating system (itself a CP/M lookalike) took over by the mid-1980s, CP/M and its successors such as DR-DOS remained viable alternatives until the rise of Windows.

Microsoft BASIC

In October 1968 a group of University of Washington employees and graduate students founded a timesharing startup called The Computer Center Corporation, nick-named C-Cubed2.

C-Cubed leased a PDP-10 computer from DEC - serial number 363. The deal with DEC included reduced fees in exchange for testing their operating system TOPS-10. The company started looking for testers, and it just turned out that a computer course in a local private school - Lakeside4 had run out of money. C-Cubed offered the students free time on their terminals in return for reporting bugs. Among the students who took up the offer were Paul Allen and Bill Gates.

They loved the computer5, learned programming in PDP-10 assembly and continued using it until C-Cubed went out of business in early 1970. That was only the beginning. In November 1970 they secured a gig with Information Services Inc. to help write a payroll program in COBOL6, and in late 1972 they joined a TRW Inc project to develop a real-time operating and dispatch system, (RODS) for the Bonneville Power Administration’s electrical grid. The project did not progress well, but Allen and Gates were allowed to work on their own project off hours.

They had an idea to build a traffic control application based on Intel’s first 8-bit microprocessor: 8008. Allen built a set of tools to develop code for 8008 on PDP-10, including a simulator, cross-assembler and debugger. They eventually completed the system, called it Traf-O-Data and even sold it to three customers. The money they earned was not worth the effort, but the experience and tools they built in the process were.

In December 1974, Paul Allen bought an issue of Popular Electronics with a new computer called the Altair 8800 on the front page. By then the two friends lived in Cambridge, Massachusetts - Allen was working for Honeywell and Gates attended Harvard University. They saw an opportunity and offered to write a BASIC interpreter for the new microcomputer. The old development tools for the 8008 were adjusted to the new 8080 processor and they went to work.

They used a PDP-10 computer at Harvard’s Aiken Computation Lab, called Harv-107, on which they completed the interpreter by late February. Allen flew to New Mexico, demonstrated the software to MITS (producers of Altair), and soon after the two friends moved to Albuquerque to work on their new project full time. They started a company and called it Micro-Soft, later renamed to Microsoft.

Microsoft continued using various PDP-10 computers as their primary development machines8 into the 1980s until microcomputers finally became powerful enough to host productive development environments.

VisiCalc

In June 1973 Dan Bricklin graduated from MIT with a Bachelor of Science in electrical engineering and computer science. His grades were not good enough to get him into graduate programs he was interested in, and he began looking for a job. He interviewed with Digital Equipment Corp. (DEC) and accepted a position with a group that was developing a computerized typesetter system9.

The first product Bricklin worked on within DEC was TYPESET-10, a typesetting system that ran on DEC’s PDP-10 mainframes10. Later he worked on a word processing system called WPS-8 that ran on DEC’s low-end PDP-8 minicomputer.

In 1976, DEC moved Bricklin’s office to New Hampshire, and he started working at a producer of cash registers called Fasfax where he led the programming department and used Forth and assembly on microcomputers.

In 1977, Dan Bricklin decided to go back to school and earn an MBA from Harvard. At one lesson, in the spring of 1978, in his own words11 he started “daydreaming” of a calculator that could be moved around like a mouse12. He decided to prototype a software version of his calculator. For that, he used Harvard’s PDP-10 timesharing computer13 to which he was connected via a DEC VT05 terminal and wrote the prototype in BASIC. During the development of that first prototype he decided to organize the numbers into named rows and columns.

The second prototype followed a few months later on a borrowed Apple II computer with a game paddle acting as a mouse.

The production version of VisiCalc was coded by Bricklin’s friend Bob Frankston. He did not use a PDP-10, but a similar mainframe timesharing system: MIT’s Honeywell 618014 running Multics. The main reason was that Frankston had learned how to cross-develop code for 6502 microprocessors on Multics while consulting with a small company named ECD Corporation15. He worked at night when compute time was cheaper, sharing the computer with Honeywell developers who worked on the Ada programming language.

VisiCalc became the “killer app” for Apple II and the model for every spreadsheet application that followed.

Test Descriptions

To recap, the three methods we compare here are:

The “bitmask” method, described in Decoding UTF-8. Part II: Determining Sequence Length - a Straightforward Approach:

int utf8_sequence_length(unsigned char lead_byte) {
    if ((lead_byte & 0x80) == 0) {
        // Single byte (0opqrstu)
        return 1;
    } else if ((lead_byte & 0xE0) == 0xC0) {
        // Two-byte sequence (110xxxxx)
        return 2;
...
}

The “lookup” method, described in Decoding UTF-8. Part III: Determining Sequence Length - A Lookup Table:

int utf8_sequence_length(unsigned char lead_byte) {
 // Hard-coded lookup table for UTF-8 lead byte lengths
 static const unsigned char lookup[256] = {
...
};

  // Access the hard-coded table to determine the sequence length
  return lookup[lead_byte];
}

The “countlz” method, which uses hardware support for counting leading zeros in a byte, described in Decoding UTF-8. Part IV: Determining Sequence Length - Counting Leading Bits:

int utf8_sequence_length(unsigned char lead_byte) {
    switch (std::countl_one(lead_byte)) {
        case 0: return 1;
        case 2: return 2;
        case 3: return 3;
        case 4: return 4;
        default: return 0; // invalid lead
    }
}

There are two sets of data in the test:

1. Pure ASCII text.

2. Cyrillic text with ASCII HTML tags.

I used two different compilers:

1. Clang 18.1.3

2. GCC 13.3.0

The results presented in this article were obtained on a Microsoft Surface laptop with a Snapdragon X1E80100 12-core CPU @ 3.40 GHz and 16 GB RAM, running Ubuntu 22.04 under WSL 2.

The code for the benchmarks can be found at: https://github.com/nemtrif/utfbench/tree/main/seqlen

My expectations based on the generated assembly were:

• For the ASCII text, I expected the straightforward “bitmask” method to perform best, as the data is very friendly to branch prediction, and the branch executed is very efficient. I expected the “countlz” method to perform somewhat worse, and the “lookup” method to perform worst.

• For the ASCII/Cyrillic mix, I thought branch prediction would be much less effective and the branchless variants would perform better. I expected “countlz” to be fastest, followed by “lookup”.

Let’s see how good my predictions were.

Clang 18.1.3 Results

The code was compiled with:

clang++ -O2 --std=c++20

The results for ASCII text are:

I did expect the “bitmask” version to perform best. For ASCII text the hot path executes a TBNZ that checks the highest bit, sets the return value to 1, and jumps to the function epilogue (assuming the function is not inlined). That said, the sixfold difference between the bitmask and table-based methods was surprising.

The same setup but with Cyrillic HTML produced the following results:

I expected the mix of Cyrillic and ASCII characters to confuse the branch predictor, and it did, but the “bitmask” method was still twice as fast as the “lookup” method. The “countlz” method performing worst was definitely a surprise given the small size of the compiler-generated lookup table and the hardware-assisted bit counting.

GCC 13.3.0 Results

The code was compiled with:

g++ -O2 --std=c++20

The results for ASCII text:

The only noteworthy difference between these results and Clang’s is the performance of the countlz method, which processed almost five times more data when compiled with GCC. The detailed explanation can be found in my recent article When Compiler Optimizations Hurt Performance where we saw how a compiler-generated lookup table meant to optimize switch-case statements actually hurt performance. GCC did not perform the optimization and that is the reason it produced better code.

Benchmark with Cyrillic HTML produced the following results:

There is little difference between GCC and Clang. The “countlz” method was hurt by branches and it ended up being roughly equivalent to the lookup method.

Conclusion

If there is a conclusion to be made from this exercise, it is to be very careful about avoiding branches by creating lookup tables - either manually or via compiler optimizations.

The boring, straightforward “bitmask” method easily won, even when data was not helping the branch predictor. Memory access turned out to be more expensive even without any cache misses.

Unfortunately, most emulators are eventually abandoned by their developers. One of the oldest ZX Spectrum emulators still under active development is Fuse - the Free Unix Spectrum Emulator. First released in 1999 by Philip Kendall, the emulator remains Unix-first, although it’s also available on macOS, Windows, Android, and a few other systems.

Fuse emulates Sinclair’s original Spectrum models, Amstrad’s successors, and even some clones like the Pentagon. It does not support the modern ZX Spectrum Next; for Next emulation options, see the SpecNext Wiki.

This little guide is a getting-started introduction that walks you through the installation and basic usage of Fuse on Windows without covering any advanced topics.

Installation

The installer can be downloaded from the official SourceForge page: https://sourceforge.net/projects/fuse-emulator/.

By default, the emulator installs to C:\Program Files (x86)\Fuse, since it is a 32-bit build.

Note the file fuse.html in that directory. It contains the list and short descriptions of most command-line options for Fuse, as well as the menu commands and key shortcuts. You may find it handy later as you get more familiar with the emulator, but we will not need it right now.

Starting Fuse and Loading a Game

When you start Fuse for the first time, the following screen will appear:

Chances are it will actually be much smaller, so the first thing to do is resize it by dragging the bottom-right corner until it’s large enough to work with.

Programs for the original ZX Spectrum were distributed mostly on cassette audio tapes. Most titles are preserved in emulator file formats - the most popular one being TZX. Loading a program into Fuse is as simple as finding a tzx file and dragging it onto the emulator window.

For example, here is how to load the legendary Jetpac game.

• Search online for something like “world of spectrum jetpac”

• Most likely, the top page in the search result will be Jetpac - World of Spectrum Classic

• Download Jetpac.tzx.zip. You may also want to download or at least read the instructions contained in the file Jetpac.txt linked from that page

• Extract the zip file to get file Jetpac.tzx.

• Drag Jetpac.tzx onto the Fuse window (or you can use File, Open from the menu if you want). The result should look like this:

Enjoy the game:

You can reset the emulator by selecting Machine, Reset… on the Fuse menu, or by hitting F5.

Beyond Games - Using the Keyboard

Unless you have the Spectrum keyboard layout memorized, make sure to select “Keyboard…” from the Help menu. An image of the original Spectrum 48K keyboard will show up:

Some key mappings to remember:

• Spectrum CAPS SHIFT key maps to SHIFT key on a PC keyboard;

• Spectrum SYMBOL SHIFT key maps to CTRL on a PC keyboard;

• Spectrum BREAK SPACE key maps to the space bar on a PC keyboard.

Press the “P” key, and the screen should look like:

Now type the following:

 "Hello Speccy"

and press the ENTER key. Note that the quote sign is on the P key and to type it you need to press Ctrl+P.

To get started with the 48K ZX Spectrum, make sure to check the official ZX Spectrum Introduction, written by Steven Vickers and Robin Bradbeer. Not everything in the book applies to the emulator, but the chapter about keyboard use is essential.

If you are intimidated by the 48K keyboard, switch to a later model which enables typing commands without the shortcuts. To do that, From the “Machine” menu pick “Select…” (or just press F9) and select the model you want to use. My suggestion is Spectrum 128K. Once you select it, the emulator will reset, and the screen will look like:

By using the arrow keys, select the second option: 128 BASIC, and the screen looks like:

Now you can type without any shortcuts:

print "Hello Speccy 128" 

(note that quotes are still Ctrl+P) and the screen will look like:

Check out the ZX Spectrum 128 Introduction manual

Resources for Programming ZX Spectrum

If you are interested in learning BASIC programming, the book to use is SINCLAIR ZX SPECTRUM BASIC Programming by Steven Vickers.

The next step is Williem Tang's "Spectrum Machine Language For The Absolute Beginner".

If you want to make any non-trivial programs for ZX Spectrum, developing directly on Fuse is not optimal. Instead, use a modern PC to edit the code, cross-compile it, then load the resulting tzx or snapshot into Fuse for testing.

Setting up such an environment is a topic for another post.

The method I described in Decoding UTF-8. Part IV: Determining Sequence Length - Counting Leading Bits uses hardware-assisted counting of leading zero bits:

#include <bit>
int utf8_sequence_length(unsigned char lead_byte) {
    switch (std::countl_one(lead_byte)) {
        case 0: return 1;
        case 2: return 2;
        case 3: return 3;
        case 4: return 4;
        default: return 0; // invalid lead
    }
}

I was pretty disappointed with the performance of this function. It was processing between 438 MB/s and 462 MB/s of text data which was far less than the “naive” method described at Decoding UTF-8. Part II: Determining Sequence Length - a Straightforward Approach.

As we saw in the Part IV post, the compiler (clang++ 18.1.3, aarch64) emits a small lookup table to avoid branching:

        adrp    x9, .Lswitch.table.utf8_sequence_length(unsigned char)
        add     x9, x9, :lo12:.Lswitch.table.utf8_sequence_length(unsigned char)
        ldr     w0, [x9, w8, uxtw #2]
...
.Lswitch.table.utf8_sequence_length(unsigned char):
        .word   1
        .word   0
        .word   2
        .word   3
        .word   4

The lookup table generated by the compiler is a degenerate case of a jump table, which is a common optimization for switch-case statements. The “naive” code from Part II uses branching instructions instead and processes over 2000 MB/s. Obviously, the branch predictor did its magic for the case of pure ASCII text, but the performance gap still surprised me1.

Playing with the Linux perf tool on a WSL Linux installation turned to be a pretty frustrating experience. It did point me to a very high number of cycles stalled in the back-end which often indicates that CPU is waiting for memory, but I couldn’t get perf annotate to work.

In any case, what I had was enough to let me try disabling jump tables; with

clang++ -O2 -fno-jump-tables --std=c++20 

the switch-case part of the function compiles to:

        cmp     w0, #2
        b.gt    .LBB0_4
        cbz     w0, .LBB0_6
        cmp     w0, #2
        b.eq    .LBB0_5
.LBB0_3:
        mov     w0, wzr
        ret
.LBB0_4:
        cmp     w0, #3
        ccmp    w0, #4, #4, ne
        b.ne    .LBB0_3
.LBB0_5:
        ret
.LBB0_6:
        mov     w0, #1
        ret

Lo and behold, the performance became comparable to the “naive” function from Part II.

I repeated the experiment using GNU g++ for AArch64. In that case, -fno-jump-tables had no effect because g++ never emitted a lookup table.

Not surprisingly, it turned out I was not the first to come up with this observation. For instance, there is an excellent article by Julian Squires from 2017 on the same topic, but focusing on x86-x64 platform: Are Jump Tables Always Fastest?

The ST was an amazing machine, not only compared to my poor old “Speccy” and similar cheap home computers, but even to the IBM PC compatibles in my school’s comp-sci lab, which cost at least twice as much.

Decades later, I decided to learn more about the graphical desktop that ran on the Atari ST - GEM by Digital Research Inc. This post is the result of my modest research project.

Much of my source material comes from the Computer History Museum. If you enjoy the article and feel generous, please consider making a donation to the museum.

Xerox Lone Star

In July 1981, Lee Jay Lorenzen, a recent graduate from Southern Methodist University, began working at Xerox’s Office Products Division in Dallas, Texas1. He was hired to work on the 16-bit version of the recently released Xerox 820 personal computer (code named Worm, as it was supposed to eat Apple). Once inside Xerox, Lorenzen got access to the Xerox Star, the first commercially available computer with a graphical desktop, inspired by the legendary Xerox Alto workstation.

Impressed by the Star’s capabilities, but not its price, Lorenzen set out to design an 8086-based personal computer that would have similar user interface to the Star’s but with a more reasonable price tag. The prototype was named Lone Star, and Lorenzen made a video2 to promote it within Xerox.

In a nutshell, the Lone Star was a desktop computer based on Intel 8086 CPU, with 128 KB of RAM, 8 KB of ROM, optional 5.25” floppy drives, and running the CP-M/86 operating system. The interesting part was the graphical desktop environment, which was obviously influenced by the Xerox Star - with menus, a message bar, icons and windows. It was coded in Digital Research’s Pascal/MT+.

The Lone Star was noticed within Xerox, and Lorenzen even travelled to Palo Alto to demonstrate it to the famous PARC research group3. The follow-on to the Xerox 820 ended up being Xerox 820 16/8 - a much less ambitious machine without a graphical desktop. However, one of Lorenzen’s former managers who had moved to Digital Research Inc. (DRI) was impressed enough by his work to recruit him there.

Gem is a Pure Crystal

Lee Jay Lorenzen joined DRI in January 19834 and started at the Operating Systems Department, led by Frank Holsworth. His first project was a character-oriented windowing system for Concurrent CP/M5. In August 1983, after seeing VisiCorp’s operating environment Visi On6, Lorenzen and another developer in the same team Jason Loveman decided they could do better. They came up with the first prototype of a graphical desktop environment and demonstrated it in late 1983. The prototype was developed on an Apple Lisa computer running an internal port of Concurrent CP/M for the Motorola 68000 CPU.

Lorenzen named the prototype “Crystal” - he had heard of an IBM project code name “Glass”7 and, without a doubt inspired by name games at Xerox, wanted to one-up it.

The success of the demo earned Lorenzen a transfer to the Graphics Department under Don Heiskell, creator of the GSX graphics library. Within the department, a new team was formed to develop the desktop environment. Lorenzen was the lead, and other members included Gregg Morris and Lowell Webster with Tim Oren and Andrew Muir joining later8. A separate team worked on GEM applications such as Paint, Draw and Graphing.

By the time the project officially started, it was clear that DRI’s CP/M-86 operating system had lost the battle for the PC market and the new target platform for GEM was set to be MS-DOS. That meant not only dealing with the 640KB memory restriction9 but abandoning the multitasking for the time being.

The graphics environment was essentially ready by late 1984. It turned out the name “Crystal” was not available, so they renamed it to Gem: the most valuable crystal. Lorenzen decided to pretend it was an acronym: Graphic Environment Manager.

GEM was officially introduced at COMDEX in November 1984 and was generally well received, with two major criticisms:

• Initially, GEM ran on IBM machines, but not on clones like Compaq. The restriction was lifted soon after.

• GEM ran well on the top-of-the-line systems like IBM PC AT but was sluggish on less expensive and more popular 8088-based machines.

On February 23, 1985, Lee Jay Lorenzen demonstrated the desktop environment on The Computer Chronicles10.

On February 28, 1985, GEM 1.1 shipped.

Atari ST and TOS

In January 1984, while the GEM project was still in its early stages, Commodore’s founder and CEO Jack Tramiel suddenly left the company after a fight with chairman Irving Gould. Never one to quit, he founded Tramiel Technology Ltd. and in July grabbed the opportunity to buy Atari from Warner Communications11. Tramiel took with him a number of talented engineers from Commodore, including Shiraz Shivji, and began work on a next generation home computer. The goal was to have it ready for the January 1985 Consumer Electronics Show (CES).

The main decisions about the hardware were made before the Atari takeover: the machine would be based on Motorola’s 68000 processor with advanced graphics and built-in MIDI. For software, the team knew they wanted a modern graphical user interface with bitmap graphics. They also knew they did not have time to develop the operating system from scratch, so they contacted DRI.

All that Digital Research could demo to the Tramiel’s team at the time was Lorenzen’s Crystal prototype that ran on an Apple Lisa. They were not impressed; one of the ex-Commodore engineers called it “smoke and mirrors”. However, the only alternative was Microsoft, and they had even less to show, so the decision was made to go with DRI.

In September 1984, Atari’s software team traveled to Monterey to port the new PC version of GEM to the 68000 CPU. In the beginning, the 68000 port ran on top of CP/M-68K, but it was clear they needed a more modern OS, with a hierarchical file system. DRI’s Jason Loveman (who had originally worked with Lorenzen on the first GEM prototype) started developing a new disk operating system named GEMDOS12 specifically for that purpose.

The entire situation was pretty hectic for a while: DRI’s graphics group worked on the PC version of GEM on MS-DOS; Atari developers were porting it to Apple Lisas running CP/M-68K; and Loveman was building GEMDOS. Against all odds, they succeeded. The operating system for Atari ST consisting of GEM running on top of GEMDOS was named TOS which simply meant “the operating system”, although many believed “T” actually stood for “Tramiel”.

Atari 520 ST, soon nicknamed “Jackintosh”, was introduced at the 1985 Consumer Electronics Show in Las Vegas and became an immediate hit. GEM ran smoothly on the powerful ST’s hardware, and there were no clones to worry about. Atari developed its branch of GEM independently of Digital Research until 1993, when the Atari ST line of computers was discontinued.

Apple’s Lawsuit Threat and GEM 2

By 1985, Apple’s hopes that the Macintosh would take the world by storm as the IBM PC had four years earlier proved unfounded. At the same time, efforts to bring a graphical desktop to PCs looked promising, and Apple resorted to legal action to stop them, or at least slow them down. Microsoft Windows, half-baked as it was at its first release, was an obvious target, but even before that, Apple sent its lawyers to DRI and threatened with a lawsuit. Their claim was that GEM copied Macintosh’s “look and feel”.

According to Lee Jay Lorenzen, it was Bill Gates who convinced Apple to go after DRI first:

I said, "Bill, did you do this? I heard that you sent Apple to pester Digital Research," and he owned up to it! I've always had good interactions with Bill. I know his reputation in the industry, but to me, personally, he's always been a supporter. He certainly didn't lie about it. He said, "Yes, they came over bugging me about the UI, and I said, ‘Windows is kind of like a Macintosh, but what's really like a Macintosh is GEM at Digital Research. Why don't you go hassle them for a while?’"

Lorenzen argued that he had “stolen” his design from Xerox, not Apple, but it is hard to deny that Gates had a point13. Apple’s user interface was, of course, inspired by the Xerox Alto, but the Lisa (and later the Macintosh) introduced significant innovations that GEM adopted14. Superficially, GEM did look like a color version of Macintosh, albeit it lacked some functionality and built-in applications.15

Ultimately, DRI’s leadership chose not to face Apple at court. They reached an agreement16 to modify GEM to look less like the Macintosh. The result was GEM 2.0, with two non-resizable file windows permanently on the desktop, without icons and no “trash bin”.

GEM 2.0 was released in March 1986 and Lorenzen was credited as one of the four authors. By that time, though, he had left Digital Research to cofound Ventura Software17.

Interestingly enough, Apple never went after Atari, and TOS continued to be based on GEM 1.0.

End of GEM

The “crippled” versions of GEM still saw some success. A very popular PC clone in Europe, the Amstrad PC 1512 used GEM as its primary desktop environment, as did Atari PC computers. But by that point it was clear that DRI did not really back its desktop environment. In a report from January 1988, Stewart Alsop II had this to say about GEM:

There are other systems that some people - primary the designers - would like to include as contenders. These include Digital Research’s Gem, which started out fairly strong but appears to have suffered from a lack of leadership. The interface is the closest to the Macintosh in structure and approach, but Digital Research has never been able to provide it with a complete or workable keyboard interface (using the home key to select an object just doesn’t make sense) nor to present enough of a marketing strategy to win over any major OEMS.

The last commercial GEM release was version 3.11, published in November 1988. The project was led by of one of the original authors, Lowell Webster18.

A few more versions were released internally or bundled with other products19. An interesting offshoot was ViewMax which served as a graphical shell for DR DOS - the most successful product of Digital Research’s final years20.

Novell acquired DRI in 1991 and sold its technologies to Caldera in 1996. Caldera eventually open-sourced GEM. According to a VCF forum discussion, three major distributions of the open-sourced GEM appeared: FreeGEM, Owen’s Free GEM and OpenGEM. Code and binaries for all three can still be found online, but development ended by the late 2000s.

Sadly, GEM remains only as a part of computing history.

Now, we will see how we can use some help from the hardware to accomplish the same task: based on the lead byte, calculate the UTF-8 sequence length. I recommend reading my recent post Counting Leading Zeros in a Byte to get familiar with the standard C and C++ functions for counting leading zeroes in a byte and the assembly instructions they use.

We will use a C++ 20 std::countl_one() function from <bit> header to get the number of consecutive set bits, starting from the most significant bit. As we saw in the part one:

• Having 0 set bits on the left side means the most significant bit is zero. If a lead byte starts with zero, it means it is the only byte in the sequence - the length is 1.

• 1 set bit means the byte starts with the 10 sequence - these are continuation bytes, so we report an invalid lead

• 2 set bits mean the lead byte starts with 110; the sequence length is 2.

• 3 set bits mean the lead byte starts with 1110; the sequence length is 3.

• 4 set bits mean the lead byte starts with 11110; the sequence length is 4

• Anything else indicates an invalid lead byte.

Without further ado, here is the code:

#include <bit>
int utf8_sequence_length(unsigned char lead_byte) {
    switch (std::countl_one(lead_byte)) {
        case 0: return 1;
        case 2: return 2;
        case 3: return 3;
        case 4: return 4;
        default: return 0; // invalid lead
    }
}

Note that we do not catch all invalid values of the lead byte here. It is OK, as long as we do proper validation at some point.

Let’s have a look at the generated assembly (clang 18.1, aarch64, -O2 --std=c++20):

utf8_sequence_length(unsigned char):
        mov     w8, #255
        bics    w9, w8, w0
        clz     w9, w9
        bics    wzr, w8, w0
        mov     w8, #8
        sub     w9, w9, #24
        csel    w8, w8, w9, eq
        cmp     w8, #4
        b.hi    .LBB0_2
        adrp    x9, .Lswitch.table.utf8_sequence_length(unsigned char)
        add     x9, x9, :lo12:.Lswitch.table.utf8_sequence_length(unsigned char)
        ldr     w0, [x9, w8, uxtw #2]
        ret
.LBB0_2:
        mov     w0, wzr
        ret

.Lswitch.table.utf8_sequence_length(unsigned char):
        .word   1
        .word   0
        .word   2
        .word   3
        .word   4

Like x86-64, Aarch64 instruction set does not have an instruction for counting leading ones - therefore we need to invert the bits and count zeros. That’s what CLZ instruction does. The switch-case statement generated a small lookup table and there is no branching except to check for the invalid value (something that a branch predictor will be able to deal with).

In the next post in the series, I plan to discuss some benchmarks that compare the three methods of calculating a UTF-8 sequence length.