I think there's lots of reasons why "Microsoft programs are so buggy" -- I put that in quotes because I think that the phenomenon of calling "bug!" is often inaccurate. The truth is, getting "correct behavior" on a PC is a difficult chore, so many (most?) of the programmers out there just aren't up to the task. There's a correct way to develop software, and there are a hundred (-thousand?) incorrect ways. The correct way requires discipline, skill, and experience; and it's expensive. And for the most part, it's not worth it (ref back to my message about people not willing to pay what it's worth).
[...]
..........
I agree.
Regarding MSFT 'bugs' or 'known issues', there are, in my experience, two categories:
a.) Problems caused by complexity.
As you know, several years ago, one of the most common Win32 issues was something we called 'DLL Hell'. DLL files -- for Dynamic Link Library -- are collections of small programs or applets. These applet repositories store logic which an executable will call upon as needed to perform various ancillary functions. For example, if you use MS Word, the main app -- winword.exe -- might call upon Interop.Word.dll to carry out specific actions.
Anyway, 'DLL Hell' was the name Geekendom gave to the operating system chaos caused by one app's installation routine or operation overwriting (or otherwise changing) the DLL files associated with another app. Although it's easy to blame software vendors -- who have the Windows API (application programming interface) as a reference -- the fact is that there are so many Windows apps and the OS is so big, someone's bound to step on someone else's foot from time to time.
b.) Problems caused by laziness, not giving a fuck, missing the point, or the anchor that is yesterday.
Everyone knows that Windows is, generally speaking, 'less secure' than OS X, Linux and UNIX (Vista's a bit of an improvement but creates other vulnerability vectors -- for example, a new, and currently mostly quiet, DRM vector).
Fewer people know why.
In brief, MSFT has traditionally spent far less time securing Windows' networking ports and internal access control methods than marketing how awesome their products are. Something called 'prvilege escalation' -- often made possible by an event called a 'buffer overflow' (there are great Wikipedia articles on these topics if anyone really wants to dig in) are ancient enemies.
For example, older versions of Internet Explorer were notorious for being vulnerable to 'privilege escalation' attacks which enabled malware to gain access to key operating system components via the simple act of browsing to a compromised site. Mozilla's Firefox gained market share in large part because of many people being fed up with these problems.
People were fed up because this is the kind of 'bug' MSFT surely could have solved long before they (partially) did recently. But the expense of a code review (IE is tied to the OS in many ways -- a full security and performance review would be a non-trivial job) was no doubt great. And, as long as market share remained strong, there probably was little incentive to bother.
With each successive version of Win32 -- Win2000, Win 2003, WinXP, Vista -- MSFT promised that the past would be jettisoned and shiny new code would replace the virus and Trojan welcoming architectures of the past. Like practically all enterprises, MSFT is a bullshit factory; still, I suspect their engineers meant it.
The trouble was all the legacy functions and code that needed support.
Turns out the past wasn't as disposable as they'd hoped (or marketed).
.d.
-- "Even bad men love their mommas."
Ben Wade
...................... http://monroelab.net/blog/