Spodletela
13th December 2002 09:46 UTC
Confused; Script workflow...
I am new to NSIS, but not to programing (and that is quite possible my problem). I am searching for some installer engine that would satisfy my needs and NSIS could be the one, but after checking some example scripts i was confused; how does this thing work?
//For instance for licence page
LicenseText "..."
LicenseData "Licence.rtf"
This two lines somehow (???) affect instalation to show licence page, but wtf triggers it (DoModal for MFC lovers)? I need for instance 2 InstallDir dialogs with second showing data gathered from the first, but after i tryed to set something like...
InstallDir "$PROGRAMFILES\Test"
DirText "bla"
StrCpy ${DATABASEDIR} "$INSTDIR\Data"
StrCpy $0 $INSTDIR
InstallDir "${DATABASEDIR}"
DirText "bla"
StrCpy ${DATABASEDIR} $INSTDIR
StrCpy $INSTDIR $0
... i only get first instalation dir dialog. I just cant figure it out and there is allso no documentation how does it work (docs show how does functions work, but it doesnt show how script flows). I even "attacked" NSIS source code with VC++, but after i encountered that script.cpp "spaghetti" code :D, i lost my will to debug further (did someone developing NSIS ever heard about yacc? Maybe (retorical; it would be really GOOD idea) it wouldnt be bad idea using it, maybe even using allready existing scripts like vbscript (i hate it too, BUT, COM support, api support,...).
Thank you for reading this and even more if you are able to clear my confusion.
Spodletela
kichik
13th December 2002 13:16 UTC
NSIS scripting language is not exactly linear. You script doesn't say show this page now, extract some files, pop up a message box, show another page, show another page, start copying files, and finally register some DLLs. It has a bit more complex strcture. NSIS controls the showing of the pages according to what you tell it but you don't tell it directly to this now like with MFC and DoModal. You set some settings for NSIS in the script and according to them it decides which pages to show.
NSIS scripts are built from three types of commands:
1) Compile time commands (!ifdef/!else/!endif/!system/!packhdr)
2) Installer setting commands - DirText, LicenseText, Page and friends.
These commands set how the installer will act, how it will look like, silent or verbose, what pages will be shown and the texts in the installer/uninstaller.
3) Commands used in sections and functions - StrCpy, File, MessageBox and friends.
These commands are run-time commands which the installer executes. Sections are executed when the installation begins, functions are called either from within section using Call or by the installer if they are callback functions (.onInit for example).
If you want to show two directory selection pages you will have to use the Page command. For example:
Page license
Page comoponents
Page directory
Page directory"" secondDirCallback
Page instfiles
>
As you see in the script I told NSIS to call secondDirCallback right after it creats the second directory selection page and right before it shows so you can change the text of the dialog from there to whatever you want to change it to according to the last directory selection page.
Currently you can't tell NSIS directly what title each directory page will have and what text will be displayed on it so you will have to set it manually from this callback function (using GetDlgItem and SendMessage).
Spodletela
13th December 2002 14:54 UTC
...
and i thought Prolog is annoying :igor:
Well thank you for an answer it did help with deceision that its
time to write my own installer. NSIS is nice project but (my opinion,
quite possible i am wrong) i belive it missed point of 3rd party installers - people use them to make their job easyer...
Anyway i will check updates, maybe something changes :up:
kichik
13th December 2002 15:09 UTC
Currently you can't tell NSIS directly what title each directory page will have and what text will be displayed on it so you will have to set it manually from this callback function (using GetDlgItem and SendMessage).
By currently I meant it will be possible soon...
Personally I think NSIS scripting language is very powerful and easy to use. But don't mind me, I am a bit biased because I am one of the developer :D
Have fun writing your installer...
Sunjammer
13th December 2002 18:04 UTC
Re: ...
Originally posted by Spodletela
people use them to make their job easyer...
I disagree, I think people use them to gain access to a powerful set of tools for performing the task of installing software. NSIS does just that and allows you to pretty much do whatever you want.
Spodletela
16th December 2002 12:11 UTC
...
What about following concept;
------------------------------------------------------
[stub]
// compressed
[script.txt] //executed by windows scripting host
[library.dll]
[other files...]
------------------------------------------------------
stub unpacks script.txt and library.dll somewhere on disk,
and runs script that performs installation of other files in
archive with usage of dynamical loaded library.dll, which is set of functions needed to manipulate with archive or to optimize size just
functions for extracting and listing archive.
That way, installer would be highly configurable and extendable,
not to mention it wouldnt be set on some type of scripting language
as it would be able to use any script that supports scripting host. If language that would be used is not by default supported by wsh, for instance Ruby, it could be easly destributed trough instalation;
------------------------------------------------------
[stub]
// compressed
[script.txt] -> vbscript or jscript
[library.dll]
[rubyinstall.exe]
[script.ruby]
[other files...]
------------------------------------------------------
stub starts script.txt, that installs rubyinstall.exe. Then it launches script.ruby and it performs installation of other files.
The only thing left are dialogs; i am not that much in script programing, but i am sure it is possible to implement NSIS like callbacks to undelaying script.
So; engine that creates dialog from text descriptions like .rc files and message handler that forwards all message calls to script callbacks; easy to use and efficient.
Size of installation (that uses vbscript or javascript) wouldnt differ much from NSIS or quite possible it would be smaller (as script engine wouldnt need to bi distributed with install).
Annoying part is that on windows 95 there is no scripting host by
default so it would have to be distributed with archive, but, hey,
who still supports w95 :D Anyway that could be fixed with some
initialization function exported from library.dll and run by stub that would download wsh from net and install it. Allso installation would have larger (becoase of wsh) memory print, but concerning todays hardware that shouldnt be a problem, even more becoase we are not talking about 100Mb of ram consumption, more about 1Mb...
And word or two about library.dll. It could be just simple dll with exported function, but with usage of com technology programing would be even easyer.
Sunjammer; installer is not *so* hard to program (compression is the most annoying part, but there are nice librarys like ZLib), but it is time consuming, i believe that people use 3rd party installers to spare some time. At least me...
(i hope my english is understendable enough, as it is not my native language)