id Games on Windows Vista/7

Some of the id Tech 3 (aka Quake 3)-engine based games won’t run correctly on Windows Vista, 7, etc. due to the UAC. Some people suggest turning UAC off or running the game as an administrator, but that is ill advised; turning off security or running it in a higher privilege to play a game is foolhardy at best, especially when a better, more secure solution is readily available.

The problem is that when these id Tech 3-engine games start up, they try to extract a DLL from one of the PK* files into the program directory. Since the Program Files directory is protected, and especially since the file being dropped into it is a DLL which as a security threat is second only to EXE files, and finally because it’s being put in the folder by a non-privileged program—the game itself—as opposed to a privileged program like the original setup program that installed the game in the first place. This all leads the system to blocking the extraction, which causes the game to terminate with an error that includes the following snippet.

found DLL in pak file: C:\Program Files\Prey\base\game03.pk4/gamex86.dll
copy gamex86.dll to C:\Program Files\Prey\base\gamex86.dll
could not create destination file
********************
ERROR: DLL extraction to fs_savepath failed

(Windows Vista/7 already have a system in place for this sort of thing and it usually works for games (eg for games that store screenshots or save games in the Program Files directory); such files are put in the VirtualStore directory in the user’s profile instead of in the actual Windows or Program Files directories, but for some reason it does not seem to work for these older id games.)

Instead of resorting to turning UAC off or running it with administrator privileges, a much more ideal solution is simply to manually extract the DLL file in question and place it into the program folder. Open the PK* file mentioned in the error (in the above example it is game03.pk4) with a ZIP compatible program (7-Zip is great). Then simply extract the file gamex86.dll into the game’s base folder (or other, possibly different folder as specified in the error).

Note: You probably won’t be able to simply extract the file directly to the program folder because of the permissions/UAC, you’ll likely need to either run the archiver as administrator or just take an intermediary step by extracting it to somewhere else like the desktop, then moving the file to the program folder (and saying yes/OK to the UAC prompt).

Done. Now launch the game, see how it runs as expected without requiring a security feature to be turned off or running it as administrator, and enjoy!

DOS Games in Windows XP

Support for old software is not a high priority anymore and is fading fast. This is bad news for gamers who want to play those old DOS (and even Windows) games that do not run on modern hardware and operating systems.

One solution is to find old hardware to run those old games on. This is the ideal solution from a compatibility standpoint, but has its own drawbacks like extra physical hardware, electricity, space, cost, and so on. Another solution is to use hardware emulation software that tricks the old software into thinking that it is running on the hardware that the emulator tells it. This is less compatible, but has advantages like price and convenience.

Emulators like DOSBox, VMWare, Virtual PC, Parallels, QEMU, and the like are a great way to go in a lot of cases. But, for really intensive games like FPSes, you will probably want to run them natively to get better performance.

The three biggest obstacles in running old software on modern computers natively are CPU, sound, and audio.

Old software was not designed to run on modern CPUs which are often too fast, and also have multi-threaded/core functions. Worse, modern systems are moving to a model that old software developers could not even conceive of in those days. There are programs that can slow a system down (usually by running the CPU in a controlled, but infinite loop) so that the old program gets fewer CPU cycles, but a much better solution is to use an emulator.

Audio in a program running natively has been handled for the most part by VDMSound. It has not been updated in a long time, but most class-gamers will attest that it works for most purposes. Emulators work well too, but they do not usually offer as wide a variety of sound cards.

Video has had its share of hacks as well. Ken Silverman—they guy who created the Build engine which powered games like Duke Nukem 3D—released a couple of tools (NOCLI and NOLFB) that will modify old apps so that they can run in XP without locking up. However, even with those, most graphics programs (eg games) will usually freeze in XP on startup and display only the first frame. The way to fix this is to install the Full Screen Video Driver For Console which comes with Windows XP but is not installed by default:

  1. Open the Control Panel
  2. Run the Add Hardware applet, click Next, wait
  3. Select Yes…already connected
  4. Scroll down and select Add a new hardware device
  5. Select …manually…(Advanced)
  6. Select Show All Deviced
  7. Select Microsoft Corporation for Manufacturer and Full screen video driver for console for Model

That’s it. Now graphical DOS software should run properly in Windows. You can still use NOLFB and NOCLI if needed. Windows 2000 could not only run graphical DOS software full-screen, but it could even run them in a window, which XP cannot do. That was a great feature that is missed. Windows Vista has changed quite a bit that a lot of even XP softare will not run in it. It’s adoption has been pretty slow, so we’ll just have to see what gamers come up with for it, although it may very well be the case that XP is the last OS for classic-gamers: future classic-gamers will probably have to run emulators that hopefully will be much better.