Source code and managed runtimes

Source code and managed runtimes

Summary: Managed runtimes and self-describing code has changed Microsoft's approach to source code protection. We have access to more Microsoft source code than ever before, and that is likely to remain the case so long as Microsoft emphasizes .NET as its platform of the future.

SHARE:

I am not an enemy of proprietary software. That shouldn't surprise anyone, as I used to work for Microsoft, but besides that, I've written heaps of articles and blog posts explaining what I consider to be the advantages of incentives created by properietary software.

On the other hand, I also have a healthy appreciation of the goals of open source software advocates (less so free software advocates, as they move beyond the practicalities into advocacy of absolute principles with which I disagree). Source code access, quite simply, is of tremendous use during development. If nothing else, it provides you insight into how the libraries you use in an application will perform, but combined with modern debuggers, provides a development experience that allows you to trace the full execution path, and thus really get to the root of problems.

It is, quite simply, a more productive way to code, which may explain why Microsoft decided to make the full source code available for the .NET Framework as part of Visual Studio 2008. Old news, to be sure, and the utility is patently obvious to regular inhabitants of the open source biosphere, but useful to people who prefer developing using Microsoft tools and technologies (as I do).

Of course, .NET naturally lends itself to a more open approach to software development due to its self-describing nature. Even before Microsoft made available .NET Framework source code as part of the debugging experience, Lutz Roeder's .NET Reflector was one of the more important tools in my development toolkit. I could take any non-obfuscated .NET assembly (more on that later) and decompile it to the language of my choice. My current copy of Reflector includes decompilation support for IL (the "native" language of a .NET assembly, which looks a bit like an object-oriented version of assembly language), C#, Visual Basic, Delphi, Managed C++, Delphi, and Chrome (a language based on Object Pascal).

That makes .NET assemblies a bit like input into universal translators. Granted, the output language has to have support for object oriented constructs, but it is possible to decompile an assembly into any .NET-compatible langauge you want. Quite interesting, and far more open than the native code past.

Of course, obfuscation can interfere with that open process. Obfuscation takes that self-describing code and mangles it in a way that decompilers like Lutz Roeder's can't untangle. Personally, I consider such things to be downright unfriendly. I have a strong incentive to rewrite and replace the obfuscated assemblies I run across.

Most .NET assemblies I use, however, don't go through the trouble of obfuscation. That's good, in my opinion. Personally, I have little interest in maintaining the code of a well-working component upon which I depend. I don't have time to become expert in all the technology areas related to libraries I use.  For that reason, I'm not likely to want to do anything more elaborate with the source code I discover through decompilation (or the source code I get as part of open source projects, for that matter) than use it to assist me in debugging. 

I do want, however, the ability to do my job effectively. Source code access is increasingly a part of that.

Microsoft has shifted from hiding the source code to protecting their rights over it via licensing. That's a good shift, and though it won't ever satisfy the demands of advocates for free software , it might satisfy those with a more utilitarian approach to the art of software development.

Topics: Enterprise Software, CXO, Microsoft, Software, Software Development, IT Employment

John Carroll

About John Carroll

John Carroll has delivered his opinion on ZDNet since the last millennium. Since May 2008, he is no longer a Microsoft employee. He is currently working at a unified messaging-related startup.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

4 comments
Log in or register to join the discussion
  • FYI

    Back in the day, before Linux design automation became readily available, I went around DAC asking vendors whether they had Linux versions working in the back rooms even though they didn't have them in the official product list.

    The universal answer was that they [i]developed[/i] on Linux and ported to Solaris and HP-UX. The reason was that with Linux they could debug all the way up and down, clear to bare metal if necessary. Today Solaris support is an afterthought and HP-UX is a dim memory.

    An interesting side-effect, by the way, was a flood of patches submitted to the Linux projects. Nothing like giving good programmers a chance to debug and enhance [u]your[/u] code.
    Yagotta B. Kidding
  • Obvuscation? *giggles*

    To paraphrase a monarch: "Let them write perl."
    John Le'Brecage
  • When in Rome...

    When Microsoft enters a new market with incumbents, customers have expectations for their products which Microsoft will have to meet.

    Can you identify any way in which Microsoft has reduced sales of products as a result of this disclosure?

    Has Microsoft provided information which will improve the sales of competing products?

    Working out the consequences - good for increasing sales or bad for decreasing them -of opening the many pieces of source code must be part of the vocation of a number of people at Microsoft.
    Anton Philidor
  • Again we owe thanks to those we criticise

    "Microsoft has shifted from hiding the source code to
    protecting their rights over it via licensing. That?s a good
    shift..."

    MS provides some source and it is pronounced good.
    Previous MS didn't provide source and it was described
    good. See a pattern developing?;-)

    "..., and though it won?t ever satisfy the demands of
    advocates for free software..."

    Because open source and free software doesn't mean the
    same thing. Advocates of free software gain nothing from
    access to source with restrictive licenses.

    "..., it might satisfy those with a more utilitarian approach
    to the art of software development."

    I'm wondering why this wasn't blogged about before MS
    was dragged into providing source? Chuckles;-)
    Richard Flude