Microsoft Releases Source of .NET Base Classes
Disgruntled Fungus writes "A few months ago, we discussed Microsoft's intention to open source the .NET libraries. According to a developer's official blog, the source code is now available. The source to libraries such as System, IO, Windows.Forms, etc. can now be viewed and used for debugging purposes from within Visual Studio. Instructions for doing so have also been provided. The source code has been released with a read-only license and 'does not apply to users developing software for a non-Windows platform that has "the same or substantially the same features or functionality" as the .NET Framework.'"
To my bearded friends from 1998: great work making an already confusing term "Free Software" even more confusing by rebranding it "Open Source Software".. this is the result. I know, I know.. you considered a whole lot of different alternatives but nothing really struck the chime like "Open Source" but maybe we all should have looked a little harder. How about "Unrestricted Software". It makes even more sense today, what with DRM and all. And the BSD trolls can still have their arguments about what "unrestricted" really means just as they do now about what "free" and "open" really mean.
How we know is more important than what we know.
Absolutely agree!
.net in a major project at work and as yet not needed to see the source code of the libraries (I probably never will) and I know there are bugs/'features' in the libraries but there are workarounds - it's not stopped us so far.
.forms library - just you watch!
You have to be *careful* how you use this.
Mind you what if you *do* discover a bug in Microsoft's code, what can you do?
You can't modify the source code - 'it's read only', even if you were allowed to to modify it you'll 'break' standards.
You can tell Microsoft - we all know how well they listen to 'customers/developers' and how long will it take them to fix it.
If you also use mono you will not be able to contribute to the project because you have seen 'the code'.
I've been using
I really don't think it's in mono's interest to try and keep compatibility with Microsoft's libraries (it's that old Microsoft Treadmill routine again).
I imagine at some point Microsoft will release a future library that will make the current version obsolete - they are already doing this with the
Mono and it's developers have put in too much hard work for this to happen - mono should follow it's own path and develop libraries from the 'ground-up'(e.g. gtk#) rather than attempt to keep up.
We should have more faith in the mono project rather than constantly 'slam-it' for 'patent issues' or because Micorsoft 'invented' it.
It is correct to say that .NET Reflector is a decompiler. It just happens that IL (the bytecode that .NET languages compile to) is quite high-level, so it's much easier to turn IL into readable C# code than it is to turn x86 machine code into C. .NET assemblies also carry a lot of metadata along with the code, allowing Reflector to find the namespaces, classes, properties and methods without needing the original source code. Reflector itself also does some other magic when possible. For example, it can read in the debug information that the C# compiler can optionally produce (the .pdb file) and use that to fill in the things that you can't find out from the assembly alone.
An interesting (for some values of "interesting") exercise is to take some VB.NET code, compile it and then use Reflector to view it in C#. Since the two compilers don't generate completely equivalent code, you can get some unexpected results. A good example to try is some VB.NET code using late binding of methods on variables of type "Object", which isn't a language feature in C#.
The CLR 2.0 source (the runtime, not just the BCL) code is up too, it's in C++, not managed code. Strangley the article and summary seem to completely miss that fact. I'm very surprised, because it's much more significant, and it can't be ascertained using the decompilers like the managed code can. THIS is probably the thing that can kill mono.
Speak for yourself.
Microsoft is actively working with Mono to make the "Moonlight" Linux port of Silverlight a reality.
Scott Guthrie blog post about this
seven two six five
seven four six one seven
two six four two e