Maximizing the 32-bit 4GB RAM Limit

If you have a 32-bit system with 4GB installed, you can reduce the amount of RAM that gets wasted and make some more of it available by opening the BIOS configuration and reducing the AGP aperture setting to the minimum amount (e.g., 4MB).

Note: this may affect 3D graphics performance, so it is best for systems which don’t do 3D gaming or systems with video-cards that have a lot of video memory.


Personal anecdote… ▼

Hotplugging SATA Drives

The SATA specification allows for SATA drives to be hotpluggable.

This usually allows manufacturers to create external drives that can be hot-swapped (via USB) more easily than with IDE drives. However, this usually also works for internal drives.

If you have an internal SATA drive (hard-drive, DVD drive, etc.) which is not connected to the motherboard and boot up Windows, not surprisingly, it will not show up in the Device Manager. If you then connect the drive’s data cable to the motherboard (and perhaps optionally) do a re-scan in Device Manager, the drive will then show up because the SATA controller detected the drive and made it visible to Windows.

This is great. If you accidentally forget to connect a SATA drive to the system and don’t want to shut down or want to create your own sort of external drive, this feature is very helpful.

Unfortunately, like most things, the pros come with cons. In this case, while the newly connected drive becomes visible to Windows and is usable, it will likely have poor performance. Windows loads the drivers for the drive on boot, so if you connect the drive after booting, instead of loading the tuned, high-performance drivers for it, it will end up using simple, low-speed access to (i.e., it will not use UDMA). You can see this as extremely slow transfers to/from the drive. If you do this with a DVD burner for example, it will be limited to ~2x even if you set it burn at 8x or whatever). You can also see this effect in the Task Manager’s Performance tab; the CPU load will jump when you use the drive, but no processes will spike because the load is coming from the kernel. This may or may not also occur in Linux or Mac.

So while SATA allows hotplugging drives, it doesn’t mean it will work well. Manufacturers will still need to provide a shim to allow for maximum performance and OS developers will need to better detect newly attached SATA drives and load the drivers at runtime.

Limiting Login Attemps

One common way to reduce the likelihood of an account getting hacked is to limit the number of login attempts and lock the account once the number of failed logins reaches some threshold.

This is a reasonable way to prevent brute-force, and even most dictionary attacks. The problem is that most implementations count each and every login attempt. When someone forgets their password or types it in incorrectly, they usually try again a few times.

If you limit the number of attempts, it should detect if the passwords are the same (or possibly even similar) since they are obviously not an attack, but rather the user wondering why their password isn’t working (for example, they may be typing in the password for a different account).

Disable Logging in an Apache VirtualHost

VirtualHosts and logs are invaluable features of a web server. However, you may not always want to log things for every VirtualHost. If you simply comment out the logging commands of a VirtualHost, then transfers to and from the VH will be logged to the main (ie, parent) log file; commenting them does not disable logging for a VirtualHost.

If you want to disable logging for a VirtualHost, one option is to log to a file in a temporary directory that gets flushed regularly, but a better solution is instead to have it log to a non-existent file (nul in Windows, /dev/null in *nix/Mac), such as in the following—mixed example—commands:

<VirtualHost …>

ErrorLog nul
CustomLog "nul" common
CustomLog dev/nul referer
CustomLog "dev/nul" agent


Windows Installer Error 2203

After much testing, I have determined that the reason that I was experiencing problems installing drivers, software, or updates in Windows recently was because I had removed the user-level environment variables for TEMP and TMP even though they were still available via the system-level environment. Creating copies for the user environment fixed the problem (at least the installation problem, now there is the issue of redundant environment variables, but that’s not so bad).

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!

Laptop Screen Going Blank

I was helping another person in the Windows newsgroup who was complaining that their laptop’s screen goes blank after 30-60 minutes and they have to open and close the lid and press the power button to get it back. My advice:

It could be caused by overheating, dust, or maybe a loose connection. Try holding the laptop up, with the display’s screen facing the ground. Gently shake it a bit and see if the screen goes blank. If it does, then that’s your problem; it’s not a laptop, it’s an Etch-a-Sketch.

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.

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.

Rule of Thumb Can Do More Harm Than Good

I just read the following line in an article in a security focues issue of NetworkLife magazine about novice computer users and firewalls:

A good rule of thumb: “If an alert occurs when users are launching any kind of Internet action, such as connecting to their mail servers, downloading programs, connecting to a Web server, or updating software, then they should accept it”

And to be honest, that has been the general consensus on this matter for pretty much ever. Unfortunately, while it is quite logical, it is not a very good rule of thumb. What happens when a piece of software, say their anti-virus app, tries to check for an update while the user is typing a paper? An alert pops up telling them that a program is trying to connect, and they think “hmmm, I’m just typing a paper; I didn’t initiate anything, so I’m supposed to block it”. They click Deny Access. The next day it tries to check while they’re playing Solitaire, so they click Deny Access again. The day after, it happens while they were in the bathroom, so they get tired of this and just click Deny Access And Remember. Now their anti-virus is never updated again.

The opposite can occur as well. They open an email and see a message from someone they don’t know and click the attachment to see the greeting card. An alert pops up telling them that a program is trying to access the Internet. They think “hmmm, I’m viewing email and I just clicked a Web-card, so it’s safe to allow it”. Now they are infected with a trojan and their zombie computer will begin sending out infected spam.

Truly, the best rule of thumb is to just educate the users in even a rudimentary fashion. If you go to the trouble of installing a firewall on grandma’s computer and telling her a rule of thumb as the above, then you may as well just give her a better, crash course instead.