Complete List of Bugs Fixed in SP2
callipygian-showsyst writes "Microsoft has published the complete list of bugs fixed in Service Pack 2.
They range from the obscure like: 'File Appears to Be Deleted Although You Do Not Have Permissions on the OS/2 Warp4-Based Server' to the serious-sounding: ' Stop error message on a blue screen when you transfer data to a USB device in Windows XP'"
This is a giant list of all of the updates, and then links to the KB numbers on the left, so you can read what each one was.
... but after reading the KB, it's an ActiveX problem that can allow a webpage to access your media library. Then again, MS has always really vague and stupid titles.
Side note: one of my favorites:
MS03-021: A flaw in Windows Media Player may permit the Media Library to be accessed
At first, I was thinking that it was supposed to do that
Well, out of the many bugs listed as being fixed thirteen were repaired that could cause code execution...
;)
Were these bugs found internally by their team or were these found by outsiders and then patched months later because knowledge was never released?
Not Prompted to Obtain a Digital Rights Management License for Installations Created by Using Sysprep
This was one bug they could have left unfound
* Microsoft Windows 2000 Advanced Server SP4
* Microsoft Windows 2000 Professional SP4
* Microsoft Windows 2000 Server SP4".
Are they intentionally driving up the number of bugs fixed?
-- "I'm not a religious man, but if you're up there, save me Superman..."
Have you heard of the term "slime"? Slime in the parlance is a "feature" introduced under the version control cover of a "defect".
Let's say I need to fix a simple little bug, a misspelling in a message, which happens to be in source code file "abcd.c". I've got sitting on my hard drive this awesome new feature (at least *I* as the developer think it's cool), but nobody wants to accept it into the product. Hey! It's in file "abcd.c" too! I check in the misspelling fix, along with 2000 lines of new code for my new feature. In version control though it shows up as nothing but "fix a misspelling". That's slime.
With open source you can't do slime... well you could try but it'd never stay undercover. Thus I'd argue this *is* an insightful comment for a non-open source release, but possibly Flamebait for a Linux release.
--Rob
Probably a problem discovered during 2003 testing, that, ultimately, was determined to be in XP. Happens a lot in testing that an incidental find sticks with the original summary even after finding it applies to other things.
XML is like violence. If it doesn't solve the problem, use more.
This isn't a bug in the firewall.
Local applications running with administrator privilege are inside the security perimeter of the firewall and have the same rights as the firewall management GUI. Microsoft would need to be enforcing mandatory access control to actually prevent third-party applications with appropriate right from managing the firewall, so all they could do would be to leave the management API undocumented and create a false sense of security.
Don't complain, you should be applauding them for avoiding another "security through obscurity" dead-end.
Before you checkin code, it must be code reviewed -- this is manditory. Someone checking in a fix described as "fixed a spelling error", while adding 2000 lines of code, will be told to remove it (or get a bug opened for the new stuff that they added, and deal with it in a different change).
/will/ result in immediate termination.
Depending on the group you work in and the phase of the dev cycle you're in, you also have to get triage approval -- this means you have to justify your change to a group of people trying to keep code churn to a minimum.
When code is checked in, the change is mailed to one or more mailing lists. Among the things in the mail are the changelist description and the file in the changelist. Again, red flags will be rased when someone looks at the diff (and believe me, some anal retentive fucker like me will catch it).
If, somehow an employee managed to get through all of those layers and snuck in those 2000 lines of easter egg code under the radar, and the "easter egg" is discovered (and it will be), they lose their job. It's one of the few things you can do at Microsoft which
if there were three changes....
1) That the reg tool existed as early in NT as when the registry was first introduced.
2) That the reg tool would allow you to dump and restore hives and keys to flat/text files
3) That the registry would be broken up into many hives that applications could load and unload dynamically and keep independantly.
In this fashion, for example, all the settings for a particular app for a particular user might end up as %USERDIR%/Application Data/foobar/foobar.dat and would be dynamically added under HKCU or whereever until it the relevant app was closed (and the hive removed).
You could always go back and manually mount that hive and make changes...
In this fashion, complete rebuilds would become unnecessary because you could spread out your critical config, and backup/restore parts independantly, prevent corruption or slow access from large hives, etc.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON