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!

Super-Duper Windows Fix

The super-duper in the title refers to the magnitude of this Windows fix rather than its keenness.

for /R %systemdrive% %i in (*.dll *.ocx *.ax *.acm) do (regsvr32 /s "%i" & regsvr32 /s /i "%i")

This command will re-register with Windows every dll, ocx, ax, and acm file on the system drive. Alternately, %systemdrive% could be replaced with %systemroot% or %systemroot%\system32 to only re-register those files in the Windows (or Windows\System32) directory and its subfolders, and ignore those in Program Files, etc. (of course those may in actuality be the problem). You could also add other self-registering filetypes (a few EXEs have actually been known to self-register).

Also, this is not exactly a cure-all. While it may indeed fix some (or even a lot) of problems, it also has a tendancy to reset a lot of settings. Most files, when they register with the system, will perform an initialization routine that usually sets variables, files, registry entries and such to the preset default, thus wiping out any changes you’ve made. This may actually be the required step to fix something you messed up, but only if you know which file needs to be re-registered; this super-duper one will reset everything.

CLS is a Hack

Open a command prompt and type the following command: cls>clstest.txt. Now examine the contents of clstest.txt. You will see that it contains one character: 0x0C—FF which stands for form-feed. That’s right, CLS clears the screen by merely scrolling the previous contents out of sight by printing out a form-feed character; well, almost merely.

If you are using XP or higher, set the command prompt window to have a larger buffer and try this command: more /p clstest.txt. It displays the contents of the file, expanding any form-feed characters it finds. What happens is that the display scrolls the previous contents up by the number of lines equal to the console window’s screen height, which can be less than the buffer height, effectively clearing the screen, but leaving buffer.height-screen.height lines unaffected; you can still scroll up to see the previous contents. Using the CLS command however does erase the contents of the buffer and resets the cursor to the top-left most position.

CLS prints a form-feed character because when it was first created back in the days of early versions of (MS-)DOS there were no back-buffers and screens were a fixed size.

This behavior of CLS is still present even in Windows 7. It is interesting to see some of the indelible backwards compatibilities.

NULL Character (and other Control Codes) at Command Line

You can type control codes at command prompt in Windows (and DOS) by pressing the corresponding key with the Control key. Get it, Control key for control code?

The connection between letter and code is simple: add 0x40. That is, for control code 1, add 0x40 to get 0x41 which is the ASCII code for ‘A’, therefore press Ctrl+A to get character 1 (SOH).

But, the alphabet only accounts for 26 of the first 32 characters. What about codes 27-31? The correspondence remains the same. Character 27 (ESC) is 0x1B+0x40=0x5B which is ‘[’, 28 (FS) is ‘\’, 29 (GS) is ‘]’, 30 (RS) is ‘^’, and 31 (US) is ‘_’.

Unfortunately, since ‘_’ is a shifted character, it requires holding Shift to create, so it is not possible to press Ctrl+Shift+- to get character 31 that way (and for the curious, no, Ctrl+- won’t work). For that, you’ll have to resort to the classic Alt+Numpad method (Alt+31 on the numeric pad).

Conversely, you cannot press Alt+0 to type character 0 (NUL). To get null, you have to use the Control key. Remember that it requires adding 0x40, so zero plus 40 is, well, 40. That’s right, 0x40 (64) is ‘@’ so, pressing Ctrl+Shift+2 (or just Ctrl+2) gets some sort of reaction. However, it does not seem to produce the expected effect, probably because nulls are string terminators for any software that uses ASCIIZ encoding (a very common method). (So Ctrl+2 is Null; that explains why it can sometimes be used as an abort chord similar to Ctrl+C or Break).

In practice (in at least XP’s command line), Ctrl+@ causes the prompt “More? ”, after which it passes whatever the user enters to the program as a parameter. For example the command echo ^@ followed by the the user entering testing would print out testing because the string was piped into the echo command. Another example: dir ^@ allows the user to select the file/directory to list (entering /s at the prompt would display all subdirectories). There does not seem to be a way to prevent the prompt from being displayed (not even by redirecting to nul).

No doubt, some creative and enterprising individual will be able to exploit this feature to enhance batch files.

Unexpected DIR Results for Numbered Files

If you have ever used the DIR command to list numbered files in a command prompt and been confused by the output, it may have been due to SFNs.

Here is an example to demonstrate the problem. In a directory with files with long names and numbered filenames, you might type dir *1.txt to list all files that end in a 1. However you may end up getting a bunch of files that do not end in a 1 mixed in with the results.

What happened? Remember that each file that has a long filename has a DOS compatible (8.3) SFN associated with it. These are usually six characters from the filename followed by a swung-dash and a numerical counter. In other words, “Long Filename.txt” would not only have that as it’s name, but also “LONGFI~1.TXT”. And there’s the 1!

If there are multiple LFN files (that are too long or have spaces) that begin with LONGFI—eg “Long File.txt”, “Long Fi.txt”, etc.—then they will be saved as LONGFI~2.txt, LONGFI~3.txt, and so on. Therefore you may get weird results for dir *2.txt, dir *8.txt, dir *516.txt

There does not seem to be a way around this, but using the /X switch can at least reveal the source of the unexpected results.

Windows Explorer File Sort

Windows Explorer allows you to sort the files and directories in a folder by various properties by clicking the appropriate column header. Folders always come before files regardless of name, and there is unfortunately no way to change this even though sometimes it is desirable to sort with mixed folders/files.

The algorithm for sorting by name is mostly straightforward but with some bumps. Knowing the sort order allows you to choose characters to use as the first character in a file or folder name to control sorting, for example when creating a filing system.

For the most part, the algorithm sorts files/folders by name according to their ASCII values, expect that case is ignored because on Windows, filenames are case-insensitive, that is “MYFILE”, “MyFile”, and “myfile” are all the same file—iirc NTFS can do case-sensitive but it’s actually a hack (mapping).

You should also be aware that numbers are treated as numbers and not strings. For example “123blah” will come after “2blah” since 123 is bigger than 2, even though “1”-“2”-“3” comes before “2”. This behavior can be changed with the NoStrCmpLogical option of the Explorer policies (set HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\NoStrCmpLogical to dword:00000001).

Another bump in the algorithm is that the following characters appear out of order: +, <, and > They come after all other characters, in this order. Also, and are ignored altogether when they are the first character.

Here is a list of characters in the order that they will be sorted when used as the first character:

1 – Not (normally) allowed as a filename character
2 – Not in ASCII order
3 – Not used in sort when first character
  (space)
!
1
#
$
%
&
(
)
* 1
,
.
/ 1
: 1
;
? 1
@
[
\ 1
]
^
_
`
{
| 1
}
~
+ 2
< 1,2
= 1
> 1,2
3
3
 

This knowledge will be used in a later article to create a filing system that will allow organization of files and folders since Windows doesn’t really have symbolic links and WinFS has been cancelled until at least Windows Vienna.