Tag Archives: clr

.net, professional, silverlight, software development, windows

A few facts about Microsoft’s new Windows Runtime

25 Comments

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.

.net, microsoft, professional, software development

Full circle at Microsoft: from the early days of .NET to the new Chakra JavaScript engine

11 Comments

A discussion with a friend about the origins of Microsoft’s .NET runtime prompted a little research. How did it come about?

A quick search does not throw up any detailed accounts. Part of the problem is that much of it is internal Microsoft history, confidential at the time.

One strand, mentioned here, is Colusa’s OmniVM:

OmniVM was based on research carried out by Steven Lucco at Carnegie Mellon University. Steven co-founded Colusa Software in February 1994 in Berkeley, California. Omniware was released in August 1995. Colusa started working with Microsoft in February 1996. Microsoft acquired Colusa Software on March 12, 1996. Steven is currently a senior researcher at the Microsoft Bay Area Research Center.

OmniVM was appealing to Microsoft because Colusa had already created Visual Basic and C/C++ development environments for the VM. The VM was also claimed to be capable of running Java.

Microsoft took to calling the VM by the name of CVM, presumably for Colusa Virtual Machine. Or perhaps this is where the code name Cool came into being. Other names used at Microsoft include Universal Virtual Machine (UVM), and Intermediate Language (IL).

Microsoft’s Jason Zander, commenting to a story on this blog, does not mention OmniVM:

The CLR was actually built out of the COM+ team as an incubation starting in late 1996. At first we called it the "Component Object Runtime" or COR. That’s why several of the unmanaged DLL methods and environment variables in the CLR start with the Cor prefix.

Still, the timing pretty much matches. If Lucco came to Microsoft in 1996, he could have been part of an incubation project starting later that year.

In June 1999 Microsoft previewed the Common Executable Format for Windows CE:

A demonstration on Common Executable Format (CEF), a new compiler target within the Visual C++® development system for Windows CE, was also presented. This compiler enables cross-processor portability within a category of devices, such as Palm-size PCs or Handheld PCs. A single program executable under CEF is translated to the native code on either the host PC or the device, as desired. This capability eliminates the need for developers to recompile an application for every possible processor on a given Windows CE-based appliance before bringing it to market, thus enabling them to support every version of a device (Palm-size or Handheld PC) quickly and easily.

In 2000 I interviewed Bob Powell, then at Stingray, who told me this in relation to .NET:

There was an early version of the system for Windows CE called the Common Executable Format (CEF). The Pocket PC, which uses around seven different processor types, and which has many different versions of the operating system, is a deployment nightmare. This problem was addressed by the CEF, which was a test case. What is now in the IL is a more refined version of that.

Hmm, now that Windows is coming to ARM alongside x86, this sounds like it could be useful technology … though despite obvious similarities, I don’t think CEF was really an early version of the CLR. Maybe the teams communicated to some extent.

Now this is interesting and brings the story up to date. Lucco is still at Microsoft and apparently his team built Chakra, the new JavaScript engine introduced in Internet Explorer 9:

image

Steven E. Lucco is currently the chief architect for the Microsoft Browser Programmability and Tools (BPT) team. BPT builds the Internet Explorer’s Chakra Javascript script engine, as well as the Visual Studio tools for creating scalable, efficient Web client applications.

Right now, these are dark days for .NET, because Microsoft now seems to be positioning HTML and JavaScript as the new universal runtime.

It seems that the man who perhaps began the .NET Runtime is also at the centre of the technology that might overtake it.

Update: this post has prompted some discussion and the consensus so far is that the OmniVM acquisition probably had little to do with the technology that ended up as .NET. The one thing that is beyond doubt is that the COM team created the .NET CLR as Zander reported. I actually spoke to Zander at TechEd recently and we touched on his early days at Microsoft working with Scott Guthrie:

I was actually one of the original CLR developers. When Scott and I first started working together, he invented ASP.NET and my team invented the CLR.

The history is interesting and if the relevant people at Microsoft are willing to talk about it in more detail it is something I would love to write up – so if that is you, please get in touch!