Exporting symbols in a .exe for external DLLs

[YoannNicod]

Hello, 

I am facing a strange problem.

Basically, I have my application that loads a DLL (I developped).

My DLL exports functions I can call from my application : OK

I would also like to call functions of my application from my DLL : it does not work.

To do that, in my DLL, I call :

HMODULE hModule = GetModuleHandle("application.exe");
FARPROC hFunc = GetProcAddress(hModule, "appFunction"); // (defined by : void __declspec(dllexport)  appFunction(void) in my application

hModule is non-zero but hFunc is NULL. When I use a tool to see exported symbols by application.exe, there is none.

So my question is : Can I export symbols from a .exe with LabWindows 8.5 ?

thanks in advance

[ebalci]

Before you call GetModuleHandle, you have to call LoadLibraryEx.

And the concept of loading EXEs as external modules and calling functions from them is a "misty" subject for me.

See the discussion in this forum also.

[YoannNicod]

Thank you for your answer,

I had already tried with :

HMODULE hModule = LoadLibrary("application.exe");  

and

HMODULE hModule = LoadLibraryEx("application.exe", NULL, 0);  

it gives the same result.

To be more precise here is the source code of dll.dll :

#include <Windows.h>
#include <stdio.h>

typedef void(*APPLI_PRINTF7)(void);

__declspec(dllexport) void dllFunction(void)
{
   HMODULE hModule = LoadLibrary("application.exe");
   FARPROC pFunc = GetProcAddress(hModule, "appli_printf7");

   if(pFunc)
      ((APPLI_PRINTF7)pFunc)();
   else
      printf("error = %d\n", GetLastError());

   return; 
}

 and here is the code of application.exe

#include <Windows.h>
#include <stdio.h>

typedef void(*DLL_FUNC)(void);

__declspec(dllexport) void appli_printf7(void)
{
   printf("7");
   return;
}

int main(void)
{
   HMODULE hModule = LoadLibrary("dll.dll");
   FARPROC pFunc = GetProcAddress(hModule, "dllFunction");

   ((DLL_FUNC)pFunc)();

   return 0;
}

I compiled dll.dll once and for all with LabWindows (8.5), and I compiled exactly the same code for application.exe with LabWindows (8.5) and Visual Studio 2013.

It works with Visual Studio (the dll finds appli_printf7 and 7 is printed on the screen), but doesnt with LabWindows (the dll does not find appli_printf7 and prompt the error 127 (The specified procedure could not be found.)).

I used Dependency Walker (and dllexp to confirm) to find out that appli_printf7 is actually NOT exported with LabWindows, and is exported with Visual Studio.

Therefore, it is normal that the dll can't find the symbol if it is not exported.

My questions are :

- Why is that so ???

- Is there a setting to set in order to make LabWindows export symbols marked by __declspec(dllexport) for .exe projects ?

- Is this a problem fixed with a newer version of LabWindows ?

- My dll is actually a plugin to my application. If I can't load symbols from my application, how can I provide an API for my dll in order to make generic functions available to it ? Is there a workaround for it ?

Edit : I tried with LabWindows 2012, same problem..

Thanks in advance 

[LuisG]

One workaround would be to turn your application into an exe/dll combo. The exe would be an extremely small wrapper that does nothing but call some predefined entry point in the dll, which then runs the entire application. The dll would export this entry point, as well as all the entry points that your plug-ins need to call. The plug-ins themselves would pass the dll name to GetModuleHandle, rather than the exe name.

Luis

[YoannNicod]

Well, it is a workaround ! It is quite messy/heavy but it should work. 

Can someone from National Instrument confirm that it is not possible to export symbols in an .exe project please ?

If I understand well, since the main application (.exe) can't export symbols, it is impossible (except with LuisG's trick) to make a software that supports plugins and provide an SDK to developers (softwares like notepad++, imageJ etc...).

If this is correct, it is a huge limitation of LabWindows.

[msaxon · Accepted solution]

In my experience, it is quite unusual though not unknown for a Windows executable to export functions in this way. I've never noticed that CVI can't do it and in the 25 years I've been programming in Windows I've never seen a published API that relies on it. It is far more usual for an application to pass callback function addresses to a DLL as parameters in a function call. That way, the application is free to use whatever function names it likes and to use different callbacks in different situations.

However, if you insist on doing it your best option - in my opinion - is to port the whole CVI application to the Visual Studio development environment. That way, you can keep programming with the CVI API but have the freedom to use all the VS facilities - including the ability to export symbols from a .exe as well as the ability to program in C++ if you like.

[YoannNicod]

Thank you msaxon for your answer, I think passing the adress of the function to the DLL is a good and simple workaround for my problem.

[LuisG]

Yes, I can confirm that you cannot currently export symbols from an exe built with CVI. Although I don't agree that this is a huge limitation (I'm not aware of any request for this feature, in the 20 years since CVI has been building dlls...) I did create a work item to remove this limitation. You can track it with ID 476881,

I do agree with msaxon that exposing callbacks is probably a far more common method of implementing a plug-in architecture in C/C++ apps. I did a dumpbin /exports on notepad++.exe and I did not find any exported symbols (I didn't test any others, though).

[YoannNicod]

As far as I'm concerned, I looked into notepad++ source code as well, and I did not find any exported functions either. Notepad++ seems to pass the handles (HWND) of the different windows to the plugin that can manipulate them directly as it wants, but does not provide functions itself.

My experience in plugins is not advanced and I was not aware of the "passing the callback adresses to the plugin" technic, which works very well by the way.

Thank you for your efforts and answers.