Hi Casey,

Your last rant about APIs at the end of episode 135 prompted me to write this post.

In a nutshell, from ranter to ranter: I love Handmade Hero, but I sometimes wish I could watch the arrogance-free version, if that makes sense :)

I've been following Handmade Hero development pretty much from the start, and I've watched most of the episodes (on YouTube, for timezone and schedule reasons). It's a fantastic initiative, and I'm looking forward to watching many more hundreds episodes.

I respect the message and attitude you're trying to convey through the episodes: keeping things simple, "compression oriented programming", focusing on the useful development rather than on "administrative cruft", etc. I share many of the same sentiments. I'm also equally saddened by the state of affairs in our industry.

However, I feel that you're sometimes unreasonably critical of the technology choices or development practices of other people, teams and companies. I'm regularly surprised--and annoyed--by the lack of humility and balance in your discourse, especially coming from a mature programmer.

Not everyone is working on a small 2D game that can realistically be implemented from scratch without relying on a single third-party library. Pretty much all games or game engines rely on third party libraries because there are no other sensible ways to provide the basic functionalities player or game developers have come to expect.

Let me be clear: I absolutely understand why you're writing HH the way you do, and I praise the effort. It makes complete sense. I also realize that you have your own style, tone and persona, and, like a Charles Bloom, ranting is part of the show (and the character).

What follows are a few specific things that bothered me about that API rant in episode 135. I hope none of it is too obvious.

First, Dependency Walker does not fail to load dependencies "because there are too many". Most of the time, missing dependencies are not a problem because the application is prepared to handle them being missing.

Let's be fair: There are way fewer dependencies than you think. For instance, most system dependencies such as kernel32.dll, ntdll.dll or user32.dll, as well as runtime libraries such as msvcrt.dll are repeated over and over. What you seem to have missed about Dependency Walker is that it shows the dependency tree: most DLLs rely directly or indirectly on the same set of dependencies, themselves relying again on the same set of dependencies, over and over. The actual number of dependencies for devenv.exe is probably a few orders of magnitude lower than what you seem to think.

Now, is it really surprising that Visual Studio's IDE rely on many third party libraries? For better or worse, VS is a large application catering to a wide audience: native C/C++ developers, C#/VB.NET developers, Web developers (HTML/JS/CSS/XML/XSLT...), mobile apps developers, etc. It features many tools and custom editors whose existence most users don’t even suspect. It's just to be expected that Visual Studio relies on many external modules, some developed in-house at Microsoft, some developed by external or acquired companies, etc.

Regarding the overall DLL situation in Windows: I agree that it's a mess. However, I do not agree that it was caused by incompetence or "mediocre programmers" that "drowned the great kernel programmers". Rather, I believe this is the unfortunate messy nature of large scale software development.

I encountered this again and again in my job (mostly working on high-end rendering software), and if you worked on any large software, you probably did too: Despite all the good will and competency of development teams, software architecture and code often become less than beautiful because requirements change, technologies evolve, employees come and go, etc. Refactorings and cleanups are started but are then interrupted for a variety of reasons: employees leaving or being moved to another team, more pressing development tasks popping up, etc. This hasn’t much to do with incompetence (unfortunately!).

Here is an interesting article on this very topic: The Lava Layer Anti-Pattern.

Regarding side-by-side assemblies in Windows: How would you solve the following classic problem which I'm sure you're familiar with: As a Microsoft developer, you need to fix a bug in a platform DLL (say, in DirectX). Unfortunately, you realize that many games (voluntarily or not) actually rely on the incorrect behavior, and fixing the bug would break those games. There aren't many options: you could keep such bugs forever; you could fix the bug and break those games; or you could keep the old DLL for those games, and provide a fixed DLL for newer games, losing a bit of disk space (and, possibly, sanity) on the way. Microsoft has pretty much always chosen the last option.

Despite your sentiment, Windows is by far the most backward-compatible consumer operating system the world has ever seen. It's not all happy bunny, but you surely realize what a feat of engineering this is, when you consider the scale and breadth of the product... The "layers of cruft", the SxS stuff, and the overall apparent complexity is what permits this feat.

Keep up the awesome work on HH, and keep ranting. Simply keep in mind that you are a role model to a growing audience, and that your opinion carries much weight. As such, a bit more humility and understanding certainly cannot hurt!

Cheers,
Franz

Franz
Hi Casey,

Your last rant about APIs at the end of episode 135 prompted me to write this post.

