At embedded conferences and in editorial offices of technical publications, when the question of Microsoft and the future of the embedded industry come up, people often assume that eventually the software behemoth of the Northwest will eventually dominate.
Not so fast. The situation isn't quite that clear cut.
I admit that on the face of it that Microsoft has a huge advantage when it comes up against any single embedded software company, even one, such as Wind River Systems, which still has a healthy 45 percent of the market. With an estimated $10 billion cash on hand, so the argument goes, Microsoft is free to do anything it wants in the embedded market, because even one percent of that reserve is larger than the annual total sales of all the embedded tool and RTOS vendors. And any embedded software company that expected to take the company on, it is argued, is doomed to failure.
But it isn't just Microsoft against one individual OS or tool vendor. Nor is it just one company with three or four OSes versus dozens in the embedded, open source and Linux market segments that the company can pick off individually as it chooses. More accurately, it is a confrontation between two APIs, Microsoft's Win32 on one side, and the API that its competitors share in common, the POSIX (Portable Operating System Interface for Computing Environments) standard.
Designed to promote portability of applications across different operating system platforms the original POSIX standard, first published in 1990, is based on Unix, a well-established technology dating back to the early 1970s. It defines a standard way for an application to interface to the operating system. The original specification defined standard defines interfaces to core functions such as: file operations, process management, signals, and devices. Subsequent releases have also been defined to cover real-time extensions and multi-threading. It is now a family of over 30 specifications for everything ranging from basic operating system services to testing the conformance to the standard.
Virtually all of the major proprietary embedded RTOSes, particularly those aimed at telecom/datacom and networking are POSIX-compliant, including Wind River, Red Hat, QNX, Oncore, Lynuxworks, and OSE. Under the Linux banner are at least a dozen vendors offering various distributions, all of which are either POSIX compliant or compatible. At the server level there are POSIX compliant UNIX and Linux offerings from Caldera Systems' Santa Cruz Operation Server Software Division, Compaq, Fujitsu, HP, IBM, Red Hat, and Sun.
The degree of compliance varies. But many of the software developers I talk to say that code carefully crafted to stick close to the POSIX specification can be ported with varying degrees of ease from one OS environment to another with only the addition of small amounts of additional platform specific code.
Indeed, many of the providers of tools for the various OS offerings take advantage of the commonalities by writing the driver code that ties their tools only very loosely to a particular tool, RTOS or integrated development environment. Longtime developers have told me that rather than go through the time and expense of purchasing a new tool for use in a new hardware or software environment, it's possible with careful analysis, to rewrite the driver code to allow tools to be retargeted. At least one RTOS vendor, Monta Vista Software, offers developers a set of tools to help port code originally developed for Wind River System's pSOS+ to Monta Vista's Linux distribution.
The only major player in the OS market that is virtually non-compliant is Microsoft. Although Windows NT, which is at the core of Windows 2000 and XP, has a minimalist POSIX API (enough to qualify for government contracts) this capability is not included in Windows CE 2.0 and, I assume, is not in CE.NET either. But despite the vitality of the open source/Linux environment and the high degree of code portability between RTOSes, Microsoft is still able to maintain a competitive edge by playing on two perceived weaknesses of its competitors.
The first strategy is to convince engineers that the choice between proprietary and open source operating systems is a black/white, either/or with no possibility of a middle ground. A developer's choice is to use either a proprietary OSes, which while involving initial costs and ongoing costs for development provides the developer with the certainty of support or develop code in an open source environment where there is little or no support and the open source licensing arrangement removes any possibility that the developer of code for Linux can make a profit.
The truth is there is a range of options in between, as long as you remain under the POSIX umbrella. Because of the code portability, a developer can move code from open source to proprietary if there is a need for additional support. And some RTOS vendors offer a range of options. Lynuxworks, for example, offers three different RTOSes with different degrees of Linux and POSIX compatibility: its own proprietary POSIX-based LynxOS; its soft real time Bluecat Linux distribution using the new 2.4 Linux kernel; and its newest Bluecat RT based on RTLinux, licensed from FSMLabs which developed an version of Linux outside of the current open source licensing arrangements.
Such offerings from Lynuxworks and other OS vendors allow developers not only to select the degree of real time they want, but the degree of Linux and POSIX compatibility as well. They allow developers to select the right mix of proprietary versus open source code and the right mix of support that a proprietary OS vendor provides and the higher degree of freedom that Linux offers.
In the Lynuxworks configuration, the small, real-time FSMLabs kernel co-exists with the BlueCat Linux operating system and the combination acts as a multitasking operating system, with real-time requests passed around the Linux operating system to the real-time kernel for immediate handling. The OnCore System's POSIX-based kernel can operate in a similar way with almost any Linux OS.
Aside from giving developers real time, deterministic operation in a fully Linux environment, the same configuration can be used, developers tell me, to carefully delineate between code they don't mind operating under the open source licensing arrangements and code that they want to retain as proprietary. Hardly the stark either/or dilemma that Microsoft suggests.
Where Microsoft does have a real edge is that despite the underlying compatibility of most POSIX compatible proprietary and open source OSes there are troubling differences between the various distributions of Linux, for example, as relates to programming interfaces, especially in the embedded environment. The industry has formed the Embedded Linux Consortium to resolve such differences. On the POSIX side, there are further moves toward standardization, with the Embedded Linux API based on POSIX (EL/IX).
Another place where Microsoft could gain an edge is in tool support. Unlike the single tool environment that Microsoft offers, the embedded software is amazing diverse, to its disadvantage. The one common link between the various embedded environments is, of course, the open source GNU tools, which are supported and enhanced not only by individuals but by major Linux providers such as Red Hat, Inc. There are also efforts in the open source environment to develop generic IDEs such as Mono and dotGNU. Most recently, IBM Corp., a major supporter of Linux, upped its commitment with the donation of $40 million of Java-based open source software to a new independent open-source community, Eclipse.org to enable the use of software from multiple suppliers. The new organization, consisting of IBM, Borland, Merant, QNX Software Systems, Rational Software, RedHat, SuSE, and TogetherSoft will manage the manages the Eclipse Platform, which is being made available in open source under the Common Public License.
All of these developments tell me that Microsoft will not have an easy time of it in any segment of the embedded and net-centric control and computing device market in which it chooses to participate. What do you think?
Bernard Cole is the managing editor for embedded design and net-centric computing at EE Times. He welcomes contact. You can reach him at or 520-525-9087.