Hi all,
I have a problem with the registry.
I have a game that writes into install=HKLM\SOFTWARE\makername\gamename.
The backup and restoring using PAL all works on Windows 32 bit, but on a 64 bit it goes into HKLM\SOFTWARE\Wow6432Node\makername\gamename.
The game can't find it: errors, nothing works anymore.
So I thought to use custom code to disable redirection with "SetRegView 64".
I don't know if it works, since I don't know how to do the backuping, importing and restoring in NSIS, like PAL does.
That's the problem and what I tried so far.
Any help please?
Thanks in advance.
[Escalated to a bug report as it's very important missing functionality which needs to go in PAL 3.0 - mod Chris]
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
Thanks for the update Chris!
Yes, I set the working directory!
Perhaps something like the following would work:
[RegistryKeys]
SomeKey1=HKCU\Software\SomeKey
SomeKey2=HKLM\Software\SomeKey2
[RegistryKeys:DisableWow6432Node]
SomeKey3=HKLM\Software\SomeKey3
The first case is how we do it now, the second is an example of how we could control things.
In a 64 Bit OS, SomeKey1 would not be redirected as HKCU typically isn't subject to redirection. SomeKey2 would be redirected.
SomeKey3 would have redirection disabled by the special section.
You would want to export all keys in 32 bit mode, as 64 bit mode would add Wow6432Node to the path in the file. You would import all keys in the first INI section using 32 bit mode, and use 64 bit mode to import the second entries.
What I mean by 32 bit mode is that if you have a reg file, and it goes to HKLM\SOFTWARE\AKey (no Wow6432Node in the file), if you import it with cmd.exe *32 (running under WOW64), it will be imported to HKLM\SOFTWARE\Wow6432Node\AKey. If you used the 64 bit CMD.exe, it would not be redirected.
What's the status on this?
I haven't heard anything about the development of PAL 3.0 for half a year. Is it possible for a mod to give a little bit more info?
Thanks in advance
Yes, I set the working directory!
I know Chris is quite busy. Aluisio may have more insight.
Side Note: This bug isn't affecting any potential releases, as a game would not be permitted to require admin rights.
Sometimes, the impossible can become possible, if you're awesome!
Thanks for the fast response, I'll wait for Aluisio's response
Yes, I set the working directory!
So it's 2014 now almost a year after I last asked about this bug.
As this is "very important missing functionality which needs to go in PAL 3.0", according to Chris, how is the status of PAL 3.0?
Is there still someone developing PAL 3.0?
Is the source code made publically available on, e.g. Github or Sourceforge? Users making pull requests should speed up the process quite a bit.
Yes, I set the working directory!
The source has always been available from SF and is linked directly from the PA.c Launcher page.
Chris is mostly busy with life and not working on PAL at present. Presently, no work is being done on PAL 3.0.
Until it is complete, you can manually use Custom Code to accomplish manual read/write/restore to the 64-bit HKLM and HKCU hives for 64-bit apps.
Sometimes, the impossible can become possible, if you're awesome!
For those following this bug, I'm currently implementing DisableRedirect variants of the RegistryKeys, RegistryValueBackupDelete, RegistryValueWrite and both RegistryCleanup sections.
A working method can be found here:
https://github.com/demondevin/portableapps.comlauncher
daemon.devin
NSIS is a 32bit executable..
if you want to read/write in x64 registry..
use Custom code..
takes only a few lines..
set in .OnInit
ie.
!include x64.nsh ${SegmentFile} ${Segment.OnInit} ${If} ${RunningX64} SetRegView 64 ${DisableX64FSRedirection} ${EndIf} !macroendif you want to use the launcher..
then use ReadINIStr or ${ReadLauncherConfig}
if you really don't want to use Custom Code
then you can edit the source to have your own custom Launcher sections..
so end-users don't have to deal with Custom code.
if you don't want to edit anything at all..
then redesign PAL with NSIS 3.0 x64 ..
it's been released.
I use PortableApps on my PC..
Tried that but it's not working. ${RunningX64} is true but SetRegView 64 seems to be ignored. Registry values still go to ...\Wow6432node\...
Google around for PortableApps sites and blogs..
there are tons of them..
download their sources and take a look ..
i have tons of x64 applications designed w/PAF..
I use PortableApps on my PC..
it's the code that you published that's not working.
anyway, already found another workaround.
what was the workaround?
can you show us?
I use PortableApps on my PC..
While PAL is currently using a modified version of NSIS 2 we will be switching it to NSIS 3 in the near future. As of the NSIS 3.02 release, NSIS now has support for HKCR32, HKCR64, HKCU32, HKCU64, HKLM32 and HKLM64 registry root keys and no longer supports SetRegView. We'll need to consider how we implement this going forward carefully and possibly adapt our handling of .reg files to match.
Sometimes, the impossible can become possible, if you're awesome!
I don't think our handling will necessarily be affected much. We'll need to do some heavy testing, to be sure, however it looks like SetRegView is still supported, what's unsupported (and rightly so) is attempting to use an incompatible registry view - i.e. SetRegView64 when on x86.
I've made changes for fixing the redirect problem, but am going to review our registry handling overall with the 3.02 changes in mind.
I was thinking we could have our registry handling bits do the appropriate 32 or 64 based on what kind of app mode we're running for any of the direct read/write commands. With .reg files, I think we'll need to look into whether we need to go to/from regular and wow32 depending on whether we're running the 32bit or 64bit version of the app for dual mode apps.
Sometimes, the impossible can become possible, if you're awesome!
Hi Gord. Actually this bug come from Registry plug-ins. Registry plug-ins didn't provide an approach to handle this problem. SetRegView will only affect the NSIS built-in instructions (DeleteRegKey, DeleteRegValue, EnumRegKey, EnumRegValue, ReadRegDWORD, ReadRegStr, WriteRegBin, WriteRegDWORD, WriteRegStr and WriteRegExpandStr). The latest version of Registry plug-ins (4.1) is release in 2011, and probably no new version will be released for this old stuff.
If SetRegView is to be used, then functions from Registry plug-ins had to be replaced by built-in registry instructions, and functions to Move/Copy registry keys/values needs to be rewritten.
Of course, finding other alternatives to replace the Registry plug-ins would be a better solution.