Linked by makfu on Tue 23rd Oct 2012 17:19 UTC
Windows Peter Bright has written a fascinating and well researched look into the real architecture and general internals of WinRT that largely contradicts some commonly accepted marketecture myths propagated by Microsoft (namely that WinRT is a new peer, NT native subsystem and framework alternative to traditional Win32 that doesn't depend on traditional Windows frameworks). Given all the recent news and discussions regarding the future of Windows and the openness of the platform, understanding WinRT's actual underpinnings and technical place in the Windows stack will prove valuable.
Thread beginning with comment 539723
To read all comments associated with this story, please click here.
Comment by Nelson
by Nelson on Tue 23rd Oct 2012 19:17 UTC
Nelson
Member since:
2005-11-29

It is not true that Microsoft spread any type of messaging about WinRT that says what the lead-in suggests.

It is just easier to say "WinRT is a new Framework to write apps as opposed to Win32".

Just like it is true that the .NET BCL is another Framework to write apps instead of Win32. It doesn't matter if they eventually call Win32, the key distinction is that in most case you're not doing the calling

Now, if anyone actually took the time to watch the Build presentations, you'd see that Microsoft does a deep dive into the Windows Runtime and does note that it is COM. In fact, I highly doubt Peter Bright would have been able to write a lot of his article without Microsoft explaining how the entire process works.

It is COM, but it is also a little more. They re-use COM where it makes sense and they augment it in key areas (IInspectable being one, .NET metadata vs IDL/TBL as another case, Inheritance across XAML types) but it is wholly COM with some enhancements.

The larger point isn't that Microsoft is lying, the rather poetic point made by Peter is that Microsoft has embraced what is right about the old to make something very modern.

WinRT takes all that was learned from COM and all that was learned from .NET and combines them together.

Beyond WinRT, the real innovation is in how easy it is to author these components. They are modeled naturally in C# and in C++ you can either use ISO C++ with Ro* APIs or use the WRL (ATL for WinRT) or you can use C++/CX a language extension from Microsoft to make authoring components easier.

You can also mix and match C++/CX. Have 95% of your code in C++11 and the API end points in C++/CX. Its super easy.

Reply Score: 4

RE: Comment by Nelson
by moondevil on Tue 23rd Oct 2012 19:53 in reply to "Comment by Nelson"
moondevil Member since:
2005-07-08

I for one am looking forward to the day desktop applications can be built using WinRT and Win32 is left for dead.

Maybe around Windows 9 - 10 timeframe.

Reply Parent Score: 2

RE[2]: Comment by Nelson
by Nelson on Tue 23rd Oct 2012 20:05 in reply to "RE: Comment by Nelson"
Nelson Member since:
2005-11-29

You already can ;) . You can call WinRT APIs from Desktop apps.

There are restrictions. Some APIs are not callable by Desktop apps (For various reasons, and its up to the discretion of the team associated with the API). For example the new XAML stack in WinRT is unavailable for Desktop apps.

My own thoughts are that Desktop apps will never get full blown WinRT. However, WinRT will be improved so that we can replicate much of Desktop apps using it.

I can see Windows 8.5 (or 9, or whatever they call it since rumor is they're moving to faster releases) having for example more powerful "snapping" capabilities (or even becoming an awesome Tiling Window Manager).

That, plus even more APIs available in WinRT will make the process easier. I'm not too worried at the moment.

Reply Parent Score: 3

RE: Comment by Nelson
by dsmogor on Thu 25th Oct 2012 15:00 in reply to "Comment by Nelson"
dsmogor Member since:
2005-09-01

For me the main message with WinRT that OOP api is now the lowest level general purpose OS api in Windows. The experiences for making .NET libraries have been taken lower level, with COM simply selected as object ABI.

The most important question is whether MS will keep Metro apps away from plugging into old Win32 underpinnings. Some policy could at least be put in place to discourage resource strapped programmers from doing short circuits from old code bases. Can e.g win32 be used on Arm? Without that, eventually retiring Win32 won't be possible.

Reply Parent Score: 2