You are here

${registry::RestoreKey} ?

6 posts / 0 new
Last post
Mark Sikkema
Offline
Last seen: 10 years 9 months ago
Developer
Joined: 2009-07-20 14:55
${registry::RestoreKey} ?

In addition to the Unicode plug-in test TAKE 2,
I found out that ${registry::RestoreKey} is not waiting to return till the process of restoring the key is finished. Which has the potential to give random results when a .reg file to be restored is a fair size and/or additional registry handling is being done straight after restoring the .reg file(this is what PAL will do if there is more then one key to back-up/delete)!

Here is a copy of the ${registry::RestoreKey} source in C.
As you can see in the source, all it does is executing regedit.exe.
So I'm proposing to change this routine into NSIS script ?

There are a couple of ways to go about this, but I want to keep in mind what JTH wrote about using the nsexec plug-in, a while back !

After some testing I came up with the following, to mimic the C script:

  1. ExecDos plug-in:

    SearchPath $9 "regedit.exe"
    ExecDos::exec `"$9" /s "$DataDirectory\settings\$0.reg"`
    Pop $R9
    ${If} $R9  0
    ...
    
  2. ProcFunc.nsh :
    SearchPath $9 "regedit.exe"
    ${Execute} `"$9" /s "$DataDirectory\settings\$0.reg"` `` $R9
    ${ProcessWaitClose} "$R9" "-1" $8 
    ${If} $R9 = 0
    ...
    
  3. ExecWait :
    SearchPath $9 "regedit.exe"
    ExecWait `"$9" /s "$EXEDIR\testHKLM.reg"` $R9
    ${If} $R9  0
    ...
    

1. Is the most simple solution, but I'm not sure if JTH agrees with ExecDos instead of nsexec plug-in ?
2. Is basically doing the same as the C script(CreateProcess()), but waiting for the process to finish
3. This option seems even simpler then 1, see below about return values !

Optionally I could include ProcessWaitClose into the C script, here is a small script what could do it in C

Return values for the different routines:

All routines return success even if trying to restore HKLM in a guest account !

The error-flag will be set by 'SearchPath' if the file cannot be found.
However, this will be undone straight after using ExecDos/nsexec or ${Execute}.
The error flag won't be set if the restoring is unsuccessful, for any of the proposed routines !

nsExec::Exec reg.exe return values:
0 = success
1 = .reg file not found
error = reg.exe not found

nsExec::Exec regedit.exe return values:
0 = success (even if .reg file is not found)
error = regedit.exe not found

ExecDos::exec reg.exe return values:
0 = success
1 = .reg file not found
-14 = reg.exe not found

ExecDos::exec regedit.exe return values:
0 = success (even if .reg file is not found)
-14 = regedit.exe not found

ProcFunc.nsh, ${Execute}  regedit.exe return values:
0 = regedit.exe not found / failed to create process
PID = process ID is returned / success (even if .reg file is not found)
${ProcessWaitClose} returns valus (probably not usable):
-1 = operation timed out
0 = process does not exist
PID = process ID of ended process (is identicle to the PID supplied to ${ProcessWaitClose})

ExecWait regedit.exe return values:
0 = success (even if .reg file is not found), error flag is untouched !
 = unsuccessful, string is untouched & error flag is set

ExecWait reg.exe return values:
This doesn't seem to be an option cause there is no switch to set it to SILENT !
John T. Haller
John T. Haller's picture
Offline
Last seen: 2 hours 25 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
ProcFunc

I'm unfamiliar with ProFunc myself. I have used ExecDOS in place of nsexec successfully in several launchers like Notepad++.

Sometimes, the impossible can become possible, if you're awesome!

Mark Sikkema
Offline
Last seen: 10 years 9 months ago
Developer
Joined: 2009-07-20 14:55
And

And PortableApps.comInstaller.exe is using ExecDos multiple times !

At least using ExecDos a launcher would wait till the process of restoring the key is finished.
And it does give a return value, but this value only seems to indicate if regedit.exe got executed or not. It doesn't indicate if regedit.exe was successful in restoring the key. (I should do some more testing on that in a guest account)

Formerly Gringoloco
Windows XP Pro sp3 x32

Mark Sikkema
Offline
Last seen: 10 years 9 months ago
Developer
Joined: 2009-07-20 14:55
After having a closer look at

After having a closer look at PAL, I come to the conclusion that what I stated above has just a very, very small chance of producing a bug.
This all only just counts if reg.exe couldn't be accessed or failt !
Even if PAL has multiple .reg files to deal with, the registry handling after restoring a .reg file could basically only be to back-up the next keys. So that shouldn't really be an issue !
But PAL does deal with 'RegistryValueBackupDelete' & 'RegistryValueWrite' straight after restoring a .reg file, which could potentially undo the 'RegistryValueWrite'.

This all said, personally I'm just not in favor of this unpredictable results when using ${registry::RestoreKey}

Formerly Gringoloco
Windows XP Pro sp3 x32

John T. Haller
John T. Haller's picture
Offline
Last seen: 2 hours 25 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Better to be safe

I always approve of the conservative approach in situations like this. Even if the launcher is a few K bigger or has a few extra lines of code as a result.

Sometimes, the impossible can become possible, if you're awesome!

Mark Sikkema
Offline
Last seen: 10 years 9 months ago
Developer
Joined: 2009-07-20 14:55
Option 3 added... ExecWait

Option 3 added...
ExecWait doesn't even seem that bad....

Formerly Gringoloco
Windows XP Pro sp3 x32

Log in or register to post comments