In a nutshell, from ranter to ranter: I love Handmade Hero, but I sometimes wish I could watch the arrogance-free version, if that makes sense :)

I for one, LOVE Casey's ranting. And I see it more as a trademark to him being an amazing coder, than anything else. The way I see it, a highly, even overcritical mindset, comes with the territory. It is part of a scientific mindset to always view the counter case. On just about anything. This always seeing the imperfections, is a sign of a mind wanting and willing to improve. The way I see it, you cant have one without the other.

Franz

I've been following Handmade Hero development pretty much from the start, and I've watched most of the episodes (on YouTube, for timezone and schedule reasons). It's a fantastic initiative, and I'm looking forward to watching many more hundreds episodes.

I could not agree more. I have watched all of them.

Franz


I respect the message and attitude you're trying to convey through the episodes: keeping things simple, "compression oriented programming", focusing on the useful development rather than on "administrative cruft", etc. I share many of the same sentiments. I'm also equally saddened by the state of affairs in our industry.

However, I feel that you're sometimes unreasonably critical of the technology choices or development practices of other people, teams and companies. I'm regularly surprised--and annoyed--by the lack of humility and balance in your discourse, especially coming from a mature programmer.

One of the lessons all my own ranting has tought me is to always turn the argument against the arguer. Even towards oneself. Being critical of Casey ranting you seem to be doing the same thing as he is. You find flaws in what you otherwise love. Being able to deliver this kind of AMAZING quality, comes with a cost. Same as Windows.

Besides, his ranting towards windows is as FAR from unresonable as they come. The windows OS is not an amazing OS with a few flaws. Its a horrible, stinking cesspool of primal fear, screaming and horror, and the only amazing thing about it is it is able to function at all. Almost all of the "technology" forced into it since even before win2000 has not improved the OS in *any* way.

There's almost nothing good in there. Just horrors that for one thing; nobody needs, nobody asked for, nobody uses, and that is sure to fail as soon as they try. Everybody would have been way better off with them *not doing anything* but improve on the basic of the OS. There's just nothing good in there. Nothing. Not a single thing. Not even one single thing.

And the worst of it is that except for the very basic of the OS, almost no one needs any of the tons of irrelevant mediocre utter horror "technology" added to it, and the main reason we know it is there is because its just so fucking stupid. Just yesterday I was asked for adminpassword to run checkdisk on my thumbdrive, but was allowed to format it...from a useraccount... no problem. The entire thing is exactly as stupid as that.

You know, I can list windows features all day, without finding even one that I can say: "That's really good". Its all utter shit. There's just nothing good in it at freaking fucking all. Not even a single thing.

I challenge you to name even one feature of Windows that is good.

In fact its amazing you can do this bad. I guess you would have to be working on Linux to be worse then this. The only way to do worse then this is to have the same set of retards working on a "free" and "opensource" OS like Linux.

Franz

Not everyone is working on a small 2D game that can realistically be implemented from scratch without relying on a single third-party library. Pretty much all games or game engines rely on third party libraries because there are no other sensible ways to provide the basic functionalities player or game developers have come to expect.

They should. Windows MUST be built that way. Its not only the ONLY way it could be any good, but also the ONLY way it could be secured and functional. By doing much LESS! That way they would properly realize all of the utter CRAP that should have been left out, and how it would dramatically *improve* this 100% complete crap OS.

Franz

Let me be clear: I absolutely understand why you're writing HH the way you do, and I praise the effort. It makes complete sense.

You could stop right here. It make sense. Windows OS does not.

Franz

I also realize that you have your own style, tone and persona, and, like a Charles Bloom, ranting is part of the show (and the character).

What follows are a few specific things that bothered me about that API rant in episode 135. I hope none of it is too obvious.

First, Dependency Walker does not fail to load dependencies "because there are too many". Most of the time, missing dependencies are not a problem because the application is prepared to handle them being missing.

Let's be fair: There are way fewer dependencies than you think.

No there are way too many. Windows 7 now inject into every single PE so many modules that it is insane. 2-3 entire GUI librarieS injected into a 2 liner that does not have a gui. And thats just 1/1000 of the horrors that come along with _every_ single little application, even if it does *nothing*.

Franz

Now, is it really surprising that Visual Studio's IDE rely on many third party libraries?

[snip]

Cheers,
Franz

Visual Studio is the worst piece of shait software ever produced. Try to uninstall it!! It cannot even manage that!!

