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.
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!
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?
@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.
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
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.
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.
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.
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.
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.
Comments are closed.