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

Microsoft’s gone Modern! – Windows 8 and “Modern” UI Style

Microsoft is getting a full make over! We had been hearing from Microsoft that the “Metro”, which is now called the “Modern” UI Style is going to be defining UI style through the bold use of color, typography, and motionstyle creating a brand new, live and fresh experience across all of Microsoft products. But over the last few months we started realizing that it’s a change in Microsoft’s DNA. Everything that’s published by Microsoft follows this UI Scheme, even Microsoft banners, handouts all are following the same theme. Microsoft changed its logo this morning – something that had not happened since 1987, but did you take a look at the new logo – here it is.

You can see that it’s all part of the same make over. You better believe it – Microsoft is super serious about the Modern user experience!

Stay tuned! I’ll write more about best practices of Windows 8 application development and Modern UI Application Development.

Namasthe!

Windows RT vs. WinRT vs. Windows 8!!

One of the things that I was confused about in the last few hours, and I am confident that many more people are going to be confused about in next few months is the difference between "Windows RT" and WinRT. Here is the simple version:

Windows RT:

1.  It's an OS.
2.  It's a variation of the Windows 8 OS that Microsoft has specifically    designed for devices running ARM devices.
3. (In case you are wondering) ARM is an architecture used by many processor companies to design their chips, including Qualcomm, nVidia, Texas Instruments and several others.
4. What that means is that when you go to the Settings -> PC Info screen of a tablet device running an ARM processor, it will show you "Windows RT" and NOT "Windows 8". So, it's a full-fledged OS that is branded and sold separately by Microsoft to tablet OEMs (aka manufacturers) who are using ARM processors in their tablet devices. In fact, it used to be called as "Windows on ARM" earlier but was later on re-branded as Windows RT.

WinRT:

1.   it’s a runtime.
2.  Conceptually, it's not very different from .net, java or any other        runtime in the sense that its main goal is to create a cross-platform application architecture on Windows 8 that supports multiple languages (C++, C#, JavaScript, etc.). 

Difference between "Windows RT" and "Windows 8":

     Now that we know that Windows RT is an OS, I am sure that some of you are wondering how it is different from Windows 8. Here it is!!

1.  Not much different from user experience point of view as both    support Metro UI.
2. Windows RT is not sold directly to consumers, and is meant only to be sold to device manufacturers (aka OEMs).
3. The goal behind Windows RT is to give end users consistent    experience across tablets being offered by various manufacturers (including Microsoft's own device called as Surface).  
4. Windows RT will come pre-packaged with MS Office, whereas Windows 8 users will have to buy (and install) Office separately.
5. There are similar differences in terms of applications shipped out of the box in Windows RT and Winodws 8, as well as the kinds of applications you can develop/install/uninstall on them. Windows RT seems to be more locked-down version of the two.
6.  You also cannot use Win32 and COM APIs on Windows RT, so you are pretty much restricted to using WinRT APIs. Although, over  next few days I am going to be closely working on a project that requires access to underlying System Information on a Windows RT "ARM" device. It seems that there may be a way to access a subset of Win 32 API on a Windows RT device. If it works, I will post my experience in a subsequent post. 

 
Please visit our Windows 8 application development page