VBScript to Determine 32-bit or 64-bit machine

Often we come across a situation where we need to see the Operating system bit information and then install application or do any customization. Here is a script which I use for this purpose:


'===============================================================

Const HKEY_LOCAL_MACHINE = &H80000002
'Lines to get the computer Name

Set wshShell = WScript.CreateObject( "WScript.Shell" )
strComputerName = wshShell.ExpandEnvironmentStrings( "%COMPUTERNAME%" )

 
'===============================================================
'To check whether the OS is 32 bit or 64 bit of Windows 7
'===============================================================

'Lines to detect whether the OS is 32 bit or 64 bit of Windows 7

Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputerName & "\root\default:StdRegProv")

  strKeyPath = "HARDWARE\DESCRIPTION\System\CentralProcessor\0"

  strValueName = "Identifier"

oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue
'===============================================================

'Checking Condition whether the build is 64bit or 32 bit

  if (instr(strValue,"64")) then

'Perform functions for 64-bit OS.
End If

if (instr(strValue,"x86")) then

'Perform functions for 32-bit OS
 End If
'===============================================================

Creating MSI for x64 and x86 machines

For some time now I have been packaging for x64 and x86 machines, and have faced numerous issues while creating the MSI for x64 machines. Well MSI will mostly work in x86 because of less complexity of 32 bit machine. There always seems to be a problem when you try to install the application in 64 bit environment.

Registry Structure:

The Registries install differently in 32 and 64 bit machines. in 64 bit machines, there is a provision to install 32 bit applications registry and this goes in SysWOW64 folder.
By default all 32 bit installers install the registry in SysWOW64 hive. If you need to install the registries in normal mode as in directly in the registry as it was in 32 bit machines, then you need to change the Component in your MSI to 64 bit component. This will ensure that your registries are to be installed as 64 bit and not 32 bit.
You might face issue in compiling your 32 bit application with a 64 bit component. I would suggest you to compile your Application with 32 bit component and change the component attribute with ORCA later on.

Folder Structure:

I would like to share the 2 basic folders which are different in 64-bit machines.
• Program Files: There are two folders for Program Files in 64 bit machines and they are Program Files and Program Files (x86). All applications which have 64 bit installer are installed in "Program Files" folder, whereas all 32 bit applications are by default installed in "Program Files (x86) folder.

• System folder: The System 32 folder also behaves in the similar manner as Program Files and in this for 64 bit installers, the files which are to be placed in System 32 are directed to "System32" Folder only. The 32 bit installers however place these file in "SysWOW64" Folder.

Now the question comes to package the applications in such a way that we get desired output. I will list down certain scenarios and how to handle them in packaging. I hope to cover most as in whatever issues I have faced and your feedback for more scenarios is most welcome.
a) Scenario: In a capture application, files are getting installed in SysWOW64/Program Files (x86) folder when you want the files to be placed in System32/Program Files folder.
Resolution: You need to check the Summary section in your WISE Package Studio. If your package is marked as Intel,1033 (or Intel,xxxx), then you need to change this to x64,1033 (or x64,xxxx).
By doing this you are changing the installer type from 32 bit to 64 bit. You cannot install this package now on 32 bit machines and you will have to create a separate installer for that. I have done a lot of research and this only seems to be the most viable option as of now.
Also you need to change your directory in WISE package Studio/MSI.
There are additions of new already defined folders in MSI for 64 bit support. These folders are explained below:
[ProgramFiles64Folder] will redirect files to “Program Files" folder and [ProgramFilesFolder] will redirect the files to "Program Files (x86)" folder in 64 bit machines.
[System64Folder] will redirect files to "C:\Windows\System32" folder and [SystemFolder] will redirect the files to "C:\Windows\SysWOW64" folder in 64 bit machines.
Choose accordingly in your package. If there is still some problems, you can try making the components to be 64-Bit and try again.

b) Scenario: There is a vendor MSI which is 32 bit and install files to "Program Files (x86)" Folder in x64 machine. But due to the functionality of the application, you would require it to install to "Program Files" folder.
Resolution: If you are thinking that you will change the Summary section in MST file from Intel,1033 to x64,1033 and it will work, well you are thinking in right direction, but it does not work. You will have to change the summary section in MSI directly through ORCA and then do rest of the customizations in MST.
WIN64DUALFOLDERS determines what happens to the path variables while installation of an MSI. Based on the application type as in 64 bit or 32 bit, the paths are determined.
If it is a 64 bit installer then you will see something like this in the log file:

WIN64DUALFOLDERS: Substitution in 'C:\Program Files (x86)\ABC\XYZ\' folder had been blocked by the 1 mask argument (the folder pair's iSwapAttrib member = 0).
This means that the file system redirection will not happen. All paths will be defined as desired.

For example:
ProgramFilesFolder will be C:\Program Files (x86)
ProgramFiles64Folder will be C:\Program Files
and so on...

The end result would be as expected.
The 64-bit msiexec.exe is used in the whole process.

If it is a 32 bit installer then you will see something like this in the log file:

