2 words, trade secrets. Microsoft would loose its competitive edge if released the source, even if it was for Win 1.0 right now. Sure, probably none of that code exists in XP or Longhorn, but still.

As an MVP for a Windows product, I had access to the Windows source code, and it actually did come in handy - not all the time, but occasionally. The company I was working for at the time was having issues with Roaming Profiles, and we had started a support call with Microsoft about it. The information the technician gave us just didn't sound right, so I read the source code for how Roaming Profiles are handled (the tech was *TOTALLY* wrong, by the way) and was able to solve the problem based on that.

Seeing the source code does help, for example, when seeing if the function does what it's supposed to do, or if the bug is at your code passing bad parameters or if it's at the library code...

Another example, I'm working with NPersist, and debugging into the code helped me understand a mistake that i couldn't figure out.

So, sure, MS probably can't open up all of it's code, but maybe relevant sections...

The are a few reasons people think they want it:

(1) Debugging beyond symbols, i.e. you can see how it works which can help diagnose things a lot quicker.
(2) The API isn't fully documented and some 'private' things would be good to get at. Especially if you are a competitor outside Daddy.
(3) Trust and Risk. The Govt licensing is kind of like ESCROW, more of a 'what if' than actually useful for engineering.
(4) Security. Threat model and proof/completeness is scarey without source. Security/Obfuscation etc.

Plus a bunch more I guess.

- David

There has never been a reason were i have actually needed to see source code to a OS either for windows or linux.

Check out the shared source initiative.
http://www.microsoft.com/resources/sharedsource/default.mspx

I'd do my very best to never lay eyes on it.

As far as I'm concerned open source code should be clearly GPL, or clearly BSD, or else I don't want to have a bar of it.

I wouldn't want to expend my energy learning about code I couldn't use, and I can't imagine the code would be terribly useful to me anyway.

I love to check out the Mono source to learn about how the BCL is implemented though.

I've sometimes looked at Rotor source to work out how the Framework does something, but normally to satisfy an interest rather than particularly because I was having a problem. I like techie details.

I've dug around in Windows CE source code - having to download the evaluation edition - in order to try to achieve a particular goal for work. Example: there are no APIs for setting up a modem. Sure, you can call RasSetEntryProperties, but there's no documentation on the BLOB for modem connections. It turns out that for UNIMODEM connections, it's a particular format that's in Platform Builder but not in public SDKs. There are no APIs to manipulate this BLOB. For enterprise, locked-down applications that need to perform remote comms, we need a way to take a device from a no-battery state and restore our software and all its required settings. Sometimes, such as with locales, we have to avoid the OS feature because we can't configure it programmatically from a cold boot.

Recently I was trying to provide a friendly user interface for configuring WiFi and IP settings for a device, and capturing that configuration to persistent storage. It looks like the way to configure WEP keys is to use the WZC interfaces, but the header is only available in Platform Builder, and it has zero documentation - the only example is the NetUI module. I was stumped on that one because, I think, the interfaces changed between versions and I didn't have CE 4.2 source available.

Enterprise device users - where the device is used in workflow - allow their units to become completely flat. (Battery, although falling-under-a-truck is common too!) We have to make it possible to get the unit back into service as quickly as possible, ideally just by fitting a charged battery and waiting a couple of minutes. This is usually possible if the OEM has implemented an internal flash store as a storage card so Autorun works (e.g. HHP, Intermec) or has an alternate solution (Symbol's RegMerge driver and CopyFiles utility, which if used to copy a shortcut to the shell's Startup folder can be used to launch anything).

On the whole, though, if I had to choose between good documentation and the source code, I'd pick the documentation - if it was accurate. Having both, with a clear guide on where to look when the documentation runs out of detail, is the ideal world. But obviously I recognise that whatever the licence says, people will steal source code.

Well, I'd say I don't *need* to be able to see it, but it can make things easier at times. For example, the .NET framework is essentially available in source-code format, if you've installed Reflector, and it can often-times help to understand how it works. Especially when the documentation is a bit lacking, or too high-level or whatever.

That said, the Windows code is far more complex than .NET, and it might be hard to follow it through from user-mode calls, through the jump to kernel-mode and back. Not impossible, of course, but maybe more trouble than it's worth.

