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

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!

VN:F [1.9.18_1163]
Rate this post
Rating: 8.3/10 (4 votes cast)
Full circle at Microsoft: from the early days of .NET to the new Chakra JavaScript engine, 8.3 out of 10 based on 4 ratings

Related posts:

  1. Full circle for Microsoft database APIs as OLEDB for SQL Server is deprecated
  2. Fast JavaScript engine in Apple iOS 4.3 is in standalone Safari only, but why?
  3. Microsoft announces launch dates for Windows 8: software will be done early August
  4. How Microsoft’s Office Web Apps were written in C# and compiled to JavaScript, maybe
  5. Here comes TypeScript: Microsoft’s superset of JavaScript

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

  • Justin

    Interesting post and it really makes you think about .NET’s future. What part of .NET do you think is dying, .NET in general or just desktop development part of .NET?

  • tim

    @Justin I don’t think .NET is dying, and the threat of HTML5 is on the desktop not the server. Still, the current situation in which the Windows folk are all-but talking .NET down is damaging and if the platform declines on the client it will impact the server too since end to end is a feature.

    Tim

  • At TechEd 2001 I interviewed Anders Hejlsberg on C# and .NET for Developer Network Journal. The interview covers some of the early days of .NET, suggesting that .NET came out of work on J++ and Windows Foundation Classes back in 1997. You can find the complete article at
    http://blog.mattmags.com/2001/07/04/anders-hejlsberg-on-c-and-net/

  • tim

    Thanks Matt. That’s the language and framework aspect more than the runtime. The link with J++ is interesting though; Microsoft underplayed it I think because it wanted to differentiate from Java.

    Tim

  • Take into account that node.js is rocking the server side world with javascript, so don’t limit yourself to the desktop environment. This could be a shift to more javascript in the server side development as well.

  • rbirkby

    Nothing to do with Colusa (except perhaps patent protection from Sun). Colusa was a register-based VM. MSIL/CIL is a stack-based VM.

    I asked Brian Harry about the origins of .Net back on the old DevelopMentor mailing list a decade ago. He said:

    “It started in early 1997, right after we merged the MTS team and the COM
    team to create the COM+ team. I was leading a team attached to the MTS team
    and had been working on a project to replace type libraries with a richer
    and more useful type information model. Nat was the GPM on the COM team and
    Mohsen was the PUM of the MTS team. We got together and put together a
    proposal to substantially update the COM model. ”

    It seems the rest of what he wrote was lost when DevelopMentor destroyed the archives. Grrrrrr.

    @rbirkby

  • rbirkby

    My recollection is that MSIL substantially evolved out of the MSVC intermediate language. Serge Lindin is the person who did much of that work.

  • Another bit of trivia is that the original developer of the 32bit Delphi compiler, Peter Sollich, went to MS in the late ’90s to work on what was vaguely described as “COM [+]? runtime optimization.” My later contact with him confirmed that this work was in fact for optimizing the JIT compiler portion of the CLR.

  • Clyde Davies

    I wondered why it was that, back in 2009, MS abandoned their plans to run JScript on the Dynamic Language Runtime. It now looks like this decision was driven by politcal rather than technical considerations.

  • pingpong

    @Clyde:

    Running JScript on DLR means that every IE process instantiates the CLR and effectively makes IE dependent on .Net. Who would want that?

  • Microsoft has invested heavily into hardware accelerating IE10 rendering, the same thing they did before with WPF and then Silverlight. In combination with a high performance JS engine, they now have a very powerful runtime and retained mode graphics engine.
    I think it is totally possible to target this engine (IE 10) with XAML and C# (via cross compilers and javascript libraries). Doing so, would solve quite a few problems for Microsoft, e.g. the fact that Silverlight failed to reach similar penetration in the consumer space as Flash. It’s speculation, but IMO totally possible.