The main reason it is the worst piece of software ever written is the same as Windos. It tries to be everything. And it fails of course utterly because of it. All seasoned programmers understand this.

Unfortunately no reasonably good programmers are in charge of it, and that's why its a horrible, terrible software, which I think is so bad I don't even want it on my system. I would rather not code at all. Visual Studio feels like a very intrusive malware! I feel unsafe and unprotected having such a retarded software on my computer. No... its worse, I feel dirty, shitty, unclean having Visual Studio running on my PC. It makes me feel uncomfortable, unsafe, insecure, and I don't feel it deserves to be trusted with the things that are dearest to my programmers heart!

/s

I love rants, but this level of ignorance about Windows is just staggering.

Here is some really interesting reading about the internals of Windows for a rainy day:

The long and sad story of the Shell Folders key
http://blogs.msdn.com/b/oldnewthing/archive/2003/11/03/55532.aspx

How would you solve this compatibility problem: Network interoperability
http://blogs.msdn.com/b/oldnewthing/archive/2006/03/30/564809.aspx

(In fact, The Old New Thing, Raymond Chen's blog, is a great read if you want to have an idea of the kind of problems Microsoft needs to solve when developing Windows.)

Better on the inside: Under the hood of Windows 8
http://arstechnica.com/informatio...de-under-the-hood-of-windows-8/1/

Farewell to the Windows Kernel Dispatcher Lock
http://channel9.msdn.com/Shows/Go...he-Windows-Kernel-Dispatcher-Lock

Inside “MinWin”: the Windows 7 kernel slims down
http://arstechnica.com/informatio...-the-windows-7-kernel-slims-down/

Franz

Franz
In a nutshell, from ranter to ranter: I love Handmade Hero, but I sometimes wish I could watch the arrogance-free version, if that makes sense :)

One of the traits that I've noticed in some of the best people I've worked with is the ability to push a line of thinking with as much force and passion as possible, and then to drop it immediately when enough evidence arises that the opinion has a fatal flaw in it.

There is absolutely no shame in this. We all want the best solution to a problem. If you believe you have the best solution, it's okay to put some emotional investment in it. If it turns out you didn't, then that's no bad reflection on you.

Because of how old I am, I call this the Usenet theory of problem solving. If you want to know something on the Internet, don't ask a question. Post wrong information instead. A question can be ignored, but a mistake can't be allowed to exist uncorrected.

So there is no downside to saying what you think is the current state of affairs, even if it's half-baked.

Franz
Not everyone is working on a small 2D game that can realistically be implemented from scratch without relying on a single third-party library.

I don't want to put words in Casey's mouth, but he's noted on several occasions that this is primarily an education project. Yes, of course on a "real" project you would use at least some third-party libraries. However, those third-party libraries are not black boxes. Someone wrote them, and that is part of the educational aspect of this project.

The cost in using a third-party library is non-zero. There is a tradeoff between the cost of re-implementing some of the functionality of a third-party library (there is no third-party library worth using that you will use all of on any given project) and the cost of integrating that library.

A significant proportion of a typical programmer's career is fixing impedance mismatches between third-party systems. This is boring work, and would make for terrible viewing.

Also consider that Casey has spent a lot of his career writing what game developers would consider to be "third-party libraries", and presumably hoping that other people will use them.

I don't have an opinion on the history of Windows, since I try not to go there, so I'm just going to add a couple of random comments.

Franz
Despite your sentiment, Windows is by far the most backward-compatible consumer operating system the world has ever seen.

That is its greatest strength and its greatest weakness. The requirement for backwards-compatibility is great for end-users, but it's a pain for developers, who have to deal with design decisions taken years ago, and APIs whose surface area only gets bigger over time.

It must be a pain for the developers of Windows especially, who are prevented from doing anything the "right way" because some old version of Excel depends on the wrong behaviour.

It's not just Windows' problem, of course, it's just that Windows has been at it longer. You could just as well argue that backwards-compatibility with C is both the greatest strength and the greatest weakness of C++.

Interestingly, Mac has the opposite problem, since it migrated from 68k to PPC to Intel. The problem isn't supporting older programs on new OSes, but supporting newer programs on old OSes. Apple provided some mechanisms to do this, but essentially decreed that it's the developer's problem if they want to sell their application to people using old machines. There's a certain elegance to this.

Having said all that, at least some of the backwards-compatibilty problems are problems that didn't need to happen. They're not because hardware was different, or because we know more than we know now, but because Microsoft made a deliberate decision to kill off a competitor rather than adopt the best technology available.

