How abot a decompiler so u can take apart NSIS compiled file to see how they were put together so you can improve your self.
Archive: decompiler?
How abot a decompiler so u can take apart NSIS compiled file to see how they were put together so you can improve your self.
I asked Justin about that one... he said that b/c there are so many different sections/commands, etc., there are almost an infinite number of combinations of installers possible. Anyway, to cut to the chase, it's a lot more difficult to make a "decompiler" for NSIS than it was to make "PimpView" for Pimp 1.3.1. That's the deal (I think...) :D
-- Jarsonic
I had to bring this back up. the other day i was working on a new version of my custom istaller and i first unistalled the older version of NSIS the installed 1.42 not realizing that i had a couple of files in that directory and they were deleted, but i had the compiled installer in a different folder and thats is all i have left now. so you may see now how a decompiler may help in this situaltion. My ideal is just the basic line like what gets put in the registry and what gets installed where. or maybe an in depth install log to see what it did the convert it into a .nsi script file.
please don't flame me if this sounds rediculous. thanx for any kind replies
bballer182
I don't know about a decompiler but a switch to disable all actions except extraction of files or a command line switch to extract files would be very handy.
Some Installer/Self Extracting EXEs can be viewed if opened in WINZIP etc so you don't have to install to get some idea, if this is not possible for NSIS then maybe the file extraction mentioned above and maybe "/readme" to view readme etc.
Something like this has come up before
I've suggested this before... :)
You can include your .nsi script inside your installer. This makes it easy to pack up your entire project and take it elsewhere (like to a different machine to play with .ini file, for instance). It would also have left you your installer script.
The other reason a decompile feature isn't a great idea is some people might like to keep their .nsi scripts secret (for whatever reason), and NSIS's license basically allows for that.
-=Gonzotek=-
p.s. I keep my script in c:\Program Files\MyProg. But you could drop it in temp and forget it if you wanted to just have an emergency copy.
I'd say more thought on source code management might be a better idea....
My 2 cents worth...
*bump*
Heres another situation where it would come in handy:
Some guy reckons that a package put together with NSIS (which was downloaded from a highly-visited site) contains a virus (Win32/DelAll).
NOD32 Virus scanner (from www.nod32.com) identifies the virus in both the installer and uninstaller, however Norton Antivirus does not.
I am pretty sure its just a false alarm.
The files inside the package are definately not to blame as they are just a series of text files once installed (and they pass all scans once decompressed). Also the packaged files in the intaller (after compression) would not likely cause the false trigger as the virus is detected in both the installer and uninstaller by NOD32.
The package was built using version 1.1g
I have searched this board and found no false alerts regarding version 1.1g (well none for any version actually!), so its most likely that the 1.19 bootstrap/header is not the cause.
That leaves one possibilty, the compiled NSI script.
(unless ive missed something)
you could have a look at Peter Windridge's NSIS file extractor to at least get some of the job done. It's at http://www.incomplete.co.uk/nsis.htm
This does raise an interesting question - what do we do when stupid virus makers find out about NSIS? NSIS is great to distribute viruses (I think), because the installers can't be scanned (though virus scanners auto-protect should catch the files once they are extracted).
But what if you actually use a destructive script?
Another thing jumps to my mind: this never happened to InstallShield AFAIK and they have a powerful script language too. So maybe it's not that big an issue.
The big thing virus writers are usually concerned with these days is getting the virus to redistribute itself to more computers after infecting one. NSIS doesn't have internet capabilities (with the exception of the http/ftp download add-on someone made) so that should it fairly safe, when compared with Outlook/IE/etc.
The other thing that gives NSIS power over virus writers is the fact that once an installer was known to contain some kind of virus code, it would pretty much be shunned by the rest of the internet community, and assuming that the author DIDN'T know about it, he should be pretty quick to fix the thing. If he did know about it, well, we'll just have to go to his house and knock him around a bit to make sure it doesn't happen any more ;)
-=Gonzotek=-
I'm glad that you brought this thread up from it's grave and it got me thinking as i read the replies that nsis could automatically save the compiler window as text or some other small file that a decompiler or the SISN (backwards of NSIS) could read to create a new copy of the .nsi file that was lost or you wanted to see what was in it before you install. just a thought. i wouldn't think that it would add too much size to the installer would it.
WA3 and NSIS ROCK!!!
Log to File
This is how you can log the results of a build to a file (works best if you've already completed the build once so it doesn't die with an error..)
Use the command line:
makensis.exe myscript.nsi > myscript.nsi.txt
Want to do it with a Shell Extention?
Well, I'm not having much luck getting it to work 8) I can only do it from a command line right now..
bad link
hey i need the file extractor cause the cablenut installer wont run and i want the files out of it but the link for Peter Windridge's NSIS file extractor is dead, anyone able to post a link or the file for me?
I'm using a litte .nsi script called "AutoBackup" for keeping a backup of the entire project inside the project himself.
The backup can be extracted using the "/source" switch in the command line of the installer.
i'm using the following directory structure:
+
|
|--+Common [DIR]
| |
| -autobackup.nsi
|
|--+PRJ1 [DIR]
| |
| -PRJ1.nsi
| -file1.dll
| -file2.exe
| -file3.etc
|
|--+PRJ2 [DIR]
| |
| -PRJ2.nsi
| -file....
where PRJ1, PRJ2 are the names of my project (and also the "filename" portion of my installer)
I simply start my script with these lines:
!define PrjName PRJ1
!include ..\common\autobackup.nsi
and autobackup.nsi is as follows:
!define ExeName ${PrjName}.exe
!define SrcName ${PrjName}.nsi
!system "del ${ExeName}" ignore 0
OutFile ${ExeName}
Function AutoBackup
Push $0
Call GetParameters
Pop $0
StrCmp $0 "/source" 0 no_source
SetOutPath $DESKTOP\${PrjName}
File /r .\*.*
SetOutPath $DESKTOP
File /r ..\common
Quit
no_source:
Pop $0
FunctionEnd
Function .onInit
Call AutoBackup
FunctionEnd
;eof
This causes all the files in "Common" and in "PRJ1" (even subdirs) to be included in the installer.
There is only a small bit of size increasing, because the files you are using inside the installer will not be added again.
The project extraction recreate the folders "Common" and "PRJ1" on the desktop (just modify the script as needed.
Unfortunately, it isn't tested for installers with more command line parameters...
Regards
Tranky