Midori: Modular by Design

This afternoon, SDTimes published the first of three stories on Microsoft operating system Midori. Reporter David Worthington scored some internal Microsoft documents, which sent Microsoft's PR team into absolute panic.

Within the last 24 hours, several reporters received calls from Microsoft PR to see who knew what and to find out where the leak is. I didn't get a call, even though I know David. Maybe my Waggener Edstrom-compiled dossier is incomplete?

Information has been dribbling out about Midori for months. But SDTimes offers the most comprehensive information so far publicly released. It's cautiously presented, perhaps so David can protect his source(s) and write three parts (I joked over IM that he's a "click whore"; it's the way of Web journalism, I guess). There's great reporting here. David has done much more than use the cut-and-paste approach someone else might have taken.

"There were no dark garages involved," David said about obtaining the documents, referring to Watergate and Deep Throat.

David's story is both disturbing and encouraging for what it reveals about Midori, and that's on several levels. Disturbing: Microsoft's ambitions, which remind one of failed projects Cairo and WinFS. Encouraging: The modular and connected design approach, among other aspects I'll get to in a few paragraphs.

GOT A TIP OR RUMOR?

Presumably, Midori is based on Microsoft Research project Singularity. Eric Rudder (remember him?) is rumored to be leading the Midori project. Eric was one of Microsoft's rising stars until he got moved up and over during a major reorganization nearly three years ago. On the Microsoft org chart, Eric reported directly to Bill Gates, at least before the chairman's semi-retirement on June 30. Eric, what are you up to now?

I'm cautiously encouraged by what SDTimes published about Midori. In March, I opined about what should be Microsoft's priorities for Windows 7. Based on the leaked information, Midori encapsulates the architectural changes I identified as most important for the next Windows version:

• Modularity
• All-device support (in one OS version)
• Connectivity/networking
• Synchronization
• Backward compatibility (through virtualization)

Most important: Starting over, with a fresh operating system.

I wanted to see dramatic changes in the next Windows version—the operating system needs them. The big changes are coming later, looks like, but Midori doesn't yet have a time horizon, if it's even an operating system that would be released. Many Microsoft research projects brightly burn and then they burn out. Midori should be different, for conceptually it's so promising. Microsoft needs to bring something like this to market.

This afternoon, I asked Microsoft for comment—and, better, for an interview—about Midori. But instead I got a canned statement, which, by the way, uses "incubation" to describe Midori: "Microsoft is always thinking about and exploring innovative ways for people to use technology. Midori is one of many incubation projects underway at Microsoft; as such we are not talking about it at this time."

Below, I will match my recommended design priorities with what David reveals about them in Midori and explain why they are important.

Fresh start. David describes Midori as a "non-Windows operating system." It's about freakin' time. Midori isn't a new version of Windows. It's a new operating system, built fresh from the kernel up, according to the SDTimes story.

Windows architecture predates the Internet. The architecture simply wasn't designed for the connectivity, networking and security demands of the Internet, particularly in the 21st century where information spreads out across multiple cloud computing services and user devices.

Microsoft should have started fresh long, long ago. But the company's obsession with backward compatibility—a priority miserably failed with Windows Vista—acted as a deterrent to change. A new start is the right approach, and, whoa, will it be new.

David writes: "At its lowest level, Midori has two separate kernel layers: a microkernel comprised of unmanaged code that controls hardware and environment abstracts, and higher-level managed kernel services that provide the full set of operating system functionality."

Virtualization. Microsoft isn't giving up on backward compatibility but doing what I've been asking for since the company bought Connectix in 2003: using virtualization to provide backward compatibility between a new operating system architecture and an older one. Unfortunately, David won't reveal how Microsoft will use virtualization for the Windows-to-Midori migration until his second story. But I commend the concept. Microsoft has the technology to make it all work.

