Support NeoGAF

[goodcow]

:lol

I'm loving this MSDN blog that was linked to in this thread, and this post deserved special mention:

http://blogs.msdn.com/oldnewthing/archive/2004/06/04/148427.aspx

Do not underestimate the power of the game Deer Hunter

During the run-up to Windows XP Service Pack 2 Beta in December of last year, there was a list of five bugs that the release management team decided were so critical that they were going to slip the beta until those bugs got fixed.

The third bug on the list: Deer Hunter 4 won't run.

Deer Hunter has the power to stop a beta.
posted on Friday, June 04, 2004 7:01 AM by oldnewthing

# re: Do not underestimate the power of the game Deer Hunter
Friday, June 04, 2004 7:10 AM by asdf
Don't keep me in suspense. Why didn't deer hunter run?

# re: Do not underestimate the power of the game Deer Hunter
Friday, June 04, 2004 7:18 AM by Raymond Chen
Its copy protection was crashing.

# re: Do not underestimate the power of the game Deer Hunter
Sunday, June 06, 2004 5:04 PM by Justin Steventon
Tim is quite right, you want to at the very least understand every regression of this class.

Copy protection mechanisms are also tricky, because they are constantly changing so that someone can't write a one-hack-for-all type fix. Since test lists are limited, even a single broken application is likely to mean that dozens more are broken.

However, Raymond's point about Deer Hunter being important is well taken. For XP, we had to make sure every 'Hunter' game was working. And there are lots of them (Shark Hunter, Turkey Hunter, ...)

Related to that, it's simply amazing what Microsoft will actually bother to not only test for, but fix, related to third party apps for Windows. The one thing I can't understand though, is what they do with all this testing since they don't do regular point updates like Mac...

For example:

http://blogs.msdn.com/oldnewthing/archive/2004/09/10/227860.aspx

Sometimes the bug isn't apparent until late in the game

I didn't debug it personally, but I know the people who did. During Windows XP development, a bug arrived on a computer game that crashed only after you got to one of the higher levels.

After many saved and restored games, the problem was finally identified.

The program does its video work in an offscreen buffer and transfers it to the screen when it's done. When it draws text with a shadow, it first draws the text in black, offset down one and right one pixel, then draws it again in the foreground color.

So far so good.

Except that it didn't check whether moving down and right one pixel was going to go beyond the end of the screen buffer.

That's why it took until one of the higher levels before the bug manifested itself. Not until then did you accomplish a mission whose name contained a lowercase letter with a descender! Shifting the descender down one pixel caused the bottom row of pixels in the character to extend past the video buffer and start corrupting memory.