Back in the day, part of Microsoft's business model was to buy up startups who hadn't shipped a mature product yet and then "maintain" them in a half-hearted way. When it looked like a competitor was about to come up with something in the same space, Microsoft would ramp up development on their version, dissuading everyone else from adopting the competitor's system.

This happened with several key APIs, including Direct3D.

From your post you seem to agree with Casey that windows has spiralled out of control, but you defend this by saying everything large always does for "reasons".

For what it's worth, I'd rather hear an opinion that I might not completely but still mostly agree with, than a toned down nice compatible with all opinion.

So Casey please don't change.

From your post you seem to agree with Casey that windows has spiralled out of control, but you defend this by saying everything large always does for "reasons".

For what it's worth, I'd rather hear an opinion that I might not completely but still mostly agree with, than a toned down nice compatible with all opinion.

I never said that Windows has spiralled out of control.

Windows is, in my opinion, a mess. I wish it was simpler, cleaner, lighter, easier to understand. But there are probably tons of talented engineers at Microsoft that understand their part of the mess, and could tell you very clearly the successive decisions they took that led to this situation, and why they took them. Just read Raymond Chen's blog for a while to get a taste of it.

Having a strong opinion and being vocal about it is not incompatible with recognizing that exceptionally difficult problems tend to lead to tricky compromises and, sadly, suboptimal or downright messy solutions. That's just a reality.

I just would enjoy HH videos and Casey's rant even more without the arrogance, that's all.

Franz

Windows is a malware DELIVERY SYSTEM!!

If you assume they are competent, it is by design.

>:>


Isn't anyway windows bashing one of their main advertising strategies? Sometimes it feels that way, reading Ars or other outlets close to release of a "new" windows version. Much negative attention.

But we know that critism is not bad, being ignored is. We use windows because its good "enough". Not for any particular person perhaps, but from an economic perspective.

One thing is sure, the Valve frontend "steam" does not give me any confidence they could do better.

It was unbelievable at first when I found out that Casey has almost the same opinion as I have.I say "almost" because people are different and they have different opinions on different matters. If we all think a like and had only one opinion then the whole world would be boring as hell. I agree to some things that Casey says but not all and it's ok to not agree to all of his opinion because everybody is different in their own way, no matter how "extreme" it is. It's a feeling he feels towards whatever he rants on based on his past experiences. If he were to "balance" it out then he wouldn't be who he is and all things he holds back (anger and frustration) will end up somewhere else, so I think his rant are somewhat healthy. Your rant on Casey's rant is also healthy as well and it's fine because, again, every one think differently.
I must say it is hard to hold back and listen without busting into a rant about the rant esp when you don't agree and the same argument keep coming up. I could then just say to ignore it or just rant about again.

Franz
In a nutshell, from ranter to ranter: I love Handmade Hero, but I sometimes wish I could watch the arrogance-free version, if that makes sense :)

You would like Handmade Hero more without the arrogance, and I would like Windows more without the greedy business policies and poor API design decisions. We are both destined for disappointment, sadly, unless the field of options proliferates.

First, Dependency Walker does not fail to load dependencies "because there are too many". Most of the time, missing dependencies are not a problem because the application is prepared to handle them being missing.

No. That is a new aspect of SxS. Originally, all dependencies listed by dependency walker (ie., in the import table) were mandatory. Optional dependencies were handled through LoadLibrary and were thus non optional.

When SxS assemblies were introduced, this changed to being "neither and both", meaning that now certain missing dependencies in Dependency Walker were OK, and also that even if there weren't any missing dependencies in Dependency Walker, there could still be unmet dependencies prior to any LoadLibrary dependencies that did not appear in the import table. The first time I had to debug a problem like this in a piece of foreign software it was pretty maddening.

What you seem to have missed about Dependency Walker is that it shows the dependency tree

I did not in any way miss that, and in fact specifically said why that doesn't matter on the episode! The entire dependency tree size is what determines the fragility! If you and I both depend on the same DLL, but you depend on one feature of it and I depend on another, then a change introduced into that DLL that is not accounted for may break your usage but not mine, but now I break because I depend on you and you depend on that usage.

Software fragility comes from the total number of edges in the graph and not the total number of unique nodes in the graph. That is a crucial point to understand. Technically, what you really want to measure with Dependency Walker would be something like a "weighted usage graph", which is how many features are used from each DLL by each DLL dependency, etc. You could call this your "suck factor" or something, and it tells you how likely you are to stop running next week when Windows Update runs.

