A History of .NET Runtimes
mattwarren.org
mattwarren.org
(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.
As a matter of interest, what did you do on the CF team?
Post Sathya Microsoft has moved to a more open model, hence the full blown CLR on Linux.
Thanks, I'd heard about 'cool', but I didn't know the part about Omni VM, that's interesting to know
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/Events/Build/2012/3-005
.NET Native is an improvement of this work.
> 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
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.
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)
[1] Was MS Technical Fellow and author of 1998 COM book: https://www.amazon.com/Essential-COM-Don-Box/dp/0201634465
And Bill certainly did program in low level assembly. The last Microsoft code he wrote himself was in the ROM of the Tandy 100 portable computer.
But they sort of missed the point of Java, which was that it was cross-platform, and a single Java package could be expected to run on a variety of hardware and OS loadouts with no changes (except maybe in configuration). Microsoft, at the time, wanted .NET to be closely tied to Windows, and though the base libraries were submitted to ECMA, to get anything useful you had to have Windows and Microsoft's Windows-only libraries. (There was Mono, but it was not compatible with Microsoft's stuff and few on the Linux side wanted to touch it.)
Things are changing, obviously, with .NET Core. We'll see if Microsoft or someone else solves for cross-platform GUI and other end-user concerns, where .NET has historically been strongest.
Microsoft's biggest internal teams turning against .NET during Longhorn created a schism that the company has never resolved. I often wonder what might have happened if they'd had the requisite leadership to force the change through organisation-wide, and MS had spent the last 15 years with a single, rational dev story.
However given the last Office related announcements, it appears that the reorganization did little to sort out those political issues.
Regarding the political issues, the Silverlight/WinRT clusterfuck also helped with WindowsPhone downfall. Release 1.0 and next major update offered a API incompatible with 1.0, what a clusterfuck....
they do not need. they have xaml over xamarin.forms, which supports all major platforms (including desktopn and mobile) it still says that its in preview however the only things that did not work well is when you need some kind of file interaction with the os, you need to create native views for all your OSs (i.e. NSFilePicker, OpenFileDialog, etc..) since there is no Xamarin.Forms widget for that. besides that it is already really mature.
It's called UNO, check out https://platform.uno/ and https://platform.uno/#Comparison
!! By the way to anyone who wants to build a system in UNO - I would like to build one. !!
I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.
I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.
I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.
If you're interested to build a system or product built on UNO with me, get in touch!
From my understanding, the Office apps that were killed were supposedly forked from the web apps and actually ran as UWP HTML/JS.
Meanwhile, Office has also announced plans to move forward with more UWP XAML Islands to integrate more Fluent Design in the UX starting soon after the Windows October release, and part of why the Office 2019 LTS was shipped where it was and arguably why Office 365 pushed to align to only support latest Windows releases so they could move forward on Fluent Design dogfooding.
They did sunset the non-UWP OneNote with this LTS release, and the UWP XAML app is supposed to be the only Windows version of OneNote moving forward.
The implication I take from the UWP "Office Mobile" app shutdowns is that Office is now confident that if UWP returns to mobile it will do so with "real" Office, which was my takeaway from BUILD that that was the strategy they were pursuing.
I think it's another case of Microsoft not being able to properly spin "nuance" in a press release, because they don't want to comment on future plans or publicly commit to things still in flux/prototyping/development.
I think it was a forced choice. Even if Flash had been supported, most flash sites and games would not have worked well on a phone.
From the fragments of leaks I read about the internal strife, the .NET code had huge performance problems and the C++ team was frustrated that "DevDiv" couldn't solve them. ("DevDiv" is Developer Division that owned NET Framework.) Therefore, they ripped a lot of "managed code" out and redid it in native code.
I hope that one day, an ex-Microsoft programmer or product manager writes a tell-all book of this period. It would be a fascinating case study.
"Safe Systems Software and the Future of Computing"
https://www.youtube.com/watch?v=CuD7SCqHB7k
Sorry a bit lazy to track down the exact moment.
I agree with those 2 forces:
1) the raise of javascript: Now is starting to develop an answer to this in Blazor (https://github.com/aspnet/Blazor)
2) iOS and Android: both are here to stay, so Xamarin is the answer. I have been using Xamarin for iOS and all though still lack of some maturity, in its actual form is very viable.
I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.
I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.
I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.
I've also done a lot of Razor MVC and modern web front end and I can't wait to get into Blazor as well - it seems about the dream platform for my style of development.
If you're interested to build a system or product built on UNO or Blazor with me, get in touch!
[1] Four and a half years! Nowadays it seems like Angular and React are pushing major versions every four and a half minutes.
Remember when Microsoft was adding '.NET' to practically all of their product names for a time? That was fun...
There is still time. It just recently got open-sourced, got a compiler written in itself and got a run-time unbundled form all the legacy crap. Those things held C#/.NET back. I feel this is a good time to adopt it for people who want to have reasonable performance, static typing and a mix of OOP/functional paradigms.
My two notes on C#:
1. It is possible to write reasonably "functional" applications in .NET. The only problem I had with that is lack of built-in copy-on-write data types and prevalent nullity.
2. LINQPad is the best damn scripting environment I ever worked with.
Then big data became a thing, and basically the entire core ecosystem was written in Java. I think it's becoming a bit of a wedge issue - Java has everything that .NET has, but .NET does not have its own equivalent of, for example, the Hadoop ecosystem.
You can use Hadoop "Streaming" with .NET easily enough and still take advantage of the "Hadoop ecosystem".
Orleans is not exactly Hadoop, but it's close enough that conversions between are relatively straight-forward, and Orleans is useful for a number of other work distribution patterns beyond map/reduce.
Beyond that, the map/reduce pattern is one of the easiest abstractions to reimplement yourself from scratch if you get the itch. I believe Hadoop is relatively over-rated from that standpoint, and arguably IMO another case of Java developers over-ceremonializing what should be a simple, lovely abstraction/design pattern into a weird spaghetti mess of configuration and ritual.
C# certainly has many features that Java, the language, does not. It gets better if you consider Kotlin instead, but it's not clear to me if that language has a chance of becoming on par with Java, popularity-wise.
Java offers nothing for game developers, there're multiple game engines written in .NET or using .NET. Java only runs on Android, .NET on all mobiles. Native interop in Java is a joke.
Khronos does have some official OpenGL specs for Java. There are none from them for .NET.
Java runs on iOS via Codename One and Gluon AOT compilers.
Native interop in Java was made hard on purpose, as Sun was pushing for WORA. Oracle is in the process of improving the situation with Project Valhala.
I love both stacks, truth is that .NET still has a bit to catch up outside Windows, while Java lost a bit of its mojo on desktops.
About native interop, I know Java did it on purpose, but as a developer I don’t care much about the rationale. I’ve heard about upcoming Valhala years ago (announced in 2014), still not ready.
Related to both of them, .NET core 2.1 already has SIMD support. Some parts of it is experimental, but it already works more or less OK, esp. on Intel/Amd.
Problem was that Sun never was too serious about their Java Gamming initiative.
Unity only adopted C# after moving out of the Mac into the PC, and it was stuck for ages in 3.5 as they didn't want to pay for the new licenses. Which meant it grew to a kind of C# dialect, which is being fixed now.
ManagedDX and XNA were Quixotic projects not well seen by WinDev. Which replaced XNA with DirectXTK when given the opportunity.
Which took a couple of years effort until Microsoft acknowledged the work done by the MonoGame guys.
Things take ages in Java because there are multiple vendors and everyone has to contribute to the process.
Intel has provided SIMD auto vectorization improvements. There are a couple of talks about it.
Not quite true; Unity has always used Mono. The very first Unity 1.0 version in 2005 was already using C#/Mono.
> Which meant it grew to a kind of C# dialect
Unity never had it's own "C# dialect".
Actually there are occasional questions on C# forums caused by people learning C# via Unity and then facing issues when using pure .NET.
Then there is the new HPC# for the new ECS and Job systems, which subsets C#.
As for Mono being already in 1.0, OS X only version, I am unsure about it, but the old blog was taken down. So I take your word for it.
The new HPC#/Burst indeed are subsets of C#, but that's a very recent development, and completely unrelated to "Unity had to make their own C# dialect to avoid Novell/Xamarin licensing issues".
> As for Mono being already in 1.0, OS X only version, I am unsure about it, but the old blog was taken down
I have worked at Unity since 2006. Yes Unity was Mac only at that point, but it still used Mono there.
I agree, that's quite a nice summary of the 2 ecosystems
I've tried to minmise that pain over the past few years with my 'functional language extensions' for C# [1].
It's a library with most of the common monadic types (as structs so there's no null issues); Immutable collection types that don't have an unweildy naming scheme like like the System.Immutable.Collections library - which are all structs, so no nulls; A type called 'Record<T>' which when you derive a type from it gives your type value-semantics (equality, ordering, GetHashCode, ToString, serialisation/deserialisation) by default; and tons more.
You still have to do stuff like build your own With method for immutable types. I have written of how these can be achieved _realtively_ easily [2]
C# has made great strides over the past 10 years to make it easier for those of us that want to work functionally to do it. It still has some way to go (discriminated unions, higher-kinds, record types, etc.) but it's already possible to write code functionally - you just need to do some boilerplate every now and then.
[1] https://github.com/louthy/language-ext
[2] https://stackoverflow.com/questions/38575646/general-purpose...
I've read that the next C# will have non-nullable reference types, have you thought about how to make your framework fit in with that? It's a "natural" Some/None in a way.
Thanks :)
> It's a "natural" Some/None in a way.
If we lived in the perfect non-nullable reference world from the start then it's arguable whether Option<A> would ever have been needed - and so going forward it should be needed less, or not at all for some devs. The question comes when you need an optional value, and so you use nullable references instead of Option<A>. With nullable references the `null` still honours the contract of `A` - this is what Option<A> protects against. If the flow-analysis for nullable references is good enough to spot that you're possibly going to use null and then forces you to use a predicate of some sort (if/switch/ternary/...) to validate the referenced value exists then I think we're good. I understand that is what's planned, but it needs to be bulletproof.
There will be devs working in the nullable reference world for a long time (due to difficulties with moving to the new world when it comes) - and so I fully expect Option to be useful for its null protection reasons for a long time.
The story is a bit bigger than just protection against null though. If instead of seeing Option<A> as A|null, you see it as A|B, where B is the single-value type: Unit. Then Option is A|Unit. If you then look at Either<L, R> which is designed to represent one of two alternative values: L|R then it's pretty easy to see that Option is Either<Unit, A>. And then when we look at Try<A> which is designed to return A or capture an exception and return it as a value, then that can be seen as Either<Exception, A>...
All of the types that represent one of two values have lots of additional powerful functionality: Fold, Map, Bind, BiFold, BiMap, BiBind, etc. and have been designed to seamlessly switch between each, which won't exist on the standard nullable reference types. So, there's still a place for Option in the bigger scheme of things.
Personally, I can't wait for non-nullable references to come in. I built language-ext to try and get a handle on a 10,000,000+ line code base that kept falling foul to null reference exceptions (along with other common C# coding world problems). It was 100% to help me and my team build more robust code. Non-nullable references is a feature we will turn on immediately, even if it takes a week to fix up the warnings and errors it spits out, this is going to be one of the most important updates the C# team have done.
A cross platform version is high on my wish list.
He didn't program in BASIC, he programmed a BASIC interpreter in 8080 assembly.
https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
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.
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.
LINQ is a good one though, that’s definitely a .NET innovation.
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/2012/06/19/some-histo...
https://blogs.msdn.microsoft.com/dsyme/2012/06/26/some-more-...
Additionally C#, like Java, also had CMU, ML, Ada, Eiffel, Sather, BETA, C++ and Modula-3 as possible sources of inspiration for generics.
But Generic Java was started in 1998 (IIRC originally as part of Pizza). It seems reasonable to say that Java covered this ground first.
Although what Java got wasn't all of Pizza, which had better generics.
I played around with Pizza (AKA Generic Java) in the late 90s, before the launch of C#.
That one at least is incorrect - C# had generic types long before Java
I had the wrong idea because (if I understand right) C#’s generic collections seem to be a copy of Java’s (which in turn were inspired by C++’s STL). Do I have that one the right way round?
The C# collections use generally poorer name choices (e.g. IEnumerator, which does not actually enumerate the elements) so I assumed they wanted to avoid making it identical to Java.
I think STL was the first mainstream one. I guess some of the ideas came from Ada? But I don’t know if Ada had standardized containers.
Long before STL was a thing in C++.
Stepanov started STL original design in Ada, before switching to C++. Recent Ada standards have adopted collection classes as well.
That depends on who you ask.
My opinion is Java doesn’t have proper generics. In Java they’re just language-level syntactic sugar.
Type system is broken i.e. type information is lost at compile time. This makes it hard to do functional-style programming in Java, that’s why other people made Scala.
Performance is broken too, generic containers box everything into objects causing huge performance penalty for containers with value types.
I think you mean “the same people”, at least in the specific case of Martin Odersky. :)
> Functional deeply integrated into a mainstream language (LINQ c# 3)
> Unified graphical application model incorporating all main styles of web, forms, svg, and 3d. (WPF .net 3.5)
> Compiler language services (c# 5)
> Async await (c# 5)
https://www.amazon.co.uk/Shared-Source-Essentials-David-Stut...
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.
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...
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.
https://docs.microsoft.com/en-us/sql/relational-databases/cl...
https://docs.microsoft.com/en-us/sql/relational-databases/cl...
Shameless plug - do you want a system built with either Blazor or UNO.
I'm a .NET developer with the perfect experience to leverage this system. I've been doing full stack and front end on various platforms for 20 years, and .NET for 15 years (version 1) and thus can leverage UNO to provide rapid and quality development.
I've already done advanced XAML in Silverlight and WPF with MVVMLight and PRISM application architectures based on TDD/CI/CD, animations, transforms, control templates, control building, designing products.
I'm also good with Blend and do the roundtrip Blend designer to Visual Studio developer workflow, or do both parts myself to design a full front end UX, UI, and code, and well as the rest of the full stack.
I've also done a lot of Razor MVC and modern web front end and I can't wait to get into Blazor as well - it seems about the dream platform for my style of development. I would favour Blazor because it's in the html and browser world and closer to the rest of the industry and an more open platform.
If you're interested to build a system or product built on UNO or Blazor with me, get in touch!
https://www.softwaredaily.com/post/5ba9fdd63e3767000494fe01/...
I think that an update to the post is due, turns out that I missed quite a few!