Architecture of Windows 10

One of the reasons why so many developers do not understand how the Windows Runtime works (other than looking into its rather sparse documentation) is not just because the tooling and language “projections” do really obscure the underlying platform. No. The real reason is: there is no clear and detailed Windows 10 blueprints. In other words: There is no officially supported, published and reviewed, Windows 10, detailed architecture available.

Why the Architecture?

So who cares about this Architecture “thing” anyway? Simple answer: you, the software developer, should care. Architecture is imposed on you. You do suffer (for many years) or possibly enjoy Windows Architects decisions.

2015 Win10 example: it turns out that for some reason inheritance has been chosen (by Architects) over aggregation in WIN  RT API and especially so in it’s implementation patterns. And then, in the same time, while learning WIN RT API, one is faced with effectively not having interface inheritance in new IDL?  What?! Why?

Well, some Windows 10 Architect (I hope) knows why. But who she is? Where are they? Who do you call for real fundamental and necessary details, if you want to really understand Windows 10 API?

Architecture tells us WHY has something been done or not. Not HOW and not WHEN and not WHO …

“How” might be answered by technical or application Architect. But that is way bellow top level Windows 10 System Architecture we are talking here. Technical/Application Architect is more of an organizational tag for an important role of a senior developer.

Channel 9?

“Channel 9” is full of Architecture. Will it help perhaps, to follow all those Architects over there? Perhaps it will. But none of them clever MSFT Architects, never ever really answers that proverbial “Why” question. Although, as a matter of fact, nobody is asking them. Especially not on Channel 9. And that is funny.

MSDN?

OK then, who else can help and is now over there on the surface of the MSDN ocean? There are indeed guys (possibly called Application Architects) who can show you how actually WIN RT API works. In a great detail, too. How COM is back into the lime light, and HOW C# now understands WIN RT components written in modern C++. As an good example, Kenny Kerr is rather insightful and talented guy. But Kenny just delivers the HOW. Kenny never asks or answers WHY.

Why is Architecture important?

Because (among few other reasons) Architectural decisions are impossible to change after implementation milestone has been reached. Which makes them very important. And in case of mistakes, very (very) expensive.

Paradoxically non existence of Architectural decision is one fact impossible to change. And neither of the two (decisions) is good information to publish. Especially not good for shareholders and the company income.

Existence of Architecture is important, but non existence of Architecture is even more important

How so?  Here is one example. Windows “zero” was quickly built as an MS DOS add-on. Built. Not Architect-ed, designed, built, tested and then again to cycle 2 and the next cycle and so on. The fact that WIN 0.x was never Architect-ed is one fact almost impossible to deny. During last 30+ years, I do not remember anyone has ever tried to deny this. So After 30+ years I will call it a fact.

Thus it is very hard to defend against the claim that Windows 1.0 has generated one enormous technical debt.  Therefore. Publishing Windows 10 (or whichever) blueprints right now might actually break Microsoft. How?

Remember this is not a source code we are talking about here. We are talking about Windows 10 System Architecture. Detailed OS Architecture is a blue print, not a source code. Skyscraper is built by producing (very) detailed blue prints, finished before actual building is built ¹.

Existence of Windows detailed architecture published will allow experts to quickly reveal the weak points. Wit the dates. The nightmare details. Inherited all the way back from Windows 0.x.

The speculations from last 30+ years (if that release happens) will quickly transform into facts. People will be able to see there was no Architecture BEFORE Windows 1.0 was ever built. In a way, Windows is one huge multi decade long struggle for hundreds (thousands ?) of good developers. And many  (many) more architects and developers know that. But. There is no detailed published Architecture available and all is just (carefully kept as) one big speculation. We all know they (MSFT developers) are working hard and they are working for years, on each new Windows release. But nobody is telling us, what exactly seems to be the problem, and most importantly why. It is impossible to argue, without Architectural blueprints. No blueprints no discussion.

Why COM (again) ?

Based on this swampy, erratic, shifting grounds is “tower of” COM. Beside WIN NT, COM is one huge achievement in long history of Windows struggle. Let me put it into perspective for you: COM is like deep sea oil rig that has never been broken. Something that is virtually unheard of. And crucially:  each deep sea oil rig improvement always starts by revisiting its architecture. One luxury that (I assume) COM architects have not had.

COM is one Windows subsystem we know a lot of about, and into which we implicitly trust, because Microsoft obviously trusts into COM. We know a lot about COM, but (again) we do not know: WHY. There are no COM blueprints published. No detailed COM System Architecture.

COM “material” is thus an good example of how very carefully Windows Architecture bits and pieces are sanitized and then  released into the “wild”.

Summary

Perhaps some of my older audience remembers Tanenbaum and his “MINIX” OS. Mid last century, people realized computers might become personal. Academia got interested in the challenge, and has produced  OS-es to utilize those little personal computers. People discussed them, re-architect-ed them OS-es, and so on. That has greatly influenced one young Linus Torvalds who has afterwards developed LINUX.  This is how software systems and especially the most complex ones called “operating systems” are and should be developed. Architecture driven, developers built.

And  what about Windows? There is no Academic proof of quality or correctness of WIN Architecture because there is no WIN Architecture to see. It was never published. We know a lot of high level details about Windows. But almost nothing bellow that. Going further will be reverse engineering. The ultimate (and punishable) NO NO.

But (beside LINUX variants) there are few more OS-es, on the market today. Do we know more about them? We do not. Make no mistake:

No modern, commercial OS will have it’s detailed Architecture published.

And here I mean OS System Architecture. Not marketing leaflets block diagrams called “architecture”. It is just too dangerous to publish such a thing called Detailed OS Architecture. Thus, around commercial modern OS-es there is a lot of deliberate speculation, and FUD. Things are happening out of the blue. Or not happening. And we can just speculate WHY. No blueprints no discussion.

Windows 10 Architecture?

I have seen WIN10 and I am using it right now. WIN10 “feels” to me as an  OS well architect-ed. I can “feel” it is quicker then its predecessors working inside the same VM with the same amount or RAM and same sized HD, and same underlying host hardware.  But, I am an Architect and I should be able to objectively quantify this subjective opinion of mine. And, I will. Here it is.

OS Architecture is the biggest crown jewel in every software company’s crown. But there is much more to it. Architecture is not to be sold and it is not ever to be seen. Ever. OS Architecture is the gem stone of great magical power. Power that is lost as soon as the stone is seen.

A rather quantum situation: we know it is there and we know it is fundamental. But we can not directly observe it.

That is the real technical explanation for you, on what is OS Architecture today. Windows 10 including.

1:  Software is not built from brick and mortar, and is thus much easier to bend this simple rule: First Architect, then design and then build. It is even feasible to break this rule and establish software development cycling. But, never without skipping any of these three phases. Never. Which (we can only speculate) was exactly the case with Windows 0.x in those primordial days of software industry.