Modularity. "Unlike Windows, Microsoft intends for Midori to be componentized from the beginning." Finally! Microsoft moved down the modularity path with Windows Embedded, ending, so far, with Windows Server 2008. The current marketplace demands modularity, for lots of reasons. Among them:

• Providing a single, secure, manageable operating system for all devices
• Scaling across multiple devices and SOAs (service-oriented architectures)
• Writing software once, rather than porting different versions to different devices, platforms or service topologies

Simply stated: Modularity is one of Midori's most important design principles. None of the other design principles effectively work without the modular, or what Microsoft calls componentized, approach.

Connectivity. Midori shares a common goal with the first real version of Windows, NT. But the scale dramatically differs. Microsoft designed Windows NT to be connected across corporate networks. That connectivity would later pose some security challenges as corporate networks connected to the Internet. Midori is much more about connectivity, regardless of device or even underlying architecture. Midori is designed to live on the Internet, to be connected.

There's something agnostic and not (more on the not in the closing paragraphs) about Midori, at least the conception revealed by SDTimes. David writes:

Midori will be built with an asynchronous-only architecture that is built for task concurrency and parallel use of local and distributed resources, with a distributed component-based and data-driven application model, and dynamic management of power and other resources. Midori's design treats concurrency as a core principle.

He continues:

The Midori documents foresee applications running across a multitude of topologies, ranging from client-server and multi-tier deployments to peer-to-peer at the edge, and in the cloud data center. Those topologies form a heterogeneous mesh where capabilities can exist at separate places.

Conceptually, the approach is very forward-thinking and anticipates distributed, cloud and services-oriented computing demands that already tax the PC client-server model. The leaked documents repeatedly refer to the importance of "concurrency," according to SDTimes. "Midori will have provisions for distributed concurrency—or cloud computing—where application components exist in data centers."

Whoa. But, damn, it's ambitious, too. Microsoft projects Cairo and WinFS both failed, and their data storage models would have brought some of these same capabilities. Concurrency and connectivity are sensible topologies. But can Microsoft really deliver them? There are reasons why Midori is still an incubation project.

Device support. Midori's connected and concurrent topologies directly relate to hardware devices. David explains:

Users move across multiple devices, consume and share resources remotely, and the applications that they use are a composite of local and remote components and services. To that end, Midori will focus on concurrency, both for distributed applications and local ones.

I won't separately call out synchronization, but incorporate here. What the above quote really means: Microsoft's concurrency topology would make personal or professional information available everywhere people need it. The seeds of this concept can already be seen in Live Mesh. Data changed on support device A replicates elsewhere.

If that's so, I have to ask: How many of the Midori concepts are already part of Microsoft's forthcoming services platform? And how different are they? David's leaked information about Midori reads very much like what I would also expect from Microsoft's SOA. If they're not one and the same, then Midori may be more than a Windows successor by a future iteration of Microsoft's SOA platform.

Services architecture. I'm throwing this one in as an extra because it's potentially troubling or exciting depending on perspective. David writes: "Midori's applications would be created using .NET languages that will be compiled to native code using the Bartok compiler and runtime system, which is presently a Microsoft Search project."

Midori would embody a .NET-language-based "type-safe abstraction set" that "will eliminate an entire class of programming errors that stem from bad pointer arithmetic, enable the changing of the boundaries between privileged and unprivileged code, and provide for universal application analysis and instrumentation, Microsoft reasons."

For some developers, the approach could mean cleaner code more easily written. But the architecture means something else: Microsoft would more deeply bake .NET into the operating system architecture and extend it to many more devices and services. If I read this rightly, .NET literally becomes the Net, from a development perspective. Such an approach would make Microsoft's bundling the browser into Windows—an act that drew a U.S. government antitrust lawsuit—seemingly inconsequential. Midori's .NET bundling would reach across a vast Internet landscape of devices, development topologies and SOAs. To repeat: .NET would become the Net.

[Please send your tips or rumors to watchtips at gmail.com]