Linked by twitterfire on Mon 24th Oct 2011 22:52 UTC
Permalink for comment 494198
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
Linked by Thom Holwerda on 04/18/13 11:21 UTC
Linked by Thom Holwerda on 04/16/13 9:29 UTC
More Features »
Sponsored Links



Member since:
2005-11-29
Here's how it works:
WinRT is basically every Windows API (input, devices, graphics, networking, etc.) implemented in native C++.
C#, VB.NET, and Javascript are consumers of the WinRT API.
WinRT exports metadata files which describe its API. Using this metadata, lightweight bridges are automatically generated for .NET languages and Javascript.
So I could write a WinRT component in C#, have the metadata autogenerated, and use it in C++ as if it was a native C++ class. Or use it in Javascript as a native javascript object.
The concept is incredibly powerful, but not exactly groundbreaking.
Basically: .NET, Javascript, and C++ are all first class citizens when it comes to WinRT. There is no favoritism like before, where .NET had to do convuluted interop into unmanaged code, and Javascript did god knows what.
Its all very slick, and did I mention fast?