My fight with Microsoft: why APIs need to be free

With Oracle choosing APIs as a legal battleground on which to tangle with Google's Android, I'm reminded of another time when APIs were used in lieu of competitive products in an attempt to control a marketplace.In another life, I was a software developer.
Written by Rupert Goodwins, Contributor

With Oracle choosing APIs as a legal battleground on which to tangle with Google's Android, I'm reminded of another time when APIs were used in lieu of competitive products in an attempt to control a marketplace.

In another life, I was a software developer. It was a long time ago, back when MS-DOS was alive and well and Windows was still just another DOS app, and when Microsoft was much more of a bogeyman than it is today. In the mid-80s, it seemed as if nothing would shift the Redmond giant: it was a commonplace that there was little point in launching new software, because if you were successful Microsoft would find a way to steal your market - and if you weren't successful, why bother?

I was working as an x86 programmer for a small start-up with big ideas, and we had no truck with such defeatist talk. Our self-imposed task was to build PC network hardware and software costing a few pounds rather than the £100+ that was the normal premium. While the hardware side had its own challenges — mostly revolving around the many different interpretations and shortcuts PC makers took with the 'standard' expansion bus — the software aspect smacked straight into Microsoft's questionable practices.

Our software had to work with MS-DOS, which from a programmer's point of view was mostly defined by an API that covered things like opening and manipulating files, starting programs and so on. MS-DOS back then was a pretty dumb beast: developed conceptually and practically as a single-user, single-task operating system, it primarily assumed that one piece of software would be running at one time. It could do more than one thing at once, but crudely: you could leave fragments of software in suspended animation and have them woken up by various events.

Networking software needs to run independently of anything else going on in a computer, because you don't know when a packet's going to arrive containing information or a request that needs to be acted on. That means, among other things, having the ability to read and write files. It was acceptable to wait for other file activity to finish before leaping in: in fact, you had to. If you overlapped file operations, MS-DOS tried to use the same internal buffers for two things at once. There was a good chance you'd mess up your disk contents — and we knew that even if this was because of limitations in MS-DOS, we'd get the blame.

Microsoft did not want competition, especially in areas where it was explicitly trying to keep third parties out.

The technical term for this problem was a lack of re-entrancy; once you were in a file operation, you'd better not re-enter the same bit of the API. Fortunately, MS-DOS had a 'safe to proceed' flag in memory called InDOS; you checked this, and if it was clear you could do your file work. If it wasn't, then you back off and try again later. Unfortunately, this wasn't specified in the MS-DOS API: everyone knew the flag was there, but Microsoft refused to officially admit it. Without it, you couldn't write safe multi-tasking software that did anything but the most trivial of tasks. Stick to the API, and you can't sell a safe network. Take over aspects of the API, and you can. (Although MS wouldn't discuss this at the time, the general consensus was that this extremely important piece of MS-DOS functionality was being kept semi-secret because it gave Microsoft a big advantage in writing application and system software.)

To fix this, therefore, we took another piece of third party multitasking software, Borland's Sidekick, and disassembled it. That told us where to look inside MS-DOS for the secret flags; we then wrote various bits of code that mirrored and manipulated the MS-DOS API so that it looked normal to application software even when things were happening over the network. As well as solving the re-entrancy issue, this meant that apps could open, read and write remote files while thinking they were dealing with vanilla MS-DOS: the operating system had no support for this at all.

Clearly, Microsoft did not like this. It did not want competition, especially in areas where it was explicitly trying to keep third parties out. Equally clearly, there was nothing the company could do: it warned darkly that because InDOS wasn't documented it could change and break everyone's software. We ignored that warning, partially because we thought that Microsoft wouldn't risk creating a version of MS-DOS that behaved so badly (this was before MS-DOS 4, which did break existing software through incompetence rather than conspiracy) but mostly because we had no choice.

If, however, the MS-DOS API had required a licence for use, there would have been plenty the company could have done — in licensing conditions, in watertight specifications, in effectively forcing approval of software. Competition such as Digital Research's MS-DOS compatible DR-DOS operating system would have been impossible (Windows did 'break' on top of DR-DOS, this time due to conspiracy rather than cock-up, and Microsoft ended up paying more than a quarter of a billion dollars in out-of-court settlement as a result).

Our network didn't set the world alight (although an early version which used telephone cabling did set our test network PCs on fire after an incident with a packing tape gun and some mains wiring: we learned from that why the Ethernet standard included serious electrical isolation), but the company did well enough to develop other, less combustible, products. We were never a competitive threat to Microsoft, feeling that if Redmond did want to treat us like a competitor it might at least have the decency to make some cheap networking products of its own instead of telling us we shouldn't be doing it.

I felt shabbily treated by Microsoft and became, briefly, a bit of an Apple fan (oh, the irony). In retrospect, the experience accounts for a lot of my bias towards open standards and honest ecosystems. It certainly informed my reaction to any big company when it cites morality and just reward for hard work as a reason for attacking competitors, even more so when it tries to use the law in ways that don't pass muster.

If you want to compete, compete. If you don't, let others do what they have to.

Editorial standards