Today I hate Microsoft. Some days I'm indifferent. Some days I love the company. Today I hate Microsoft.
It has absolutely nothing to do with any Slashdot or Register or other news article. Both of those sites loathe and are hostile toward any company and/or person that makes more than 1 million USD per year.
Nope. None of that. It has everything to do with DestroyWindow(). I hate Microsoft's DestroyWindow() function. MSDN Library has this one little innocent comment that caused me to waste an inordinate (and highly frustrating) amount of time today:
"A thread cannot use DestroyWindow to destroy a window created by a different thread."
WHAT THE...!?! I have words for that that are inappropriate for this blog. I need a good chunk of lye for cleaning of the mouth.
Let's think about this. I understand perfectly that people wouldn't want other processes calling DestroyWindow. That's uncouth. However, within the same process, Windows should never give a hoot as to what thread calls DestroyWindow. From an application developer perspective, I despise restrictions like this that seem so utterly silly and trivial, it begs the question. I'm sure there is some completely, totally, sane, and utterly sensible (er, retarded) reason for the restriction that someone in the marketing department would send in reply to this. If a programmer wrote actual code for that restriction, he or she needs to be shot...by firing squad. If it was implicit, then someone needed to fix that problem behind the scenes 10 years ago. To me, this is a major bug in the OS, but it is too late to fix it.
The obvious workaround to this bug is to notify the thread that actually owns the window that another thread wants it destroyed. Unfortunately for the clueless developers at Microsoft who think this is "normal", this is what is called a "hack" - a workaround for a major limitation. No one should ever have to write hacks. Ever.
I'm beginning to notice a trend with the way MSDN Library works - basically, a programmer will write a function he/she is told to write, but whenever I look at the new stuff being added (function-wise), it seems to me that all they do is document the laziness of the developer. In fact, the newest documentation seems to be somewhat "whiny" in the approach...like "why are you reading this? .NET solves all your problems". No, .NET will never do that. Now if you gave me 4 billion USD, that would solve the majority of my problems. .NET = no. 4 billion in cash = yes.
It has absolutely nothing to do with any Slashdot or Register or other news article. Both of those sites loathe and are hostile toward any company and/or person that makes more than 1 million USD per year.
Nope. None of that. It has everything to do with DestroyWindow(). I hate Microsoft's DestroyWindow() function. MSDN Library has this one little innocent comment that caused me to waste an inordinate (and highly frustrating) amount of time today:
"A thread cannot use DestroyWindow to destroy a window created by a different thread."
WHAT THE...!?! I have words for that that are inappropriate for this blog. I need a good chunk of lye for cleaning of the mouth.
Let's think about this. I understand perfectly that people wouldn't want other processes calling DestroyWindow. That's uncouth. However, within the same process, Windows should never give a hoot as to what thread calls DestroyWindow. From an application developer perspective, I despise restrictions like this that seem so utterly silly and trivial, it begs the question. I'm sure there is some completely, totally, sane, and utterly sensible (er, retarded) reason for the restriction that someone in the marketing department would send in reply to this. If a programmer wrote actual code for that restriction, he or she needs to be shot...by firing squad. If it was implicit, then someone needed to fix that problem behind the scenes 10 years ago. To me, this is a major bug in the OS, but it is too late to fix it.
The obvious workaround to this bug is to notify the thread that actually owns the window that another thread wants it destroyed. Unfortunately for the clueless developers at Microsoft who think this is "normal", this is what is called a "hack" - a workaround for a major limitation. No one should ever have to write hacks. Ever.
I'm beginning to notice a trend with the way MSDN Library works - basically, a programmer will write a function he/she is told to write, but whenever I look at the new stuff being added (function-wise), it seems to me that all they do is document the laziness of the developer. In fact, the newest documentation seems to be somewhat "whiny" in the approach...like "why are you reading this? .NET solves all your problems". No, .NET will never do that. Now if you gave me 4 billion USD, that would solve the majority of my problems. .NET = no. 4 billion in cash = yes.
Comments
Post a Comment