|
|
Comments and Discussions
|
|
 |

|
hi Neil,
we have an .exe that manages several dll. Ours architecture loads dynamically several dlls and also it is possible to exchange instance of class between dlls. We have a problem after Freelibrary() function. It seems that a FreeLibrary() function deletes a memory used by another dll. After FreeLibrary I find corrupted a __vfptr table in a class allocated in the another dll. If I change the order of dlls loading and unloading the problem disappears (But It can't be a solution ).
Could you help me??
Thanks
M.
picm
|
|
|
|

|
Could you teach more about DLL?
I will be wait for:
Kellyc.mara2007@hotmail.com
|
|
|
|

|
Hi
DECLARE_DLL_FUNCTION is declared as
DECLARE_DLL_FUNCTION(ret, cc, func, params)
What means 'cc'?
In your example this is WINAPI but i don't know what WINAPI is?
------------------------------------------
gouranga
JID badzio(at)chrome(dot)pl
------------------------------------------
|
|
|
|

|
Ok, i know
This is 'type' of export (PASCAL, WINAPI etc)
Another question - do u have any wrapper for DLL with class?
------------------------------------------
gouranga
JID badzio(at)chrome(dot)pl
------------------------------------------
|
|
|
|

|
I have a dll that is in itself a program for the pocket pc (windows mobile 2003 SE)
but i want to edit the code
but i cant seem to open it
so do you have any idea how i can conver the file to make i usable?
if you want i can send you the file
thnx in advance for any replies
Ziggy
|
|
|
|

|
If I don't misunderstand the issue, this is a mission impossible.
|
|
|
|

|
Hi Guys , i want one help Regarding OPSEC SDK.
Open Platform for Security SDK is provided by Check point server which contains API's written in C also it contains many header files dlls etc..
I am new to C language and donot know how can i use the functions etc.. in C# with the matching datatypes....
Can anybody help me for writting the warpper class for it
Thanks and Regards,
Nitin.
|
|
|
|
|

|
Hello
Great article, congratulation!!
But, how to calling this dll Class from VB.
Bye.
|
|
|
|

|
This is a class to ease the work of calling DLL functions in C++. This is not a DLL. And nothing related with VB.
|
|
|
|

|
it's a very useful thing .
|
|
|
|

|
I can only agree ... small, but efficient!
|
|
|
|

|
Hello all I tried to wrap some DLL functions of a DLL of mine with DLLModule.h It looked simple and efficient to me but I can't get it working. My VC++ 6 always bails out with the following error message during compile. error C2248: 'Init' : cannot access private member declared in class 'CDLLClass' i:\advancedpipeserver\aps\aps.h(149) : see declaration of 'Init' The definition of my class looks as follows: class CDLLClass : public CDLLModule { DECLARE_DLL_FUNCTION(long, WINAPI, KillProcessByName , (char *) ) DECLARE_DLL_FUNCTION(long, WINAPI, ExistProcessByName, (char *) ) BEGIN_DLL_INIT() INIT_DLL_FUNCTION(long, WINAPI, KillProcessByName , (char *), "fnKillProcessByName") INIT_DLL_FUNCTION(long, WINAPI, ExistProcessByName, (char *), "fnExistProcessByName") END_DLL_INIT() };
The initialisation of the class is done like this: CDLLClass *aps_module; aps_module = new CDLLClass; aps_module->Init("apsdll.dll"); If I comment the "Init" function I can compile and can see the functions wrapped inside the class. -aps_module 0x008249f0 -CDLLModule {...} -__vfptr 0x00429184 const CDLLClass::`vftable' [0] 0x004011a4 CDLLClass::`vector deleting destructor'(unsigned int) [1] 0x00401023 CDLLClass::Init(char const *) -m_hDLL 0x00000000 unused CXX0030: Error: expression cannot be evaluated KillProcessByName 0xcdcdcdcd ExistProcessByName 0xcdcdcdcd
So I can see my functions declared but what looks strange to me is that the function "IsLoaded()" is missing. "Init" and "Destructor" are defined in the "virtual function pointer table" of the class. But to my knowledge, this is only the virtual Init-function from the base class CDLLModule. So far so good but why do I see this strange error message as soon as I uncomment my "aps_module->Init...." line ? It doesn't see or should I say accept the Init-Function produced from the MACROS.
Any idea ? Regards Oliver
|
|
|
|

|
Found solution myself....
I think there is a mistake in the example code of the article or I have some settings wrong which cause my VC++ 6 to bail out during compile. class CMyClass : public CDLLModule { DECLARE_DLL_FUNCTION(int, WINAPI, GetEngine, (char *, char *)) DECLARE_DLL_FUNCTION(int, WINAPI, StartEngine, (HWND)) . . . The "public:" is missing in the class: class CMyClass : public CDLLModule { public: <== Missing in Example Code !!! DECLARE_DLL_FUNCTION(int, WINAPI, GetEngine, (char *, char *)) DECLARE_DLL_FUNCTION(int, WINAPI, StartEngine, (HWND)) . . .
Regards, Oliver
|
|
|
|

|
You missed the "public:" in your class. That's all.
|
|
|
|

|
Hi,
I am trying to use this technique. Can anybody show me how to use this for a function that takes no arguements.
Thanks...
-Nikhil
|
|
|
|

|
Just leave blank at where arguments supposed to be. But don't forget the parenthesis.
|
|
|
|
|

|
I suppose also I forgot to use _T() macro in GetProcAddress( m_hDLL, #function_name ); to be able to compile it in UNICODE...
--
Best Regards,
Andrew
|
|
|
|

|
I have written a small game engine for strategy games. I just realised that I now want to convert my engine into a DLL which can be loaded in by other programmers in my group which will help them to access my functions dynamically.
My game engine is written in VC++ using DirectX..
Plz advice.
Srinivasan Veeraraghavan
Game Programmer
srinivasan@indiagames.com
|
|
|
|

|
A regular dll may work. And this wrapper will help them to ease the usage of your dll. Another way is to write a com object, it may be a better way in some situations.
|
|
|
|

|
> A regular dll may work.
Yes, there are two choices actually: Win32 API's approach or exporting C++ classes. Both are easy to implement while the second seems to be more elegant.
> Another way is to write a com object...
This may result in degraded performance, especially if you need to create many small objects or use the objects cross-appartment (from multiple threads). I suppose it is critical for a game engine.
--
Best Regards,
Andrew
|
|
|
|

|
Hi,
Any one know how to get the .h file from .lib file ?
Thanks
|
|
|
|

|
This is a great way of handling the plug-in code. I do have one problem. I get the following error: <snip...> "the value of ESP was not properly saved across a function call." <snip...> I understand the error (and no, removing the /GZ will only HIDE the error), but I can't seem to figure out what's different in the call. Here's my (simplified) DLL func: extern "C" _declspec(dllexport) int StartEngine(HWND hWnd) { return 1; }
|
|
|
|

|
Nevermind. My fault. I've added "__stdcall" and exported the functions via the .def file. Nothing a little late night coding with a beer can't solve. - Jack -
|
|
|
|
|

|
should be, but not tested
|
|
|
|

|
I have implement a standard MFC dll and I have export a function pInit(void)
but when I would like use this dll.
My derived class CPlugin don't work load the dll
could someone help me please!
|
|
|
|

|
this wrapper only work with regular dll
|
|
|
|

|
what a shame wher could I found a similar wrapper class??
|
|
|
|

|
Hello YAO,
how should I declare the things, if the return value
of the dll function is an unsigned int*?
Thanks for you help
juergen
|
|
|
|

|
I have not tried, but I guess you can simply use "unsigned int*" as the corresponding argument, or enclosed with a parentheses if not work
|
|
|
|

|
Hi, everyone, How to load a MFC dll, which itself uses _declspec( dllexport ) type function export from another dll, with using LoadLibrary()? When I use LoadLibrary() to load the dll it always return to me a NULL. If I comment out the function call to the _declspec( dllexport ) type of function, then LOadLibrary will successfully load the dll. How can I solve this problem? If I use WINAPI to replace the _declspec(dllexport), the compiler will complain me extern function is not resolved. Thanks in advance.
|
|
|
|

|
You can investigate possibilty of DELAYLOAD linker switch...
When you have bunch of possible .DLLs, but only one should be loaded during runtime => here is an alternative and very elegant solution:
Suppose you have A.DLL, B.DLL, C.DLL and during runtime you will load only one of it, based on some interpretation...
So, during build create X.DLL that has all common methods of A,B and C that you want to EXPORT...
Now, use X.LIB to link with your executable...
In you exicutable before calling any of X Exported functions, and after what DLL (A,B or C) should be loaded copy one of A, B or C into X.DLL...
Sure, you have to link with DELAYLOAD:X.DLL...
|
|
|
|

|
Oops, again are we reinventing the wheel? ... thanks, I think this article now is outdated and this solution using DELAYLOAD need be remarked.
|
|
|
|
|

|
Does anyone know how to link a dll using Developer Studo/ C++.NET by using a .lib file during the link step? Sometimes vs 7.0 allows specification of command line options for the linker and sometimes it doesn't. It seems to depend of the project.
|
|
|
|

|
Arbesto Pelta wrote:
I think this article now is outdated and this solution using DELAYLOAD need be remarked.
Alternative solutions are worth noting, but the article isn't outdated.
What about loading DLLs whose name isn't even known at compile time?
That's what plug-ins are...
Regards.
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
|
|
|
|

|
Yes Philippe, you are right: IMHO the solution offered in the article is not outdated, it is a good solution, a linker independent solution and a more controlled solution than the linker v6.0 offered. Personally I like the solution and I am going to use it.
But I think that the article is outdated because actually the linker offer a direct solution that I suspect the author didnt know when he wrote it (I dont knew the linker solution not even the author solution before read them). It is an easy solution that would be remarked. The linker solution was pointed in a thread response, ok, but I think this solution deserve to appear in a more remarked position.
I think that maybe the author must to have the righ to modify his article introduction, that's all.
And again you are right, the author solution is very useful when you need to use a dll whose name isn't even knwon at compile time. However (I am not sure but...) the /DELAYLOAD solution seem to solve this situation too, developing your own helper function.
I think that the author solution has another notable virtue: it is a solution with a very low overhead, there is not hidden hooks or callbacks, only a function pointer, thats all. The programmer can add his own call controls when he need. For example, if you need to call a dll function repeatedly in a exhaustive for loop then maybe you prefer to check (one time) that the dll and function pointer are ok before going to do the for loop instead of check it before every time you want to call it.
Thanks a lot
Arbesto
|
|
|
|

|
Philippe, with all due respect -- I really confused trying to understand you:
>>
What about loading DLLs whose name isn't even known at compile time?
<<
I thought, that's the purpose of the article as well as proposed DELAYLOAD approach... Name of DLL may not be known -- however entrypoints should be defined... That's sure what plug-ins are...
So, please, clarify, what exactly did you mean???...
|
|
|
|

|
Perhaps I am not familar enough with the DELAYLOAD mechanism.
For me, you specify the DLL to be used at link time (thus giving its name), but the DLL is loaded only when needed.
From a quick glance at MSDN, it seems that's the "regular" way of doing things, perhaps there are some smart workarounds for this limitation.
So, you have to specify all the DLLs that have to be loaded by the program, at link time.
Plug-ins are, by definition, written after the release of the program, so they are loaded by the program when giving their names by initialization data (good old INI files or equivalents, registry, environment, you name it).
If there is a way to use DELAYLOAD with unknown DLLs, I will be curious to know.
Mmm, I reread your second message... I understand it better than yesterday, I think. You mean that you specify /delayload:x.dll, but on the callback, you load another library instead, and the delayload mechanism loads the preset functions of the given DLL instead.
Well, you still have to do a LoadLibrary, you just avoid the GetProcAddress. It seems to be a bit convoluted a solution to this simple problem. DELAYLOAD is useful when there are a lot of functions to load, but plug-ins often have only a few exposed functions, so it seems a bit of an overkill. Not all tools are suited for all purposes.
Regards.
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
|
|
|
|

|
Philippe, I almost regreat that I've started that discussion...
Sure, if you consider that "you still have to do a LoadLibrary, you just avoid the GetProcAddress. It seems to be a bit convoluted a solution to this simple problem." So, if you consider "convoluted solution" direct function call, compared to pointer to function call -- really there is nothing to talk about here... Not to mention necessary duplicate function declarations...
That's really nothing I could say...
GL
I
|
|
|
|

|
Don't regret anything, and don't take it personnaly.
We just exchange ideas, and express our opinions. There not such a thing as "the right method".
This discussion may be useful for those pondering which method to use, as we expose advantages and inconvenients of both.
The choice is then left to those implementing the solutions.
Direct function call vs. pointer function call.
I use the following method:
typedef char * (*STR_F_t)();
STR_F_t GetString;
GetString = (STR_F_t)GetProcAddress(g_hInstDllLib, "GetString");
This way, whether I choose to link the DLL or load it dynamically, I call the functions the same way.
Duplicate function declarations.
I agree, it adds quite some overhead/work. One can automate the generation of such declarations, but it is still a hassle to create and maintain.
But for plug-ins, as I said, the number of functions is quite low, so it may not be critical.
Last note: I know that 95% (wild guess ) of CP readers use Visual Studio 6 or .NET, but for those with lower version (?) or users of alternate compilers (Borland, gcc, Mars, etc.), the traditional method still works.
Regards.
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
|
|
|
|

|
OK, Philippe -- As I said DELAYLOAD has some advantages and some disadvantages -- nothing is for free in that world...
I also, never argued against article proposition, even more I'm using close to that Article approach for about 10 years now...
However, I would like to see -- how would you approach the task of Dynamically loading MFC Exported Class for example...
Would love to see your manually created file with hundreds of mengled typedefs and GetProcAddresses...
GL
I
|
|
|
|

|
Anonymous wrote:
never argued against article proposition
I never said that, it is Arbesto that was a bit over enthousiastic and stated that the article was outdated.
Anonymous wrote:
how would you approach the task of Dynamically loading MFC Exported Class for example
Actually, I don't do MFC, unless required by my employer But I see your point, depending on the need, one tool is better suited that other. Although if you mean to load MFC42.dll, for example, a hardcoded binding seems more suitable, since the program need it inconditionnaly.
I you mean to load a MFC-based class, like those given on CP, I probably choose DELAYLOAD, or at worse, as I said, I would generate the binding with a script.
Thank you for this interesting discussion, I hope it will give some hindsight to readers. At least, I will sure consider using DELAYLOAD now
Regards.
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/
|
|
|
|

|
Philippe Lhoste wrote:
Anonymous wrote:
never argued against article proposition
I never said that, it is Arbesto that was a bit over enthousiastic and stated that the article was outdated.
I am sorry if my first email has supposed any kind of discussion and misinterpretation for the opinions manifested by others.
I explained why I consider the article was outdated, maybe it was a problem with my dictionary What about "the article has an old introduction"?. I say this because I think that is a pity that the DELAYLOAD solution will be relegated to the messages zone instead of figure in the article introduction, that was all.
My apologizes again,
Arbesto
|
|
|
|

|
Arbesto Pelta wrote:
maybe it was a problem with my dictionary
Or maybe mine
I saw "outdated" and interpreted "obsolete"...
But you are right, the subject deserves a full article comparing the various methods to bind a DLL.
Regards.
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/ |
|
|
|
|

|
I cant answer your question but I have some comments on your article.
I really cant find the advantage of using the macros. Wouldn´t it be better to make a function instead of the macro. Then could also be the testing and error checking implemented.
Try this @ home. (B&B)
|
|
|
|

|
The thread below about the suitability of using COM instead of this simple approach reminds me of the hype that SOAP is being given these days. Many folks suggest everyone to switch to SOAP in every occasion instead of resorting to good old GETs and POSTs with some custom return format, without a second thought on the burden imposed by this huge technology, both in terms of efficiency and complexity of development. In many situations, what could have been dealt with in a couple of hours worth of coding becomes a major nightmare, just for the sake of the promised flexibilty SOAP is supposed to bring along. Sure SOAP can be great for middle to large projects, but most of the time it adds next to nothing to a simpler approach.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
 |
|
|
General News Suggestion Question Bug Answer Joke Rant Admin
Make using of dll functions much easy
| Type | Article |
| Licence | |
| First Posted | 25 Jun 2002 |
| Views | 241,839 |
| Bookmarked | 75 times |
|
|
|