Now, is it really surprising that Visual Studio's IDE rely on many third party libraries?

Yes, because it didn't used to. As Visual Studio has become less and less reliable, more and more slow, and increasingly crash-prone, so too has its dependency tree ballooned in size. I do not believe these to be coincidental, but obviously one would have to undertake more rigorous forensics to be sure.

Regarding side-by-side assemblies in Windows: How would you solve the following classic problem which I'm sure you're familiar with: As a Microsoft developer, you need to fix a bug in a platform DLL (say, in DirectX).

The answer to this question would depend largely on the particular nature of the library I was working with (the answer can change depending on the degree to which hardware dependencies are involved), but I can guarantee you my answer would never be side-by-side assemblies. In general, you want 99% of dependencies to bound to the application, and in no way do you want them to be centralized. And you doubly don't want to centralize them and then re-proliferate them, so that they are half bound to the app but half not. It's like taking the worst of both kinds of deployment and putting them into one design.

I say this not as a hypothetical matter, but rather as someone who shipped a 3rd-party library commercially for five years across dozens of revisions and hundreds of bug fixes on seven separate hardware platforms. On Windows, there was even a piece of code in the library to ensure that it had to be installed separately for each app - it would check to make sure nobody tried to install it centrally.

As such, a bit more humility and understanding certainly cannot hurt!

I, for one, do not wish anyone who watches Handmade Hero to approach things like Windows with humility and understanding. I want them to be furious with the current state of software, and to endeavor to do a much better job than our generation is doing right now.

Believing that Windows is somehow a "natural result of software development" is not a philosophy to which I would ever subscribe, nor would I ever encourage others to feel that way.

Poor software quality is only inevitable if we believe it to be.

- Casey

On side-by-side assembly topic - today I installed new Visual Studio 2015. Built simple application that uses standard C library functions. Before VS2015 your C application depended only on msvcrtXYZ.dll file, right? Now you depend on all these files. And that is direct dependency from your executable, not through kernel32 or other system dll.

