noisehole
16th November 2007 11:20 UTC

windows 2000
hi,

i noticed some issue with nsis 2.29 and windows 2000:

- registry access like DeleteRegValue fails
- $PROGRAMFILES(64) does not point to the localized "Program Files" folder, its always "c:\Program Files"
- prolly all reg functions are affected, these above mentioned issues are definitely broken on my good old w2k test box

i guess that the KEY_WOW64_32KEY / KEY_WOW64_64KEY api flag is breaking the registry access. i learned the hard way in my own software: if you pass either of these flags to RegOpenKeyEx on a w2k os, you will get an error and wont get access at all. the msdn page states that this flag is unsupported on w2k.

i didnt dare to update to >=2.30 because of the modern ui beta. i dont have the time right now to dig into the source, so maybe my assumptions are wrong or this issue is resolved by now. sorry for the noise if thats the case. if it isnt: how do i solve this?

regards

edit: so i assume this has been introduced with SetRegView, but commenting that command out does not help

kichik
16th November 2007 12:25 UTC

KEY_WOW64_32KEY and KEY_WOW64_64KEY are never used when SetRegView is set to 32. KEY_WOW64_64KEY is used only when SetRegView is set to 64. The same goes to $PROGRAMFILES and $PROGRAMFILES64 which aren't affected by SetRegView.

On top of that, DeleteRegValue, $PROGRAMFILES and other registry functions all work perfectly fine for me on 2000. The problem must be elsewhere.

The MUI beta is a beta of MUI2. The good old Modern UI is not affected.

noisehole
19th November 2007 12:12 UTC

sorry for jumping to conclusions, i did some further testing to analyse my problem. turns out i expected some other behavior (or/and didnt read the documentation carefully enough ;) )

setregview 64: if using this and running the installer on a 32bit windows, it will break registry access. "!insertmacro MUI_LANGDLL_DISPLAY" wont read/save, my uninstall function is unable to remove regentries etc, etc..

$PROGRAMFILES64: same situation on 32bit windows. it isnt set at all, its hardcoded "c:\program files", no matter where the real $PROGRAMFILES (manually changed or localized) is.

now these arent really bugs, as i said i just excpected other behaviour. i package 32 and 64bit software in distinct installers with the same nsis script. i use "setregview 64" as the first cmd in (un).onInit and $PROGRAMFILES64 instead of $PROGRAMFILES. this way i hoped to not have to worry about what the user is actually running.
to fix it, i will only use it after checking for a 64bit os, no problem. but wouldnt it be convenient if it was as i am describing? with the current behavior, is there any advantage for nsis users (cant think of any right now)?

regards

kichik
19th November 2007 19:31 UTC

This way, the common case of installing executables into the Program Files will cause 32-bit executables to be installed into "C:\Program Files" on x64 instead of "C:\Program Files (x86)". I prefer having the user explicitly require installation as 32-bit or 64-bit.