
A History of .NET Runtimes - edroche
http://mattwarren.org/2018/10/02/A-History-of-.NET-Runtimes/
======
sureshv
Few more missed include (Device CLR's were in C, Desktop/Server in C++):

(1) CLR for Sony/Ericsson phone OS and (2) Variant running on linux (in
2001/2002).

I worked on the Compact Framework team back in the day so there's a few more
things to point out related to the internal politics of Microsoft at the time.

The devices strategy was a mess even back then due to
Alchin/Valentine/Ballmers love of Windows desktop 'everywhere'. Windows and
Office dominated the company so things like .Net were always going to be
secondary to that.

The origins of the CLR can be found in the purchase of Colusa in 1996 which
had the Omni VM for running C++ in a sandbox. The original C# language was
called cool and came from that project.

~~~
dusanbab
Was the framework you mentioned in (1) a Microsoft project, or something else?

As a matter of interest, what did you do on the CF team?

~~~
sureshv
Worked in the Compact CLR Execution Engine, IL Verifier, and other stuff. On
(1) both were done at MS but ended up as proof of concept.

Post Sathya Microsoft has moved to a more open model, hence the full blown CLR
on Linux.

------
pjmlp
The AOT compilers misses NGEN, which is part of .NET Framework since v1.0,
although it only does dynamic linking with very little optimizations.

And the cloud compiler created for Windows Phone 8.x, based on Bartok from
Singularity.

[https://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-
an...](https://channel9.msdn.com/Shows/Going+Deep/Mani-Ramaswamy-and-Peter-
Sollich-Inside-Compiler-in-the-Cloud-and-MDIL)

[https://channel9.msdn.com/Events/Build/2012/3-005](https://channel9.msdn.com/Events/Build/2012/3-005)

.NET Native is an improvement of this work.

~~~
matthewwarren
I _tried_ to only focus on runtimes, although the line got a bit blurred at
times! But yeah, it would be nice to have included a mention of NGEN. When I
get a chance I'll update the post

> And the cloud compiler created for Windows Phone 8.x, based on Bartok from
> Singularity.

Interesting, I didn't realise that all this came from Bartok, thanks for the
info

~~~
pjmlp
They are not fully explicit about it, just talking about Bartok and MDIL as if
invented for WP 8, but they are scattered all over Singularity documentation
and papers, so it is quite obvious where they come from.

------
marcoperaza
Something that makes following Microsoft tech _different_ for engineers, in my
opinion, is that naming has historically been driven by marketing/sales, not
engineering. There is not a 1-1 mapping between the branded/advertised
functionality and the technical components responsible for it. This makes
sense when your audience is purchasers at a company. They care about what
features/scenarios are supported, not how they are implemented (sorting
through that is, at most, the job of someone lower on the totem pole).

Engineers, on the other hand, want to know how the system works. Even when it
_shouldn’t_ matter to us, we can’t help but think in terms of the actual
mechanisms driving the system’s behavior. We don’t like black boxes, because
we experience daily the leakiness of all abstractions. And for an engineer
targeting Windows as a platform, the technical details obviously _do_ matter.

I think this difference is especially jarring to developers used to the __nix
world, where everything is much more developer-oriented. I would bet that the
early success of Microsoft products against Unix is partially due to this
difference in focus. Ideally, you communicate differently with both groups,
but in reality you have to make trade offs. It would just create more
confusion if there was one set of names /brands for end-consumers and another
totally different set for developers.

(Another difference is that Windows has historically been one big project, so
features _do_ in fact span technical components, which due to being under
single management, are less regimented to begin with.)

The web has definitely changed things by making operating systems less
important. At least the perceived importance of marketing to developers has
increased. I think Microsoft has done a good job adapting to this change
lately.

------
jasode
I think the history of the _internal politics_ at Microsoft in regards to .NET
and also the external industry trends is fascinating.

The common thinking is that C# & .NET was a ripoff of Sun Java because of the
_" write once run anywhere"_ threat. That's sort of true but missing some
nuance.

I'm not a MS insider but here's my understanding of what happened. We have to
separate the C# language from the CLR runtime. In the 1990s, Microsoft was
already researching how to enhance and extend the COM interoperability model.
(Otherwise known as "how do we get multiple programming languages to talk to
each other?")

Based on some old interviews with Don Box[1], instead of this work being
productized and released as "COM+ version 3" or whatever, it morphed into the
CLR. This was a natural evolution that would have happened even without Sun's
JVM threat.

C# the language, on the other hand, was a more direct response to Java the
language since Microsoft's J++ (Java clone) was abandoned because of Sun's
lawsuit.

As for .NET, it's interesting that Microsoft always had this large internal
group of programmers (mostly Windows kernel and Office teams) that didn't
fully buy into the .NET vision. On the other hand, Bill Gates himself was a
big believer in it. My pet theory is that since Bill Gates programmed in BASIC
in the 1970s and not in low-level C/C++/assembly, he had a natural affinity
for the vision of high-level C# & .NET being pervasive throughout Windows.
Even with Bill's support, there was always an ongoing internal tension between
the C++ vs the NET framework camps. (On a related note, it seems like Apple's
internal programmers are more happily embracing Swift over Objective-C to a
greater degree than Microsoft's internal adoption of C# over C++.)

Two major forces outside of Microsoft's control curtailed .NET's planned world
dominance: (1) the rise of Javascript in the browser which negated .NET
Silverlight, and also Java applets and Flash. (2) the rise of Apple iOS and
Android.

.NET is still very popular but it definitely did not fulfill the more
ambitious dreams that Bill Gates had for it.

(On a related note, I also wrote an old comment about the decline of .NET's
WPF and its limited adoption:
[https://news.ycombinator.com/item?id=14098832](https://news.ycombinator.com/item?id=14098832))

[1] Was MS Technical Fellow and author of 1998 COM book:
[https://www.amazon.com/Essential-COM-Don-
Box/dp/0201634465](https://www.amazon.com/Essential-COM-Don-Box/dp/0201634465)

~~~
iainmerrick
It does seem like all these .NET projects are reactions to rival technologies.
C# is a Java clone, C# generics are an (arguably improved) Java generics
clone, .NET Micro is J2ME, Silverlight is Flash, etc.

What are some examples of where C# / .NET paved the way and others followed?
Maybe popularizing async/await?

I’m definitely not claiming MS as a whole is always a follower. It seems like
Direct3D led the way for the whole industry, for example.

~~~
pjmlp
How come C# generics are a copy of Java when they were invented first and the
only reason they didn't make it to 1.0 was not to delay the release schedule?

Java annotations are based on .NET atributes, and initially had a clusmy
implementation requiring an annotations processing tool until they finally got
integrated into javac.

LINQ paved the way to more FP acceptance among enterprise developers. Check
"confessions of a language salesman" from Erik Meyer.

Also .NET always had AOT/JIT from the very beginning, whereas AOT was tabu at
Sun and only commercial JDKs always had it as option.

~~~
iainmerrick
Hang on, Wikipedia says Generic Java was 1998, generics were adopted in J2SE
5.0 in 2004, and C# 2.0 wasn’t released until 2005. Am I missing something?
I’m sure there was cross-fertilization both ways but it seems like Java
generics came first.

LINQ is a good one though, that’s definitely a .NET innovation.

~~~
pjmlp
Yes you are missing the remaining part of the sentence "the only reason they
didn't make it to 1.0 was not to delay the release schedule".

Don Syme of F# fame was leading generics research since 1999, while they were
designing the CLR, but it was clear they would have to delay 1.0 if they
wanted to included them, so they just went ahead without them for 1.0 release.

[https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-
gener...](https://blogs.msdn.microsoft.com/dsyme/2011/03/15/netc-generics-
history-some-photos-from-feb-1999/)

[https://blogs.msdn.microsoft.com/dsyme/2012/06/19/some-
histo...](https://blogs.msdn.microsoft.com/dsyme/2012/06/19/some-
history-2001-gc-research-project-draft-from-the-msr-cambridge-team/)

[https://blogs.msdn.microsoft.com/dsyme/2012/06/26/some-
more-...](https://blogs.msdn.microsoft.com/dsyme/2012/06/26/some-more-netc-
generics-research-project-history/)

Additionally C#, like Java, also had CMU, ML, Ada, Eiffel, Sather, BETA, C++
and Modula-3 as possible sources of inspiration for generics.

~~~
iainmerrick
Just lost out in a photo finish, then (over a span of 5 or 6 years...!)

But Generic Java was started in 1998 (IIRC originally as part of Pizza). It
seems reasonable to say that Java covered this ground first.

~~~
pjmlp
Faire enough I forgot about Pizza.

Although what Java got wasn't all of Pizza, which had better generics.

------
mariusmg
Does anyone remember Rotor ? That thing (codeveloped with Corel) was pretty
interesting. Too bad about the look but don't touch license model.

~~~
teh_klev
Yes...and I also had Ted Neward's book "Shared Source CLI Essentials" to go
along with it:

[https://www.amazon.co.uk/Shared-Source-Essentials-David-
Stut...](https://www.amazon.co.uk/Shared-Source-Essentials-David-
Stutz/dp/059600351X)

The problem with Rotor was that they ripped out of all the good bits and
replaced with not so good things, for example they replaced the garbage
collector with a naive implementation.

That said I still learned quite a lot from studying and playing around with it
way back then.

~~~
Boulth
I've also read that book, it was excellent!

------
dusanbab
Back in 2008/9 I was a co-founder at a company (Red Five Labs) that created a
.NET Compact Framework runtime for Symbian OS (featured on most Nokia &
Samsung smartphones at the time). We got to a .NET CF 2.0 level of
compatibility.

It was a venture-backed startup out of Johannesburg, South Africa.

Although we wrote the runtime ourselves, we made extensive use of some of the
mono libraries until we were able to rewrite most of these optimized for
Symbian.

[1]
[https://web.archive.org/web/20100112091803/http://www.redfiv...](https://web.archive.org/web/20100112091803/http://www.redfivelabs.com:80/)

~~~
voltagex_
What happens to that code once the company disappears?

~~~
dusanbab
Unfortunately it went with it. There were some superficial talks about it
winding up in the Symbian Foundation, but those didn’t materialize.

And yes, it probably points to a major problem with a small company developing
critical framework or tool components when the codebase isn’t participating in
an open source license.

There were many mistakes made along the way, in retrospect.

------
alexvoda
Is the .Net environment in SQL Server since version 2005 considered a
different runtime?

~~~
danbruc
No, SQL Server just uses the normal .NET Framework to execute managed code
which is also implied by the name of the feature, Common Language Runtime
(CLR) Integration. Well, maybe one could also read this as integrating - in
the sense of implementing - a CLR into SQL Server.

~~~
sebazzz
Yes, SQL Server hosts the .NET framework runtime but with added security
configuration. There are also other applications hosting the framework (like
IIS), and you can actually host the framework yourself (both the full and core
framework). I was actually playing with the idea of hosting .NET addons in
Kodi but it turns out it is too much work for a single developer as a hobby
project.

~~~
snaky
What would be the advantage of .NET Kodi addons over Python? They would be
faster that's for sure, but if I understand it correct, addons are not the
main reason of Kodi suboptimal performance. The downsides are obvious - while
you can relatively easy skim over the source code of the Python addons, it
wouldn't be easy with .NET binaries - and most of the addons wouldn't provide
source code. And the regular user can easily hack the feature, fix or two into
Python addon code by himself, that wouldn't be so easy with .NET addons.

------
nailer
As someone outside the .net world, is there a wasm version? Can I run a .net
language in a web browser and have access to the DOM, or render the UI for a
.net app as DOM objects on a web page? That would be super useful.

~~~
codenesium
Blazor is coming. It's not GA yet.

[https://github.com/aspnet/Blazor](https://github.com/aspnet/Blazor)

------
swolchok
The recent Software Engineering Daily podcast on "Unity and WebAssembly"
mentions that Unity has a .NET to C++ toolchain. Is that some kind of stock
Mono feature, or is that another .NET runtime?

[https://www.softwaredaily.com/post/5ba9fdd63e3767000494fe01/...](https://www.softwaredaily.com/post/5ba9fdd63e3767000494fe01/Unity-
and-WebAssembly-with-Brett-Bibby)

~~~
elisee
That's probably IL2CPP, developed at Unity:
[https://docs.unity3d.com/Manual/IL2CPP.html](https://docs.unity3d.com/Manual/IL2CPP.html)

------
memsom
You missed two that I can think of: (1) the runtime written in F# that Frank
Krueger’s Continuous uses (and I believe also Xamarin Live player uses in some
fashion.) (2) Goa WinForms was a C# compiler that targeted the Adobe Flash
Player, and implemented part of the BCL and WinForms UI. If you include the
CrossNet I think this also counts.

~~~
matthewwarren
Nice! Thanks for the info, I'll check those out, I'd not heard of either of
them.

I think that an update to the post is due, turns out that I missed quite a
few!

------
stevefan1999
Let's look forward for .NET Core 3.0 and CoreRT: This would make it very
competitive to Go not only being both native and self-contained but also going
ahead in desktop-based, GUI programming.

