AndrewRich
19th July 2001 01:52 UTC
Hi folks,
I'm an experienced InstallShield programmer looking to move some of our apps to a lighter-weight installation package. NSIS looks quite interesting, but I need to know about its support for external DLL functions and custom dialogs.
We have several custom DLLs with various functions exported for use by the InstallShield project. Can NSIS call exported DLL functions?
Our product requires a bit of configuration by the user at install-time. Can NSIS display custom dialogs and act on the results?
Thanks for reading.
Gonzotek
19th July 2001 02:20 UTC
NSIS doesn't call external .dlls nor does it do cutom dialogs. However, it's open-source, so you can easily add the custom dialogs. Calling the functions from .dlls might be a bit harder, as I beleive they are made to work with InstallShield, are they not? What, generally, are the functions in the .dlls related too? If we have some idea of what you're trying to accomplish in the install it will be easier to specifically answer your questions. A small post-installation program could be written to overcome NSIS limits without messing with the NSIS code.
-=Gonzotek=-
AndrewRich
19th July 2001 02:59 UTC
Originally posted by Gonzotek
Calling the functions from .dlls might be a bit harder, as I beleive they are made to work with InstallShield, are they not?
Pretty standard DLLs with exported functions. The prototypes are all LONG WINAPI if that makes any difference.
What, generally, are the functions in the .dlls related too? If we have some idea of what you're trying to accomplish in the install it will be easier to specifically answer your questions.
Our application is a web server/database that manages and generates reports from data passed from remote agents. We have DLLs that export functions more easily implemented this way; a variety of file, service, and database functions. As an example, we have one DLL that exports the following functions:
CheckDB [check the existence of an SQL database]
CheckService [check the status of a service]
CreateDB [create an SQL database]
InstallLocalService [install a service as the System Account]
InstallLocalServiceX [install a service as another user]
RemoveLocalService [remove a service]
StartLocalService [start a service]
StopLocalService [stop a service]
KillProcess [kill a running process, uses PSAPI.DLL]
IsPortAvailable [check availability of a TCP port]
These functions are called during the installation of the application to, for instance, install the service or create the database in SQL Server.
The custom dialogs I mentioned are things like selecting an SQL Server host machine, entering between three and five TCP ports for the server application to use, entering passwords for the reporting agents to use.
The InstallShield project that builds this installer is just huge. It's out of control. So I'm looking for another solution that will still have the flexibility of InstallShield without the tremendous overhead.
Thanks for reading!
spaetz
19th July 2001 11:52 UTC
I guess you'd have to write a 5kb C app, that you hand over the name of the .dll and the function and it would basically call the .dll. You simply do the
ExecWait "Calldll.exe Functionname"
You can delete the small app afterwards. Shouldn't be that tricky.
AndrewRich
19th July 2001 17:58 UTC
RunDLL32?
Isn't that what RunDLL32 is meant for? Hmm, I will have to investigate this.
saivert
5th August 2001 17:42 UTC
Concerning RunDll32/RunDll
To use Microsoft's RunDll/RunDll32 the DLL functions need to use some specific prototype, calling-convention and return value (void ??). However I do not know about the specifics of this (search MSDN for info). I once tried to make a DLL that exported a function with this prototype: 'void MyRunDllProc(char *params);' but when I tried to run 'RunDll32 mydll.dll,MyRunDllProc someparams' RunDll32 failed. Also it's not advicable to use any external DLL function caller anyway, just rewrite NSIS to include a Instruction such as (syntax displayed):
CallDll retval($0-9|$INSTDIR|$OUTDIR) dllfile dllfunction parameters....
You could just use LoadLibrary and GetProcAddress in the code of NSIS. I am sure this will work for most purposes, as long as the DLL function returns a string, number or nothing (void). Also the DLL function could have any parameters as long as it was char and int types, else you would also have to specify the types in the CallDll instruction. [END_OF_TRANSMISSION]