[Guide] Installing & uninstalling with x64

Discuss & post Update Pack addons here.
Post Reply
User avatar
code65536
Posts: 735
Joined: Wed Mar 14, 2007 2:58 pm
Location: .us
Contact:

[Guide] Installing & uninstalling with x64

Post by code65536 » Sun Oct 12, 2008 9:41 pm

I was recently asked via PM about installs/uninstalls on x64. I have since learned some new things about Wow64, so I'm updating my response, and I thought that I might as well do so publicly in case anyone else has the same question.

Introduction

* With Win32, 32-bit stuff goes into system32 and Program Files and 32-bit registry entries are written normally.
* With Win64, 64-bit stuff goes into system32 and Program Files and 64-bit registry entries are written normally.
* With Win64, 32-bit stuff goes into syswow64 and Program Files (x86) and 32-bit registry entries are written to Wow6432Node.

Automatic Translation

If you are reading/writing to the file system or to the registry with a 32-bit process, the Wow64 translation layer will be at work. What does this mean?
* All attempts to read from / write to Program Files will get redirected to Program Files (x86).
* All attempts to read from / write to system32 will get redirected to syswow64
* All attempts to read from / write to applicable registry keys will get redirected or reflected to Wow6432Node
* When you write a REG_EXPAND_SZ to the registry containing the string "%ProgramFiles%", it will get translated to "%ProgramFiles(x86)%" (according to Microsoft's documentation, this works only for REG_EXPAND_SZ and if you use the % version)

What this also means is that if you are installing a 32-bit application using a 32-bit installer, you don't have to worry about whether or not you need to use system32 or syswow64, since the Wow64 translation layer will take care of everything for you. But if you use a 64-bit installer process to install a 32-bit app, then you're going to have to handle all those file system and registry redirections yourself, and that's not fun!

Quick Overview

So let's say that you are making an INF to do your install:

* 32-bit app installing to 32-bit system using a 32-bit installer: Normal INF (system32, Program Files, etc.)
* 32-bit app installing to 64-bit system using a 32-bit installer: Normal INF (system32, Program Files, etc.)
* 32-bit app installing to 64-bit system using a 64-bit installer: Special INF (syswow64, PF (x86), etc.)
* 64-bit app installing to 64-bit system using a 64-bit installer: Normal INF (system32, Program Files, etc.)
* 64-bit app installing to 64-bit system using a 32-bit installer: You can't do this without taking some special steps

The above doesn't just apply to INFs, but to any mechanism of installation, like batch files. Clearly, there is an advantage to using a 32-bit process to install a 32-bit application, and a 64-bit process to install a 64-bit application. That way, you can use the same installation INF/script/etc. for all three cases (32-on-32, 32-on-64, 64-on-64). My DirectX installers, for example, use the exact same INF for both the 32-bit and 64-bit installers, and the INF works for all three installation cases. It makes life a lot easier!

32-bit and 64-bit Processes

Okay, so now that we know that we want a 32-bit process to install 32-bit stuff and a 64-bit process to install 64-bit stuff, how can we make sure that the installer has the right bitness? Well, if you are compiling your own installer, that's easy (if you are compiling your own x64 installer, why are you even reading this?).

But in many cases, people use scripts, like INFs and batch files. How do we determine the bitness of that? Well, if a batch file is processed by the 32-bit version of cmd.exe, then it'll be a 32-bit process, otherwise, it'll be a 64-bit process. For INFs, it will depend on which setupapi.dll (or advpack.dll) that you get, and that, in turn, depends on whether you get the 32-bit rundll32.exe or the 64-bit rundll32.exe. For the registry, it will depend on whether you are running the 32-bit version of reg.exe (or regedit.exe) or if you are running the 64-bit version. See the pattern?

If you are launching cmd.exe (which is what you are doing every time you run a batch file), rundll32.exe, reg.exe, regedit.exe, or any other system executable from a 64-bit parent process, you will, by default, get the 64-bit versions of those unless you explicitly specify otherwise. If you are launching a system executable from a 32-bit process, you will ONLY get the 32-bit process (unless the parent process makes a special API call to disable the Wow64 file system redirection).

AFAIK, Windows setup for 2K3x64 and XPx64 is a 64-bit process (my experience with Win64 is limited to Vista, so I am not 100% sure). Anything done in Windows setup is, by default, a 64-bit process. Unless you kick into 32-bit mode by explicitly calling the syswow64 version of cmd.exe or rundll32.exe to start a 32-bit process (and any descendant system-executable processes that they launch will also be 32-bit). 7z and WinRAR sfx stubs are 32-bit, so they will always launch the 32-bit version of rundll32, cmd, etc. You can get around this by creating your own launcher of the correct bitness that the sfx stub can call.

I personally prefer to launch INFs from switchless installers (launch the INF straight from the sfx stub for a 32-bit install, or call up the 64-bit version of runinf for a 64-bit install) so that I have perfect control over the bitness of the installing process.

Uninstallation

If the uninstallation registry entry is in the "normal" registry, then Windows will launch your installer normally; if the registry entry is under Wow6432Node, then Windows will launch the installer under a Wow64-translated state. So if you are calling rundll32.exe in your uninstall, you'll get the 64-bit version in the former case and the 32-bit version in the latter case. This helps ensure that if you are using a batch file or INF to uninstall, you'll get the correct bitness for the uninstallation.

Do I need both 32-bit and 64-bit versions?

For some things (generally, DLLs such as runtimes or shell extensions), you should install both the 32-bit and 64-bit versions. For example, if you play a 32-bit game on Windows x64, that game is going to use the 32-bit DirectX runtimes (a 32-bit process cannot use 64-bit DLLs and vice-versa), while a 64-bit game will use the 64-bit DLLs, so you need *both* sets of DLLs to be installed.

The same goes for shell extensions, as Microsoft ships with both 32-bit and 64-bit versions of the shell. Windows Explorer will be a 64-bit shell (the user also has the option of running the 32-bit Explorer if they wanted). The Open File dialog of a 64-bit process will be a 64-bit shell. But the Open File dialog of a 32-bit process will be a 32-bit shell. So if you only install the 64-bit version of a shell extension, that extension won't be available if the user manually runs the 32-bit Explorer or if the user is trying to use the shell extension in the Open File dialog of a 32-bit process.

So you need to carefully consider what you are installing--in some cases, the correct course of action is to install both the 32-bit and 64-bit versions of a particular product (keep in mind that virtually all system libraries and utilities are installed in both 32-bit and 64-bit flavors in Windows x64--there is a reason for that!)
Last edited by code65536 on Wed Jan 14, 2009 8:41 am, edited 5 times in total.
My addons: CmdOpen - HashCheck - Notepad2 - MS Runtimes - DirectX

Into the breach, meatbags!

yumeyao
Moderator
Posts: 1718
Joined: Sun Aug 27, 2006 9:24 pm
Location: Taiyuan, Shanxi, PR China

Post by yumeyao » Sun Oct 12, 2008 11:28 pm

thank you for such a detailed description. you're grately appreciated.
Image
My work list(Hosted by dumpydooby)

User avatar
5eraph
Site Admin
Posts: 4621
Joined: Tue Jul 05, 2005 9:38 pm
Location: Riverview, MI USA

Post by 5eraph » Mon Oct 13, 2008 9:31 am

Tutorial added. :)

Thanks, code65536.

User avatar
ENU_user
Posts: 1253
Joined: Wed Jan 25, 2006 1:42 pm

Post by ENU_user » Tue Oct 14, 2008 1:06 pm

to reduce some limitations where one needs to run programs that use outdated commands that in some cases are interfacing through the parallel port kernel mode (on win98 and dos there wasn't a limitation to interface applications using anything through the Driver level in opposition to newer and more protected windows systems since win NT \ xp

so. ., without the need to special mode some programs .. the original Inpout32.dll was build for that purpose to continue and allow certain programmers commands to work like with earlier windows systems ..

the wow'd64bit vista system file Inpoutx64.dll is offered to continue and support the same thing but I gathered it may get useful to use this for other purposes, more info and abouts here

Post Reply