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'"
Why is it so hard that the editors can't use the appropriate icons for them?
It's time this site starts to grow up.
Slashdot Moderation: From positive to terrible in 2 "insightful" posts.
if we're close to the time when the majority of slashdot readers don't know what OS/2 Warp4 is?
"Complete" list of bug fixes? Probably not. More like a list of all the bugs they think they fixed, not counting the bugs they inadvertantly fixed plus the bugs they inadvertantly introduced.
But, but, but...then it wouldn't be slashdot any more!
There are a lot of instances of the word "cumulative" in this list ("Cumulative patch for Internet Explorer..."). I wonder how many true bugs are fixed with this, not just support article entries.
That would be something of a waste of time, considering the official home/windows update available version will be out tomorrow and will be around 80MB. The 250MB is for network admins, not home users, definitely not dialup users.
Score:5, Insightful? If this were a Linux distro getting an update, this would be marked as a Troll or Flamebait. At the very least, Funny would be more appropriate.
Okay, tell meonce again how many months it took to root out those errors? Some where known for a long time. And I expected a longer list... waaaaay longer!
Modifying a large operating system while attempting not to "break" any end-user configurations is nothing short of a prodigious task.
The modifications were probably developed and committed to the Windows source tree in a relatively short period of time. However, Windows must accommodate a diverse array of configurations, including many that are very "fragile" and obscure. Because of this, the modified build likely endured an extensive testing process, hence the multiple delays.
Do you like German cars?
MS says it's a feature... I think it's a bug: programmatically disable windows firewall
And you have to be in administrator mode. Oh no, you mean if I log in as administrator the programs can do bad things.
If I logged on to linux as root and ran a program it could cause the same sort of problems
I/O, I/O, its off to disk I go, with a read and a write, and a bit and a byte, I/O, I/O, I/O, I/O
I expected a longer list... waaaaay longer!
Is this the usual anti-MS knee jerk reaction, or could you actually name any bugs in particular which haven't been fixed? I certainly couldn't name more than 20 bugs (I'm talking about bugs in the operating system, not instabilities linked to 3rd party device drivers, etc). The list seems pretty long to me, waaaaay longer than I would have expected.
not really.
It's 250MB of patches for XP Pro, XP Home, and XP Meida edition. 3 slightly different OS.
Regular for a single one of these would only be around 50-60 meg.
Steven V>
I patented screwing your mom. But it got revoked for "prior art."
Calling software defects "bugs" denotes that somehow critters are crawling into code and having their way with the bits. Once upon a time, there were real bugs in computers. They prevented relay contacts from closing. There's no such thing as software "bugs" today, only logic defects.
In reality, defects are created by people with imperfect logic. Calling defects "bugs" is transferring responsibility from the human creator to a mythical insect.
Defective software is a fact of life. Unlike Star Trek Vulcan science officers, humans lack pure logic. Maybe that's the price we're paying for being human.
Until space aliens possessing pure logic visit Earth and mind-meld with humans, we're doomed to imperfect logic. This means microcode cast in silicon, assemblers, compilers, and program generators will continue delivering defective output. To compound the problem, it also means that application solutions humans are abstracting and describing using these tools will continue containing logic defects.
If you think defects are rampant today, you ain't seen nothing yet. The order of complexity of software-based systems is most likely accelerating at a rate faster than Moore's law.
The best we imperfect logic humans can do is learn from our mistakes. Unfortunately, this seems to be rarely practiced. Many realities about the art of software were described by Fredrick Brooks in "The Mythical Man-Month: Essays on Software Engineering." The second edition of the book published 20 years later confirms that the realities of software are as true today as in 1975 when the first edition of the book was published.
A precious few people practicing the art of software are aware of software sins of the past. Most practitioners are blindly recreating them, and are pushing the blame onto the mythical "bug."
I beleive a lot of files have been re-compiled to prevent buffer overflows and take advanateg of the NX flag on processors that support them. Many of these programs don't have a 'bug' as such, but are being made more secure.
It is a bit scary watching the install and seeing all these things being replaced.
Also the ~250MB is the admin version, that has every update. The version for home users will only have the necessary ones they need, and should be quite a bit smaller if the machine is reasonably up to date.
Probably still the biggest SP for windows ever though.
I guess XP Media center is quite a bit different, but XP Home is mostly a stripped down XP Pro, with more wizards and different control panels. 2000 Server and 2000 Advanced Server have a bunch of extra server apps, and completely different kernels and base drivers (for SMP and big memory support) when compared to 2000 Pro.
My Other Computer Is A Data General Nova III.
Holy FUD. I do not know if you are a software developer, but I have come across many bugs, including my own, that could be titled does not work. That does not mean that it never works, it means that in some configurations, when you do X, Y, and then Z, while having Q in the background, things do not work properly. This is a primary source of bugs- a combination of events happen that you did not plan for occur, causing a malfunction. It does not mean that it is common.
Most of us I think have heard the 65,000 bug quote for windows 2000. Considering the amount of code in windows, this is normal. Dont quote me on this, but I have heard there is somewhere on the order of 3 million lines of code in windows. This is about one bug per 46 lines of code, which is a little better than average from what I have read in industry studies for projects of this size.
ok. i would like other peoples opinion here. Would it be possible for a hacker to look through this list and find a combination of exploits to create worm/virus/etc.? Since I definitely won't be installing this until 2.1 due to all of the issues this update causes (even to M$ applications). It's probably safe to assume that most users wont be installing this for a while (or is it?).
This is all most people need or want to know about an update.
Care to try your hand at a plain English explanation of a "buffer overflow?"
You can only pull this kinda crap (that MS has been proven and even admitted to of having done) when your sure it is the other guy that is blamed. Kinda like when IE fails to load a page it is the websites fault but when Mozilla fails to load a page it is Mozilla's fault.
OS/2 has been killed but it is still being used. Those customers are smart enough to know that any problems are not OS/2 fault but MS. Since MS wants them at one time or another to switch it is probably not to wise to alienate them by showing them how buggy MS software is. Once they switched and are totally locked in THEN you spring the bugs on them. It helps sell the next version. Just explain to me exactly why I should have upgraded from Win95? What exactly has been added that is so helpfull? Stability? Stabilty is a bug, it should have been fixed in a patch.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
These things *should* be stored in a small config file. That's one of my (many) problems with Windows. Just throw everything into the registry, no matter how small or unimportant to the OS itself.
They *can* hack in an easter egg while *USING SOURCE CODE CONTROL*. And in the management reports it will show up as "fixed a misspelling".
I've done it, I know bunches of other people that have done it, and I've been directed by my manager at one company to do it.
The cutoff date for features is *way* earlier than the cutoff date for defect fixes, and on occasion we'd (i.e. my first level department) discover a feature that we needed to have in the product, but which higher level management would never agree to due to the schedule. Our first line boss would give us the OK to slime it in. It's the old "It's easier to beg forgiveness than to ask permission".
Would somebody lose their job? I guess it all depends on whether your first line manager goes to bat for you or not... but that being said I've *never* heard of a programmer losing their job due to slime.
--Rob
Why is so unreasonable to expect any user to have a rough idea of what programs they run on their computer so that they just update the bits they need to?
For example, if I run an AMD CPU, why do I need:
810064 - Short Battery Life on Your Pentium III-M Tualatin Processor Computer
I thought Windows Update was supposed to supply you with just the updates you need? Even if it cannot do that level of system checking, what about MS just doing a "portage" or "apt-get" system like in Linux?
MS has a reputation for bloatware and having to download a huge Service Pack where you only need 20-30 of the updates does nothing to quash that reputation.
Not to mention millions of people downloading a 250MB+ Service Pack and wasting bandwidth...
Gentoo Linux - another day, another USE flag.
Because if the temperatures reach those thresholds, then your 'properly designed heat solution' obviously isn't.
If you have a 'properly designed heat solution' then you should never get throttled or should only be throttled very very little.
This is a case of the OS responding to a condition *prior* to the computer locking up. The Linux kernel has a similar feature.
Such bug does NOT mean that all writes to USB devices are failing - only on some specific device under special conditions. Usually any functionality in Windows never *completely* broken - unlike Linux where you can get respected distro with non-working DSL support or 50%-failure rate boot loader. As I wrote: SlashDot is deep into blind anti-MS propaganda... shame on you! And what so special about list of bugfixes? Have you seen Debian or Mandrake change logs recently? (and in case of XP SP2 it is list for 2 years! two!)
Slashdot - free anti-Microsoft propaganda 24/7
You have no idea what you are talking about. Most apps use some kind of lib or something to access their configs, that keeps the config to a standard, at least internally to the app. If you have another application that needs to access that config, its usually fairly easy to do so. What your saying is, its good to make it easy for any application to access any other application's configuration. How often do you just randomly pick a registry entry and decide to use it for something? When you write your program you know what you'll need and you predefine the config files or in your case the registry. As long as you know what your accessing and how to access it, nothing else matters. The worse thing about the registry is how easily it becomes corrupted. Also, as far as I know there is no tool bundled with Windows to allow you to edit the registry from the command line. So what do you do when your registry is hosed and you can't boot to a gui? I may be wrong, but I don't beleive there is a way to edit it easily from DOS, and booting into Linux is useless because the registry isn't editable with a text editor or something simple like it should be. The registry is a great idea in theory, but horrible in practice.
Regards,
Steve
I consider myself pretty tough on Microsoft, and I particularly don't like the registry, and definitely prefer text files. And contrary to the opinion of the other person who replied to you, there are standard APIs for accessing the values in .INI files or property files.
.REG extension, put the right data in it like this:
.NET programming brings back text files for configuration in the form of .config files. There are standard APIs for accessing their settings. So it looks like even Microsoft is finally admitting that the registry might not have been such a good idea.
But nevertheless, I have to say that it is unfair to claim that the Registry is easily corrupted. It can be corrupted, and if it is corrupted, really, really, bad things happen. Nevertheless, it very rarely does get corrupted, and a back up copy is kept, and I believe installed automatically if necessary.
It is fair to say that the registry is a bad idea, and that if it is corrupted the system could completely collapse, making it a serious single point of failure. But it is not fair to say that it is easily corrupted. I'm not sure I've seen a case of a corrupted registry in the last 5 or 6 years, though I did used to see them from time to time back in the good old days.
Of course, if someone has some compelling stories of registry corruption, it would be interesting to hear them. And though I'm sure such stories exist, I bet they are rare.
By the way:
You can add information to the registry from the command line. Create a file with a
- -
REGEDIT
HKEY_CLASSES_ROOT\TestApp.Application = Delphi Automation Server Test App
- -
Now type:
start myFile.reg
and it goes into the registry.
Final note,
- Charlie
This is why $diety invented the home directory. It's there, I don't understand why app developers refuse to use it. Especially on nix based systems like Linux and OS X, where you just put a .appname folder and put the config files in there and the user doesn't see it unless they want to.
Life would be much easier (especially in the way windows installs programs. On the mac you can juts copy your apps folder over to a new install and they'll all work, try doing that with Program Files)
...and that's all there is to it.
I agree. After I switched to linux I noticed how many people make it seem they're running linux (because of their pro linux comments and being modded up for praising linux), but run windows. Look how many people comment on big microsoft stories. Sometimes it's over a thousand.
I want to see slashdot's webserver statistics showing what people are really running. I wouldn't be surprised if it's only 10-15% of people running linux.
I think in addition to our karma, we should have a linux-o-meter linked to our ID name. That would expose that asshole who shouts out "winblowz," "Micro$oft" and all that other childish crap who's really running windows xp in his mother's basement. There's nothing wrong with people using windows. Hell, I use it at work. It's just when the slashdot "politics" skew the reality of the situation that it starts to get aggrivating.
And by the way, yes I did switch to linux to seem cooler on slashdot because that is all that matters in life.
It's actually saved me some trouble. You'll know that your disks are out of free space (thus preventing the audit log from growing) when you see that ol' Blue Screen. A similar machine without the setting would just behave very erratically and just fall all over itself.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Once: Tie a rope between two fixing points. This is like unto your entire hard drive, with many config files interwoven. If a thread frays out of the rope, it doesn't break.
Now tie a thread between two fixing points. This is like unto your registry. If a thread frays out... it's game over.
Again: take a pile of gravel. This is like unto a pile of small files on your hard drive.
Now, carefully stack the individual pieces of gravel one atop another to build a thin, tall pillar. This is like unto your registry on your hard drive.
Take one piece of gravel from each system. Which lasts better?
Discussion: Similar principles apply elsewhere. Microsoft have a tendency to lose the plot when faced with a choice between "robust" and "shiny". They also fall victim to their own propaganda.
Got time? Spend some of it coding or testing
This is understandable, and for the most part I agree with you - however, what data format is best?
/etc/aliases, do I want to do this:
y coworker</to>i ases>
/etc is commonplace (although OS X does a great job of screwing that up as soon as I touch the GUI again, arg)
When I need to edit a configuration file, I sure as heck don't want to type XML out for my frequently reconfigured application that requires simple directives. Ever mess with Tomcat? Hacking on that configuration scheme is a total nightmare.
However, for something more robust like apache, a more involved configuration is required. Apache's configuration is so right, nothing could make me happier - FOR APACHE. Yes, it's a form of XML (IIRC it uses expat or a modified expat to parse the configuration), but it's hardly strict and rarely cumbersome.
Realistically, when I'm editing
<?xml>
<aliases>
<user name="root">
<to>me</to>
<to>myboss</to>
<to>m
<to>management</to>
</user>
</al
(yes I know a mailing list would be better served in this example - I am trying to illustrate a point)
or this?
root: me
root: management
root: mycoworker
root: myboss
I'll learn 30,000 configuration formats to prevent the mess in the first example from taking over my system.
The nice thing about Mac OS X, those XML files that are scattered everywhere are almost never touched (at least on my machine) - if they're not configured through the GUI, they're generally some kind of internal data that I don't need to touch - at least, I haven't had to yet.
However, mucking in
As for your program parsing comments, here's a very simple solution:
If you have a program which is 'glue' for multiple programs that use multiple configurations, write a program that parses both formats and creates a third format. If your target programs are decently designed they will mostly likely use one of the following types of configurations:
m4 - which is made to do conversions, writing the rules are daunting at first, but it's just like any other language.
XML - XSLT, XPath, all stuff that is easily available (and I'm sure you already know about)
plain old text files - generally when someone uses the above two their app is sufficiently complex to warrant one, when someone uses this, generally it's simple - if not, the "big" services all have (E)BNF waiting and ready in their RFC's or man pages. Just about anything else can be parsed with two builtins in the perl interpreter: split() and join() (pick another OSS language if that one doesn't suit you - they all have equivalents for reasons that will be left as an exercise to the reader).
In reality the third is the time waster, for obvious reasons. However, once you know how to parse a zone file, sudoers, etc, you don't have to write it again. In reality the ever-changing configurations are the simple ones, the ones that fall into the split() and join() category. In rare cases, you might have to use a regular expression, oh dear.
another thing is important to mention, that is the fact that if you are mucking around in a configuration file for an application so often, generally one of two things are the problem: you need to constantly adjust this program based on technical or business requirements, or your program does not provide ample command line options. In the latter case, perhaps your programming resources could be used to either add the options to the program (libpopt is very easy to use and almost every GNU program uses it, if not, they're probably using getopt(), a little more painful but fairly standard nonetheless), or find one that suits your needs from a configuration perspective - after all, if the author of the program didn't think command line options or a good, easy to edit configuration were important, there's probably a good number of features it's missing anyways.