Mike Dimmick wrote: > 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. >
The issue isn't Reg*Ex, it's GetNamedSecurityInfo in the SecureObject CA. SE_REGISTRY_WOW64_32KEY isn't sufficient. > 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> > Per-component, one immediate CA can schedule different deferred/rollback CAs based on component bitness and the package platform (to differentiate between x64 and IA64). And no IA64 warming up my office but they're around.<g> -- sig://boB http://joyofsetup.com/ ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