WIN64DUALFOLDERS: 'C:\Program Files (x86)\' will substitute 17 characters in 'C:\Program Files\' folder path. (mask argument = 0, the folder pair's iSwapAttrib member = 0).

This means:
ProgramFilesFolder will be C:\Program Files (x86)
ProgramFiles64Folder will become C:\Program Files (x86)


I hope this will help you in Packaging your applications for 64 bit.

Windows 7 Language Pack Installation and Un-Installation on 32 bit and 64 bit Machines

Recently I had to package Window 7 MUI for around 13 languages, both for 32 bit and 64 bit machines. I could not get any complete documentation for Installing, Un-Installing and making it work with the Deployment tool.

I thought to write this article so it reduces the work of people who still have to make Language packs as a package.

Windows 7 Language Packs come in a DVD and generally have a cab file called, lp.cab for all the languages in their respective folders.

Following are the main command lines to be used while installing and Un-installing the Language Packs:



Installation:

dism /online /add-package /quiet /norestart /packagepath:lp.cab

and

Un-Installation:

dism /online /remove-package /quiet /norestart /packagepath:lp.cab



The lp.cab file can be copied to a temp location by your MSI and then a setup.bat file would be required to run the above command line.

I had copied lp.cab, setup.bat,setup.vbs, uninstall.bat and uninstall.vbs to “%windir%\temp\” folder.



Here are the uses of all these files and how they are related in MSI.



Lp.cab: This is the basic installer cab file of the language pack which you can get through the source or DVD
Setup.bat: This is the batch file to install the language pack as per the above command line.
Setup.vbs: This .vbs file locally calls the setup.bat file, as if you are deploying from Deployment tool/network location then the batch file throws an error as it cannot resolve the UNC paths.
Uninstall.bat: This is the batch file to un-install the language pack using the above mentioned command line.
Uninstall.vbs: This .vbs file locally calls the uninstall.bat file, as if you are deploying from Deployment tool/network location then the batch file throws an error as it cannot resolve the UNC paths. Also this when wrapped in MSI, you can un-install the package from Add/Remove Programs and the language pack can be un-installed.


After creating and adding these files to a temporary location, you can add 2 custom Actions, one for install and other for un-install to run the vbs files from installed filed.

The Installation Custom Action can be placed just before InstallFinalize with condition as NOT REMOVE, and the Un-Installation Custom Action can be placed just after InstallInitialize with condition as REMOVE.



Now since you have read this from Packaging perspective this goes well for both 32 bit and 64 bit machines. But if now you try to install this MSI from Deployment tool or any other deployment tool which uses system account to run, you will face an issue with the 64 bit machines.

The reason for not working in 64-bit machines is that when the MSI is run in system account all the scripts/batch file are run through cmd.exe which is in c:\windows\syswow64 folder. This does not work for dism command line and I had to use a workaround for this issue.

The work around is that you need to run the dism command from %windir%\Sysnative.

This works fine and I have inserted the below line in the batch file for both install and un-install before running the dism installation command:

cd %windir%\sysnative



So the batch file looks like:

Install:

@echo off

cd %windir%\sysnative

dism /online /add-package /quiet /norestart /packagepath:%windir%\temp\Microsoft_Win7MUI_Arabicx64 \lp.cab



Uninstall:

@echo off

cd %windir%\sysnative

dism /online /remove-package /quiet /norestart /packagepath:%windir%\temp\Microsoft_Win7MUI_Arabicx64 \lp.cab





I hope all this information will be helpful for you to create the language packs. It took me a week to figure these things out. Hope you will not face this difficulty.

Context Menu Creation for gVIM application in x64 machine

I was stuck in an application where I had to use the 32 bit source for both 32 and 64 bit machines. The application seemed to work fine, except the context menu option in x64 machines.

I found a great post by David Vielmetter on his blog http://davidvielmetter.com/tricks/context-menu-issues-with-gvim-in-windows-7-x64/ and I was able to solve the issue. I think context menu many times create an issue in 64 bit machines and this is a good way to solve them (This is entirely my point of view). If someone has some better suggestions, they are most welcome to comment here. I too would like to learn more on how to create 64 bit context menu options.

Context Menu for WinMerge appliction in x64

WinMerge application has the same source for x86 and x64 machines.
The application works fine when packaged in MSI for x86, but the same application will not work on x64 as the context menu option will not be visible. To get the context menu option, follow these steps:
1) Install the source on 64 bit machine and from INSTALLDIR, copy the ShellExtensionx64.dll file.
2) Register this Dll file and keep its registry information in a reg file.
3) The 32 bit version of this ShellExtension is ShellExtensionU.dll, hence make the component of this .dll conditionalized to be installed only on 32 bit machines. For this you can write the Condition as: (VersionNT32)
4) Create a 64 bit component and import ShellExtensionx64.dll and its registry in it. The condition to make this component install only in 64 bit machines is: (VersionNT64)
5) Also keep in mind to launch the application before taking a second snapshot of the application. This will include some HKCU registry keys which go in HKCU\Software\Thingamahoochie\WinMerge
This is important as a registry is created in this hive, ContextMenuEnabled=1, which enables the context menu in the application.