With all due respect to the esteemed Senator from MuleSource, I wonder what Dave Rosenberg has been smoking. In this blog posting, Dave says that Microsoft's release of the source code to the .NET Libraries is "a patent trolling dream."
I've dealt with my share of patent trolls (I was an expert witness defending against a big one), but I'm also an experienced developer who is familiar with Microsoft development tools.
Microsoft has shipped the source code to its C/C++ runtime libraries with Visual Studio for many years. The practice of publishing copyrighted source code is hardly new: it goes back at least to DEC and IBM. For example, I used to read Dave Cutler's source code for RSX-11M in the 1980s, and I read IBM VM-370 system routines in the 1970s.
If I look in my C:\Program Files\Microsoft Visual Studio 8\VC\crt\src directory or my C:\Program Files\Microsoft Visual Studio 8\VC\atlmfc\src directory, I can view the source code for any of the C/C++ runtime library, MFC, and ATL routines. Sure, the source code starts with a Microsoft copyright claim, but frankly I don't care:
/***
*abs.c - find absolute value
*
* Copyright (c) Microsoft Corporation. All rights reserved.
*
*Purpose:
* defines abs() - find the absolute value of an int.
*
*******************************************************************************/#include <cruntime.h>
#include <stdlib.h>#pragma function(abs, _abs64)
...
What's important to me is that I can debug into the library routines if and when they are implicated in programming problems. abs() is a bad example, because it's not something I'd misuse, but there have been plenty of times when being able to debug down into the library has shown me where I've gone astray.
What about the .NET Framework libraries? Well, for one thing, for the basic libraries I can refer to the .NET Framework Standard Library Annotated Reference (Addison-Wesley, 2004 and 2005), of which I was an editor, and find out not only how whole classes and specific members work, but what the designers were thinking. For another, I can use Lutz Roeder's .NET Reflector and see the source code reconstructed from the compiled code, along with the documentation.
Why does that work? Mostly, because the .NET Framework compiles to an intermediate language (IL), not native code. The IL gets JIT-compiled at runtime (or at installation time for the libraries), but that doesn't interfere with the IL and metacode information in the assembly.
In addition, Microsoft chose not to scramble or obfuscate the .NET library code. They have always wanted developers to understand how the library works.
So what's new? Three things: more libraries are being released as source than are covered by the ECMA/ISO standards; we'll be able to debug directly into the library source; and we'll be able to see the internal comments. If history is any guide, the internal comments will be rife with misspellings:
*Exit:
* returns the aboslute value of number
Brad Abrams has a posting about the source release here. He in turn links to a posting by Scott Guthrie and a podcast by Scott Hanselman and Shawn Burke.
Posted by Martin Heller on October 5, 2007 08:18 AM