I took an OS course in college that focused on Windows NT (Windows 2000 hadn't come out yet). My class had to sign an NDA, but we were allowed to look at the source code Windows NT. It really helped in understanding how I/O Completion ports worked.

See this recent discussion from Adam Barr.
http://www.proudlyserving.com/archives/2005/05/microsoft_and_i.html

I just love linking things together.

Your Fired!

Would there not be intellectual property issues there?

I could also see it making life marginally easier for those people whose sole motive for understanding Windows better is to find vulnerabilities to exploit in one way or another.

With something as huge as Windows I personally doubt the value of seeing the source: exactly *who* has the time to get their head around it?
Do I really want the pain of trying to debug Windows?
Personally I'd rather tell MS when something doesn't work and let them sort it out. Life's too short.

The only reason why there are so many Unix OS around is because it is simple and a good (only?) operating system with books about kernel architecture and OS designs. This is what every student will learn - and it will use Unix (for example Minix) to start building his own OS (for example Linux).
NT Kernel or at least it’s stripped-down and simplified version should be available to public, as well as good book(s) explaining what, why and how. This could help bring NT kernel into universities, their curriculum and more books which study OS design (this is the area heavily polluted by Unix).
I believe this give Microsoft and Windows public image lift. Simple comparison of basic system and logic behind Unix vs. NT should give everyone idea of how more modern and better designed Windows is in comparison with Linux or Mac X (or any other Unix).

PS: http://research.microsoft.com/~daniel/uhh-download.html

I second releasing the NT kernel for learning purposes. It's a good way to understand how to develop a modern kernel not something a couple of decades old. Competitors could use the source to understand the kernel better and provide some of the features in their product but the risk is somewhat minimal. Releasing the source would open up a new stream of revenue for MS though and from the looks of things they're trying to hold on to the cash they have while aquiring more. I'm probably wrong on that assumption so you can slap me if you desire.

There may be a lot of risks involved in releasing it but maybe MS should start weighing them to see if they'd ever release the source to anything like that. Windows and Office are Microsoft's biggest products so I wouldn't expect them to be completely open but giving out some important nuggets could have a huge impact. I know I wouldn't be looking for exploits but rather ways of doing things just a little bit better or differently than I currently am. Not everyone is looking to develop new malicious software for Windows and I don't think the source would help them that much more than the leverage they already have. They've done this well with 0% of source code yet haven't dented Linux or OSX with 100% source for Linux and only application source for OSX. They target market share but they only need to use the system to understand how to exploit it and source code would do very little to help them since it doesn't seem like they even know how to read it for the most part.

I wouldn't read it but I sure could use it. In other words, there's an advantage to having the source available. For one, it would help existing open source initiatives get better compatibility with Microsoft products. See Wine and Apache POI for example. The end result is I would be helped out indirectly as I use these types of products. Imagine what could happen if the Wine project could achieve upwards of 95% compatibility or better. I'd no longer have to reboot my machine to check my Artisoft Televantage messages. I could run my favorite media player (not Windows Media). Those are just a few things that come to mind.

Personally I dont really think i'll spend my weekends looking through windows code, even if the code was available.
I just want to develop good software at the right time, and generally that dosent mean looking through what everyone else have allready made. Rather it means trust that the components you relay on are working, and thats what I do with Windows.

On the other hand it would make me feel good if all the super geeks out there, without girlfriends, could spend their weekends looking through the source, and then tell me "Its all gooooood". Can I get that?

Kind of surprised no one mentioned it yet, but if MS did release the source to the kernel so you'd be able to see the not yet explored bugs (as every app has - yes I do like MS and Windows) wouldn't it expose the users of that systems to a grater risk ? I think MS can release the source to something like Windows 3.1 that no one uses anymore, but that's about it, unfortunately there is still plenty of users on W95 and NT OS's :(

I meant to say "the source of the kernel" :)

CzechMate: I think that the general oppinion is that security through obscurity (http://en.wikipedia.org/wiki/Security_through_obscurity) isent the best protection, but ofcourse the argument has some sense to it.

On the other hand there is a major chance that security holes would be made public and fixed, because of all the good hackers out there, looking throug the code and telling MS "Look, theres a hole in my IIS!".

Now I have a problem with theory that bugs and security holes can be found by looking at the code. The problem is that I am a developer and I have systems to maintain. You cannot find problems by just looking at the code (at least not in large systems, and not with solid developers). Otherwise my life would be so much simpler.
And if closing the source is not the best protection, it still is protection.

I'm the first to admit that I'm not a typical developer, but I helped a customer fix a system that processed over $1M of business a day by reverse engineering part of kernel32.dll. I eventually found a bug in EnterCriticalSection. It would have leapt right off the page at me had I had the source.

However, it took quite a while before I convinced myself that it was a problem with Windows and not their code, so I don't know that it would have saved more than a couple of days.

Generally speaking, though, it's nothing but beneficial to customers to have the source - the question is whether it's beneficial to *Microsoft*.

Regarding the "security through obscurity" - sure I'd like to be able to better debug problems etc but the fact is that if there is code available, bad people (well they prolly aren't bad, they just have other problems) have much improved chance of using modern analysis tools against the source to find holes. So in the big picture I think the no-source is another layer of security, but for developers and the kind there should be more layers so that you could delve deeper (similar to Reflector) to the code up to a certain point. And this is what MS is kind of doing, just look at the Avalon and managed code in general. It's layers of managed code you can view with Reflector and I don't think they are trying to obfuscate their managed code.. But when going really "deep" you have MILCORE native dll that Avalon/managed code calls for certain innovative stuff.

Opening Windows to Customization

Drinking the 64bit Kool-Aid and knowing how it's made

Drinking the 64bit Kool-Aid and knowing how it's made