Some advice for Microsoft: Dump Windows

If Microsoft really wants to get a firm handle on security and shore up their OS offerings, they need to jettison nearly everything under the covers in Windows, and basically write a windowing shell on top of a UNIX-based core, much like Mac OS X. Make it pretty, make it fast, and make it backwards compatible with existing Windows applications via virtualization.

In light of the new Windows flaws announced yesterday, I think it's time to reiterate a point I made a long time ago:

It's time for Microsoft to dump Windows.

In fact, ten years ago would have been a good time to start. At the risk of berating the obvious, it's clear that security will continue to be a major problem for Microsoft. The reason is their tether to legacy code, and their patchwork attempts to shore up their OS core. It's time to let it go.

Apple did it, and did it well. They created a virtualized environment to run Classic MacOS apps in order to ease the transition. When they switched processor architectures, they developed Rosetta, which allows PowerPC apps to run on an Intel platform without modification, again, easing the transition. It can be done. It has been done. It should be done.

If Microsoft really wants to get a firm handle on security and shore up their OS offerings, they need to jettison nearly everything under the covers in Windows, and basically write a windowing shell on top of a UNIX-based core, much like Mac OS X. Make it pretty, make it fast, and make it backwards compatible with existing Windows applications via virtualization.

With multi-core CPUs, ever-cheaper RAM prices, and Vista's already heavy minimum requirements, the time is right. They could launch a whole marketing campaign revolving around the proven security benefits in the new version of Windows, touting "35 years of development!" and make all the UNIX geeks groan.

They could leverage the massive amounts of POSIX code already running on dozens of UNIX-based platforms. This would be a benefit for many software vendors, since the similarities between their platform-specific applications would be significant, and thus reduce development time. Windows would immediately benefit from enhanced security, and the chains of 20 years of questionable code could be thrown off, or at least relegated to a virtualized sandbox.

There would be plenty of work involved in this effort, of course, but given the fact that it's already easy to run Windows apps side-by-side with Linux and Mac OS applications using VMware or Parallels, it's certainly not as large a task as it might seem. They could even write their own X11 clone and have their way with it, like they do with most other existing protocols and frameworks. If need be, they could buy CodeWeavers and use that framework to deliver Windows apps on a UNIX-based core. The options are many, and the need is there.

It would be interesting to see what might happen to Linux and FreeBSD if this were to happen. With Windows joining the party, I could see a legion of open-source coders writing and adapting their code for a UNIX-based Windows, and vice-versa. Hardware vendors would find it much simpler to write drivers that would support Mac, Linux, and Windows.

Microsoft would benefit greatly from enhanced security and a smaller footprint. Developers and vendors would benefit greatly from a simplified codebase, and users would benefit from a wider range of available software, and obviously the enhanced security.

The Internet would obviously benefit greatly from all of these things. In time, even the monster Windows-driven botnets would die, and spam would be reduced.

I ended my last discussion of this topic with a Henry Spencer quote: "Those who don't understand UNIX are condemned to reinvent it, poorly." It's as true now as it was then. It'll be true for a long, long time.

So take the challenge, Microsoft. Innovate. Adapt. Cut your losses. Start replacing your foundation, lest the whole structure collapse.

Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies