@Yet another Anonymous Coward
Firstly the name's Turner not Taylor. If you can't even get *that* right... Onto your points:
Anonymous Coward: "I'll tell you why I'd like it to be opened: because I'm a fairly decent programmer with kernel-mode and device driver experience, and next time some awful bug is giving me trouble I could just *fix* it instead of having to struggle to find some workaround"
And are you going to make sure that your fix isn't ever overwritten by a patch? What if it turns out you weren't as skilled as you thought and perhaps you didn't know the full picture of why it does what it does and you broke compatibility with something else which you didn't or couldn't test at the time? Perhaps you could get away with this for entirely closed off installations but not much else. And of course if *you* can do it, so can millions of other people write their own 'improved' versions of Windows. As a Windows Developer myself I certainly wouldn't want to be coding for such a potentially moving target and I doubt MS would be chirpy about trying to support homebrew versions of Windows either.
AT: "Malware authors being able to find hooks and holes with much more ease."
AC: That's a fairly limited impact. Most malware these days spreads by idiots clicking on it anyway"
You know this how? Most virus checkers root out EXEs these days, it's opening malformed data files that's the bigger problem - that and visiting websites that are loaded with malformed HTML or images. Thanks to UAC in Vista, even running an EXE can have limited impact (assuming the user hasn't turned it off..), but if the writer of that EXE was able to leaf through the source in order to find a way of buffer overrunning their way to elevated privileges then that would make their life a whole heap easier.
AC: "it doesn't even need OS exploits or holes"
Unless you're talking about clicking on .EXEs, yes they do.
AT: "Malware authors being able to create 'pirate' versions of Windows with the malware built right into the OS"
AC: "That one's a total strawman. They can do that right now"
No they can't. Not at the level I'm talking about.
AC: "and it doesn't need access to the source, and access to the source wouldn't make it any easier. If your supposed pirate released a hacked version of windows based on the original sources, it wouldn't have the MS digital signatures on the system files, so they'd have to disable all the checking and system file protection feature in the os anyway... which you can already easily do, in which case you dead easily trojan or wrapper or replace wholesale any windows system file you like anyway. The source is neither necessary nor even useful for this kind of attack."
You're somewhat assuming I mean Window Mode binaries. I don't. Sure you might be able to disable System File Protection, but with the source you could make a version of Windows which *pretends* like it's doing it, but actually isn't. You could make a version of Windows which fakes the appearance of MS signatures on binaries that don't actually have them (to the UI level at least). Once you're inside Windows, especially the kernel level and you're able to simply add bits in without having to add new DLLs or wrapper existing ones then you can do a great deal and without much chance of detection.
AT: "Software developers being able to see how things work will start to use and rely on internal behaviours."
AC: Dude, that's what MS already do anyway, and that's why their public APIs are no use. MS' use of secret internal APIs to gain commercial advantage for their products was half the issue in the monopoly trial, remember?
Of course I do and I also recall the trouble it caused, how long ago that was and how much of a totally different issue that was. For a start, it's one thing to use undocumented APIs and another entirely to rely on the internal behaviour or data structures of a documented API. You might check through the code and decide that an API is almost certainly going to be thread-safe even though it's not marked as such. Then you rely on that at your peril when later versions break that. And it's one thing for MS to be able to ask the Word team whether changing some aspect of the undocumented API will cause them a problem since that's still an internal matter which MS can control. Once the source gets out then they can't have any idea how much changing internal data structures will break the code of people who've tried to be 'a bit clever' and have leveraged access to the source to get around the API. Not to mention people copying chunks of Windows into their own DLLs just to change some behaviour and then finding that the chunk they copied isn't always compatible with different OS patches.
Come on mate, if you blur the line between OS software and application software at the *source code level*, it would lead to an absolute mess as people all over the world leverage knowledge that they shouldn't and couldn't rely on just to try and get an advantage over their competitor. And on top of that, you only have to look at the huge number of Linux distros to see what other problems you may well get.