64-bit windows has program-running issues

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install a shotfactory on a 64bit version of Windows 7.
2. Try to use a normal firefox browser.
3. Try to configure IE for a shotfactory and then use it.
4. Try to request more than one IE screen shot.

What is the expected output? What do you see instead?
I expected things to work normally, but I ran into several issues:

I configured a firefox browser, but it wouldn't run due to the executable being 
installed under the "Program Files (x86)" dir and the firefox script only 
looking under "Program Files" (via "progra~1").

When configuring IE, I would start IE in the normal (GUI) manner, register it, 
and it would fail to request a screenshot due to the User Agent string not 
matching.  This is because the GUI buttons run the 32-bit version, but msie.py 
was running the 64-bit version.

If I fix the User Agent string to match the 64-bit version of IE, the browser 
is not killed at the end of the run.  This causes problems with future runs 
because this browser window would stay on top, making all future screen shots 
duplicates of the first (lingering) window.

What version of the product are you using? On what operating system?
Latest svn version.

Please provide any additional information below.

To fix these issues, I decided to add some path checking where the program 
would run the 32-bit version by default, even on 64bit Windows.  The scripts 
first check for a version under "c:\progra~2\" (this is the "Program Files 
(x86)" dir), and if not found, falls back to the normal "c:\progra~1\" version. 
 This makes the default browser path work for all browsers whether they are 
installed under the x86 dir or not.  It also works around the browser-closing 
issue (since the 32-bit version of IE closes properly) and it fixes the 
registration issue (since the version the script is running matches the version 
that the GUI runs).

Instead of adding a bunch of duplicate code into each browser subclass, I 
changed the parent class to have a better start_browser() routine and made it 
use several new subclassable routines.  Then, I removed the start_browser() 
routine from each subclass and inserted just the needed member functions into 
the classes to customize the browser-starting.  Most classes just need the new 
get_browser_path_suffix() routine (which returns the default path string 
relative to the program-files dir).  For chrome, it gets a custom 
get_browser_cmd() routine (that skips the default program-files search) and 
also a custom wait_for_browser() routine (that lets it call its maximize() 
function).  For msie, it still has its custom registry error check.

Original issue reported on code.google.com by 4WayneD on 14 Aug 2010 at 5:57

Attachments:

• windows-64bit.patch

[GoogleCodeExporter]

Note that the get_browser_cmd(self) routine in chrome.py should end with a 
return, not an assignment.  Change the "command =" part on the last line to a 
"return".  It will then look like this:

    return appdata + r'\Google\Chrome\Application\chrome.exe'

I missed that when I was editing the chrome routines.

Original comment by 4WayneD on 16 Aug 2010 at 7:50