GetProcAddress
Author
I''ve created a simple dll and tried to load it during runtime. When I called GetProcAddress(...) I get the return error as "proc not found" even though I''ve check the name in supplied to the parameter very carefully. Does anyone mind looking at my codes?
Author
Please go to www.digitalextent.com/public/ and get the Win32App.zip and tester.zip files. The Win32App should be compiled as a DLL Project. Tester is the project used to test the dll file. Thanks for you help.
quote:Original post by vbisme
Please go to www.digitalextent.com/public/ and get the Win32App.zip and tester.zip files. The Win32App should be compiled as a DLL Project. Tester is the project used to test the dll file. Thanks for you help.
If you post the code here, between [ source ] and [ /source ] tags (without the spaces) you''ll get much more response. Quick question: have you specified these functions for exporting, and given them the proper calling convention, such that the names are not mangled?
Don''t listen to me. I''ve had too much coffee.
Welcome to the wonderful world of "name mangling".
DLLs and the calls like GetProcAddress() were in Windows before the days when anyone used C++. So DLLs and GetProcAddress() was intended for C functions.
In C, only one function in a piece of code can have a particular name, e.g. CreateWin32App().
In C++, multiple functions can have the same name (i.e. polymorphism) e.g.:
CreateWin32App( int anInt );
CreateWin32App( string aString );
So if a program can have 2 functions of the same name, it''s feasible that you may want to expose BOTH functions in your DLL.
And given that Windows, and GetProcAddress in particular are from the C days, there isn''t a direct way of doing this.
Enter "name mangling". You CAN have both functions exported from the DLL if their names differ somehow, so with name mangling, the compiler adds some extra ASCII characters to the name of what you export to specify the calling convention (stdcall etc) AND the number and type of parameters the function takes.
The way in which the names get mangled can differ from compiler to compiler and even between compiler versions.
If you run Dependency Walker (comes with MSVC) and load up your DLL, you can see what the *REAL* exported names for your DLL are. In particular, the name for "CreateWin32App" has been mangled into:
"?CreateWin32App@@YAPAVWin32App@@XZ"
The ?, @@''s YAPAVWin32App and XZ are part of the mangling which would be required if you were making the most of polymorphism and namespaces etc. If you put the above string into your GetProcAddress() call, then the program would work.
But you''re not using polymorphism etc for that function, so the best thing to do is to force the symbol which gets exported to NOT be mangled/decorated.
Two common ways to do this:
1) Persuade the compiler that the function you''re exporting from the DLL is actually C so that it doesn''t mangle it.
In Win32App.h, change:
WIN32APP_DLL Win32App * CreateWin32App(void);
to
extern "C" WIN32APP_DLL Win32App * CreateWin32App(void);
And rebuild the DLL.
2) Add a .DEF file to the DLL project to specify how you want the exported functions to be named. Check MSDN for details.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
DLLs and the calls like GetProcAddress() were in Windows before the days when anyone used C++. So DLLs and GetProcAddress() was intended for C functions.
In C, only one function in a piece of code can have a particular name, e.g. CreateWin32App().
In C++, multiple functions can have the same name (i.e. polymorphism) e.g.:
CreateWin32App( int anInt );
CreateWin32App( string aString );
So if a program can have 2 functions of the same name, it''s feasible that you may want to expose BOTH functions in your DLL.
And given that Windows, and GetProcAddress in particular are from the C days, there isn''t a direct way of doing this.
Enter "name mangling". You CAN have both functions exported from the DLL if their names differ somehow, so with name mangling, the compiler adds some extra ASCII characters to the name of what you export to specify the calling convention (stdcall etc) AND the number and type of parameters the function takes.
The way in which the names get mangled can differ from compiler to compiler and even between compiler versions.
If you run Dependency Walker (comes with MSVC) and load up your DLL, you can see what the *REAL* exported names for your DLL are. In particular, the name for "CreateWin32App" has been mangled into:
"?CreateWin32App@@YAPAVWin32App@@XZ"
The ?, @@''s YAPAVWin32App and XZ are part of the mangling which would be required if you were making the most of polymorphism and namespaces etc. If you put the above string into your GetProcAddress() call, then the program would work.
But you''re not using polymorphism etc for that function, so the best thing to do is to force the symbol which gets exported to NOT be mangled/decorated.
Two common ways to do this:
1) Persuade the compiler that the function you''re exporting from the DLL is actually C so that it doesn''t mangle it.
In Win32App.h, change:
WIN32APP_DLL Win32App * CreateWin32App(void);
to
extern "C" WIN32APP_DLL Win32App * CreateWin32App(void);
And rebuild the DLL.
2) Add a .DEF file to the DLL project to specify how you want the exported functions to be named. Check MSDN for details.
--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com
Author
Thanks a lot for the help.
Is it ok to mix .def files with __declspec(export) in the same project?
[edited by - vbisme on September 11, 2002 3:55:16 PM]
Is it ok to mix .def files with __declspec(export) in the same project?
[edited by - vbisme on September 11, 2002 3:55:16 PM]
Author
Um, one other problem, if you have already looked at the codes, I can''t call class functions. Even if I export them using the .def file.
I''ve uploaded the projects with changes on the site www.digitalextent.com/public
I''m sorry for not posting the codes here. I think it needs to be viewed in project forms. Thanks for the help.
I''ve uploaded the projects with changes on the site www.digitalextent.com/public
I''m sorry for not posting the codes here. I think it needs to be viewed in project forms. Thanks for the help.
you dont export the class functions, you export the whole class, and create and instance of that class in your code.
HOWEVER I''m pretty certain that if you are doing runtime linking this system wont work, which is where COM comes in I belive, as you will need to use access functions to interact with teh classes inside the DLL.
However, as I''ve not tried runtime linking a class in a DLL I could be wrong, but from what I''ve read on the subject I belive I''m right, I dare say someone will correct me if I''m not
HOWEVER I''m pretty certain that if you are doing runtime linking this system wont work, which is where COM comes in I belive, as you will need to use access functions to interact with teh classes inside the DLL.
However, as I''ve not tried runtime linking a class in a DLL I could be wrong, but from what I''ve read on the subject I belive I''m right, I dare say someone will correct me if I''m not
Before you can export them, you have to declare them as static, which causes other problems.
You could create a wrapper funtion that calls a funtion in a globally created object...if you don''t feel like exporting the class
You could create a wrapper funtion that calls a funtion in a globally created object...if you don''t feel like exporting the class
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
