C# and Visual Basic on the WinRT API

While Win32 APIs can be called from .NET languages, doing so can be quite difficult. So for the last two year Microsoft has been building a replacement known as Windows Runtime or WinRT with cross-language support in mind. WinRT components can be created in both C++ and .NET and may be consumed by both of those as well as JavaScript.

While ostensibly an OOP-based framework, COM is very different than .NET. Prior to WinRT, COM was interface based rather than class based. This meant that it lacked many things .NET developers take for granted such as constructors and static methods. C++ Component Extensions addresses this.

WinRT’s flavor of COM uses the same metadata format used by the Common Language Runtime. This information is stored in WINMD files that show the structure, though not the implementation, of all the public classes. FXCop is used to verify that the APIs exposed by these files obey the .NET Framework Design Guidelines.

.NET has had an “API Design Board” since the very beginning. Inspired by this, the Windows Runtime will also have an API Design Board to govern it. Many of its initial members sit on the .NET board and many of its guidelines are directly lifted from the rules followed by the .NET Base Class Library.

Windows Runtime returns an HRESULT instead of throwing an exception. For well-known HRESULT values the corresponding exception is thrown, otherwise a COMException is used.

The new async/await keywords now work with WinRT’s IAsyncOperation interface just like it does with .NET’s Task object.

All Windows Runtime collection interfaces are mapped to the .NET framework equivalents. IReadOnlyList and IReadOnlyDictionary were added to .NET 4.5 in order to account for the read-only collections in WInRT.

There are two places where the WinRT and .NET APIs couldn’t be matched. WinRT steams are not directly compatible with .NET’s IO.Stream class, but an extension method called AsStream can be called to handle the conversion. WinRT also has an interface called IBuffer that cannot be easily implemented in .NET. Again, there is an extension method for translating between IBuffer and byte arrays.

Read more: InfoQ
QR:

Posted via email from Jasper-net