You forgot the debug from log file approach.
I''ve found it''s the only workable solution because when *my* programs crash they take down the whole computer, making any process that runs on the same CPU unavailable (i.e. nixs options 1 and 4).

The work from debug approach is a good one and you are in
control of the debugging information that you get. I have one suggestion. I personally use a single debug log file but have different methods writing to it. I use a method to write debug stuff, one to write true error stuff and one to write specifically for directx errors and make sure all input to the file is labeled as such. I always include the class, method and directx method that caused the failure. It has been extremly useful as I just was able to debug a crash in my system yesterday in just a couple of minutes.

It depends what you mean by "viable gaming platform." I''ve been using Win2k since beta 3 came out. OpenGL applications are extremely quick (using my TNT2). Quake III framerates are far above anything I was seeing under Win98 (128 Mb RAM in both cases). Quake II and (GL)Quake I both look awesome, too. With RC3''s inclusion of DirectX 7 (and - finally - decent driver support for the TNT2 in D3D on Win2000), I''ve found it to be very stable on new(ish) games. Unreal Tournament works beautifully. Alpha Centauri likewise. I had problems with Ultima IX (who didn''t?), but with the latest patch its noticeably less choppy under Win2k than it is under Win98. Also, Win2000''s networking layer seems to be better - lower ping times in multiplayer games (admittedly, with an ADSL connection I don''t really notice it). I''ve heard from people (I''m a computer consultant) having problems with it, and in most cases its been due to: unsupported hardware, requiring use of old drivers (its sometimes possible to reuse an NT4 driver, which won''t support most of DX7 except through the largely nonexistent HEL). Its also noticeable that Win2k - like NT4 - uses a machine more thoroughly, so overclocking failure is more common (for some reason, a lot of people seem to think that if a machine will boot the overclock worked; this is not the case. If it doesn''t overheat after being at 100% CPU usage for, say, 24 hours then its acceptibly clocked!). Also, if you have less than about 70 Mb of RAM, you won''t want to use it for high performance games..... because you won''t have very much physical RAM free without switching off services, etc., and thats just a pain.

As for development - Win2k is wonderful for writing games. Assuming that you want to use uptodate calls (ie. no execute buffers!), the entire API is supported. On top of this, you gain incredible stability (especially when compared with Win98). I''ve recovered from some really nasty crashed apps (due to bad programming on my part), and I rarely (if ever) have to reboot.

As for debugging... I debug over a network, use log files, AND use Win2k''s ability to debug fullscreen apps (although this can still fail, sometimes). There is never just one right answer!

I''m using Win2k RC2, and I''m just wondering how you debug fullscreen aps?
When my apps crash they just sit there and I have to CTRL-ALT-DEL switch to VC6 (the app is still in the FG so I can''t see anything) and then hit SHIFT-F5 to cancel debugging so that my app exits. How can you hide the app and get back to the debugger while it''s still running?

I''ve got a dual monitor config. on my NT box ( Matrox G400 DualHead ) and I''m doing remote debug to a Win98 computer about a foot away. I always considered it to be the most optimal situation ( never experienced any sluggishness ) because I could have MSDN on one monitor and be programming on another and debugging on a third, but the thought of using a log file is something that I consider to be a great idea no matter what kind of debugging your doing. However, since I do the majority of my debugging remotely then the OutputDebugString function pretty much covers everything I need. Except when my workstation crashes...then I''m screwed.