Hi guys,

Since I did most of the beta testing for mritter´s "64bit compatability code" in WPI 7.1 I am going to tell you all I know about how you can make use of it and what you need to know in order to successfully install a variety of applications (32&64bit) on a 64bit system and make registry changes etc.

Introduction:

Windows 64bit (Vista, XP or Server) comes with two sets of dlls and programs for most of the onboard functionality: the 64bit code and the same thing again as 32bit code. The 64bit code will be in the same place where the 32bit code resides on a 32bit system : The %windir%\system32 folder, the %Programfiles% folder or in the registry, the "HKLM\Software" tree for instance.

The 32bit code otoh will be in different folders: %windir%\SysWoW64, %Programfiles(x86)% and in the "HKLM\Software\Wow6432Node" tree.

If you are thinking, alright, that´s easy, just start the "%windir%\system32\cmd.exe" on a 64bit system if you want to start the 64bit cmd.exe then this will work if you double click on it in Windows Explorer but for some strange reason, this may not work from within another application, script or WPI for that matter.

The reason for this is redirection. Windows will usually redirect your call to the 32bit programs automatically if you start the call from a 32bit program. Lets say you want to start a script from WPI that adds the serial number of a 64bit application to the registry:

First, you start the installer of the 64bit application. It will install fine but it will expect its registry settings in the HKLM\Software tree in the registry. Now, next thing you do is call the "regedit /S reg.reg" code from WPI or a cmd script. What usually happens is, Windows will see that you started the script from a 32bit application (WPI) since even on 64bit Windows, wpi files are by default associated with the 32bit mshta.exe in the SySWow64 folder.

So instead of going to the HKLM\Software tree, your registry code will get redirected to the "HKLM\Software\Wow6432Node" tree. Of course, your application does not expect its code at this place and won´t be registered.

So what you have to do is make sure that on a 64bit system, WPI is started with the 64bit mshta.exe otherwise you will not be able to start any 64bit process on the system (without turning off redirection and to my knowledge that is not possible for simple scripts) and folder and registry redirection will then occur.

In addition, from version 7.1 on, you can now specify in WPI what cmd.exe or regedit.exe to use for your scripts. If you activate the "64bit processing" switch for any application, this will tell WPI you wish to use the 64bit cmd and regedit.exe in the "%windir%\system32" folder. If this switch is not activated for an application, WPI will use the "%windir%\SysWoW64" folder path to access cmd.exe and regedit.exe which means you always get the 32bit versions of those programs even on a 64 bit system and even if the 64bit mshta.exe is being used.

The latter is necessary if you wish to install a 32bit program and want registry code to go where the 32bit application excepts it on a 64bit system, in the "HKLM\Software\Wow6432Node".

Conclusion:


So what do you need to know if you are installing a mixture of 64bit/32bit applications on a 64bit system while pertaining compatability with 32bit Windows versions:

1. Make sure to start WPI the following way in all cases (32bit and 64bit windows):



That way you will make sure that on a 64bit Windows, the 64bit mshta.exe will be used, which as stated above is a necessity for the "64bit processing" option in WPI to work. On a 32bit OS, this will always work also, so no harm done.

If you wish, you could also associate wpi files with the 64bit mshta.exe prior to starting WPI. You could do that using the ftype command like this for instance:



However, this would change the association system wide and you may not want to do that. (I don´t).

2. If you are using any other way of starting WPI, make sure to start it from a 64bit process. (or have a way to turn of redirection -> if you are a C programmer you can, I think).

For instance, if you are starting WPI from a an application compiled from a script (like with bat2exe etc.) you will almost always get a 32bit exe. If you start WPI from that exe you will never be able to access the 64bit paths/registry trees from any script started in WPI.

3. If you are installing a 32bit application in WPI, you do not have to activate the "64bit processing" switch for that application. If activated, the 32bit application will still install fine, however if you then add scripts or registry edits afterwards to add settings/registration info etc. the 64bit cmd/regedit.exe will be used and the code will most likely end up somewhere where the 32bit application won´t find it :-)

4. If you are installing a 64bit application you should activate the "64bit processing" switch for that application. It will also work when that switch is not enabled but only the program itself will then install fine. Any registry edit etc. will not be at the right place afterwards, as written in detail above.

That´s more or less it. It may seem a bit overwhelming at first but once you are getting used to it, it is not much of a deal.

Hope the above helps!

Bye,
Alex

Some Addons:


In case you need some way of 64/32bit checks in your own scripts here are a bunch of codelines I am using. That way you can easily adapt your scripts (only cmd, no vbs or powershell yet) to a mixed 32/64bit environment:


This will check for the OS version (64/32bit) installed:



The first line of code does not suffice because the 32bit cmd.exe will not report "AMD64" on a 64bit system. So if you happen to start that script on the 32bit cmd.exe or if your call gets redirected because you started it from a 32bit program, you want to make sure that you get the right answer. Therefore, on a 64bit system, always check for the outcome of a script in both the 64bit and the 32bit cmd.exe.


This will set a variable called %PROGRAMS% depending on the installed bitlevel OS. This will point to the "C:\Program Files" folder on each OS:




The code below will do the same but point to the "C:\Program Files(x86)" folder on each OS (if applicable):




You could do the same thing for the Common Programe files folder. This one is the folder where the 32bit programs go on a 32bit/64bit system:




And if you need to prevent some 32bit program from starting up on bootup you may need this:




Feel free to add some of your own :-)

Bye,
Alex

Thank you man. I just started WPI with the line you started first until today. But that would cause the installer.hta to be started with the 32 bit mshta.exe. If I now associate .htafiles with the 64 bit mshta.exe RegEdits do not longer get integrated correctly. I sent it to Mark, we have to change line 556 in installer.js from
to because that is the name of the .exe file for me in Vista x64. The x64 regedit.exe is in %windir% for me.

In your posted code for associating htafiles with 64 bit mshta.exe, shouldn't "%%1" be "%1" ? (Does not work for me otherwise)

Hi Dynaletik,

mhh, strange, regedits for me work fine with the release 7.1 version but I do not associate htafiles with the 64bit mshta.exe anymore, just tried that as a test.


Not in a script because the first "%" would get expanded, no ? Of course if you add that line directly into a cmd.exe you would only need one "%". But maybe I am mistaken on that one ?

Bye,
Alex

Oh yes. You are right. Just tried directly. If you insert it into a batch file, it works like you posted, sorry.
For me, regedits only work, if installer.hta gets opened with 32 bit mshta.exe. But if you do not associate htafiles with 64 bit .exe it will get opened with 32 bit .exe by default, as WPI executes it. (Even if you start WPI.hta with 64 bit mshta.exe).
If I change the line like mentioned above, it works in 32 and 64 bit mode for me.
EDIT: Just reinstalled Vista using the new WPI 7.1. Everything works fine now, I changed installer.js like mentioned and checked 64 bit processing for all entries. I called WPI with an .cmd file that got executed via AutoUnattend.xml: