If you want to compile NSIS by yourself you have to install the Sources. The Sources are shipped with every official \W{http://sourceforge.net/project/showfiles.php?group_id=22049}{NSIS distribution} as well with the \W{http://nsis.sourceforge.net/nightly/nsis.zip}{nightly} development Snapshots. NSIS is programmed in Microsoft Visual C 6.0. Therefore it contains all necessary files including the Project Files. You can also use the current Version 7.0 of Visual C but the output is a few KB larger. The Sources also include a makefile for the famous Open Source Compiler GCC but unfortunately it is a little bit outdated. If you are working with GCC and want to provide a updated working makefile or your using an other Compiler like Borland C++ Builder or Open Watcom C/C++ and want to provide makefiles or project files please drop a line on the \W{http://forums.winamp.com/forumdisplay.php?forumid=65}{NSIS Forum}.
\\<b\\>Note: If your using Visual C 6.0 you have to update the \W{http://www.microsoft.com/msdownload/platformsdk/sdkupdate/}{Platform SDK} to avoid crashes when using CopyFiles. See \W{http://forums.winamp.com/showthread.php?s=&threadid=131964}{here} for further informations. You should also install the \W{http://msdn.microsoft.com/vstudio/downloads/ppack/default.asp}{Processor Pack} for decreasing the excutable Size.\\</b\\>
Like any other program installers made by NSIS return errorlevels as a result of their execution. Very useful if you call an NSIS Installer from within an other installer with \R{execwait}{Execwait}.
Create a key with your product name under \\<b\\>HKLM/Software/Microsoft/Windows/CurrentVersion/Uninstall\\</b\\> to add entries to the "Add/Remove Programs" section in the Control Panel.
For Windows NT (NT4/2000/XP), it's also possible to create the key in the HKCU hive, so it will only appear for the current user.
There are several values you can write to key to give information about your application and the uninstaller.
Write a value using the WriteRegStr command (for strings) or WriteRegDWORD command (for DWORD values). Example:
The best way to install the VB6 runtimes is to use the \R{upgradedll}{UpgradeDLL macro} to upgrade the DLL files, and the \R{addshareddll}{AddSharedDLL macro} when installing the software for the first time to increase the shared DLL count. Define UPGRADEDLL_NOREGISTER before upgrading Stdole2.tlb (and undefine it before upgrading other files).
You can extract the files from vbrun60sp5.exe using any archiver that supports CAB compression, or if you have installed the latest version on your system, copy the following files from your system directory:
In the uninstaller, use \R{unremovesharedll}{un.RemoveSharedDLL} to decrement the shared DLL count, but remove the Delete /REBOOTOK $R1 line, because it's never a good idea to remove the VB runtimes. The system to registering shared DLL files does now always work and many application require these files.
\c # skip shared count increasing if already done once for this application
\c IfFileExists $INSTDIR\myprog.exe skipAddShared
\c Push $SYSDIR\Asycfilt.dll
\c Call AddSharedDLL
\c Push $SYSDIR\Comcat.dll
\c Call AddSharedDLL
\c Push $SYSDIR\Msvbvm60.dll
\c Call AddSharedDLL
\c Push $SYSDIR\Oleaut32.dll
\c Call AddSharedDLL
\c Push $SYSDIR\Olepro32.dll
\c Call AddSharedDLL
\c Push $SYSDIR\Stdole2.tlb
\c Call AddSharedDLL
\c skipAddShared:
\c SectionEnd
\c
\c Section "Uninstall"
\c Push $SYSDIR\Asycfilt.dll
\c Call un.RemoveSharedDLL
\c Push $SYSDIR\Comcat.dll
\c Call un.RemoveSharedDLL
\c Push $SYSDIR\Msvbvm60.dll
\c Call un.RemoveSharedDLL
\c Push $SYSDIR\Oleaut32.dll
\c Call un.RemoveSharedDLL
\c Push $SYSDIR\Olepro32.dll
\c Call un.RemoveSharedDLL
\c Push $SYSDIR\Stdole2.tlb
\c Call un.RemoveSharedDLL
\c SectionEnd
\H{useful_system_plugin} Calling an external DLL using the System.dll plugin
Some install processes are required to call functions contained inside third party DLLs. A prime example of this is when installing a Palm(TM) conduit.
\\<b\\>Some background about System.dll\\</b\\> \\<br\\>
The System.dll plug-in (by Brainsucker) enables calling of external DLLs by providing the 'Call' function. There are a number of other functions provided by System.dll, but they will not be covered here. For more details about the other functions, lock the doors, take the phone off the hook, screw your head on *real* tight and head on over to the Contrib/System directory and read the doco there.
\\<u\\>Data Types\\</u\\> \\<br\\>
System.dll recognises the following data types:
\b v - void (generally for return)
\b i - int (includes char, byte, short, handles, pointers and so on)
\b l - long & large integer (know as int64)
\b t - text, string (LPCSTR, pointer to first character)
\b b - boolean (needs/returns 'true':'false') - by the fact this type is senseless -> usual integer can be used ('0':'1')
\b k - callback. See Callback section in system.txt.
\b * - pointer specifier -> the proc needs the pointer to type, affects next char (parameter) [ex: '*i' - pointer to int]
\\<u\\>Mapping System.dll variables to NSIS script variables\\</u\\> \\<br\\>
There's not much point in being able to call an external function if you can't get any data back. System.dll maps function variables to NSIS script variables in the following way:
NSIS $0..$9 become System.dll r0..r9
NSIS $R0..$R9 become System.dll r10..r19
There is one final wrinkle: placing a period/dot ('.') in front of a System.dll variable means 'makes no change to source' and it appears to be used everywhere except \e{where a pointer is returned}. This is important and WILL cause you grief if you forget!! See the example below.
Using System.dll::Call
To call a function in a third party DLL, the Call function is used like this:
section at the end are the parameters that are passed between your DLL and your NSIS script. Note the absence of the dot in front of the 'r1' parameter...
\\<b\\>Before starting to code the NSIS script\\</b\\> \\<br\\>
Before you start to code any NSIS code, you need to know the full prototype of the function you are going to call. For the purposes of this example, we will use the 'CmGetHotSyncExecPath' function from the Palm 'CondMgr.dll'. This function is used to return the full path of 'HotSync.exe'.
\\<u\\>Function Definition\\</u\\> \\<br\\>
int CmGetHotSyncExecPath(TCHAR *pPath, int *piSize);
where
\b pPath is a pointer to a character buffer. Upon return, this is the path & file name of the installed HotSync manager.
\b piSize is a pointer to an integer that specifies the size (in TCHAR's), of the buffer referenced by the pPath parameter.
return values:
\b 0: No error
\b -1: A non-specific error occurred
\b ERR_REGISTRY_ACCESS(-1006):Unable to access the Palm configuration entries
\b ERR_BUFFER_TOO_SMALL(-1010): The buffer is too small to hold the requested information
\b ERR_INVALID_POINTER(-1013):The specified pointer is not a valid pointer
Also, if the buffer is too small the value in *int is the size (in TCHARs) that the buffer should be.
This function definition maps to the following System.dll definition:
CmGetHotSyncExecPath(t, *i) i
i.e. It takes a text variable, a pointer to int, and returns an int value.
\\<u\\>Using the external dll function\\</u\\> \\<br\\>
Now that we've sorted out what the function does, and how it maps to the System.dll format, we can use the function in a NSIS script.
First, it is recommended to turn 'PluginUnload' off before making multiple calls to System.dll. According to Brainsucker (and others), this will speed up execution of the installer package.
Second, you have to change the output directory to that where the DLL you want to use is. It may also work if the DLL is on the system path, but this hasn't been tested.
The following code fragment will install 'condmgr.dll' to a temporary directory, execute the CmGetHotSyncExecPath function, display returned data and finally unload the System.dll plug-in.
Lots of thanks go to \\<b\\>kichik\\</b\\> and \\<b\\>Sunjammer\\</b\\> for spending a lot of time assisting in solving this problem. Also to \\<b\\>brainsucker\\</b\\> for creating the System.dll plug-in in the first place.
\H{dumplogtofile} Dump Content of Log Window to File
This function will dump the log of the installer (installer details) to a file of your choice. I created this function for Afrow_UK who requested a way to dump the log to a file in \W{http://forums.winamp.com/showthread.php?s=&threadid=125431}{this forum thread}.
To use it push a file name and call it. It will dump the log to the file specified. For example:
\H{readreg_multi_sz} How to Read REG_MULTI_SZ Values
I wrote this script to help rpetges in \W{http://forums.winamp.com/showthread.php?s=&threadid=131154}{this forum thread}. It reads a registry value of the type REG_MULTI_SZ and prints it out. Don't forget to edit where it says "Edit this!" when you test this script. The values must point to a REG_MULTI_SZ value or the example will spit out an error.
