Netcentric View:

Will Microsoft Win The Embedded Code Quality Battle?

By Bernard Cole
iApplianceWeb
(01/03/02, 03:14:50 AM GMT)

In the battle for the hearts and minds of developers of small footprint control devices as well as information appliances ranging from handheld devices to set top boxes, I'm still betting on the traditional embedded RTOS and tool vendors.

Microsoft has still got a strangle hold on the desktop environment and the developers there, but in the world of connected and distributed computing devices the Seattle-based software firm will always come in second.

Why?

Simple. Even though the company has managed to build a credible embedded, reasonably real-time and deterministic RTOS in its Windows CE platform, it is still most comfortable and effective in those segments of the small footprint device market that bears some resemblance to the desktop and where its traditional marketing expertise can be brought to bear.

Win CE 2.0 is a decent mainstream RTOS for applications that are not too fast, not to demanding deterministically and which do not operate in particularly sparse memory environments. So, I was looking forward to further improvements in these directions with its so-called third generation CE product, code-named Talisker, now called CE.NET.

But that is not likely, now.

Microsoft has revealed its newest embedded strategy and, unfortunately, it is clearly centered around the "richly textured" applications market it defined on the desktop and that's clearly where the company feels most comfortable.

At Microsoft's most recent Windows CE developers conference in Las Vegas, the company delineated a two pronged strategy similar to that developed previously for the Win CE 2.0 and its scaled down Embedded NT product.

Windows XP Embedded offers a minimum configuration footprint of 4.8 Mbytes, going up to 14 Mbytes for a basic Win32 system, and 25 Mbytes for Win32 with security infrastructure. Ultimately, XP Embedded can be larger than 70 Mbytes for the full Win32 API set.

In contrast, Windows CE.Net is expected to offer a footprint of "just a few" megabytes, which makes it more likely to be used in hardware-constrained devices such as PDAs, smart phones, Web pads and basic set-top boxes.

Even though CE.Net is expected to incorporate "only" about 1,800 of the 18,000 APIs contained in Windows XP Embedded, these "embedded" applications had better not be too hardware constrained or Microsoft will not be able to weave the "richly textured" magic spell that has so successfully held users in thrall on the desktop.

Given that reliability and security, especially in the aftermath of Sept. 11, is moving to the top of the agenda as far as net-centric computing applications is concerned, I think that every bit of that 25 Mbytes of code for the security will have to be used in the connected in which CE.NET will operate.

If an application developer is given the option of paring down the code that is not needed in order to make the .NET-enabled smart device relatively memory conservative, a lot of the code that will have to be given up will relate to keeping the connected device secure from hackers.

And every time Microsoft brings that "richly textured" application environment spiel up, it makes me extremely uncomfortable.

It gives me the impression that Microsoft and its developers have not learned the one basic rule that most embedded developers learn in school, or on the first real world application they develop: the more complex the application environment, the larger and more complex the code base. And it follows with the certainty of a syllogism: the more apt there are to be bugs and fixes and bugs in the fixes to the fixes.

No matter how much money a company spends on ensuring the quality of the code there is an irreducible minimum amount of code that will always buggy. While it has not been proven mathematically, embedded developers tell me the best that can be done on the average software project is to reduce the error rate to about one error in every 100 lines of code.

On average large commercial application programs, the error rate is about 20 errors per 1,000 lines and in more sparse embedded environments, that can be reduced to a little under 10 errors or so. The more focused the application, the less feature rich, the higher the code quality.

Thus, Windows 2000, which contains about 40 million lines of code, is estimated to have had about 600,000 bugs, if it is built to the above standard industry quality.

Given that WinXP is about twice that size that tells me that there is the potential for an incredible number of bugs. And as more .NET services are added later, size, application richness and bugs will likely increase.

Embedded XP will probably have far less than the full version. And I accept as a given that the much smaller code size of CE.NET and the extra effort that Microsoft has in recent years thrown and improving the code quality of its embedded OSes means that it will be reasonably free of bugs.

That is not what bothers me. It's that "richly textured" application environment that Microsoft keeps talking about that both embedded XP and CE.NET that is of concern.

For it's the embedded developer, who doesn't have the financial or manpower resources of Microsoft, who will have to come up with high quality code in this fecund application environment.

Even if the company provides an abundance of code test and debug tools, it will still come down to developers spending hours and weeks and months on making sure the code is even half as reliable as the code in traditional embedded applications.

Reader feedback

A good alternative: our third party commercial RTOS vendor provided (for an additional fee) source code, an entirely worthwhile expenditure. We could configure and debug better, effect minor customizations and quickly fix showstopper bugs.

Without that source we would have been hosed.

Steve Peters
Firmware Engineer
Honeywell

Simply put, given that code errors nearly always exist in a product, when I or my customer find one, if it is an error in to OS, it is not acceptable to anyone to say that "Well, the error is in the OS, and microsoft will fix it in its own good time. " Open source is the ONLY way to go. If an error exists it is the only way to say for sure to my customers that I, or someone I can hire, can find and fix it. Some small er RTOS vendors may have better track records at being responsive to fixing OS code errors, I don't believe you could find one with a worse history of resonsiveness than microsoft using its desktop products as a guide.

I am not willing to play 'code quality roulette' with microsoft on MY products.

Richard Fellows
Chief Engineer
Holly Street Networks

Bernard Cole is site leader and editor of iApplianceweb and an independent high technology editorial services consultant. He welcomes your feedback. Call him at or send an email to .

For more information about topics, issues and technologies mentioned in this story go to the flashing icon in the upper left corner on this page or go to the iAppliance Web Views page and call up the associatively-linked Java/XML-based Web map of the iApplianceWeb site.

Enter the appropriate key word, product or company name to list instantly every news and product story, product review and product database entry relating to the topic since the beginning of the 2002.