You are here
NSIS Portable Help Needed
Have you looked at the NSIS Portable that's already available on Smithtech's site since it doesn't need admin rights (AFAIK) and then make a more current version of that? (no need to reinvent the wheel). It doesn't backup keys in HKLM. Besides, the keys you're worried about are for the file associations which don't matter since you can drag/drop onto the NSIS GUI to compile or use the "Open" dialog.
Smithtech's version only backs up the following reg keys (and their subkeys):
[HKEY_CURRENT_USER\Software\NSIS] [HKEY_CURRENT_USER\Software\NSIS\MRU] [HKEY_CURRENT_USER\Software\NSIS\Symbols]
It seems the users setting were moved from HKLM to HKCU is version 2.24 and newer of NSIS. what version are you trying to make portable?
Read about that in this thread.
If there is admin rights, he wants to delete the keys, which is the proper thing to do. The reason he's reinventing is because there's are new registry techniques John implemented in 7-Zip Portable that are faster and have better crash handling.
I have the newest version, 2.34, and on install it creates the keys in both HKLM and HKCU.
It creates the settings keys in both locations, which is why i need the code to handle both. The file associations aren't a big deal, but since settings are kept in both locations, it would be best to clean them ALL if it can be done.
I agree on cleaning up all registry keys created, but do all of them NEED to be created for the app to function? I say "no" since I installed the latest version of NSIS over the top of the one in Smithtech's version and it ran fine (only using HKCU keys).
Point being why not try just creating the HKCU keys and see if the app works (I already tested it and it does). The launcher on closing could then save the HKCU settings to \Data\settings and delete the HKLM keys (if the user has admin rights and they get created). HKLM keys are used for "All users" settings in my experience which aren't needed in this case.
What is the HKLM keys are created by the application as soon as it's run? I'm not sure if it is, but if the app does create them then we'll have to try to clean them up.
I don't know about the user rights code, I haven't needed to use it yet.
I'm still learning myself.
As for the reg keys, you can define them as a "||" delimited string and then loop through them to do what you need to.
!define REGKEYS "HKLM\SOFTWARE\Classes\.nsh||\ HKLM\SOFTWARE\Classes\.nsi||\ HKLM\SOFTWARE\Classes\NSIS.Header||\ HKLM\SOFTWARE\Classes\NSIS.Script||"
The loop code can be found in my Template, as well as the Portable Application Template in the forums.
My template is much less complicated as it doesn't encompass as much so you may want to start with it first.
All I ever use is makensisw.exe. It looks like it doesn't do much in HKLM and barely anything in CU. Would it make sense to consider just that?
If the portablized version handles parameters, you could put it in SendTo and have it compile scripts pretty easily ... or perhaps have it set up as a "run" add-on for Notepad++.
I didn't look at the CL version; maybe it does even less with the registry.
I was gonna make a full package at first, then later make a package just using makensisw.exe. I figured with the full package, new users that want to take a crack at developing could have examples and documentation available.
Oddly, I have an 85% finished NSIS Portable as well. I can post it and someone else can finish/maintain it if they'd like.
I'll take a look at it....i'll try to merge our work together and after i get the registry stuff fully sorted, upload a dev test package.
Thought I'd throw my 2c in here. NSIS, for as long as I've been using it, has not touched HKLM unless it is installed. Simply running the app only modifies HKCU.
I've got a launcher as well using Klonk's PAT.
That could be the case. I'll double check everything tonight and try to finish up this package.
any news on this package as I'm really interested..
The HKLM stuff I was discussing before does not need to be handled, those keys are only created by the NSIS installer, so are not needed in this case.
I have a new issue though, see the updated main post for details.
If you're sure there's only going to be one REG file in that directory, it's pretty easy.
FindFirst $0 $1 "$INSTDIR\Data\settings\*.reg" FindClose $0 4.9.5.9 FindFirst user_var(handle output) user_var(filename output) filespec Performs a search for 'filespec', placing the first file found in filename_output (a user variable). It also puts the handle of the search into handle_output (also a user variable). If no files are found, both outputs are set to empty, and the error flag is set. Best used with FindNext and FindClose. Note that the filename output is without path.
Thanks, that worked great after I actually read how the function works.
I haven't had a chance to test SmithTech's on multiple PCs to see if there are multiple settings files created, I'm hoping it's only 1 though. If anyone else wants to test his and report your results, I can try to incorporate that into my launcher so settings stay saved.
If there is more than one REG file created, you can use the FindNext command and it will find the next file. It will return an empty string when no more files are found.
This is interesting for you though, cause you'll have to merge the files So I hope this is not the case. An idea if that arises though, would be to import all the individual files into the registry, then export them into your own single file. The possible registry keys should be known from SmithTech's launcher source, so it shouldn't be too much trouble. Just be sure to clear out then restore any existing reg keys before running that procedure though.
That's a good idea if there are multiple files, i'll have to keep that in mind depending on what I figure out about those files. It'll make for one hell of a messy PRE-INSTALL CODE section though.
One more idea that may solve both situations is to have the installer launch SmithTech's program (if it is detected), thus importing the reg settings. Then export what you want and kill (or have the user manually close) SmithTech's program (by closing/killing NSIS). Then you can just wipe out his whole directory and install clean.
You should be able to detect SmithTech's launcher by pulling some kind of version info from the launcher EXE using the MoreInfo plugin (included with NSIS) -
That seems a bit more complicated than moving and renaming a file lol.
Agreed, but if you have to deal with several REG files, it may be easier. Ehh, just an idea
has only one reg file.
But switching from his version to the new one causes leftovers in the registry
It shouldn't with Dev Test 2, I set it up to properly handle the previous reg settings....maybe there's some file's i missed in the app dir, but the registry should be handled correctly now.
It does.
Even with DevTest2.
I run a fresh copy of Smithtechs version, installed yours over it and run yours.
this
ExecWait $EXECSTRING CheckRunning: Sleep 1000 FindProcDLL::FindProc "${DEFAULTEXE}" StrCmp $R0 "1" CheckRunning CheckRunningMakensisw: Sleep 1000 FindProcDLL::FindProc "makensisw.exe" StrCmp $R0 "1" CheckRunning CheckRunningzip2exe: Sleep 1000 FindProcDLL::FindProc "zip2exe.exe" StrCmp $R0 "1" CheckRunning CheckRunningMakensis: Sleep 1000 FindProcDLL::FindProc "makensis.exe" StrCmp $R0 "1" CheckRunning ;=== Put the settings file back Sleep 500 CLean-Registry-Code Goto TheEnd
but I dont know the other method. So maybe the other one is better but the one I have is the one John uses in Sumatra
oh man, great work!
don't check for a few days and devtest 3 is up and running
gonna give it a shot