(of course depending on actual functions you use - but from names of files it's pretty obvious: stdio, string, time, etc...)

Madness!!! What is wrong with them???
http://blogs.msdn.com/b/vcblog/ar...ntroducing-the-universal-crt.aspx

App-local deployment of the Universal CRT is not supported. The Universal CRT is a Windows operating system component.

So no more copying msvcrt/msvcrp files next to exe file. Either build with static CRT runtime or use redistributable installer.

To reiterate some points already expressed in this thread --

Software as it exists today is definitely not the best quality it could be. There is disagreement about which parts are worse but I think we can all agree there is room to improve. Many developers think the solutions are iterative on current technology and so strive to maintain backwards compatibility so they can build up little by little and carry user-developers with them along the way.

The Handmade Hero community has taken a different tack, primarily because of the strategy of the code on the show. This community has fostered an belief that much of modern software simply needs to be tossed out, because the cost of trying to improve upon it is greater than the cost of building something new from scratch. It is frustration with the lack of tools to facilitate this, and the lack of support for this idea outside of the community, that results in a strong defensive stance and vigorous criticism of other groups and pieces of software that don't follow this creed.

Casey, being the progenitor of the community and having enough experience with the current software environment and knowledge of what was possible in past environments, has especially strong opinions on this front. And from what I've seen, he is one of the few voices advocating this position.

Sometimes, the fewer voices there are, the more loudly they must shout to be heard by others.

What OP interprets as arrogance in Casey's arguments seems to be more likely a strengthening of advocacy for his position. As has been made clear here, he has plenty of supporting evidence to back up his criticisms. If he doesn't deliver it in total coherency and in rigorous detail on stream, it's because he is more interested in giving the programming community a good example than belaboring his points, so he strongly delivers the criticisms simply so that they can be made part of the conversation.

So basically, Handmade Hero doesn't need balance, because most of the other rhetoric existing today is "in balance" with it. It is one voice among many.

Edit: I would also like to add an argument both against and for humility in programming.

Humility is useful in the sense that what is a "good practice" in programming changes almost annually. I mean "good practice" in both what is generally accepted by various communities and what is best to write for current hardware. To keep up with this, you must always assume that you do not have the right answer, and keep seeking the new right answer. This can be tiring and costly and hard to justify sometimes, but humility always is.

Humility can also be a barrier if no one else, at least the most-heard voices, are humble. Being humble becomes being submissive, and your voice is drowned out. There are a lot of very loud voices in programming circles, voices who don't always represent what may very well be the new best practices. In these cases, being humble can mean allowing the argument to become one-sided, which can quickly turn into there no longer being any argument at all. Thus, dogmas are born.

Oh man - Martins, that is even worse than I thought :( Such a total fail.

- Casey

Somebody from MS turned up in Reddit thread where people are discussing C++ redistributable stuff in VS2015: https://www.reddit.com/r/cpp/comm...3fqxj0/visual_c_2015_redist_dlls/ Turns out app-local deployment for VS2015 is supported. But it isn't documented anywhere. He writes:

Go to https://dev.windows.com/en-us/downloads[1] ; download and install the "Windows Standalone SDK for Windows 10." After installing the SDK, the Universal CRT DLLs for app-local use may be found under C:\Program Files (x86)\Windows Kits\10\Redist\ucrt\DLLs. You should include all of the DLLs from that directory with your program.

So basically don't use redist DLL files files that are installed together with VS. Instead download new Windows SDK, and copy all those DLL files from my screenshot next to exe. Then it is supposed to work. Ugh..

Every year Microsoft makes it harder to actually ship a working executable.

- Casey

mmozeiko
On side-by-side assembly topic - today I installed new Visual Studio 2015. Built simple application that uses standard C library functions. Before VS2015 your C application depended only on msvcrtXYZ.dll file, right? Now you depend on all these files. And that is direct dependency from your executable, not through kernel32 or other system dll.

(of course depending on actual functions you use - but from names of files it's pretty obvious: stdio, string, time, etc...)

Madness!!! What is wrong with them???
http://blogs.msdn.com/b/vcblog/ar...ntroducing-the-universal-crt.aspx

App-local deployment of the Universal CRT is not supported. The Universal CRT is a Windows operating system component.

So no more copying msvcrt/msvcrp files next to exe file. Either build with static CRT runtime or use redistributable installer.

So, most of those files are also shown when Casey uses Dependency Walker on HH. Also, look at the size of them, they're tiny. This is some OO stuff going on at worst, and at best it is simply the artifacts of a huge software project with lots of small teams working on their own stuff and delivering their own deliverables, or something. Putting all those files into a single .dll wouldn't decrease the complexity, just as splitting a single .dll up into separate files doesn't increase the actual complexity, only the perceived complexity.

Also, no one in this thread has mentioned the efforts internal to Microsoft (that are not secret AT ALL) to do exactly what you say Microsoft are not doing, which is to slow this crazy train down and rethink how things are designed at the macro scale.

Look at the TINY versions of windows that MS have made available for the Raspberry Pi or the Arduino Galileo, for example. In the case of the latter, that thing is like 150MB if I recall correctly. And it will run virtually any C/C++ that can be compiled with Visual Studio where it makes sense for the platform (no DirectX, for example.)

So, there ARE efforts within Microsoft to untangle the mess Casey described. And hey, bonus, they're producing deliverables; you're just not going to find those changes anywhere in the game development sphere for a very long time.

GUIs on Linux (the more "modern" ones) are equally as complex as what Casey showed. Linux STILL HAS AUDIO PROBLEMS on a lot of hardware, and it hasn't been fixed because no one seems to be able to pin down exactly what is causing these issues on certain pieces of hardware. It's not even a driver thing, it's just that the nested audio APIs on Linux are such a mess that it is nearly impossible for a single person to contain all the knowledge necessary to fully assess the situation, forget actually making the fixes.

Gnome and KDE are the same way. I can't show you a screenshot of a linux equivalent of depends.exe, but anyone who's had any application issues on Linux can attest to the side effects of the spiderweb of dependencies and what happens one just a single strand of the web breaks. I remember when doing "yum upgrade" was something you waited for the weekend to do, because you knew you were going to be spending many, many hours fixing things. Fixing things, and installing things in just the right order, as Casey described similarly for Windows. Except for Linux, some of those packages are broken, so the software has to be compiled from source. Well I hope your build environment is up to date, because that is a whole other infrastructure of dependencies that often conflict because two libraries you need to compile an app you need each require different, mutually exclusive versions of the same supporting library in the same location at the same time...

So it isn't just Microsoft. It's just how HUGE software projects like this are done; it's cheaper to do them poorly than it is to do them properly.