problem in GetProcAddress

I believe the GetProcAddress api only takes an ANSI string.

While msdn indicates it takes an LPCSTR, doing a dumpbin /export of kernel32.dll shows only one export:

413 19C 0001152A GetPrivateProfileStringA
414 19D 0000FE8E GetPrivateProfileStringW
415 19E 0005DE0F GetPrivateProfileStructA
416 19F 000373D8 GetPrivateProfileStructW
417 1A0 00023D7A GetProcAddress
418 1A1 0001FBAD GetProcessAffinityMask
419 1A2 00063E69 GetProcessHandleCount

If it supported ANSI and UNICODE, it would look like the GetPrivateProfileString exports (with A and W appended).

Looking at this further, the problem is the signature of the dll function. You can't return the address of a temporary variable from a function. You need to pass in the buffer of the string and size to the function.

Prototype
DWORD _stdcall LoadStringFromDLL(HINSTANCE hInst, int ids, LPTSTR lpBuffer, DWORD nSize );

HI,
I have posted the exact code what I am using. I have also made a check for failure of LoadLibrary

if((g_LibHandle=LoadLibrary(L"Resource.dll"))==NULL)
{
int x=GetLastError();
MessageBox(NULL,L"LoadLIbrary failed",L"Test",MB_OK);
}

this section is not executing. Initilally I was getting this message when some problem was with dll. But now I am not able to solve it I tried with changed signature also but after that also it is giving error 87 in GetLastError.
I donnot kanow how to proceed further.Please help.
Regards:
Ravi Ranjan

There is no def file in the resource1 project. So, nothing is gonna be exported from it

Attach the DLL you created. Did you check the DLL to see what the exported names are? You're expecting the DLL to have that name, but nowhere did you ever check to see if that exported name really exists. Did you use Dependency Walker (depends.exe) or dumpbin to see what the actual names are that are exported?

The very first thing to do if GetProcAddress returns NULL is to look into the DLL that was created, and not to write or change code -- GetProcAddress() doesn't make mistakes. Once you see what the exported names are (or if they're even there), then you write or change code to handle the problem, and not before.

There is nothing wrong with GetProcAddress() -- the problem is that you don't know what wound up in the DLL as the exported name, so please attach the DLL that you created.

Regards,

Paul McKenzie

Hi,
Mr. Arjay is rigt I have checked the dll with depends.exe and it is showing the same entries as mentioned by Mr. Ajay.

If it is showing this type of output in depends.exe then what I should do.Please guide me.
What ever code I am using is I have allready attached as .zip file.(Usingdll, and Resource1[2])
I am unable to find where I am doing wrong.
Here I am not able to attach the dll as it is of size almost 41KB and tis size is not acceptable trough this site.
Regards:
Ravi Ranjan

Hi,
Mr. Arjay is rigt I have checked the dll with depends.exe and it is showing the same entries as mentioned by Mr. Ajay.Do you know why the names are mangled?

The reason is that for C++ functions, the compiler adds decoration to the name when compiled, since C++ allows functions to be overloaded (same name, different arguments).

Here is a brief explanation:

Since the linker knows nothing about the C++ language, the C++ compiler has to "fool" the linker into believing that for example, "foo(int x)" and "foo(double x)" are two different functions. So the way it does this is to change the name of foo to "foo@whatever1", and "foo@whatever2" (I put the "whatever" there, just for illustrative purposes). Now the linker can do its job correctly, since the linker sees two seperate entries for the "foo" function.

So what ends up in the DLL exports? "foo@whatever1" and "foo@whatever2". So how do you prevent the C++ compiler from mangling the names? You use the "extern "C" modifier:

#ifdef __cplusplus
extern "C" {
#endif
int foo(int x);
double func();
// maybe more functions
#ifdef __cplusplus
}
#endif

So you have to tell the compiler that between the extern "C" and the ending }, the functions declared are not to be mangled. Once you do this, this means that you cannot overload non-mangled names. In other words, those prototypes are now "C" function declarations.

Since they are now "C" function declarations, the names that will show up in the DLL are "foo" and "func" (given that you have a .DEF file also, which you do have), instead of "foo@whatever".

This is all covered in this dev-archive FAQ on building DLL's:

http://www.dev-archive.com/forum/showthread.php?t=231254

Regards,

Paul McKenzie

Actually, as RaviRanjan1774 has mentioned, the WinCE SDK needs a LPCWSTR for GetProcAddress. So, that part of the code is correct.Ahh! :wave:
I mislooked this post! (Unfortunately, RaviRanjan1774 didn't mentioned it in his OP..., and I missed his reply about " VS2005 for PocketPc ")
I am awfully sorry! :blush:

The root cause was that , though you were including the .def file in the project, the linker wasn't instructed to use it. Hence it was being completely ignored leading to no exports. Remove the declspec(dllexport) and things like that, revert to your initial setup, add the .def file to project and make sure you do this:

Go to project properties, linker, Input .
Here in, specify resource1.def in the Module Definition file item. Do a clean build. All should be well.Also be sure to deploy the resource1.dll to the emulator. Otherwise it will use the old dll with the mangling and drive you crazy.