Flutterby™! : Windows issues 2002-07-12 22:22:42+00

Windows issues

2002-07-12 22:22:42+00 by Dan Lyke 7 comments

People who are going to get smacked by Dan #4218: The next Windows developer who references Mandrake versus Red Hat versus Debian versus SuSE Linux distributions, or the various glibc version issues, as a problem.

Urm, glibc versions ARE sometimes a problem, especially with big chunks of software (like, say, web browsers) that need them. And the Red Hat distribution seems to get worse and worse - in terms of invasive installer and similar nastiness - each time it appears.

But I agree with the fundamental point that Microsoft has nothing to feel smug about in this area. Funny thing is, one of the few chunks of Microsoft system that I upgrade regularly and frequently is the only one I've EVER seen with intelligent and robust version-checking on upgrades and ability to deal with minor system differences. I.e. it always installs right and does the right thing.

It's DirectX, the hardware-abstraction drivers for games. My theory is that the game developers simply tolerate(d) less BS. I was in the beta program for DirectX and I remember some of the scathing commentary fired by developers at the time.

But that could be wishful thinking. Microsoft also has a vested interest in encouraging people to write games, after all ....

Todd, your view of DirectX doesn't jive with that of most of my peers (computer professional and developers - even some game developers), who generally think - with a few version exceptions (8.0a) - that DirectX is a mess. Among its most heinous crimes, with regards to installation, is that you can't back out of a version/installation.

My last boss - who coded the NT system debugger for seven years - once asked a DX developer how he could get back to a previous version. The answer? "Um... re-install the OS."

Shawn, ditto on the DirectX woes, in fact that's one of the many things that's been giving me woes over the past few. Driver support for various features is sketchy, software emulation doesn't always kick in even when we ask for it, so we're learning to have loops that iterate through the various options to a call rather than asking for less restrictive terms.

At Scotch Night a week or two ago, Leo reported an exchange with one of his developers at Maxxis:

But we've had lots of other weirdness that just shouldn't work that way. Differences in how the CLR reports security violations on different machines (CLR doesn't like executables on network drives...), similar MDAC component issues, and no easy way to figure out what's going on.

Just way too much crap pushed back on the developer to check, when the OS layer already knows why things are erroring.

Hmm, interesting. OK. I confess - I have never needed to back out a version of DirectX. The backwards compatibility has always been seamless (at least from the user perspective). I agree, though, that if you did need to back out a version, you'd be screwed.

The part of DX I consider saner than most other Microsoft OS upgraders is the part that checks version stamps and only upgrades the parts which actually need upgrading. Practically a necessity, because many games won't run unless you try to install "their" DX (the version they were built and tested with, usually). This means that generally you run the DX installer as often as you install a game, but game manufacturers now routinely include it on their CDs, so it's painless, and the version checking means that it's pretty harmless. I have never broken an older game by running a newer DX installer. Never.

Now, Dan mentions nVidia drivers. Video card drivers are my bane because they have everything wrong with them that the DX installer does not: If you install a new version of a video driver you sometimes break older games; you have to go onto the web and look for the damned driver through a long chain of links which often drives you past lots of annoying advertising; they don't always have a clearly defined installation path; and they don't have obvious version numbering or version checking.

But, hey - it IS easy to save the old driver for backout reasons, since it's usually only one or two files!

So what do you do if the choice comes down to: Make backing out a version fairly easy, since you'll probably need to ... or make it very hard, but never needed?

One caveat: I may also be a bigger DX cheerleader than it deserves because I remember the days of DOS games when the game companies were obliged to beg, borrow, write or steal their own device drivers. Game makers should not be in the hardware driver business. A game shouldn't even have to know what hardware the system has, only that its requirements are or are not met.

I agree that DX still has a lot of problems, years after the fact. I haven't been in its internals in, goodness, seven years or more. And it was a mess then. But some of that is not just bad code.

Among other things, DX can't keep up with the competitiveness of video card manufacturers, who are always looking for the Next Big Thing so they can control the market, and who change their hardware specs at the drop of a hat. Everyone knows that there is only room for one Reference Standard Video Card at a time in the game market, and this makes for a lot of pushing and shoving. That, too, stinks in its way. Not least for those who have to buy and use the damned cards.

I think the real issue is that if the software developers do their job right, then yes, none of this is a problem. And my gripe is how bloody hard Microsoft makes it for the software developers to do their job right. When I compare the issues with the portions of DirectX that I'm fighting with, for the same functionality that I once used the QuickTime for Windows 1.0 (and 1.1, which was a fix done at my request) API, it seems like we've gone backwards.

But most game developers have struggled with these issues long enough, since the DOS driver days, that they're still used to dealing with it as they did with DOS drivers, and that's okay. I'm pissed off that we've got processors with 100 times the clock speed of the minimum requirements of the last game I shipped, but accessing the video card is as complex as it was back then.

And from a developer's standpoint: try writing code for DirectX in any compiler other than Microsoft's. Even in 1995, when I first messed with DirectX (at version 3.0), I had to first port my code from Watcom C/C++ to Microsoft C/C++. Sure, Watcom worked with DirectX 2.0 but Microsoft never gave them the lead time to release an updated compiler with the updated DirectX. The only way to stay current with DirectX was to use Microsoft's compiler and in games, if you are coding the the version of DirectX that is new or mainstream when your game is RELEASED (read: two years after development starts), then you are screwed.

To make matters worse, after spending thousand$$ on Microsoft products to develop my game titles, I got to compete for shelf space with Microsoft's own titles. Is that not the definition of a monopoly?