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).
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
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!
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%\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.
Macromedia Fontographer is one of the still few font editing applications there are. Unfortunately, it has barely been updated since the days of Windows 95; the focus has been on the Mac version, and even that has not been updated much.
Fontographer for Windows is a port of the Mac version and as such, it is less stable than native Windows programs, which is why it has not fared as well with newer hardware and operating systems. Running Fontographer on modern systems does not work well and can simply fail and exit the app or cause a catastrophic crash which can actually bring all of Windows down and require a hard reset.
There are two main problems with Fontographer on modern systems. The minor problem is that when the combined physical+virtual RAM exceeds 1.5GB, Fontographer complains that you do not have enough memory and quits. This is because it uses smaller pointers which overflow and look like there is a minuscule amount of RAM.
The solution to this problem (if practical) is to reduce the amount of virtual RAM so that the total memory is less than 1.5GB. Of course this won’t help if you have more than 1.5GB of physical RAM and you would have to actually pull some out for the one program. This problem has been around for a long time but there do not seem to be any plans to fix it. Another option is to add enough RAM to the system so that the wrapped available RAM meets Fontographer’s requirements (in other words, ACTUAL_RAM_SIZE mod RAM_POINTER_LIMIT_SIZE >= FONTOGRAPHER_MINIMUM_RAM); surely it can’t need too much (depending on the version, it needs 6-16 megabytes).
The other problem that can occur with Fontographer on modern systems is a complete crash. When run, Fontographer can completely freeze Windows in it’s tracks and require pressing the reset button on the case to bring the system back up. This is probably also caused by it’s memory allocation problems but may be caused by something else.
One thing to try with this that has had success is to run Fontographer in “compatibility mode”—this is available in Windows 2000 and up. Select the Fontographer executable (eg: “C:\Program Files\FOG41\FONTOG.EXE”) and bring up it’s properties dialog. Select the Compatibility tab and set it to run as Windows 95.
Fontographer should now work and allow you to create fonts in Windows.
It has become more and more popular to blame computer problems on bad RAM—poor RAM. While it’s certainly possible to have a RAM module with a problem, it’s not as common as people would have you believe. In the past few years with the release of various RAM testing apps, there has been a surge of comments to the effect of “test your memory”, “you’ve probably got bad RAM”, “you need to replace your RAM” in response to posts about computer problems. It is just so easy to blame the RAM since it’s one of the only things that can successfully explain intermittent or unexplainable problems. The snafu is that even when the RAM is at fault, it’s not necessarily because the RAM is bad, it could—and usually is—because the connection is bad.
There are three common ways that RAM can be the cause of a problem. The way that everyone is raving about is a defective RAM module, that is a problem in a RAM chip or circuitry. This would render it useless (for all intents and purposes) and require just chucking it and getting a new one. Another problem could be the contacts on the edge of the RAM module could be dirty or have a patina on them, which impedes contact with the socket. In this case, the RAM may or may not be detected and could work partially or not at all. Finally, the RAM socket itself could have a problem. It could be that the contacts are dirty or the pins/pads are bent. Fortunately the contact problems are more common and easily fixed.
If the contacts on the RAM module are dirty, then simply using a little water to dampen a small sponge can be used to clean them. There are fancy patina cleaners, but all you really need to do is to clean those little pins on the edge. Pretty much anything will do, even alcohol or solvents, as long as you don’t let them dissolve the metal, just clean them and wipe it off. The best solution of course is to use some good old soapy water and some toilet paper.
The RAM socket is a little more tricky. If the pins are dirty, an effective solution is to lightly wet a used toothbrush, and gently scrub the socket up and down with it. This will do a good job of cleaning it.
If the pins on the socket are bent, then it may not make proper contact with the RAM module and will be a problem. More often than not, you will have to abandon the socket or even the whole motherboard, but with a little dexterity and the right tools you can fix it. You will need a long, find-tipped object, like a dentist pick, or something. It must be long enough so that your hands don’t obstruct your view, and pointy enough so that you can work with the tiny pins. You will probably need two so that you can grasp them and bend them back. You will also need good lighting and perhaps a magnifying glass. Take a good look at the socket and locate the bent pin. Examine it carefully to determine exactly what the problem is and which way you need to bend it to fix it. Use the tools to carefully bend it back to match the others. Plug in the RAM and give it a test. Be aware however, that they are metal and can only be bent so many times before snapping.
In conclusion, don’t throw away your RAM just because someone told you that it’s the cause of a problem or because a testing app said there’s problem(s). Before heading to the store, clean the RAM edge and run it through the test app. If that doesn’t fix it, clean the socket. If that doesn’t fix it, check for bent pins. If that doesn’t fix it, then go to the store.
If you get the following message for FOLDERS.DBX when trying to “compact all folders” in Outlook Express
The folder is currently in use by Outlook Express or by another application.
there is a simple solution. The error message is deceptive since the actual cause has nothing to do with being in use. The problem occurs when you try to compact all folders and not all folders are actually present on disk. This can happen if a .DBX file got deleted somehow (for example if you decided to save some space by deleting the .DBX files of empty folders.) When OE tries to compact, it checks the folders.dbx file to see what .DBX files to expect, and when it can’t find one, it complains with the inaccurate message above.
The fix is simple, just replace or recreate the files. The easiest way to do this is to simply open the missing folders in OE because it will automatically create a .DBX file if one does not exist.
If you do not know which ones are missing, you can click on “Local Folders”, press the * key on the keypad to expand all branches, then click on each and every folder—you could also use the Down key instead of clicking, but then you have to wait a second on each folder for OE to open them, clicking opens them instantaneously.
After you’ve ensured that all .DBX files exist, you can successfully compact all folders.