WinRT, so much new and interesting… so much old and broken? I’ve read a few articles now, watched a couple of talk recordings – nothing great and in-depth but I think I’ve picked up a few details.
WinRT is effectively the combination of ‘COM done better’ and ‘OS API done using the result’.
On the COM done better side we get, nicer integration into more languages. Along with that is a metadata format which is shipped with the code. Metadata which includes versioning information to try and avoid some of the COM interface versioning hell. You get better runtime reflection – every WinRT type can tell you what interfaces it implements and provide some kind of name. Apparently there is type inheritance (although apparently only the WinRT core is allowed to use it…), and generics and better handling of events and asynchronous callbacks. A new better type of string, simple structs and collection types built into the core that everyone can consistently use as part of their own APIs. Each app apparently even has its own COM(I mean WinRT) registry, so no conflict issues.
OS API done using the result gives opportunities to do things the way they should be done. It also allows for namespacing and componentization, which when mixed with the metadata mean much improved discoverability and general developer experience. No need to call clean-up methods, because they are automatically called when the associated type is released…
Take for example the PropertySet in WinRT. Using this from c# in VS11 the only vaguely apparent suggestion that this isn’t a .Net type is its namespace. I can easily see developers thinking that this was a replacement for StringDictionary (which has conveniently been removed from the .Net 4.5 core runtime). But you will see the difference if you create a circle of references between PropertySets. You have to manually break the circle or the PropertySet memory will never be released!
As a bonus to this post, I’ll end by mentioning that WinRT apparently does not support exceptions! This may seem strange to anyone who has used it, since calling WinRT APIs certainly throws exceptions, but this is entirely language integration, under the hood an error is limited to a 32bit integer – a HRESULT. This means WinRT components cannot provide useful error details directly through their APIs without mangling those APIs to provide a bunch of output parameters that are normally never used.
I was watching one of the WinRT talks where they decided to describe a ‘feature’ that if an error occurs in the WinRT core libraries, it can directly tell the attached debugger additional details, since they cannot be returned to the calling code! (One can only hope that they provide a way for custom written components to do this too, it is going to be bad enough that when ComponentArt 19 for Metro comes out every error returned to your code is ‘COMException’ at runtime, not being able to find out useful details while debugging would be a nightmare.) Almost makes one wish for the return of GetLastError…