Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Problems with calling a DLL function in a custom action.


4 replies to this topic

Valerio

Valerio
  • Members
  • 3 posts

Posted 20 September 2001 - 20:40

Hi,
i've a problem with a custom action which needs to execute a function in a DLL.

The prototype of the function is this (in C):

__declspec (dllexport) BOOL GetProcessPath (char* szProcessName, char** szPath);

(i pass a pointer and a pointer to a pointer:
first one is untouched, the second one when the function returns
will contain a pointer to a buffer the function allocate itself).

I've prototyped it in my InstallScript this way :

prototype LONG SPProcLib.GetProcessPath (STRING,BYREF STRING);

and i call it with :

res = UseDLL (szInstDir ^ "SPProcLib.dll");
bProcessFound = GetProcessPath ("SETUP.EXE",szSetupFile);

What's bad is that GetProcessPath is not executed and the installer rollbacks as
when you prototype wrong.

Could you tell me where's the error ? Its the char** in the C function ?

UseDLL of course returns OK, so its not a dependencies problem. Also, the DLL works if
used from a test C program.

Thanx,
Valerio


Martin Aigner

Martin Aigner
  • Full Members
  • 133 posts

Posted 20 September 2001 - 22:07

A pointer to a pointer makes no sense because you want to change the value of the string and not the place, where the string is saved in memory.

Valerio

Valerio
  • Members
  • 3 posts

Posted 21 September 2001 - 10:39

Hi,
i think at this point that i haven't understood very well how prototypes work
with installscript :)

I've changed the C function again, to accept 2 pointers :

__declspec (dllexport) BOOL GetProcessPath (char* szProcessName, char* szPath);

what the function does in the end before return is :
strcpy (*szPath,(char*)sModuleEntry.szExePath);


I prototyped the function in installscript as :

prototype BOOL SPProcLib.GetProcessPath (POINTER,BYREF POINTER);

i call it with :

POINTER pSetupFile;
POINTER pSetupName;
STRING szSetupFile, szSetupName;
BOOL bProcessFound;
NUMBER res;

bProcessFound = FALSE;
szSetupName = "SETUP.EXE";
pSetupFile = &szSetupFile;
pSetupName = &szSetupName;

res = UseDLL (szInstDir ^ "SPProcLib.dll");
bProcessFound = GetProcessPath (pSetupName,pSetupFile);

The script still rollbacks .....
i even tried with prototype BOOL SPProcLib.GetProcessPath (STRING,BYREF STRING) and
still doesn't work :(

All these troubles coz i need to copy the setup.exe file (which is executing)
in a directory during installation process,and i have found no other ways to do it
than coding a dll using PSAPI and TOOLHELP32  which browse thru the active modules
lists and get the path for SETUP.EXE.

If there's any other ways, maybe using proprietary installscript/MSI functions/properties,
please help ! :) Tried using SOURCEDIR, ResolveSource action, and everything .....
all i was able to retrieve using MSI functions was SUPPORTDIR, but that's not what
i need. I need to get the path of the real SETUP.EXE which the user launch.

Regards,
Valerio



pnunes

pnunes
  • Members
  • 13 posts

Posted 12 October 2001 - 21:23

I have had problems referencing SOURCEDIR in ISWI installscripts. I am not sure what the problem is with this variable. As a workaround, I use the following code in Installscript to create my own SOURCEDIR global variable.
nvsize=1024;
MsiGetProperty(hMSI,"SourceDir",SOURCEPATH,nvSize);
In this case SOURCEPATH is used to hold the value for MSI's SourceDir. You should only need to execute this code once since the Installscript environment will retain the global variable SOURCEPATH through the whole installation. Note that you must always reset the value of nvSize to some sufficiently large buffer size before all MSIGetProperty calls since the function will change it to whatever is the actual length of the property.

Paul Nunes