For novel ideas about building embedded systems (both hardware and firmware), join the 30,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
By Jack Ganssle
Open Source Windows
How would you like to read the Windows source code?
I'm not a Microsoft-basher. IMO Windows was largely responsible for unifying the PC market and making cheap computing ubiquitous. But I'm as fed up as most users with crashes, device driver incompatibilities, and all of the rest. As I write this a new as-yet-uninstalled firewall package glares from the desk, daring me to start the installation. I've put it off for weeks, knowing there's probably 4 hours of utter frustration and more than a dose of magic needed to get the damn thing working. Despite the hassles, though, I do acknowledge and appreciate the graphical desktop that's so much easier that the DOS, CP/M, and punched card days of yore. Microsoft deserves acclaim and profits for their vision and even more so for their persistence in transforming a quite awful Windows 1.0 to today's many useful versions.
I've often thought that the appropriate remedy for the Microsoft vs. Department of Justice dispute would be to make all versions of Windows open source. The tens or hundreds of millions of lines of code would be so overwhelming it's doubtful there would be any negative impact on Microsoft's business. But the scrutiny of developers could only lead to enhanced, more reliable products.
Of course, such a program would be entirely unsuccessful without a sea change in the company's approach to users. They'd have to embrace input from developers.. That might be a hard cultural shift.
Recently Microsoft entered the "open source" fray by making the source code to key components of Windows CE publicly available. It's a breathtaking step for a company that traditionally regards their source as a trade secret. See the press release at http://www.microsoft.com/presspass/press/2001/jul01/07-24AcademiaPR.asp, and go to http://www.microsoft.com/windows/embedded/ce/tools/source/default.asp to get the source code itself.
The released Windows CE code is distributed under its own special license (http://www.microsoft.com/windows/embedded/ce/tools/source/license.asp), which does not look much like those advocated by the Free Software Foundation (http://www.fsf.org/licenses/licenses.html) or other true open source purveyors. You can't distribute the code for commercial purposes at all. Avoiding philosophical debates about open source versus proprietary code, the fact that Microsoft believes in the latter means they must have distribution limits.
I have to praise Microsoft's legal approach. The GNU General Public License is partially manifesto, and largely tells you what your freedoms are. But it's 2970 words, 5 pages of dreary flag-waving. In contrast, Microsoft's license is a mere 291 words, written without a hint of legal jargon. Though considerably more restrictive than the GPL, the CE license is so concise and well-written that I can tell what the issues are at a glance. A refreshing change from their past practices.
Metaphorically rubbing my hands in anticipation I delved into the source, trying to get a sense of how Microsoft writes code. An avalanche of books from Microsoft Press leads one to believe the Company pioneers clean software engineering, and I wanted to see just what their code looks like.
A quick search for the four letter words all too often tossed into code in the frustration of mid-project problems (including "Bill" and "Gate"s) yielded zero hits. Given that many developers were involved either they have stringent standards for politeness or someone cleaned things up pre-release.
The supplied 120,000 lines of code is far too much for me to evaluate, so I examined about two dozen modules, and found the code varies from occasionally beautiful to a convoluted mess. I was disappointed to find there's clearly no common software standard. Some modules are nearly devoid of comments (one has 44 single line comments for 1600 lines of C); others exhibit the reverse ratio. One assembly routine with but 7 instructions has 127 useful and informative comment lines. An inspired bit of software.
In some places you can almost feel where a valiant effort was made to achieve some level of consistency. But then old, bad habits creep in and the goodness dissipates as functions drag on in length and complexity. And they do drag on. We know that no function should exceed a single page, yet some seem to rival War and Peace in length.
Many modules and functions unbelievably haven't a single descriptive header, leaving the reader to guess what the silly things do by reading unclear code. The header files are rife with undocumented constants and typedefs. Even the copyright message varies widely from module to module. Does anyone read this stuff?
And why does the company persist in using cryptic three and four letter file and directory names?
To be fair, I read a lot of code from many different companies. The CE software looks no different than the vast majority of what I see. No better, no worse, and no less inconsistent. However, in my experience, when developers take the effort to build beautiful code, they also generally create correct code. CE is positioned as a fundamental building block of big embedded systems. That demands a level of reliability far beyond what's expected on the desktop. Is this stuff correct? Is it reliable? Clean it ain't.
It is possible to write great code, consistently. Check out http://sources.redhat.com/ecos/, the source to the eCos RTOS, or http://www.micrium.com for the source to uC/OS. Both are about as close to poetry as software gets. Both show consistently beautiful code, written to a standard. uC/OS is now certified to DO-178B so is also correct.
That's the way code should be.