Hacker News Reader

Comment by bunderbunder | Hacker News Reader

Can he read the source of ASP.Net when he encounters an issue with the web frontend?

Yes. Recently they even went a step beyond the traditional "shared source" thing by releasing it under the Apache 2.0 license.

http://aspnetwebstack.codeplex.com/

Less so with MSSQL. But it's less of an issue there, because MSSQL provides a very good view of what's going on under the hood to begin with, and Microsoft has done an extremely good job of documenting the whole thing.

View on HN

Having worked on the MSSQL source code -- even if you could see it it would not help. It's a incredibly complicated monolith with a lot of historical baggage. Not kind to fresh eyes. Remember that SQL Server was originally Sybase SQL Server.

I remember Sybase ads from my teens. I did not know they were assimilated to generate MSSQL, interesting!

Actually, MS bought the rights to the Sybase software, not the company. There are still quite a few similarities.

That apocryphal last comment is irrelevant though as the code bases entire split many, many, versions ago. (pre 7.0)

Why wouldn't it be relevant? It emphasizes that SQL Server has been a product longer than Google has been a company. Moreover, there's still Sybase code still in the project.

Is the Sybase code the biggest problem? Hell no. How about the fact that there is no "standard library" and there are no less than four different hash table implementations written by different people at different times -- only one of which you should probably use, although you wouldn't know it from the "documentation"? That's a pretty big one and almost definitely what I'd characterize as "historical baggage."

And if memory serves it's been through at least one, possibly two ground up rewrites since then.

It's been through massive rewrites, but they didn't throw away the code and start from scratch. They took five years (between SQL 2000 and SQL 2005) and completely revamped the offering. Looking at SQL 2012, it's really quite impressive how far they've come along, albeit in 12 years.

Whoa. That is actually pretty cool. I didn't realize that Microsoft would open-source such a core piece of technology.

Depending on how you want to define "open source", they've been doing it for a long time. They often make the source available to look at, but don't permit the creation of derivative works.

That said, one of my the nicer things about developing in .NET is that the library source is so accessible. I can easily step into library code from the debugger if I need to. If I haven't already downloaded the source code for that component then the IDE will automatically grab it for me before stepping in. So for my purposes (just wanting to figure out WTF is happening under the hood), the source code generally feels much more accessible on Microsoft's platform than it does on more orthodox open source ones.

That depends on the library, of course. Yes, if the library is open source or shared source, you can step into it with no trouble. But if you're using a closed source library (a phenomenon that's far more common in the Windows world than in the Linux world), you're eventually going to run into problems where the library returns an unexpected value and you just don't know why.

He's referring to the .NET base class libraries (System.* and others). Microsoft releases the source so you can debug right into it.[1] The BCL is far from "open source", it's a "read only, nothing else, not even compile" type license IIRC. But you can step right into the C# implementation of most of the shipped-with-.NET libraries.

1: http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-...

But even then, it depends on the library. For the most part .NET assemblies are so easy to decompile that even when you don't have the source that doesn't end up being much of an impediment. (The only thing you really don't get is comments.) There are some vendors who insist on obfuscating their assemblies, but they're easy enough to avoid.

Even if they don't obfuscate the library's license will often have an anti-reverse engineering clauses.

Seriously? I can see a license that prevents you from creating a clone by inspecting decompiled source.. but a license that doesn't allow you to attach a debugger?

Wouldn't be enforceable, I'm guessing, as per the protections for reverse engineering that the DMCA codified in 17 USC ss. 1201(f):

. . .a person who has lawfully obtained the right to use a copy of a computer program may circumvent a technological measure that effectively controls access to a particular portion of that program for the sole purpose of identifying and analyzing those elements of the program that are necessary to achieve interoperability of an independently created computer program with other programs. . .

If I recall correctly, I read a while ago they have even opened up their kernel code to Univ programs. Don't know if that is still true.

They have done that for quite awhile, at least it was happening ~8 years ago when I took an OS course at my school. Windows source was available, can't recall which version.

Windows Research Kernel. It's an almost-complete source code of Windows ~2003. There's a few omissions, like the TCP/IP stack.

https://www.facultyresourcecenter.com/curriculum/pfv.aspx?ID...

Reply on news.ycombinator.com