The GW Micro blog has been discontinued. For instant updates on GW Micro products and events, follow us on Twitter, and like us on Facebook.
Happy New Year. Now, Don't Try This at Home
by Aaron Smith on Tuesday, January 8 2008Let me first offer an obligatory Happy New Year to all. I know you hear this kind of dribble from most companies in early January, but I do feel that this year is going to be great for us. There are a lot of cool things in store for GW Micro customers in many different areas.
But now on to something that doesn't have anything to do with any of that. Every so now and then, I'm asked how you can switch between versions of Window-Eyes, mainly for testing purposes. Back in ye olden days, under Windows 9X, all you had to do was close Window-Eyes, copy over the main Window-Eyes application files, and then re-start Window-Eyes. But those days are long gone, which is preferable even if we do have to do things a bit more complicated now.
The biggest difference with newer operating systems is that Window-Eyes uses integral system components that stay loaded even when Window-Eyes is closed. I'm referring to the Window-Eyes Display Driver, and if Load Before Startup is enabled, the Window-Eyes Service. That's just under Windows 2000 and XP. Under Windows Vista, there is at least one other process that's always running to ensure that Window-Eyes can properly communicate with Vista's new security model (there's no official name -- it's just called weproxea [wee-prox-ee-uh]).
So how does one go about switching between versions? Well, I'll tell you how I do it. But before I do, you must understand that we don't support doing this. The ideal way to switch versions, even if it involves unwanted hoops, is to uninstall the current version, install the wanted version, test, uninstall the wanted version, and then re-install the current version. If you ever contact support with problems, and have used this or any other quick-switch method of moving between versions of Window-Eyes, you're likely to get scoffed at, and asked to come back once you've uninstalled and re-installed.
With that out of the way, I have a batch file that I often use to switch between release builds and custom builds to test regressions, newest features, bug fixes, and what-not. I'll list each section of the file, discussing it as I go. I call the file updatewe.cmd:
@echo off
This line simply suppresses the verboseness of the commands for the sake of simplicity.
REM Set up Variables
SET shareName=s:
SET newWeFiles=%shareName%\aaron\we
SET newWeSystemFiles=%shareName%\aaron\we\system32
As the remark line suggests, this section sets up several variables that are used later on.
REM Set up share
IF NOT EXIST %%shareName%% (NET USE %shareName% \\server\share /user:username password)
I keep all of my files on a network share, because I find myself moving from machine to machine and operating system to operating system. Keeping my files in one location makes accessing them much easier. But, in order to copy the files from my network share, I have to make sure it exists first, which is what the previous line does (minus the for-my-eyes-only information like username and password). The ironic thing is that I keep this batch file on that network drive, so if it doesn't exist when I run it, things have gone quantum-ly wrong.
REM Kill running processes
TASKKILL /F /IM weproxea.exe
TASKKILL /F /IM weserv.exe
The section kills any of the processes that might be running so that the files involved can be copied with success. As mentioned previously, weproxya only runs under Vista, so that line will throw errors under XP. The weserv line will have the same kind of result if the Window-Eyes service isn't running. But these aren't critical errors, so the batch file will continue. The /F parameter kills processes forcefully, and the /IM parameter specifies the name of the process to terminate
REM Copy in new files
XCOPY /Y "%newWeFiles%\*" "%wineyes%"
Assuming that we have the share set up, and the processes killed, now it's time to copy some files. The /Y parameter suppresses any overwrite prompts, which is good since we're overwriting files, and don't want to be prompted about every single one.
REM Change to the system drive
%SystemDrive%
Now that the files are copied, we'll switch over to the system drive to prepare system files for copying.
REM Change to the System32 dir
CD %SystemRoot%\System32
Now that we're on the system drive, it's time to get into the System32 directory, where the Window-Eyes system files are stored.
REM Delete any old backups
DEL /F %SystemRoot%\System32\gwm*
If this batch file has been run before, then there are old copies lying around. This just cleans those up. The /F parameters forces the removal of read-only files.
REM Rename current system files
REN gwm* gwmold*
The only way to copy in system files that are in use is to rename them first, then copy over the new files.
REM Copy in new system files
XCOPY /Y %newWeSystemFiles% %SystemRoot%\System32
This copies the system files, which should be successful since we previously renamed the current ones. We're using the /Y again to supress overwrite prompts.
REM If there was an x on the command line, restart
IF %1%==x SHUTDOWN -f -r -t 0
Finally, if I run the batch file with an x on the command line (the %1% means the first argument supplied on the command line), the machine will automatically reboot by running the shutdown command with a -f (force running processes to close), a -r (specifies a reboot), and a -t 0 (do it all in 0 seconds -- i.e. right now).
There are a couple of gotchas that I have to remember before running this batch file. The first, and most obvious, is that Window-Eyes must be closed. It's hard to copy files that are in use. The second thing is that I have to make sure I get all the files copied successfully, otherwise, Window-Eyes will be in a weird state, and I'll have to take time to figure out why. That goes without saying, but it's tripped me up before, and I've ended up doing the whole uninstall/re-install thing because it was faster than trying to figure out what got all screwed up.
There are other issues to keep in mind as well. For example, it's possible that registry entries and such changed between versions, and copying files may not be enough. This is one of the many reasons why this method of switching versions isn't supported.
And that's about it. This particular batch file copies in the newest stuff. I have another one that references other directories to copy in older stuff. One of these days I'll combine the two into one, and specify the version I want to copy on the command line. I should also mention that this isn't the only way to get the job done, nor is it necessairly the best way. This is a quick, brute-force method that does what I need it to do, but there's not much finesse to it. I would say that I'll post an updated entry when I update my batch file, but given my track record of doing what I say I'll do throughout past blog entries, I wouldn't count on it.
As the title of this blog entry suggests, we're not responsible for your system getting all screwed up by doing something like this. If you decide to attempt a batch file like method of switching between versions, you are on your own. In other words, don't do it, and good luck when you do.