Once the problem was identified, fixing it was comparatively easy. The application compatibility team has a bag of tricks, and one of them is called "HeapPadAllocation". This particular compatibility fix adds padding to every heap allocation so that when a program overruns a heap buffer, all that gets corrupted is the padding. Enable that fix for the bad program (specifying the amount of padding necessary, in this case, one row's worth of pixels), and run through the game again. No crash this time.

What made this interesting to me was that you had to play the game for hours before the bug finally surfaced.
posted on Friday, September 10, 2004 7:00 AM by oldnewthing

 

[tedtropy]

The next time a MacAddict goes on about how much more stable OS X is versus XP, hopefully they'll bare in mind moments like this and how incredibly daunting a task Microsoft has in making sure the OS is as compatible with every goofy little piece of software out there as possible.

 

[goodcow]

The next time a MacAddict goes on about how much more stable OS X is versus XP, hopefully they'll bare in mind moments like this and how incredibly daunting a task Microsoft has in making sure the OS is as compatible with every goofy little piece of software out there as possible.

Exactly, I find the fact that they even do this in the first place astounding.

 

[goodcow]

http://blogs.msdn.com/oldnewthing/archive/2003/12/24/45779.aspx

Why not just block the apps that rely on undocumented behavior?
Because every app that gets blocked is another reason for people not to upgrade to the next version of Windows. Look at all these programs that would have stopped working when you upgraded from Windows 3.0 to Windows 3.1.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Compatibility

Actually, this list is only partial. Many times, the compatibility fix is made inside the core component for all programs rather than targetting a specific program, as this list does.

(The Windows 2000-to-Windows XP list is stored in your C:\WINDOWS\AppPatch directory, in a binary format to permit rapid scanning. Sorry, you won't be able to browse it easily. I think the Application Compatibility Toolkit includes a viewer, but I may be mistaken.)

Would you have bought Windows XP if you knew that all these programs were incompatible?

It takes only one incompatible program to sour an upgrade.

Suppose you're the IT manager of some company. Your company uses Program X for its word processor and you find that Program X is incompatible with Windows XP for whatever reason. Would you upgrade?

Of course not! Your business would grind to a halt.

"Why not call Company X and ask them for an upgrade?"

Sure, you could do that, and the answer might be, "Oh, you're using Version 1.0 of Program X. You need to upgrade to Version 2.0 for $150 per copy." Congratulations, the cost of upgrading to Windows XP just tripled.

And that's if you're lucky and Company X is still in business.

I recall a survey taken a few years ago by our Setup/Upgrade team of corporations using Windows. Pretty much every single one has at least one "deal-breaker" program, a program which Windows absolutely must support or they won't upgrade. In a high percentage of the cases, the program in question was developed by their in-house programming staff, and it's written in Visual Basic (sometimes even 16-bit Visual Basic), and the person who wrote it doesn't work there any more. In some cases, they don't even have the source code any more.

And it's not just corporate customers. This affects consumers too.

For Windows 95, my application compatibility work focused on games. Games are the most important factor behind consumer technology. The video card that comes with a typical computer has gotten better over time because games demand it. (Outlook certainly doesn't care that your card can do 20 bajillion triangles a second.) And if your game doesn't run on the newest version of Windows, you aren't going to upgrade.

Anyway, game vendors are very much like those major corporations. I made phone call after phone call to the game vendors trying to help them get their game to run under Windows 95. To a one, they didn't care. A game has a shelf life of a few months, and then it's gone. Why would they bother to issue a patch for their program to run under Windows 95? They already got their money. They're not going to make any more off that game; its three months are over. The vendors would slipstream patches and lose track of how many versions of their program were out there and how many of them had a particular problem. Sometimes they wouldn't even have the source code any more.

They simply didn't care that their program didn't run on Windows 95. (My favorite was the one that tried to walk me through creating a DOS boot disk.)

Oh, and that Application Compatibility Toolkit I mentioned above. It's a great tool for developers, too. One of the components is the Verifier: If you run your program under the verifier, it will monitor hundreds of API calls and break into the debugger when you do something wrong. (Like close a handle twice or allocate memory with GlobalAlloc but free it with LocalAlloc.)
The new application compatibility architecture in Windows XP carries with it one major benefit (from an OS development perspective): See all those DLLs in your C:\WINDOWS\AppPatch directory? That's where many of the the compatibility changes live now. The compatibility workarounds no longer sully the core OS files. (Not all classes of compatibility workarounds can be offloaded to a compatibility DLL, but it's a big help.)
posted on Wednesday, December 24, 2003 10:06 AM by oldnewthing

 

[Phoenix]

The next time a MacAddict goes on about how much more stable OS X is versus XP, hopefully they'll bare in mind moments like this and how incredibly daunting a task Microsoft has in making sure the OS is as compatible with every goofy little piece of software out there as possible.

Right, because OS X has never had a 'must fix' bug related to a 3rd party application.

 

[goodcow]

Right, because OS X has never had a 'must fix' bug related to a 3rd party application.

I don't think he, or at least I, mean that, it's just that there's so much more software out there to test with Windows, AND, a much larger userbase and variables to test against.

Some of these specific patches just make me go, "Why the fuck did you bother?" But then, as the blog owner himself says:

http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.aspx#comments

# re: When programs grovel into undocumented structures...
Tuesday, December 23, 2003 12:54 PM by Raymond Chen
Colen: Look at the scenario from the customer's standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn't work at all. You're going to tell your friends, "Don't upgrade to Windows XP. It crashes randomly, and it's not compatible with program Z." Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn't work because it is using undocumented window messags? Of course not. You're going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.)

Lots of those classify for my "why?" comment.