GetProcAddress and a DLL

I’ve created a very simple Win32 DLL. It only has one exported function called “Test” whose declaration looks like this:-

Code:

---

#ifdef MYDLL_EXPORTS
#define MYDLL_API __declspec(dllexport)
#else
#define MYDLL_API __declspec(dllimport)
#endif


MYDLL_API HRESULT Test(void);

---

Then in the source file:-

Code:

---

MYDLL_API HRESULT Test(void)
{
        return (HRESULT) 66;
}

---

Now in my executable, I’ve done this:-

Code:

---

static HMODULE hDLL;
typedef HRESULT (STDAPICALLTYPE * LPFNTEST) (void);
LPFNTEST _pfnTest;

---

Then I load the DLL:-

Code:

---

hDLL = LoadLibrary("MyDLL.dll");

---

All the above works fine and hDLL gets a non-NULL value . Now I come to obtain the proc address for function “Test”:-

Code:

---

_pfnTest = (LPFNTEST)::GetProcAddress(hDLL, "Test");

---

but _pfnTest ends up as NULL and GetLastError() returns 127 (ERROR_PROC_NOT_FOUND). What have I done wrong?? I haven't implemented any code yet in DllMain(). For example, I haven't initialised anything. Should I have done?

Quote:

---

Originally Posted by John E

but _pfnTest ends up as NULL and GetLastError() returns 127 (ERROR_PROC_NOT_FOUND). What have I done wrong??

---

You have not accounted for the name decoration that the VC++ Compiler has subjected your DLL's Exported Functions to.

To know exactly what it has done, open the DLL in Dependency Walker and observe exported function names...

• www.dependencywalker.com (for latest version)

You either need to GetProcAddress of the functions using their decorated names, or better - create entries in your DLL Project's DEF File that define the names of the exported functions the way you would like to see them as.

Something like this -

Code:

---

LIBRARY          "MYDLL"

EXPORTS
        Test          PRIVATE

---

Your function is exported using the C++ decorated name. Use extern "C" before the function prototype, or use a *.def file in your project containing:

Code:

---

EXPORTS
        Test

---

To know for sure that your function is exported with an undecorated name, use Dependency Viewer to list its exports.

Note: I've noticed another potential problem, which will not affect this test function since has no parameters, but your dll declares the function as __cdecl (depending on your project's default settings), and the exe tries to use it with STDAPICALLTYPE which I assume stands for __stdcall calling convention.

Regards,

Thanks guys. It's ages since I wrote a DLL. It's all starting to come back to me now!! :wave:

Hmmm.... this still isn't quite right. According to this MSDN article the use of dllimport and dllexport should eliminate the need to specify exported functions in a module definition file (.DEF)

However, in my case, that's not working. I'm finding that I still need to list the functions as EXPORTS in a .DEF file - even though I'm correctly defining __declspec(dllimport) and __declspec(dllexport). Any ideas about what I might be doing wrong?

Quote:

---

Originally Posted by John E

Hmmm.... this still isn't quite right. According to this MSDN article the use of dllimport and dllexport should eliminate the need to specify exported functions in a module definition file (.DEF)

---

Only if you are linking with the export library, in other words, you're using Visual C++ and you add the .lib to your project.

If you're using LoadLibrary() and GetProcAddress(), there is no .lib file to help the linker resolve the name. You must either use the *exact* name you see in the exported function list when you ran Dependency Walker, or you use a def file and rebuild your DLL to get a totally "clean" function name.

Regards,

Paul McKenzie

If you use __declspec(dllexport) you don't need the def file.
In fact, with only a def file you might get into an ambiguous name situation (like it happen to me before), when a class declared a method with the same name of the global exported function. The solution was to use __declspec(dllexport) for the global function.
The problem we suggested you might have was that your function was exported with a C++ decorated name. Thus, you need to use extern "C" before __declspec(dllexport).
Got to go now... :)
Regards,

Quote:

---

Originally Posted by Paul McKenzie

Only if you are linking with the export library, in other words, you're using Visual C++ and you add the .lib to your project.

---

You mean if I link statically, rather than dynamically?

Surely if I link statically, there's no need to mess about with dllimport and dllexport at all??

Paul wasn't talking about static link, he compared dynamic linking with on-demand GetProcAddress() call.

Quote:

---

Originally Posted by John E

Hmmm.... this still isn't quite right. According to this MSDN article the use of dllimport and dllexport should eliminate the need to specify exported functions in a module definition file (.DEF)

However, in my case, that's not working.

---

I don't think that is the case. It is not working because you are doing a GetProcAddress with non-mangled name while using dllexport without using a def file causes name mangling and hence the failure.

The reason it works when you add the .def file with the names is because you are putting the name in unmangled form in it and that is what you are using in GetProcAddress.

So, summary si this:

• if you use dllexport approach without def file, please understand that the Visual C++ compiler mangles the name and this is the form in which your function will be exported. For e.g. your Test function will be exported as , ?Test@XWZ or something of that form. So, if you do a GetProcAddress, make sure you use "?Test@XWZ" and not "Test".
• If you use dllexport, but also supply a .def file with the undeclared names, the linker is gonna put that in the dll export section. So, you can now use GetProcAddress(hMod,"Test")
• If you do use .def file, there is no need to use dllexport directive
• If you do not want to use .def file and still want to use dllexport directive, wrap those functions with
  
  Code:

  ---

  extern "C"
{

}

  ---

Quote:

---

Originally Posted by John E

You mean if I link statically, rather than dynamically?

---

A dll is always dynamically linked. What Paul was referring to was implicit linking versus explicit linking via LoadLibrary/GetprocAddress

Thanks for the help. I did realise that the problem was because of decorated names. What I didn't realise was that I had to link to the lib if I used __declspec(dllexport).... I've managed to get it to work now, without the DEF file :wave:

Quote:

---

Originally Posted by John E

What I didn't realise was that I had to link to the lib if I used __declspec(dllexport)

---

No. using dllexport does not mean you have to link to the .lib file.

Whether you use dllexport or def file, you will always be able to use LoadLibrary/GetProcAddress approach , provided you pass the right export name to GetProcAddress

Oops... one other thing, just before I shoot myself in the foot...!

Ultimately, this DLL will be going to someone who'll be calling it from Visual Basic .NET. This means that my lib file would be useless to them. Therefore, I guess I'm better off sticking to the .DEF approach on this occasion because I don't really want the names to be mangled.

Quote:

---

Originally Posted by kirants

A dll is always dynamically linked. What Paul was referring to was implicit linking versus explicit linking via LoadLibrary/GetprocAddress

---

I think that Microsoft refers to these as "run-time dynamic linking" vs. "load-time dynamic linking". See http://msdn.microsoft.com/library/en..._libraries.asp

Mike