Midori: The "Post" Windows OS?

The big excitement in Microsoftland this week has been further news of Midori. Midori is claimed to be Microsoft's "post-Windows" operating system—a new platform for the future. The SD Times claims to have seen internal Microsoft documents describing the company's plans for the new OS, and it says that Midori will be a commercial derivative of the Singularity project. Say hello to a cloud-computing-ready .NET OS.
Related Stories
Midori: a non-Windows OS in the works, not just experimental
Dreaming in the cloud
Singularity's big feature is that it is written in managed code. While Midori looks to follow suit, it is also written for a cloud computing world. Microsoft has already spoken of its plans for cloud computing; in particular, the company plans to introduce tools to enable cloud computing applications to be written as easily as normal applications are today. Midori will offer the same; the Midori platform will give developers the basic tools to write applications that can be run in massive parallel and that can withstand unreliable communications.
Parallelism is, of course, a key constraint for future software. Constrained by escalating power consumption, CPU vendors are no longer giving developers "free" single-threaded performance, but multiple cores instead. Though single-threaded performance is still making modest improvements, they're small compared to the potential improvement seen in going from two to four to eight or more cores.
Cloud computing provides immediate access not just to a handful of cores, but to hundreds or thousands. Cloud computing also introduces unreliability; network connections can become slow or go down completely, so cloud software must be built to tolerate this, for example by retrying jobs performed on CPUs that have become unavailable.
Why they named it after bright green booze, I have no idea
Problem one: compatibility
Midori is also claimed to offer an upgrade path from current Windows. As well as running directly on hardware like a normal OS, Midori will be able to run under the Hyper-V hypervisor, coexisting side-by-side with Windows and Linux. It can also be run as a process on a Windows machine.
Initially, then, Midori might work as just another Windows program used for cloud applications. As Midori applications become more abundant and can be used for more day-to-day computing tasks, it can run as a complete OS under Hyper-V, so the machine would be shared between a (legacy) Windows virtual machine and a (new and shiny) Midori VM. Further still into the future, as Windows applications become less and less necessary, Midori can be run as the sole OS on a machine, with the occasional Windows app relegated to a virtual machine.
It's clear that Microsoft needs a long-term plan for its OS. Although the company is still utterly dominant in the desktop operating system market, the future is murkier. In the short term, Microsoft cannot let the problems that plagued the development of Windows Vista recur. Mojave stunts aside, Vista has failed to win over consumers.
Perhaps more importantly, it failed to deliver what MS had planned for the release. The early software released to developers in 2003 used managed code far more extensively than Vista actually has; plagued with bugs and compatibility problems, virtually all of the managed code was eliminated from Vista.
Problem two: parallelism
Longer term, the shift to multicore processors (and eventually to massively multicore, with tens, hundreds, even thousands of processors) will need a significant change from both software developers and OS vendors alike. Parallel programming is complex at the best of times; traditional approaches to software development make the problem even worse.
For example, programs today typically depend on having a certain amount of information that is shared between different threads and, generally, that information can be updated. This is unproblematic in a single-threaded environment, but when multiple threads are used, the developer must ensure that no thread tries to use the information during an update.
This is done by locking and unlocking the shared data, and improper use of this locking is a common source of bugs in multithreaded programs. It is also a cause of performance problems, and is one of the reasons why a quad core processor is rarely four times faster than a single core processor.
A platform for the future
Microsoft's long-term operating system goals must address both of these problems; MS needs a platform that it can modify to address new needs without being hamstrung by compatibility. It also needs a platform that will make things as easy as possible for the increasingly parallel computers that are now inevitable. Although parallel programming will always require some input from the developer—the fundamental complexity of doing several things at once will never disappear, and there's no silver bullet—the system must make this as easy as possible.
Is Midori that long-term operating system? Well, it certainly does some of the things that a future Microsoft OS should do. The safety and portability of managed code would eliminate many of the security flaws that still regularly crop up in software. .NET already makes these bugs impossible; Singularity and Midori perform even greater analysis of software and prohibit even more bugs. To help address problems with parallel programming, Midori's programming model uses immutable data; immutable data can be shared without locks and so prevents lock-based bugs from ever occurring.
Another way in which Midori is engineered for high concurrency is through an asynchronous architecture. Current OSes are usually largely synchronous; that is, whenever software asks the OS to do something (read a file from disk, send data over a network, etc.) the software must wait until the OS has completed the action. With an asynchronous design, the OS returns control to the software immediately, allowing the software to do useful work while waiting for the OS to finish the operation it was asked for. When the operation is finished, the OS notifies the software.
Although sometimes the software has nothing to do until the operation is complete (if it needs to know what data is in a file before it can proceed, say), this is not universally true. For example, writing to a file is something that can often be done asynchronously. Allowing applications to keep running even when long-running operations are going on in the background, and using notifications when those operations are complete, can give asynchronous programming significant performance improvements over synchronous equivalents.
The downside is that asynchronous programming tends to be more complex than synchronous programming, because it often makes it difficult to tell which order the different parts of a program will run in; it makes the program's structure harder to see and understand. .NET provides good support for asynchronous programming already to try to reduce the inconvenience, and it is likely that Midori would have further improvements to make asynchronous development easier.
The ability to run Midori as a process on existing Windows systems is another strong point in its favor. This provides a clean migration path, allowing Midori applications to run alongside Windows applications, which is essential for any post-Windows OS.
Dead end or huge hit?
Although Midori has some compelling features for a "next" operating system, it's premature to proclaim it to be the post-Windows OS. Going to an all-new OS means sacrificing both the hardware and software support that Microsoft has been nurturing for the past 20 years, and that's a very high price to pay. The pain of losing the software can be mitigated by virtualization—Apple used a similar approach to support legacy Mac OS applications on Mac OS X—but hardware support is a bigger problem; the only way to support hardware in a new OS is to persuade hardware vendors to write new drivers. That's hard enough for a new version of Windows, let alone a whole new OS.
The current Windows code has also had a vast amount of real-world testing; though it's not perfect, it works well in a huge variety of configurations and workloads, and giving this up is sure to give Microsoft pause for thought.
Microsoft runs many software projects for research and experimentation purposes. Microsoft has formally admitted only that Midori is an "incubation project"—an internal project that may or may not result in an eventual commercial product. As such, Midori could be anything from a complete dead-end, to the OS 95 percent of the world will be running in five to ten years.
I suspect that the truth will lie somewhere in between; a future Microsoft OS will use virtualization to provide backwards compatibility, and that future OS will use managed code. Finally, the asynchronous, networked, fault-tolerant parts will materialize within the next year as part of Microsoft's cloud computing initiative—a software platform, libraries, and tools. Indeed, this cloud computing platform might be Midori.
Harder to believe is that these ideas will be combined to make the future OS, and that the future OS will be fundamentally designed for cloud computing. Microsoft might want—need—a new OS, but betting the farm on the clouds in the sky is a risky gamble.

Source: Arstechnica.com by Peter Bright.