Blinker
15th June 2009 17:25 UTC

Plugin .DLL w/MFC - Error Calling Functions.
Hi All,

I have an installation package that contains MyLibrary.dll, an MFC DLL. During my installation process, I extract MyLibrary.dll, and its dependencies into the $PLUGINSDIR, and try to execute a function in MyLibrary. When I make the call, I always get "error" returned..

Prior to making this an MFC DLL, everything worked without a hitch. I made another C app which made calls into this DLL just to make sure the functionality was there, and everything worked as expected.

Snippet:

File /oname=$PLUGINSDIR\MyLibrary.DLL "${SERVER_INSTALL_PATH}\work\Utilities\MyLibrary.dll"   
File /oname=$PLUGINSDIR\msvcr90.dll "${SERVER_INSTALL_PATH}\work\Application\msvcr90.dll"   
File /oname=$PLUGINSDIR\mfc90.dll "${SERVER_INSTALL_PATH}\work\Application\mfc90.dll"
File /oname=$PLUGINSDIR\microsoft.vc90.crt.manifest "${SERVER_INSTALL_PATH}\work\Application "\microsoft.vc90.crt.manifest"   
File /oname=$PLUGINSDIR\microsoft.vc90.mfc.manifest "${SERVER_INSTALL_PATH}\work\Application\microsoft.vc90.mfc.manifest"

System::Call "$PLUGINSDIR\MyLibrary::SAYHELLO() i .r0";
${If} $0 == "error"
    MessageBox MB_OK|MB_ICONSTOP "Error saying HELLO"
    Quit
${endif}

I've tried the above, and also threw in a "SetOutPath $PLUGINSDIR" prior to SAYHELLO thinking it might be a path issue (not able to find MFC .dlls), and still no go.

Am I overlooking something? Any suggestions on what to try next?

Cheers.
Mike

sgiusto
16th June 2009 13:27 UTC

I assume you are using Visual Studio.
You can compile your library with debug info. Then create your installer with the debug version of the dll in it, launch the installer and then 'attach to process' from visual studio.
Then check where is the problem by debugging the dll code

hope this helps

Blinker
16th June 2009 13:30 UTC

Originally posted by sgiusto
I assume you are using Visual Studio.
You can compile your library with debug info. Then create your installer with the debug version of the dll in it, launch the installer and then 'attach to process' from visual studio.
Then check where is the problem by debugging the dll code

hope this helps

Thanks for your reply. I believe the error has something to do with dependancies, not the actual SAYHELLO call itself, but I can't be certain. I've ran Dependancy Walker on my library, everything checks out fine. I've hit a wall.

I just get "error" back from my call, which doesn't come from my code, it comes from the System::Call item.

Is there anyway to step deeper into System::Call, or another NSIS Build that will give me the extra info I need?

sgiusto
16th June 2009 13:37 UTC

You can download source code for sysyem plugin and debug it as stated before.
Alternatively you can write your own plugin that wraps the calls to the MFC dll to avoid using the system plugin

Blinker
16th June 2009 19:19 UTC

Thanks Sguisto.

I've download the source, and all the tools, and its choking during the compile, giving me a "Couldn't find a good version of libcp.lib" message.

I found this post, which shows how to compile JUST System:
http://forums.winamp.com/showthread....hreadid=211121

When I do this, I get:

C:\Users\Mike\Desktop\nsissource\nsis-2.45-src\Contrib\System\Source>link /nologo /opt:nowin98 /entry:DllMain /dll /out:System.dll kernel32.lib user32.lib ole32.lib Buffers.obj Plugin.obj System.obj 
   Creating library System.lib and object System.exp
Buffers.obj : error LNK2019: unresolved external symbol _g_stacktop referenced in function _Alloc
Plugin.obj : error LNK2001: unresolved external symbol _g_stacktop
System.obj : error LNK2019: unresolved external symbol _g_stacktop referenced in function _DllMain@12
Buffers.obj : error LNK2019: unresolved external symbol _g_stringsize referenced in function _Alloc
Plugin.obj : error LNK2001: unresolved external symbol _g_stringsize
System.obj : error LNK2019: unresolved external symbol _g_stringsize referenced in function _DllMain@12
Buffers.obj : error LNK2019: unresolved external symbol _g_variables referenced in function _Store
Plugin.obj : error LNK2001: unresolved external symbol _g_variables
System.obj : error LNK2019: unresolved external symbol _g_variables referenced in function _Int64Op
System.obj : error LNK2019: unresolved external symbol _RealCallBack referenced in function _CreateCallback
System.obj : error LNK2019: unresolved external symbol _CallBack referenced in function _Call
System.obj : error LNK2019: unresolved external symbol _CallProc referenced in function _Call
System.dll : fatal error LNK1120: 6 unresolved externals

Anybody have the latest symbols for system handy?

Anders
16th June 2009 19:50 UTC

what does SAYHELLO() look like in your code? is it stdcall?
Are you sure its exported as "SAYHELLO"? (Check with Dependency walker)

Blinker
16th June 2009 20:14 UTC

A week ago, everything worked fine. I added SAYHELLO just to a message box to confirm I could call into the DLL.

I converted the project to an MFC DLL, no functionality, exports or declarations have changed.

When I fire up depends, it shows the export as expected:

long SAYHELLO(void)

I have the MFC DLLs (MSVCR90, MFC90 etc) inside the PLUGINSDIR, along with my DLL.

If I paste in the OLD version of my DLL (non MFC) from a week ago, it can SAYHELLO without any problems.

I recently installed Vista SP2 along with IE8 as well, which had me wondering as well. When I fire up depends, it gives me:

"Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module"

I tried a DEPENDS on the NON-MFC version of the DLL (the one that works), and it gives me the same errors.

The Module list includes "SHLWAPI.DLL" and "IEFRAME.DLL" marked in red indicating an error. I find several copies of these on my PC, and have even tried placing these in the PLUGINS dir to see if that resolves anything... No go.

My next step was to try to dig deeper into SYSTEM to see if I can see what's choking, I see posts indicating "scons" may not work properly with VS 2008, so I'm trying now to resolve that.

Is there anything I may be overlooking?

Thanks for your replies...

Blinker
17th June 2009 16:17 UTC

Wow... That was fun.

Got it figured out, my fault. My exports from the .DLL since moving to MFC did not match 100%. For each function I wanted to export from MY Dll, I put "__declspec(dllexport)" before the function name. I removed all of these and added them to a .DEF file, and it worked.

When I viewed everything with Depends prior to my change, the function name it was exporting was decorated, so when System tried to find SAYHELLO, it would fail.

This all came to light when I finally got SYSTEM.DLL to build, I was able to add/use the extra logging to track down the culprit.

Thanks for all your replies guys...