Slashdot Mirror
Why Can't Microsoft Just Patch Everything?
paneraboy writes "If smaller software companies can patch all of their bugs serious or minor, ZDNet's George Ou asks, why can't Microsoft -- with its massive army of programmers and massive budget -- patch all of its vulnerabilities? Had Microsoft fixed a low risk browser vulnerability six months ago, perhaps we could have avoided last week's zero-day exploit. Currently, more than two dozen Windows XP issues remain unpatched. Ou thinks Microsoft ought to fix them all." From the article: "Almost 4 years after the launch of Trustworthy Computing, I found myself wondering why am I staying up till 4:00 AM to deliver an emergency set of instructions (Home and Enterprise) to my readers because Microsoft felt it unnecessary to patch a flaw six months ago that was originally low risk but mutated in to something extremely dangerous."
Here's one from the article flagged: "Less critical" from 2002: SA7127 Check out the first paragraph of this 'less critical' item's description.
By the way, when I read a statement like this one:
If smaller software companies can patch all of their bugs serious or minor, why can't Microsoft just patch all of their vulnerabilities with their massive army of programmers and massive budget?
I start thinking there ought to be some kind of credibility (karma) system for anyone giving public opinions. You know, give the article '-1', give the guy 'Terrible Karma'. Make all his subsequent articles dissapear for you, or even better, replace the article with a 'joke of the day', you know, to dilute the real news a bit.
Seems like some members of the press don't understand coding. You can't just go and patch everything. Regression testing? Making sure all the changes work as needed without impacting other subsystems.
Do you really think if Microsoft COULD do it, they wouldn't.
To paraphrase a certain mercenary, where's the percentage in that?
"The dew has clearly fallen with a particularly sickening thud this morning"
You can only patch a leaking boat so much, even if you drydock the vessel for a few months. When it's only held together by the barnacles and the masthead, it's going to sink whether you bail it out or not. At some point, you're going to have to re-think the design of that hull, and start from scratch.
[
I think MS has come a long way from where they were, but I agree. To the people who claim it can't be done: OpenBSD does it!
Why should they?
People will still buy thier product, people accept that it sucks.
Unless they see a good ROI on patching or developing good code they won't.
Quite honestly if it isn't a worthwhile use of their resources they shouldn't patch code.
When there is serious competition and code quality becomes a competative advantage they'll fix it.
Microsoft is growing and profitable having their developers do other things, until such time as they are held hugely financially liable for their bloated buggy crap they won't make that their prime focus
Issuing patches is dangerous.
Every time Microsoft patches its software, hackers use their patches to discover security holes and to issue exploits!
But when they don't patch their software, no bad guys notice these vulnerabilities. In fact, no virus or worm has *ever* exploited a vulnerability before a critical update was released!
Duh.
We recently had heard in the office over one of the Yellow Machine that's made by Anthology Solutions.
Why can't the Mozilla Software Foundation allt the 6300
Firefox Bugs? instead, they have to release a "new" version... just freeze the freaking lreleases and patch your bugs!
No, OSS is not free of bugs
Ubuntu is an African word meaning 'I can't configure Debian'
The biggest problem that M$ has is their size. Sure they have tons of cash and an army of coders, but I bet the left hand doesn't know what the right is doing. There must be so much red tape there as to basically paralyze them. Just look at the lack of innovation coming out of M$. Windows has been stagnant since Windows 98 and Office hasn't improved much since Office 97. M$ is being crushed under their own weight.
gasmonso http://religiousfreaks.com/If Microsoft fixed everything, then the companies that made programs that allowed users to work around the "flaws" in Windows would go to the federal prosecutors and demand that Microsoft be sued for having a monopoly on fixing their own bugs.
All kidding aside, Microsoft has a huge amount of users, maybe more than any other product in existance (I didn't do the research). This does mean that more bugs will be found, and the reason behind not fixing certain bugs may be that the bug was addressed in a future rollup or patch already. Because Microsoft is a massive corporation with so many departments, it is possible that Microsoft BugCentral says "Fix this!" and Microsoft PatchCentral says "We fixed it in Article 931321 coming next week" and Microsoft ReleaseCentral says "We're waiting for a fix on another bug before releasing that."
I'm not a fan of it, but it is really hard to just come out and say they're ignoring a bug, when it may be something deep set within the software (hard to remove) or it might be addressed but on hold for another reason (opened up another flaw?). If we think we as geeks found all the vulnerabilities, we're fooling ourselves. Windows is a massive program, and even Linux has ongoing flaws. When Linux has as many third party apps and interconnecting drivers as Windows does, I'll accept a complaint towards getting things fixed post haste. Until then, we just have to (thankfully) support third parties that give us options! (And paychecks)
You mean like when someone says "if smaller software companies can patch all of their bugs" means "if all smaller software companies can patch all of their bugs"? Thanks for the permission to flag all of your future posts as "joke".
--
make install -not war
I can hear Microsoft execs right now: "Well when you put it that way...why didn't we think of this before?"
"What's the status of our new software?"
"Ready for launch Mr Carver, and - as requested - it's full of bugs, so people will be forced to upgrade for years."
"Delicious."
/not serious... no, seriously.
A-Bomb
Just because MSFT has an army of programmers, it doesn't mean it has an easier time patching its old code. Larger groups of people (be they developers or military groups or a bunch of friends going out drinking) almost always require more grooming and maintenance. Look up "Dunbar Number" - here - I find it fascinating.
;)).
A smaller, and thus possibly more agile group of programmers may actually be able to patch more holes than a mammoth like MSFT. Size can be a disadvantage (don't quote me on this
Simpy
with its massive army of programmers and massive budget -- patch all of its vulnerabilities?
This is impossible. With patches, new releases, and updates there will always be new bugs introduced, some exploitable, some not. No program will ever be invulnerable to malicious attacks. As long as a person made it another person can break it. Maybe micro$oft could be doing better at realeasing patches, but it will never be error free. And that goes for all software.
Patches, no matter what they are, are woven into most things that Microsoft and developers do. There are numerous dependencies, and the numerous divisions, API sets, and partner dependencies make this difficult if even impossible to do on an ad hoc basis, as a generally available patch that breaks things is irresponsible.
Yes, it happens anyway.
Thie is the downside to having a huge, inter-dependent set of apps. Regression testing and dependency testing regimens have to be followed to ensure that small or even massive destabiliations don't happen. This also means that the easy stuff and the most urgent stuff (by their reckoning, not necessarily mine or yours) gets done first, and the tough stuff is just tough.
It's also what makes the closed source model more difficult to deal with, as Microsoft isn't just one pool of programmers, rather thousands of coders working on largely interdependent projects. While it looks like they should be able to do this, it's a reality that it cannot. And it would be irresponsible for them to do so, given so many users, and so many inter-related apps. We just wish it could. That's why OSS methodologies have a bit of an edge in this context (and others).
---- Teach Peace. It's Cheaper Than War.
no, I didn't mean that ;)
The best way to find a bug is to take the code away from the original programmer and give it to a dedicated tester.
The best way to fix a bug once it's found is to give the code back to the original programmer, and tell them to go fix. Because they know the code. And it's less likely that fixing the bug will introduce more bugs. Obviously, this limits the amount of people you can set to the task of fixing them - and in a project the size of Windows, there are a lot of them.
If smaller software companies can patch all of their bugs serious or minor, ZDNet's George Ou asks, why can't Microsoft -- with its massive army of programmers and massive budget -- patch all of its vulnerabilities?
Ok have I missread something?
Small companies = 1 or 2 programs with each a couple of thousands lines of codes. Usually new program, so fresh and structured code.
Microsoft = dozens of programs, with each a couple of millions lines of codes. Usually based on ancient versions returning to the age of C when code was a little less structured than now and imprissivly patch over and over again.
This said, you also count that some microsoft software are dealing with complex coding like memory managing, thread managing, hell all the computer managing.
Also add that the goal of every microsoft user is exactly to find all flaws in microsoft and just point at them and says"HAHA! There is a bug there mr. MS." So it's not surprising that microsoft software have to deal with a lot of bugs.
I think that pretty much make a answer to why Microsoft is like this.
Most importantly, why wasn't the utmost care taken on anything that takes foreign input (browser parsers, etc).
I'd take a gander and say because you just don't know what people are going to throw at it until you let them have it.
It's more cost effective to release a piece of software and apply patches periodically than to attempt to work out all the bugs (which is almost impossible) before you release it.
Where the whole thing is allocated dynamically, based on what someone else told you the size was.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
In a company run by Software Engineers, bugs would be fixed before new features are added and we'd see life cycles similar to open source projects that produce typically stable and largely bug free 1.0 releases.
The reality of Corporate America, however, is based on quarterly results. Getting that next release out the door and being able to sell is everything. That means that all clean-up work (bugs, exploits, refactoring) will be prioritized along with new features and unless it's really critical will likely not get done for a long time, because they are lower priority since they bring no customer sales.
Unless and until those bugs affect the bottom-line, the company won't do a thing about them. A good recent example would be Sony's rootkit problem, which it turns out was pointed out to them before the public release on sysinternal's blog.
http://www.gloryhoundz.com/
The article is making a very dangerous assumption here... assuming that other companies fix all their bugs. They are only fixing bugs that we know about. Who knows what they have found in-house that has remained unpatched because it was deemed too obscure.
Another thing the author is missing is that these competitors stay in business by creating the impression that all vulnerabilities are fixed. Microsoft is vastly more publicly responsible than the smaller competitors mentioned. In the interest of continued business, they are pretty much required to adopt a policy of full disclosure. Smaller companies are not required to do this as much because they are the underdog, and everyone loves an underdog.
If it was discovered Microsoft knew about some bugs and didn't publicly release the information, there would be massive outcry. If Mozilla did the same, they might get a slap on the wrist, but I doubt it would seriously affect their business. As I mentioned above, they are the underdog and everyone loves an underdog.
Government's view of the economy: If it moves, tax it. If it keeps moving,regulate it. If it stops moving, subsidize it.
Incompetence, disinterest, different priorities, and no business reasons to do it.
Oh, he didn't really want an answer?
Assorted stuff I do sometimes: Lemuria.org
We're used to OSS products that can be patched in a day, but we're also used to seeing those patches break things in unanticipated ways, often making things worse.
We're also used to picking on Microsoft for having buggy software. But they have extensive and long testing procedures, without which MS software would be WAY buggier on release. Their software is massive (for some good reasons and some bad ones), so it's a huge undertaking to fully test it.
In order to avoid, as much as possible, unanticipated consequences of a patch, Microsoft cannot simple make the fix and release it. An argument could be made that if they were to do that, they would often create more vulnerabilities than they started with, so releasing too quickly would be a BAD thing to do. Windows 95 is an example of something that was released too quickly, lacking certain kinds of testing entirely; you can see the unfortunate results when you try to connect a Win95 box direcly to the internet and wait 5 minutes.
So, why can't Microsoft 'patch everything'? Here are the reasons:
(1) First, you have to FIND 'everything', and Windows is just massive.
(2) When you make a change, you have to test it extensively, which takes a LOT of time.
(3) Some patches are one-liners. Some affect large amounts of code that makes it even harder to anticipate consequences.
(4) Sometimes, you have to test things one at a time. This serializes your patch process in such a way that it just takes a very long time. This is very hard to avoid.
The fact of the matter is that if Microsoft were to 'patch everything', we would have a lot more to complain about. People should stop asking for stupid things and be realistic.
Even OSS projects can't 'patch everything' successfully. Sure, many of them are better designed from the start, so there are fewer things to patch, but when a patch needs to happen, the same amount of testing is going to have to happen, one way or another (either you release a beta and let it get tested for a while, or you just stick it in and wait for the shit to hit the fan and end up fixing the consequences the same amount of time later anyhow).
Also, certain people forget that Microsoft did go on a 'patch everything' hunt and DID fix a huge number of bugs. They still didn't find everything.
Oh, and if we're just talking about patching everything that's currently known, my argument still stands. Patching a bug of vulnerability is often quite difficult.
Maybe it should be named zero-year exploit.
Signatures are for stupids.
This is not the reality of software development. This is the reality of incompetent developers and management perhaps: making technical decisions based on how to lock in your customers, work around lawsuits, and shove software out the door to crush the competition.
Plenty of systems---yes, open source ones are good ones to look at---are not so bug-ridden and complex that they can't stay ahead of the curve and react quickly. If you write good software, if you're at least decent at what you do, that is the reality of software development.
But, they don't. They have reports of bugs for months, often, and do nothing until it's publically reported and/or there's an exploit in the wild. Does it take Microsoft 6 months to come up with a patch for a single buffer overrun? Or are they just too arrogant and think they're above doing anything about problems until they're exposed?
How often do we see bug reports from Microsoft about a critical vulnerabilities, compared to third-party reports?
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
There are two types of "patching".
... and opened a whole other category of exploits FOR THE OS.
1) Patches to fix code flaws in an otherwise sound security model.
2) Band-aids for a flawed security model (anti-virus updates are in this category).
Microsoft focused on "user friendly" and "easy of use" for so long to the detriment of security. And security cannot be retro-fitted to a system.
When they merged IE with the OS, just to be able to beat Netscape, they opened the OS to a whole new category of exploits.
And then ActiveX made web app programming so much easier
It _is_ a less critical bug. All modern linux systems have the same 'bug' by design, and not only for 16-bit applications. The consensus is that this is not worth fixing. (To execute an arbitrary file, even one on a fs mounted noexec, simply use ldlinux.so to launch it)
Try out fish, the friendly interactive shell.
Attention all hands! Abandon metaphor! ABANDON METAPHOR!!!
Though I must admit, it gives new meaning to "software piracy". Ahrrrrrrrr.
Software (despite what M$ would have us believe) doesn't wear out.
The only way to sell new stuff is have it break down. They only fix a few vulnerabilities at a time to make us believe they're trying to keep it safe, but they really built the "rust" at the factory.
Add a few new "features" (read code bloat) and the replacement cycle starts all over again.
They're probably secretly supporting a few exploits the keep the damand up.
That problem was fixed, um... 4 years ago?
/lib/ld-linux.so.2 ./test ./test: error while loading shared libraries: ./test: failed to map segment from shared object: Operation not permitted
$
On your Brady Campaign link... is it OK then for me to sue Ford because a drunk driving a Ford wiped out and took out my fence or loved one?
Don't blame me, I voted for Kodos
Comment removed based on user account deletion
The initial post is a strawman argument...
...which predicate the argument on the notion that small software companies patch all their bugs.
If smaller software companies can patch all of their bugs serious or minor, ZDNet's George Ou asks
So if I go looking for bugs in say the Opera browser I wont find any, because small companies patch all their bugs?
Nobody patches all their bugs; not small companies, and not large companies. The argument is a piece of sophistry that simply sets up another round of MS bashing. A fun sport, but it shouldn't be mistaken as anything exccept sport.
"All of our products now certified 'Good Enough'(tm). The new version will fix (insert issue here) anyway."
On a related note, don't you just love the dinosaur ads MS is now using. "Still using Office 2000?!? What a relic you are! You ever heard of the dinosaurs? Well that's you if you don't upgrade RIGHT NOW! Also, the 'Good Enough'(tm) guarantee expires the day the new version comes out."
Ignore anything I said above, I actually agree with everything you believe - mod accordingly.
Microsoft has alot of employees to feed large salaries to. The teams of developers, designers, programers, PR guys.. They're still giving support and updates to an OS that's coming on 8 years old, on top of all their new product.
Now, I can't say for certain, but I imagine that means that every time they release a new OS, their support staff grows bigger, whether in house or contracted out (I'm not sure how MS handles it).
This is ALOT of people folks.
So, you're in charge of keeping MS a growing profitable company. Does it make sence to focus your time on patch after patch after patch, which does nothing but tie up your employees with aditional support and coding while in no way contributing to the effor of actually paying them? Do you focus on pushing out the new OS, forswearing support of a decades worth of previous OS's, Office, and other programs (I'm not going to venture a guess at what they're still supporting... and how many questions they have to field about things they're not still supporting, and how many questions they get for, I dunno... any program that was ever made for PC that people have trouble making run out of the box.."
Smaller companies don't have tis problem. For most of them, all they need is a relatively short testing period to make sure itruns on Windows. Microsoft has the reverse problem : to make sure ANY legitimate programs, however poorly implimented, run out of the box whilte at the same time distinguishing between those and malicious unwanted programs. They can't cater to the smart people either. Linux has less bugs, but lets face it; even the easy to instal builds are a brain job for newbies, and impossible for most grandmothers.
So yeah, Microsoft has a full plate, and as ugly as it sounds, I doubt its economically fesable for them to fix everything. They have to prioritize. New features= new money. New patches = no money + continued expenses.
Conspiricy theories aside, does anyone really think they *like* having a reputation for buggy software?
Note the vast majority of "bugs" in bugzilla that are labeled "enh" --> those ones are enhancements that users would like to see.
Instead of counting against Mozilla, the fact that they allow so much user input is a great OSS feature.
No one said OSS was free of bugs. Since end users are allowed to submit bugs, the only ones that should be counted are those that are confirmed.
Try the following list: bugs that are in Firefox, not marked "enh", and have an action priority (P1-P5). (note: copy/paste link since bugzilla refuses connectiosn referred by /.)
Only 179 bugs. Sure, those are only the ones that the Mozilla team deem necessary to work on; however, we've seen from their reactions with 1.06 -> 1.07 that they are very quick on figuring out what's important and patching it quickly. Sure, that's a lot of unpatched bugs. But: that list is publicly available. Any researcher can go in and say, "hmmm.... let's find the security flaws that Mozilla has left unpatched". And they do, trust me; the thing is, the Firefox team patches the bugs that cause security flaws. Other ones are cosmetic, user interaction, or feature-based in nature. They still appear as "bugs", even though they don't pose a security threat.
The issue is not that OSS has no bugs - that's an obvious farce. The issue is that Microsoft first misdiagnosed a critical bug, and then left it unpatched for 6 months and counting. The Firefox team consistently finds those bugs that do pose a threat, and they leave the work they do open and transparent so that security researcheres can check up on what happens. Microsoft - let's put it thise way: if security researchers never found the flaws in Microsoft's programs, Microsoft would save money and increase efficiency by not fixing them.
There was a business mantra in the '90s, and still out there today, that defines "quality" as whatever it takes to please the customer. Consultants hauled in buckets of money generating cliches out of that. Companies may be driven by customer satisfaction, which is fine as far as it goes, but it doesn't mean their products are any good.
The flaw in the cliched definition is that often the customer doesn't know what they're getting or have any basis to judge how good the product is.
Microsoft, being driven by market share, is a step removed even from that level of quality. They only want their customers to be happier with their products than with the competition (which is often another of their products or an earlier version of the same one).
Making things properly is not in their range of capability.
sigs, as if you care.
Imagine you write a long long book. Even if you try to correct all the typos you may miss some of them. It is hard to publish a book with no typos at all.
I think that was great fun! If MS management believes that the security problems are "typos" then I understand they cant fix them all. Of course, security problems are more like problems with the story line: contradictory events, inconsistent background and such things.
Maybe they still have not accepted that the reason for their security problems is the poor design of Windows (particularly integrating things very freely). As long as they dont accept the truth they will try to correct typos, and that will not make the story any better.
Excuse me, how much CASH do they have in hand? Some tens of BILLIONS, I believe?
(When they aren't handing it out to stockholders in one-time stock prop schemes...)
This is exactly my constant point - they HAVE THE MONEY to hire the PEOPLE to FIX their problems! AND THEY DON'T!
Period. End of story. Nuttin' more needs to be said (but will be, anyway.)
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Read = 4
Write = 2
Execute = 1
0444 = Read by everyone
0111 = Execute by everyone
As an example of the extra hurdle copying imposes, say you want to attack someone via a set of holes in Firefox. With /lib/ld-linux.so, you need only the following, if you can't make firefox itself do arbitrary things:
With out the ld-linux vector, you have to:
So it's not a huge hurdle, but it's there!
--
Given enough personal experience, all stereotypes are shallow.
if they "patched everything", then they would need to find an alternate source of their weekly worldwide exposure. as we know, even bad news can be good news, it's getting your name out there that's important.
also, the constant need for patches allow them to feel they are still relevent.
I've worked for MS in the past, in their Windows Sustained Engineering (WinSE) division. So I think I can bring some valid criticism to this situation.
The major issue is: How many customers is it affecting? Nevermind that it's a huge security flaw with the potential to be exploited. Has it been exploited yet? If so, by whom and who was affected? If nobody has been affected, why not? These things go into determining the prioritization for a fix.
Another slew of issues is: How many man-hours will it take to fix the bug? Can the functionality which causes the bug simply be removed without terribly ill effect? Does the person who originally wrote the code still work at Microsoft? Given the fondness for contingent staffing (aka CSG, contract workers) at Microsoft, a good number of people come and go on pretty much a 6 to 12 month basis. I know that some divisions tend to not let contract workers do development expressly for this reason, but there are always exceptions. (ie, a full-time employee (FTE) leaves the company and the company has a CSG with the skills to replace him in the interim while they hire a new FTE) Also, how many man-hours will it take to test the bug? If it will take 5,000 hours to test a bug that presently affects nobody, it ends up near the bottom of the priority list. If it will take 2,000 hours and they have a report or two from customers who have experienced the bug themselves, fixing it becomes a higher priority.
You also have to keep in mind that Windows isn't just one program. Windows XP, for example, is XP Home, XP Pro, the new XP N (sans media player), and Windows Media Center Edition I believe is also XP-based. So that's four platforms that need a fix developed and tested. That doesn't seem like much, right? Ok, Microsoft localizes their software in 44 different languages, which will all need to be fixed and tested. Four platforms, 44 languages, that's 176 different variations which need to be fixed and tested. They will generally not release a fix for only one language at a time.
The open-source community is filled with people with a lot of free time on their hands, as is evidenced by the fact that they are willing to do development work for free, and some of them do quite a lot of that development work. If a team of developers and a team of testers were to volunteer at Microsoft, giving their time over at no charge what-so-ever, I imagine you might see more of these bugs that don't actually affect anyone get fixed sooner. But as long as the company needs to make a risk-vs-cost analysis, bugs that don't affect anyone (yet) will not get fixed any time soon.
Reinvent the wheel only at either a lower cost, greater effectiveness, or your own personal enrichment and satisfaction.
The reason MS can't patch anything is because MS has exactly the same technical challanges that every major Linux distro has. Dependency hell.
MS likes to pretend that windows is immune to such things, but the truth is every piece of software is interconnected. MS creates the illusion of no dependency problems by solving as much of it as possible behind closed doors, and wrapping the results in binary installers. The sheer amount of effort to resolve the problem is high
The book "Mythical Man-Month" by Frederick P. Brooks addresses this EXACT issue. The idea of a "Man-month" in software development is a joke (specifically software development, but it applies to other fields as well).
Often times, the more people you put on a specific problem/project, the SLOWER it goes because of issues like communication, and stumbling over each others' toes, not to mention simply dividing tasks.
-.-- -.-- --..
One fish / Two fish / Red fish / Blue fish
ShyaOS - Think Differently!
http://silverstr.ufies.org/blog/archives/000879.ht ml
This post pretty much sums up why is isn't practical for Microsoft to fix every single bug. The harsh truth is that it's (financially speaking) not worth it.
Instead, you take the software and reverse-engineer a mathematical description of it. Once you have a mathematical model, you can use theorum provers to determine what parts of the code are mathematically illogical/incorrect/incomplete. Once you know what parts of the code simply don't make sense, you can restrict your debugging solely to those parts of the code. You don't need to investigate the code that works. Assuming there is any.
Of course, for "trivial" classes of bugs (buffer overflows, buffer underruns, null pointer access, etc), there are code validators which will specifically look for those flaws. splint (a lint derivative) is one, the Stanford Code Validator is another. As these form the bulk of easily exploited bugs, it would seem obvious to scan the code with these first. To make certain you've caught everything, there are also validating mallocs, such as Electric Fence, which detect obviously bogus memory accesses.
I don't know how long it would take to do a reasonable scan of the Windows source code, using such tools, but I would not think it likely to take more than a few months to do the most rigorous of these checks (convert to formal notation, then use a maths theorum prover) to locate all suspect areas, and maybe a few more months to actually correct all of these bugs. You'd probably want to use a memory profiller and/or a validating malloc first, though, to cure the really obviously bogus code.
After all that, you would then want to do regression testing to ensure you'd not broken anything in the process (or unbroken something that actually needs to be broken). This would not correct "all" of the bugs in the code, but it would reduce the number by a couple of orders of magnitude and in a timeframe that would be very reasonable.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
If you come up to me and say, "Hey, you know a lot about computers. What computer should I get?", and I tell you to get a Mac because it will meet your needs out of the box (yes, you told me what you need to do already), and you proceed to disregard my advice and get a Windows box, then just whom, exactly, is stupid and arrogant?
Wow, run-on sentence.
Short version: You keep saying those words. I do not think they mean what you think they mean.
MS is supporting every interface they ever sold with the exception of detail implementations of SCO Unix at the kernel level with Windows NT. that includes MS-DOS 2.10, four or five versions of windows basic runtime scripting, all kinds of stuff going back 20-plus years.
you can't unscramble that much spaghetti code and conflicting system calls to find the hooks to fix. by contrast, any wild-eyed wobbly who wants to break in and (pick one: wreak havoc, steal credit card info, make zombies, hack spy satellites) only has to find one hole in the snakepit to let his own snakes in.
so that's why they don't patch everything in windows. it's like counting to infinity.. just when you're almost there, somebody slams the door, and you lose count.
Travoltus had a SIG over here a few years ago that I copied down because I liked it so much... quoting...
63,000 bugs in the code
63,000 bugs
ya get 1 whacked with a service pack
now there's 63,005 bugs in the code.
that's where MS is at. Promoting Secure Computing, indeed. hard act to get on the road, that.
if this is supposed to be a new economy, how come they still want my old fashioned money?
Windows contains above 100M lines of code (recollection from some time back, probably more now).
The overall design philosophy is 'tight integration', so everything affects everything.
Any software testing problem is combinatorial: all combinations of inputs checked against all outputs. This is why testing cannot be used to produce a quality product, only to check whether the development process is capable of producing a quality product.
I guarantee you that MS's bug list for each product is in the 10s of 1000s. It is a major effort to even sort through bugs and choose the most critical, consolidate by root-cause, isolate to DLLs, AND REGRESSION-TEST THE FIX(es).
In a large system, the overhead of source code management (checkout, change, test, merge with the release with the bug, and then merge into later releases of code) is enormous. The productivity of people doing bug fixes in these large systems is very low, no matter how expert they are. This is why developers HATE fixing problems in released code.
No large company can fix all their bugs, even when bug fixes don't generate new bugs.
Lew
"The Constitution, the WHOLE Constitution, and nothing but the CONSTITUTION."
Go back and read Fred Brooks' Mythical Man Month. Microsoft doesn't have the money to hire enough coders to fix all their bugs. Their code is just too complex for that to work. Each coder coming in to change something affects all (most) of the others. Hiring more coders just makes it more difficult to fix bugs.
Where I work there are 5 programmers on a project that was written from scratch within the last year or two, and we were all on the project from the beginning. Even still we still have problems where two different coders are assigned to two seeming different bugs that have subtile interactions. More than one patch was stopped at the last minute because it overwrote a file from a different patch. (We use CVS which helps a lot, but it is not perfect - I'm told most companies do not use any version control, I have no clue how they can get any patches out)