Re: [WiX-users] Re compiling WiX C++ libs for 64-bit

[Mike D. <mi...@di...>]

>>> Comments inline.

-----Original Message-----
From: wix...@li...
[mailto:wix...@li...] On Behalf Of Bob Arnson
Sent: 25 March 2008 15:21
To: Sanin
Cc: wix...@li...
Subject: Re: [WiX-users] Re compiling WiX C++ libs for 64-bit

> 2. If so, here is the problem:
>   - existing WiX C++ libraries (wcautil.lib and dutil.lib) are 32-bit.
>   

That will be changing soon. The file-system redirection API doesn't 
solve problems with the registry, so we're adding support for 64-bit 
custom action builds. That will probably appear in the next couple of weeks.

>>> You can access 64-bit registry keys from a 32-bit process by adding the
KEY_WOW64_64KEY flag to the samDesired parameter of RegCreateKeyEx or
RegOpenKeyEx. If required, you can delete a 64-bit key from 32-bit code by
calling RegDeleteKeyEx.

>>> I'm not sure if this is a better or worse option than having to
recompile for 64-bit, but I think it's less work than adding support for
picking either 32- or 64-bit versions of the WiX custom action DLLs. Would
light simply select the 'correct' version depending on the
Package/@Platform? That would probably give wrong results for 32-bit
components manipulated by the 64-bit version. Could you write the custom
action correctly to manipulate both 32- and 64-bit components from the same
deferred action, or would you need two custom actions? Does light schedule
two immediate actions if the same WiX scheduling action is required for two
different components, one 32-bit and one 64-bit? Are they going to work
correctly if they have a limited view of the overall process, with only
information about 32-bit components going to the 32-bit deferred action and
only 64-bit components to the 64-bit action? Do you even have an Itanium to
test on? <g>

>>> I think it's better to go with opening the right key for the component.

-- 
Mike Dimmick