Microsoft in the Future: Thinking Ahead on the OS

The ZDNet Duo, Foley and Bott recently elaborated on the fiasco a week or so ago, going more into depth with Mary-Jo Foley's reveal of her data on Midori.

Of course, I will be quick to point out that Microsoft, if it ever plans to make Midori a product, isn't going to do anything overnight, and is thinking way ahead. Just like Microsoft though somewhat ahead with the building of NT. (I will note that NT could have started sooner, but its led Microsoft to have a clear path to upgrade their decrepit piling of code that was DOS/9x, and further Apple's defeat at their hands.)

On commenting on Bott and Foley's articles however, I will now begin. I think there is more then enough room to add some points.

From Bott:

But will Midori replace Windows in the near future?

I will note that he goes on to say no, and that it would co-exist, much like NT did with the 9x line, but I would like to place emphasis on the point that he makes later on, because I feel that it wasn't pointed out quite enough in his article:

Maybe it will make more sense if we give Midori a new name: Windows NNT

Note that Midori, while quite possibly a new kernel for the Windows OS, will in all likelihood have the same name, and a very similar interface.

That said, lets move on to the next point Bott tries to make.

An operating system built on a completely different kernel would, by definition, be frightening to conservative business customers, and incompatibility issues would be legion, by definition.

Of course, I note the business aspect, but I will nit-pick at the incompatibility issues, more on that in a second, as I get another similar subject covered really quick.

And just as in the early days of the NT family, hardware manufacturers would continue to focus their priorities on the mainstream OS, meaning that choices would be more limited for early adopters of the new OS.

Driver issues. The biggest plague known to adoption of any OS. Well this one totally fits into me talking about incompatibility issues.

When Microsoft made Windows NT, they made it so that you could stack new API on top of the core kernel with relative ease. They almost went through with this to the most extreme point, that of the micro-kernel, but they stopped just short of that, making NT a hybrid kernel, much more stable then monolithic kernel alternatives of the time, such as the 9x branch.

When they did this, it made it possible to add Win32 and DirectX over time to NT, allowing for older Microsoft systems to move up. In time other features were added, like SFU, Windows Driver Model, and more recently, .NET and Windows Display Driver Model.

Of course, when NT was first introduced, it had hardware incompatibility due to its use of the NT Driver Model vs. VxD on 9x systems. This goes back to "the early days of the NT family" incompatibility bit Bott mentions, however Microsoft has better developed driver models at this point, going so far as to introduce WDDM recently, in addition to Windows Driver Foundation. These driver models are much safer to implement into a new operating system then VxD was.

Of course, this only solves hardware compatibility issues. There is the small issue of software, as Bott mentions. Microsoft, as always, had and has to keep an eye on this. Here, I'll point out some technologies Microsoft has for virtualization, regardless of whether or not they choose to port API or not. 

• Shims (Microsoft has been using these for years)
• Virtual PC (Virtual Machine)
• Hyper-V (Hypervisor)
• Application Virtualization
• Virtual DOS Machine
• WoW64 (For using 32 bit code on 64 bit)

Any new OS will probably just be able to have API plopped on top of it, but in case Microsoft wants to depreciate one, its entirely possible using any of the above techniques.

Now to move on to what Foley mentioned. I think one line from here sums up her point exactly:

Midori is another attempt by Microsoft to deliver on “Cairo,” Microsoft’s distributed, object-oriented operating system that never saw the light of day.

The distributed part is very interesting, as it fits with the "cloud" that everyone is so interested in, especially with Microsoft's SoftGrid technology that I mentioned earlier.

A micro-kernel is exciting, and I think that this could be exactly what Microsoft is trying to do. If they wanted to go micro, they could just use the NT code base, pushing the last hurrah to fully make it micro.

Instead they are using Singularity (to whatever extent) for this project. The result could still look a lot like NT, but written in an object-oriented, managed code variant.