Microsoft Maps Out Migration From Windows - Systems Management News On The Web

CHANNELS

ON THE WEB

PRINT EDITION

BZ MEDIA

AS OF 8/20/2008 9:22AM EST

Microsoft Maps Out Migration From Windows
By David Worthington, special to Systems Management News

July 31, 2008 — At the risk of undercutting one of its core product lines, Microsoft is carefully conceptualizing a way to move millions of users away from the existing Windows codebase and onto Midori, a legacy-free operating system that it is currently incubating in its skunk works.

SD Times has viewed internal Microsoft documents that reveal the company’s preference of an orderly replacement strategy rather than breaking sharply with its past.

The company is acutely aware that Windows is installed on the majority of the world’s computers and has a broad legacy of applications and devices—one that carries with it a lot of value.

But heritage comes at a price: Evolving Windows to meet new opportunities is a costly proposition. “Legacy support is a huge anchor on Windows,” remarked Larry O’Brien, an independent analyst and consultant who writes the Windows & .NET Watch column for SD Times.

To read details about Microsoft's post-Windows operating system, click here.

According to the documents, the company plans to create Midori’s “legacy-free bubble,” both at the programming model and at the user level. The models differ in the degree to which Midori and Windows coexist, and virtualization could wind up in the mix.

Microsoft’s desire for legacy support has twin roots: It needs to establish a migration path that offers comfort to its customers, while avoiding the pitfall of users implementing virtualization to run other operating systems that would perform tasks better than Windows can. Such a future runs the risk of relegating Windows to the role of a co-resident installation that executes legacy applications.

Virtualization creates a motivation and need for Microsoft to do something to take back the initiative—and none too soon, said Jeffrey Hammond, a senior analyst with Forrester Research. “It may just be the developer crowd I run with these days … but I see more Macs in developers’ hands [today] than at any time in the last 18 years,” he added.

The documents describe the legacy-free objective as being a preemptive strike against non-Microsoft operating systems, enabling the company to compete head-on by enticing customers to replace Windows with Midori instead of a non-Microsoft OS.

As first reported by SD Times, Midori is being designed as a componentized OS and can run directly on native hardware (x86, x64 and ARM), be hosted on the Windows Hyper-V hypervisor, or even be hosted by a Windows process.

The Microsoft documents propose three possible ways for Midori and Windows to work together. The first, and perhaps most complex, has applications that run on both Midori and Windows by following a program model that operates similar to Microsoft Research’s Accelerator project. Applications in the Accelerator model execute some parts of applications under Windows threads while executing others on the GPU via a DirectX device driver. Windows wraps the GPU’s hardware resources into that device driver.

Under this scenario, Windows persists as the predominant Microsoft OS, and the Windows Executive, which manages exceptions, stacks, threads and other core constructs, would be extended to support Midori as a subsystem. But doubts remain about the technical implications of that choice.

Microsoft would, as part of this scheme, create a Windows device driver to execute Midori code under Windows, with dedicated hardware resources and rudimentary OS facilities such as Midori’s scheduler and threading model, which enables concurrency. The low initial investment of this driver-based approach to compatibility has its appeal, but the company believes that running a full-featured operating system as a driver would be unwieldy, given the baggage of integrated debugging, its own IO system and its own user interface. Another drawback, noted O’Brien, is that this really doesn’t fit with the line-in-the-sand mindset toward legacy code that Midori is supposed to represent.

A second approach to Midori would fork the executive responsibilities and require the development of an executive for Midori that is based on and would run in parallel with the Windows Executive. This has the advantage of not having to create the Midori Executive from scratch, but maintains the conundrum of trying to run a legacy-free bubble inside of what remains legacy code.

The Midori documents noted several other disadvantages to that approach, including the challenge of assigning resources to the two operating systems. O’Brien pointed out that such an approach would also require some sort of coordinating super-system, which might have to be written from scratch.

The most radical suggestion involves writing the proposed Midori Executive itself from scratch, which would transform the bubble into a truly legacy-free platform. But again, noted O’Brien, Midori would have to have something along the lines of a hypervisor to allow it to run in harness with Windows, which brings its own complications.

“The idea of using a hypervisor to act as a kind of meta-OS coordinating the legacy Windows code base and the legacy-free bubble is elegant,” commented O’Brien. He noted that certain critics might draw parallels between the challenges of implementing some of the aforementioned scenarios and Microsoft's repeated failures to deliver its often-promised Cairo and WinFS distributed object-oriented file systems.

The Midori documents also address device driver compatibility, suggesting that it would be possible to have Windows wrap legacy drivers as services, then use cross-OS communication for device access while keeping a strict separation between those services and Midori’s device drivers.

Furthermore, one of the design goals for Midori is to isolate device drivers from the OS. The company is undecided on at least two driver issues: whether device drivers should be written using managed techniques, and whether to build them with a language that lends itself—at least in part—to static analysis. In both cases, increased reliability is the objective.

In the discussion about drivers or the applications that use them, the Midori documents indicated that some internal controversy remains over the degree to which the company can ignore backward compatibility. They indicated that another of the Midori design principles is that the projected OS should be in no way watered down by a commitment to the Windows legacy.

Microsoft Executives Talk Competition

Microsoft Hits a Home Run But Misses Mark With Earnings

VMware Shakeup Reflects Shrinking Lead

And it is possible that “legacy Windows” may persist in some form or another. The documents suggested that sharing source code for key subsystems between Midori and Windows might be preferred to their duplication, but that approach would have its own set of concerns about overall system reliability.

Another suggestion found in the Midori documents involved porting over some Windows code to bootstrap the refresh effort, temporarily sacrificing some benefits to ease the migration.

Likewise, the company proposed a method that would make it possible to write code that can be compiled for either OS in a manner reminiscent to Mac OS X’s Universal Binary option. But that approach also risks compromising Midori’s approach to secure programming, as well as adversely impacting exception and memory management, according to the documents.

Taking it at face value, Midori is an astonishingly ambitious undertaking, even for Microsoft, said O’Brien. “Evolution towards an OS suitable for the ‘manycore’ era would be tough enough, but [the documents] are very aggressive, essentially saying ‘Take it in one bite!’ ”

Related Search Term(s): virtualization, Windows, Microsoft

EMAIL THIS ARTICLE

SEND FEEDBACK