Windows 8 - WinRT - Motivation & History

Just when you thought .NET , WPF, Silverlight, C# formed a steady story, in comes WinRT, HTML 5 and JS seemingly shaking the whole foundation!
WinRT is the new API for the window operating system. Hey Wait! So is Win32 gone? No - It is still there! This is what you can call "the object oriented Windows API". Hey Wait! So is .NET gone? No -It is still there! It previously didnt cover the whole spectrum of the operating system services and we always had to fall back on the operating system's win 32 or COM API at times thru .NET callable wrappers for COM objects and PInvoke for Win32 API.

Now you dont need to do that - you can use WinRT from c#, c++ and js. From the days when MSFT thought of doing the whole OS in managed code (remember longhorn) to WinRT is quite a shift! Now to access operating system services and certain other utility services you have many basic routes - Win32, COM API , .NET, WinRT.

I have to digress here to put in perspective the various routes here.

• First we had Win32 which was a C thingy


•  Second we had some object oriented libraries like MFC which tried to wrap over the Win32 in various interesting ways to make it easier for people to access the underlying libraries. Similarly there are different libraries for different languages to access the underlying operating system services for instance one for VB and another for Fortran.


• Third we thought there should be a common way to access system services from different languages and then came COM which provided that capability through a binary interface standard enabling components to be developed in any language and used using any language. Also COM objects were made automation compatible & self reflective through dispatch interface and type libraries. This enabled even dynamic languages like VBScript to use COM Objects. But still, inspite of COM and its noble efforts in leveling the field, C++ based apps continued to be the first citizens in accessing Windows services.


•  Fourth came .NET inspired by Java which gave a common API to most languages and made those languages "almost" first citizens and also included garbage collection as one of its key services similar to Java. Reflection was also key component of the .NET framework where types are self describing as the metadata of the types are stored inside the assembly containing the types. This metadata can be queried through .NET reflection classes.

Now .NET was still only a wrapper to the underlying operating system services which were still primarily exposed as COM objects and Win32 C api. This means the WinDiv team develops the OS services and api and then releases to the DevDiv team which wraps that with .NET api. This means every time OS is released the .NET api lags behind the native OS api as they have to "write code" to do this wrapping. So it would mean that there was delay in release of the OS for .NET team to catch up or some OS api calls or objects werent wrapped in .NET and hence .NET libraries were always a subset of the Windows API.
So to solve this issue, MSFT thought we will write the entire OS in managed code using .NET and that way there is no wrapper. .NET is THE only native API. All know what happened to that effort (longhorn). Went down the drain to due to various real reasons.

Now that seemingly clean solution not attained, they are still faced with this old problem. That is when they thought of this new object oriented API called WinRT. WinRT is next best thing to writing the OS in .NET and some would argue infact even better. More importantly they have also made this new API accessible to all languages similar to .NET but they have gone one step beyond to make this api accessible to even dynamic languages like js. This way one of the key motivations of going towards .NET is addressed in the release of the new API. Infact some would argue C++ was being neglected in the C# world of .NET and with the advent of WinRT a certain sort of parity is restored. Some would argue that only now you could call all languages real first citizens.

Now still the question lingers in one's mind, as to how did they make one API consumable by all languages.

• First as WinRT was developed in the lines of COM, every class (object) of WinRT has to implement Unknown which constitutes the same three methods QueryInterface , AddRef and Release.


•  Second they introduced a new interface which needs to implemented which is called IInspectable which is the interface which provided the self describing reflective capabilities (runtime type information) which was previously achieved through IDispatch in COM.


•  Then they constructed the API in form or interfaces similar to a COM Object - for instance a FileInformation class will implement interfaces IStorageItemInformation, IStorageItem, IStorageFile.

This was the underlying structure of WinRT. There are some patterns borrowed from COM but a lot of things have been written new. For instance the apartment system and the metadata system is different in WinRT compared to traditional COM.

Now this is a pretty standard structure and then over this structure they brought in something called language projections which were auto-generated apis for each language from this underlying structure & metadata. The reason that these projections are generated rather than coded like in .NET, helped to decrease the time lag between the time the base services are developed and the apis consumable by other languages are created. In fact the metadata format is similar to the format used for storing .NET metadata. And in a way WinRT has kind of used best of both worlds - .NET & COM to creates its underlying structure.

So now having ruminated abt the Windows API evolution history, the various APIs available to use and also a little bit on how WinRT is structured, we are told that that all apps dont get access to all APIs.
So what part of API is available for the different types of desktop applications is a question which needs more research & understanding.

• NET Apps - Windows Services, Console, WinForms, WPF Apps
• Unmanaged C++ based Non UI apps - Windows Services, Console
• Win32 based native windowing Apps (using WndProc)
• Silverlight Based Rich Client Apps
• Metro Apps - Unmanaged C++, Managed C#, HTML5/JS 

The thinking would be except for Metro Apps all the apps (1-4) to work on Windows 8 need not be ported. To do that would be absurd. But still two things which developers need to look at now are:

• How to develop Metro Apps, the new kind of App which has been introduced in Windows 8 which in turn use the WinRT in different languages (C#,VB,C++,JS)
• How to use WinRT api in the non Metro Apps as there could be utility in using WinRT api if it exposes all of the underlying OS services in an object oriented easy manner in the language of your choice instead of using PInvoke and COM Wrappers.

The thinking would be except for Metro Apps all the apps (1-4) to work on Windows 8 need not be ported. To do that would be absurd. But still two things which developers need to look at now are:

• How to develop Metro Apps, the new kind of App which has been introduced in Windows 8 which in turn use the WinRT in different languages (C#,VB,C++,JS)
• How to use WinRT api in the non Metro Apps as there could be utility in using WinRT api if it exposes all of the underlying OS services in an object oriented easy manner in the language of your choice instead of using PInvoke and COM Wrappers.

Some questions crop up like what happens when .NET and WinRT projections provide the same functionality - what do you use? Do you have a choice?
We will further dwell on these topics in a later blog.

Please visits  our Windows 8 application development page