I’ve just come out of Martyn Lovell’s talk on WinRT internals here at BUILD in Anaheim, California.
Make no mistake: Microsoft has re-invented the Windows API in WinRT. Just to recap, WinRT is the API for Metro-style applications, the touch-centric, app-centric API for tablets and, one presumes, eventually for Windows Phone (though Microsoft has yet to admit it).
WinRT is only useable from Metro applications. You cannot call WinRT from a Win32 application, nor vice versa*. I think it is reasonable to assume that a future version of Windows which runs only WinRT is a possibility; and that Windows 8 on ARM will look a bit like that even though Win32 will still be there, but mainly out of sight; but I am speculating.
Does that mean Win32 is now legacy? In a way, but such a huge legacy that for the moment we should think of Windows 8 as two platforms side by side.
There is no inter-app communication in WinRT other than by the pre-defined contracts built into the system (though Lovell noted that you could always use the file system and polling for a crude inter-process communication).
There is no way to install a shared dynamic library. Apps can only use the system libraries together with what you install with the app. Each app lives in its own context and is isolated. In other words, WinRT is not extensible, other than within your app’s code*.
If you figure out a way to bypass limitations of WinRT by calling other Windows APIs, your app might work but the submission process for the Windows Store will prohibit it.
Versioning is built into WinRT. This means that when Windows 9 comes along, you will be able to code just against the Windows 8 versions of the classes, for compatibility, and your IDE can support this by only exposing the Windows 8 version of the API.
The CLR exists in the Metro environment, for use by .NET applications, complete with JIT (Just in time) compilation. However only a subset of the .NET Framework libraries are included. Microsoft aimed to include only what was necessary for Metro. I am not sure yet what is included and what is not, beyond the obvious (no Windows Forms, for example) but will be investigating what is documented. The native WinRT APIs look similar to a COM callable wrapper from the .NET side. That said, you do not normally need to care about WinRT interfaces, even though these are there in WinRT. Normally you interact with WinRT classes, making it more natural for .NET than working with COM.
WinRT is full of asynchronous calls. Lovell told us that Microsoft had seen in the past that if both synchronous and asynchronous APIs are available for the same function, then developers often use the synchronous version even when they should not, making applications less responsive. The new await keyword in C# makes this easy to code.
WinRT makes use of the ILDasm metadata format which is also used by .NET. This means you get rich metadata for IntelliSense and debugging, but note that the actual runtime is not .NET; they just borrowed the same metadata format.
WinRT objects are reference counted like COM for memory management, with weak references to avoid circularity. You should not have to worry about this; you can code according to the conventions of your language.
There are three ways to write WinRT applications. One is C++, in which case you write directly to the “projection” of WinRT into your language. The second is .NET, in which case your code goes via the CLR. The third is HTML and JavaScript, in which case your code goes via the “Chakra” JavaScript engine also used by Internet Explorer 9 and higher. Lovell assured me that there is little difference in performance in most cases, though there could be advantages for C++ in certain niche scenarios. Of course we heard that story for .NET as well, but from what I have seen it is more plausible in WinRT.
There is no message loop in WinRT. There is no GDI in WinRT. All graphics are via DirectX. XNA, the .NET games framework, is not supported. It seems that you will need to use C++ for fancy DirectX coding, though this is not confirmed. Of course your XAML or Canvas code will be rendered by DirectX under the covers.
It is fascinating to see how Microsoft has borrowed XAML and ILDasm from .NET, but that WinRT is native and not .NET at its core. My take on this is that Microsoft intended to preserve the productivity of .NET, but without any performance compromise.
Despite the inclusion of .NET though, the fact that only a subset of the Framework is available, and that interop to the Windows API will not work*, means that most existing apps will need considerable work to be ported to Metro.
*Updates
A few clarifications.
It has been shown that you can call WinRT from Win32 (the favoured word for Win32 seems to be “desktop applications”) though I’m not sure how useful it is.
Concerning P/Invoke (Platform Invocation) to Win32 APIs, apparently this does work for a certain specified, small subset of the Windows API. It also works for your own native code DLL, with the proviso that if your native code DLL calls a disallowed Win32 API it will raise an error.
WinRT is partially extensible. A Framework Extension is a library which you can reference as a dependency in your app’s manifest. When the app is deployed it will download this dependency from the Windows Store. An example is the C Runtime Library. An extension library installs into its own directory, and can be used by multiple WinRT apps provided each one also references it in their manifests. However, the caveat is that only Microsoft can create these extensions: there is no way to create your own shared extension for general distribution, though an enterprise can deploy a shared extension internally.
Very sad to hear that XNA will not be supported.. Such a great gaming framework and with Xbox Live support coming it seems like a great fit.
“…most existing apps will need considerable work to be ported to Metro.”
This brings to mind Bob Muglia’s famous statement from 2010-10 “Our strategy … has shifted”.
Not that I’m necessarily objecting.
But this does call upon devs to recalibrate and place a wide range of new bets, with risks. Rhetorical question: In my limited learning time, which technologies should I invest further in? WinRT or the now somewhat “legacy-ized” Silverlight and .NET. Or perhaps iOS or Android?
Vic
I still make the same comment, I don’t see a future where Metro style apps will be the only thing. Not everything is touch based full screen apps. The desktop paradigm is in some, maybe even many, cases a very powerful and correct model to use for your application, where keyboard and mouse is the correct tools.
And also, Metro style apps can run inside a window in the windows window manager as a normal window.
I see a future where they use this common type model to enchance the native model in windows though, and thus slowly obsoleting win32 by starvation as apps move over to a better model (not metro, but a better type model).
Hi Tim,
Thanks for this article. Was there any mention of how C sharp is memory managed when NOT going via the CLR, and going to these language projections. Or are all C sharp apps still managed by the .NET runtime and Garbage collection etc?
The Tech Stack seemed to indicate that some C Sharp apps, will sit directly on top of WinRT not going via the .Net RT
Cheers
This is a good article from a Telerik guy who used to work at MS: http://dougseven.com/2011/09/14/i-know-what-youre-thinking-and-youre-wrong/
“My advice…keep doing what you are doing, and invest 20% of your time in learning about Windows 8 and the Metro style app models.”
Vic
C#/VB apps are still managed, complete with CLR and its JIT and GC services. It’s the WinRT libraries themselves that are native. From .NET perspective, though, it doesn’t really matter much, since you see the entire WinRT as if it were a managed assembly – WinRT interfaces are seen as .NET interfaces, WinRT classes as .NET classes etc. This is more seamless than COM Interop because there are no interop assemblies anymore – you directly reference .winmd (Windows Metadata) files from assemblies, and CLR is able to read metadata from them, project it as CLR types, and provide all necessary interop machinery at runtime.
“The CLR exists in the Metro environment”
As you say in the following, it’s not really “the” (full, standardized) .NET CLR. WinRT includes a new stripped-down non-standard CLR. Aside from many APIs that aren’t available, there is one huge restriction that nobody seems to be aware of: user-defined structs can’t have methods!
http://social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/33a91dcd-4f5c-4de1-b666-6a7eba0b772f
Porting any big .NET project to WinRT is going to be a bear, not nearly as simple as shown in the Build keynote demo.
“…most existing apps will need considerable work to be ported to Metro.”
Well, are we sure about that? Below is the list of “.NET classes” which can be used in Metro as well as the list of breaking changes from .NET, and ignoring the absence of Windows Forms (and ADO.NET?), compatibility seems quite high.
Anything major missing?
http://msdn.microsoft.com/en-us/library/windows/apps/br230302(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/windows/apps/br230232(v=VS.85).aspx
Lovell told me that it has been trimmed extensively though they aimed to cut what was deprecated and what no longer applies in Metro.
Tim
@int19h Regarding C Sharp app on top of the WinRT. The Platform model slide, shows C sharp running NOT on top of .NET RT, but on top of WinRT.
And they talk about WinRT being “projected” into these languages, it appears that interfacing is not via Com Callable Wrappers
It is not via COM Callable Wrappers but we were told that it looks similar to that – it does use the ILDasm metadata as I understand it. C# does run on the CLR – pretty sure about that!
Tim
WRONG ON SO MANY LEVELS.
will give you details later.
1, WinRT IS accessible from ‘Desktop’ apps, here is an example for .NET http://ermau.com/using-winrt-from-net/
and it is also doable from Win32 C++ programs. It is just COM.
2, WinRT IS extensible, you can create Extension SDKs and distribut as VSIX
http://msdn.microsoft.com/en-us/library/windows/apps/hh441589%28v=VS.85%29.aspx
And some MS official ‘Extension SDKs’ are available through WinStore as ‘dependency’, and I guess this mechanism may be available for 3rd party ‘SDKs’ too.
Hi Guest, this is all new to me so happy to be corrected. My understanding though is that the extensions will end up as DLLs for your app, you are not adding shared components that other apps can use. VSIX suggests that it is *Visual Studio* which you are extending. I am not sure about “Framework extension SDKs”; obviously there has to be a way for Microsoft to update or extend WinRT with its own components but is that available to third parties?
Agree about accessing WinRT from desktop apps, and of course on Windows anything is possible, which is where the comments about the store are interesting – in other words, you can do things Microsoft does not intend you to do, but if you submit an app to the store it will be blocked.
I will try to clarify both issues while I am here at Build though. Thanks for the links.
Tim
yeah, accessing outside API from Metro is technically possible but will fail for Store.
but accessing WinRT from desktop apps is totally OK since desktop apps dont use appx and winstore.
talking about Callable Wrapper, somebody found something in the leaked builds, called ‘Jupiter RCWs’ inside clr.dll
http://forums.mydigitallife.info/threads/27533-Win8-M3-(7989)-findings-relevant-to-Managed-.net-amp-WPF-SL-developers?p=478815&viewfull=1#post478815
@Tim:
RIGHT ON SO MANY LEVELS.
will give you details later.
(Maybe next week some time :).
Vic
The Windows API functions call undocumented native functions in the kernel. Do WinRT methods call the same native kernel functions? Or does the distinction between WinRT method calls and native function calls just go away? From the point of view of kernel/executive OS components, like the Object Manager and Memory Manager, how do WinRT calls “get to” or interact with these OS components?
Is it correct to say that WinRT is really a new subsystem? Like POSIX, OS/2 and Windows are separate subsystems? I’m not arguing that it is, but explaining why WinRT is (or is not) a new subsystem could be useful.
Discussed briefly with Mark Minasi – who says definitely not.
Tim
Great dive into WinRT !
I’m just wondering how the HTML5/JavaScript Metro applications will be packaged and protected against reversal …
For packaging I’ll expect some sort of signed zip/jar (no mention about .appx on MSDN) but for protection, outside of heavy obfuscation for JavaScript I can’t envision any other way (maybe a new precompiled/binary format ?)
If the protection is not good, writing HTML5/JavaScript apps will not flourish to much IMHO.
Since the Metro documentation state that the applications are self-consistent (no shared DLL’s, etc), I’m just wondering how you can create a modular, BIG Metro application by creating reusable components/libraries …
Do you have more details for all of these ?
BTW, all the HTML5/JavaScript way of programming Metro apps remind me about Opera widgets that you can build for several years now 🙂
Too strong “shift in a strategy” will push more developers (especially young) to seek better opportunities outside Microsoft realm (i.e. mac, android etc.)
A deep-dive into WinRT and CLR under Windows 8 and better details of the actual Windows 8 architecture can be found here A bad picture is worth a thousand long discussions.
Just finished watching the relevant Build session, “Using the Windows Runtime from C# and Visual Basic”, good information for everyone concerned about .NET/WinRT issues:
http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-531T
Turns out I somewhat misunderstood the restriction on .NET structs (no methods) that I was concerned about. This restriction applies only when exporting .NET libraries as WinRT libraries for use by other languages, and that’s actually not mandatory for Metro projects. You can still define .NET assemblies that are private to your own project, and those get the full CLR functionality (minus unavailable APIs) rather than the limited WinRT-projected-into-CLR functionality.
@alex:
>Too strong “shift in a strategy” will push more developers
>(especially young) to seek better opportunities outside
>Microsoft realm (i.e. mac, android etc.)
That was already happening. That’s what this is a response to. Devs who dislike change probably will also be unlikely to change to a new platform like the iPad. MS devs who like new stuff are now in heaven.
From what I’ve seen so far, MS has taken back a big chunk of the technology high-ground with Win8/Metro (no market share yet, but in fundamental capability).
After watching the “8 traits of great Metro style apps” presentation last night http://bit.ly/qOlJvp (one of the most popular from Build), I get the impression MS has prepared well for addressing the tablet space. They needed an answer to the iPad/iPhone and they have indeed delivered the technology (although not yet the sales).
Vic
New Metro is a stupid mistake. Limited, no extensible, bad looking and organized on the screen, heavily restricted and ultra expensive for developers (30% of the app piece for nothing – ridiculous).
Worst and most stupid idea created by Microsoft so far.