Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Microsoft Releases Source of .NET Base Classes

Posted by Soulskill on Fri Jan 18, 2008 04:02 AM
from the yes-there-is-a-catch dept.
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.'"
+ -
story

Related Stories

[+] Open.NET — .NET Libraries Go "Open Source" 310 comments
An anonymous reader writes "whurley just posted a blog about Microsoft's announcement To Make .NET Libraries available under a crippled 'Open Source' program using their new Microsoft Reference License. The post includes the official pr doc from Microsoft as well as several points about how this really isn't open source. One example: If a developer finds a bug in the code, rather than fixing it themselves and submitting a patch to the community they'll be encouraged to submit feedback via the product feedback center."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • by k-zed (92087) on Friday January 18 2008, @04:08AM (#22090818) Homepage Journal
    Microsoft has just begun killing Mono.

    (Think "oh, that implementation really looks like ours! you must have read it! here's a lawsuit for you")
    • by Jugalator (259273) on Friday January 18 2008, @04:16AM (#22090854) Journal
      They could already have done this if they wanted to though.

      (see also Lutz Roeder's popular .NET Reflector software)
      • mod parent up, you could already view the source code be tunining the internediate language back into c# or vb or c++ with reflector.

        This just means that you can debug it easier now (you could save the source code in reflector and use that do debug in the past)
        • That's not the actual source. It's an interpretation of what the source does. It's kind of like a reverse compiler if that makes sense. (At least that's how I understand it.)
            • by Nurgled (63197) on Friday January 18 2008, @08:38AM (#22092072)

              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#.

            • Re: (Score:3, Insightful)

              If you're able to get comments from a dissassembled binary, then something is wrong. The whole point of comments is that they are ignored by the compiler. If what you say is true, then MS really screwed up.
    • by apathy maybe (922212) on Friday January 18 2008, @04:25AM (#22090878) Homepage Journal
      Really?
      You have one person read the source, document it and put the documentation online somewhere.

      You have second person read documentation and re-write functionality of code.

      ReactOS does this exact same thing to re-implement the Win32 API, except that they have to 'break' the executable files. (My memory is shot, I can't remember the term for this, or the process as a whole...)

      So long as the documentation does not contain source, merely what each function does, and so long as there is no obvious link between the two persons, there should be no problem.
      • My memory is shot, I can't remember the term for this, or the process as a whole...)

        Clean room reverse engineering? Or something along those lines right?
        • My memory is shot, I can't remember the term for this, or the process as a whole...)

          Clean room reverse engineering? Or something along those lines right?
          I'm guessing he's thinking about "Chinese wall".

          You're right, "clean room" technique is probably the more correct term. But the term "Chinese wall" sounds more exotic, so I'm going to bet that that's the one he was trying to think of.
      • I seem to remember that interfaces could also come under copyright, so there's a potential problem wherever your using the same interface as the thing your trying to clone.
      • > except that they have to 'break' the executable files.
        > (My memory is shot, I can't remember the term for this,

        Decompiling?
      • Why not just have the developer read the .Net MSDN docs for the .Net API. It's not like anything they are doing is extremely complicated. You should be able to get things almost identical by just reading the .Net API docs. Granted, there's a lot of functionality, and it would take quite an effort to code all that, especially considering Microsoft's tendency to continuously add to the API, but it's not something that you would need to see the source to implement.
        • by Ash-Fox (726320) on Friday January 18 2008, @09:36AM (#22092752) Homepage

          Why not just have the developer read the .Net MSDN docs for the .Net API. It's not like anything they are doing is extremely complicated.
          Because the MSDN documents are not accurate. Many times I found the API documentation do not contain the true behavior of certain APIs. This is one of the reasons why Wine requires testing API functionality on Windows first instead of just basing it all on the MSDN documentation.

    • Except these look like they're just the core classes - which have ALREADY been implemented in Mono. We know that Mono team didn't have access to the source, so merely a timestamp on the source files will prove non infringement.
    • All things being equal, it's better if companies don't publish their proprietary source code under restrictive licenses.

      However, don't be overly dramatic. This sort of thing isn't new and open source projects know how to cope with it. Microsoft would have a hard time making any claim actually stick, unless there was blatant infringement. Furthermore, the Mono project can now also simply have some independent third party regularly check their code against Microsoft's to make sure nothing sneaks in.
    • Actually, that possibility is even more remote now:

      To help clarify and address these concerns, we made a small change to the license to specifically call out that the license 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. If the software you are developing is for Windows platforms, you can look at the code, even if that software has "the same or substantially the same features or functional

      • If the software you are developing is for Windows platforms, you can look at the code, even if that software has "the same or substantially the same features or functionality" as the .NET Framework.
        Mono is for Windows platforms and others. Seems like a gray area to me.
        • Re: (Score:3, Insightful)

          They clearly are developing software for the Windows platform. They can't use the source, but they can take a look and work out what the behaviour of the libraries will be in various corner cases so as to make sure that their libraries are compatible. In a closed environment, if I had access to source like this, I'd try to keep code writers away from it anyway, and only let the testing team read it in order to make test cases that check out all the corners. In an open source environment, however, I guess it
    • Re: (Score:3, Insightful)

      Microsoft has just begun killing Mono.


      I doubt it as the line I suspect you're referring to, "the same or substantially the same features or functionality" as the .NET Framework.'", could equally apply to Java.

      Bob
    • Very different sound actually.
    • Re: (Score:3, Interesting)

      Microsoft is actively working with Mono to make the "Moonlight" Linux port of Silverlight a reality.

      Scott Guthrie blog post about this [asp.net]

      "Over the last few months we've been working to enable Silverlight support on Linux, and today we are announcing a formal partnership with Novell to provide a great Silverlight implementation for Linux. Microsoft will be delivering Silverlight Media Codecs for Linux, and Novell will be building a 100% compatible Silverlight runtime implementation called "Moonlight".

  • The license 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.

    So you can look at the source all you want, unless you're a mono developer.
  • NOT open source (Score:5, Insightful)

    by LarsWestergren (9033) on Friday January 18 2008, @04:13AM (#22090844) Homepage Journal
    A few months ago, we discussed Microsoft's intention to open source the .NET libraries.

    Yes, and as one of the first posters pointed out [slashdot.org], unlike Java [java.net] for instance, this is NOT being published under an open source licence, Microsoft even says so. So why do you keep using the term?
    • Yes, they should be definitely be calling it a "shared source license" instead, since that's what it technically is.
    • Re: (Score:3, Insightful)

      The license is the "Microsoft Reference License", their "look, but don't touch, and refrain from competing" license. They've loosened it a little - you are now allowed to use the licensed material to develop software that has "the same or substantially the same features or functionality" as the .NET Framework ; as long as it's still on Windows.

      Very obviously a "back off!" clause for Mono and dotgnu.

      Previously, people referred to the source by using Reflector ; this of course, doesn't quite produce the same
      • I bet their webmaster has a comprehensive list of all IP addresses suspected to be OSS sympathizers....
        This AOL IP address don't look right, it must be a OSS sympathizer!
      • Re:NOT open source (Score:5, Insightful)

        by Coryoth (254751) on Friday January 18 2008, @08:39AM (#22092082) Homepage Journal

        ...to develop software that has "the same or substantially the same features or functionality" as the .NET Framework ; as long as it's still on Windows...Very obviously a "back off!" clause for Mono and dotgnu.
        Which is sad really. Only Microsoft could see such a requirement as good, and herein lies the problem of the monopoly. Ultimately .NET is a (relatively) nice programming framework and set of libraries, and were it developed by anyone but Microsoft they would welcome attempts to expand it's availability. Pretend .NET was developed by a small company that had focussed just on the Windows platform. If they were going to open source the libraries, the first thing they'd be doing is ensuring license compatability with Mono so they can expandtheir market. Hell, look at anyone other than Microsoft who do .NET stuff, like Chrome [wikipedia.org], or the .NET compiler for Eiffel: they both put in significant work to try and make sure they work with Mono (I believe the Eiffel guys actually have active discussions with the Mono team). In any sane world this would be the thing to do, it's only in Microsoft monopoly land that these sorts of license restrictions make any sense whatsoever. Which really shows you some of the ways the MS monopoly is holding the industry back.
    • 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 "unr
      • Re: (Score:3, Insightful)

        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.

        And thanks to you for rigid, dogmatic, inflexibile intransigence and refusal to recognize any deviation from your True Path in a world of absolutes as anything but schism and heresy. Hey look, two can play. I recognize your nick (I've was here originally with a 4-digit UID, with a name I've discarded). I always believed you were abov
  • Yay! (Score:5, Funny)

    by 4D6963 (933028) on Friday January 18 2008, @04:14AM (#22090846)

    Can't wait to see the best bits of it on The Daily WTF! \o/

  • by nighty5 (615965) on Friday January 18 2008, @04:32AM (#22090904)
    Too bad the library is written in VB....

    • What is wrong with VB.Net? It has exactly the same feature set as C#. I realize that it was bad in the past, but it's grown up quite a bit since the old days.
  • Reflector (Score:5, Informative)

    by Anonymous Coward on Friday January 18 2008, @05:00AM (#22090972)
    Of course, anyone doing serious development with .NET has been looking at the source for years now in any case by using Lutz Roeder's .NET Reflector, which is a C# (etc) decompiler (not just a disassembler). It's the only way to reliably discover and work around the horrible bugs and misdesigns in MS's libraries. (Yes, WSE, I'm looking at you.)

    Reflector is downloadable from http://www.aisto.com/roeder/dotnet/ [aisto.com]. And it's obfuscated, so it won't run usefully on itself :-)
  • Looks rather clunky (Score:5, Informative)

    by Dr_Barnowl (709838) on Friday January 18 2008, @05:30AM (#22091048)
    Has anyone looked at the instructions for using these sources in Visual Studio? It seems monstrously crippled compared to debugging third party sources in Eclipse.

      * Each source file you debug into is dynamically downloaded once for each session and not retained.
      * Setting breakpoints in the source is a multi-step process, because the source is different from the corresponding symbol files because the copyright banners they insert change the CRC. You have to tell the IDE to ignore that.
      * You have to manually tell it to load symbols for each file.
      * The symbols are also served up from an MS server (but they are cached beyond a single session).
          * Some of these symbol files are 10MB, so VS "may be unresponsive" while you download them.
      * "Go to Definition" doesn't work.

    This in contrast to the same support in Eclipse, where all you have to do is
      * Download the source
      * Tell the IDE where to find the source

    14) Can I point a web browser at the symbols URL and download the symbols directly?

    No, you'll get an HTTP 400 (Bad Request) response.
    So in addition, you'll need a professional version of Visual Studio, because the Express versions don't support the Source Server feature.

    Given that it all seems so inconvenient to use, I think I may be sticking to Reflector.
    • How long will it take somebody to sniff the protocol with Wireshark, and figure out how to download all the source code?
      • Or if you use squid or privoxy to proxy. That's how I get the updated Microsoft drivers and such from Windows update and flash based clips...<ahem>
    • I rather like it. The MS system pulls always exactly the correct file version for th DLL in question - after a patch, files are re-downloaded. And it doesn ot go into MS classes for single stepping without being explicitly told. In 90% of the cases that is what developers want. When I single step through a front end, I sont want to automatically go through all the stupid source of the components in question. If I debug a component, though, this may be handy.
    • Due to security reasons my computer at work doesn't even have an online connection. This is becoming more and more a nuisance, but the way Microsoft tend to deal with this is just horrible. One more reason to not go for Microsoft as the main platform. (offline activation sure is fun).
    • Re: (Score:3, Insightful)

      You have to manually tell it to load symbols for each file.

      Give them some credit here. You only have to tell VS to load files outside the current call stack.

      That said, I agree that this sucks. Needing to purchase VS 2008 and debug my code to see theirs is annoying to say the least. I was hoping to download the source and analyze Windows.Forms.Controls, System.Data.DataViewManager, and various implementations of the IBindable interface... Things that plague my understanding of the ".Net Maze" to this day.

  • You can only *look* at the code and you cannot re-distribute the libraries not to mention the legal aspects (specifically mono).

    This is probably only useful from an *educational* point-of-view and when you think about it, there is so much publically available code out there already how much more will you learn from the .net sources anyway (I'm sure someone here will prove me wrong).

    I thought one of the major benefits of OOP was code abstraction - in theory there should not be a need to see the implementatio
  • it's not open source (Score:5, Informative)

    by nguy (1207026) on Friday January 18 2008, @05:41AM (#22091094)
    Microsoft is not releasing those libraries as open source. What they are doing is what they and other companies have been doing for a long time: releasing some of their source code in read-only form to "help" people debug.

    In fact, the real problem with this is that, in case of ambiguities, people will code increasingly to Microsoft's source code instead of the specification. Furthermore, after having released it, Microsoft may attempt to claim that the Mono project copied some of their source code in violation of the license.

    One can't prevent Microsoft from doing this, but it's not a good thing.
    • Re: (Score:2, Interesting)

      Absolutely agree!

      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 .net in a m
      • My question is:

        If you see a "bug" in Microsoft's code, can you write a fix for it, date stamp it and sell it to MS as your code with a restrictive license?
    • Re: (Score:3, Insightful)

      In fact, the real problem with this is that, in case of ambiguities, people will code increasingly to Microsoft's source code instead of the specification.

      Come now. One of the benefits of open source that we constantly hear is that if any question of the actual behavior of something comes up, the developer can go straight to the source. Now you are saying that this is a bad thing?

      I agree with you that developers should code to the interface as documented, but if that is the case then most open source developers should not look at the source code for the underlying packages they use.

      I think MS is doing this to make life simpler for their customers and

  • by Fross (83754) on Friday January 18 2008, @05:46AM (#22091128) Homepage
    I thought it meant the developer who originally wrote them has been let out of his nice padded room.
  • by Anonymous Coward on Friday January 18 2008, @08:38AM (#22092074)
    This release is not intended to benefit the Slashdot crowd. Of course it isn't "open source", and Microsoft never said it was. This is Microsoft assisting developers working with .NET on the Windows platform. There are a huge number of developers who fit that description. Sorry if you don't, but not everything is about you.
  • by aldousd666 (640240) on Friday January 18 2008, @08:51AM (#22092196) Journal
    The CLR 2.0 source [microsoft.com] (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.
      • I wondered about that myself, actually. There is nothing that Microsoft distributes or sells that opens gzip or even tarchives for that matter. Nothing on WinInternals (formerly SysInternals) either. It's like they're saying 'here you go you open source freaks you can have this, but figure out how to open it yourself. We know you already have all the gtools installed, or just fire up your beloved mingw environment, you bunch of lazy whining traitors.' Haha, so I went a little overboard on that, but I thi
      • Re: (Score:3, Informative)

        I love how they indicate which packages you'll need, WinZip and Perl. Perl. How did I miss that being included in the VS canon?

        On Windows you will need:
        Windows XP SP2.
        Microsoft Visual Studio .NET 2005.
        Perl 5.8.7 (available from http://aspn.activestate.com/ASPN/Downloads/ActivePerl/.)
        Archiving utility of choice--WinZip or other.
        256 MB of memory.
        One gigabyte of free disk space.

        And then there's this:

        Features
        The Shared Source CLI archive contains the following technologies in source code form:

        • An implementation of the runtime for the Common Language Infrastructure (ECMA-335).
        • Compilers that work with the Shared Source CLI for C# (ECMA-334) and JScript.
        • Development tools for working with the Shared Source CLI such as assembler/disassemblers (ilasm, ildasm), a debugger (cordbg), metadata introspection (metainfo), and other utilities.
        • The Platform Adaptation Layer (PAL) used to port the Shared Source CLI from Windows XP to other platforms.
        • Build environment tools (nmake, build, and others).
        • Test suites used to verify the implementation.
        • A rich set of sample code and tools for working with the Shared Source CLI.

        So it only does C# and JScript? WTF, hello, VB? Also, what other platforms? Vista? I thought that a