problem retrieving own created DLL procedure address

[Mitsukai]

i have to solve this prooblem now before i can solve my other problem..

so here it is:

		this->hModule = ::LoadLibrary(sModule);
		if(!this->hModule)
			return false;
		this->pCreate = (bool(*)(HWND))::GetProcAddress(this->hModule, "Create");
		if(!pCreate)
			return false; // we returned false here
		this->pDestroy = (void(*)())::GetProcAddress(this->hModule, "Destroy");
		if(!pDestroy)
			return false;
		this->pMove = (void(*)(int, int, int, int))::GetProcAddress(this->hModule, "Move");
		if(!pMove)
			return false;
		if(!this->pCreate(this->Handle()))
			return false;
		return true;

my code cannot retrieve the function Create from my DLL.
the dll is:

#ifdef BUILD_DLL
    #define DLL_EXPORT __declspec(dllexport)
#else
    #define DLL_EXPORT __declspec(dllimport)
#endif

bool DLL_EXPORT Create(HWND hParent);
void DLL_EXPORT Destroy();
void DLL_EXPORT Move(int iX, int iY, int iW, int iH);

#include "CView.hpp"

#include "main.hpp"

	CAppView AppView;

	bool Create(HWND hParent)
	{
		return AppView.Create(hParent);
	}

	void Destroy()
	{
		AppView.Destroy();
	}

	void Move(int iX, int iY, int iW, int iH)
	{
		AppView.Move(iX, iY, iW, iH);
	}

i think i did something wrong. i checked if BUILD_DLL is defined. i checked if i loaded the right module. both are true. so i dont understand why i cannot retrieve the procedure adress of Create. i will try some EXPORT TABLE viewer to check some things.

i checked with export viewer:

_Z6CreateP6HWND__ (Ordinal: 2, Entry Point RVA: 12f4h (4,852))

so i still dont know why it fails to retrieve

[Paul McKenzie]

so i dont understand why i cannot retrieve the procedure adress of Create. i will try some EXPORT TABLE viewer to check some things.

That "EXPORT TABLE" viewer is called Dependency Walker (depends.exe).

Second, none of that code creates an exported name called "Create". Please see the FAQ here:

http://www.codeguru.com/forum/showthread.php?t=231254

You are missing the last and vital step -- creation of a module definition file.

Regards,

Paul McKenzie

[Paul McKenzie]

i checked with export viewer:

_Z6CreateP6HWND__ (Ordinal: 2, Entry Point RVA: 12f4h (4,852))

Please use Dependency Walker, as it is graphical and displays the actual exported name.

So i still dont know why it fails to retrieve

So where in this do you just see the name "Create"? I don't see it, and neither did GetProcAddress(). I see a "_Z6CreateP6HWND__ ", but that isn't "Create".

The way that GetProcAddress() works is that the name you give it must match exactly with the exported name. This means it must match by case, characters, and number of characters.

In other words, if you tell GetProcAddress(whatever, "Create"), then GetProcAddress() will look for "Create" -- not "CreateXYZ", not "Create@whatever", and certainly not "_Z6CreateP6HWND__ ".

Regards,

Paul McKenzie

[Mitsukai]

i use anywhere pe viewer.

i tried _Z6CreateP6HWND__ and it worked...

i understand what that faq is saying its very clear. except im not using VC++ im using mingw. and the dll already comes with a .DEF and .A file.
i will try making __stdcall and see if it will fix this...

well all that didnt any good except fix the way the function is called internally ofcors, i dont know any GCC commandlines

[Paul McKenzie]

i understand what that faq is saying its very clear. except im not using VC++ im using mingw. and the dll already comes with a .DEF

The DEF file is supposed to be used when building the DLL, i.e. it's supposed to be part of the project build.

If the DEF file is not part of the build process, the DLL will build successfully, but with cryptic exported names. Are you sure that the DEF file is being used when building the DLL? Is it added to the project build settings in whatever IDE you're using? What does this DEF file look like?

If the DLL doesn't have the name as just "Create" in the exported function names, then something is incorrect or wrong in your building of this DLL.

i will try making __stdcall and see if it will fix this...

I doubt that will do anything. All that does is make sure that the parameters are pushed on the stack in a certain order, and that the function being called is responsible for restoring the stack on return.

Regards,

Paul McKenzie

[Mitsukai]

it looks like this:

EXPORTS
    _Z4Moveiiii@16 @1
    _Z6CreateP6HWND__@4 @2
    _Z7Destroyv@0 @3

also im using codeblocks....

here is the automated commandline...

mingw32-g++.exe -pedantic -DBUILD_DLL -D_WIN32_IE=0x0300  -O3 -c main.cpp -o Release\main.o
mingw32-g++.exe -pedantic -DBUILD_DLL -D_WIN32_IE=0x0300  -O3  -c CView.cpp -o Release\CView.o
mingw32-g++.exe -shared -Wl,--output-def=Release\libstmapps.def -Wl,--out-implib=Release\libstmapps.a -Wl,--dll  Release\main.o Release\CView.o   -o Release\stmapps.dll -s  -luser32 -lcomctl32

[Paul McKenzie]

it looks like this:

EXPORTS
    _Z4Moveiiii@16 @1
    _Z6CreateP6HWND__@4 @2
    _Z7Destroyv@0 @3

Then that is the problem. What did you expect to happen using a DEF file like that? This is what I would have expected (and is clearly stated in the FAQ).

EXPORTS
    Move @1
    Create @2
    Destroy @3

I don't know how GCC does things, but I bet that the DEF file you did have was made so that programs built with GCC can link implicitly with the DLL that is built.

However, GetProcAddress() and LoadLibrary() do not work this way. These functions know nothing about what compiler or language was used to create the DLL. They are "dumb" in the sense that whatever name shows up in the export table, that's the only name it knows and uses. Therefore that name better be "clean" and not have junk characters surrounding it.

Regards,

Paul McKenzie

[Mitsukai]

i tried editing the .def file but its generating an automated def file overwriting...

i will have to look into GCC parameters...

[Arjay]

As Paul said, the def file needs to look like:

EXPORTS
    Move @1
    Create @2
    Destroy @3

[Zaccheus]

If I may suggest something:

#ifdef BUILD_DLL
    #define DLL_EXPORT __declspec(dllexport)
#else
    #define DLL_EXPORT __declspec(dllimport)
#endif


extern "C"
{

bool DLL_EXPORT WINAPI Create(HWND hParent);
void DLL_EXPORT WINAPI Destroy();
void DLL_EXPORT WINAPI Move(int iX, int iY, int iW, int iH);

}

That should export the Create function as _Create@4, such that you can then write: ::GetProcAddress(this->hModule, "_Create@4") even without using the DEF file. The @4 just specifies that the function takes 4 bytes as its parameters (in this case the HWND).

WINAPI is #define-d as __stdcall and tells the compiler that your function should be called in the same way as other Windows API functions are.

[Mitsukai]

i did extern C and now dey produce Create@4. i tried the command line --kill-at which is suposed to kill the @n but its not working.

[Paul McKenzie]

i did extern C and now dey produce Create@4. i tried the command line --kill-at which is suposed to kill the @n but its not working.

Really, you have to get the compiler to use your DEF file and not produce one itself.

It would be shocking to believe that there is no way to turn the autogeneration off, as DEF files were designed to be put together "by hand", not generated automatically.

Regards,

Paul McKenzie

[Mitsukai]

its that codeblocks manages the commandlines mostly i cant change it or i must make a makefile and i dont wanna do dat. for now Create@4 etc. is just fine