hello everyone,
i wrote my own DLL so i have a fully invokable .lib... that's good.
now i am writing a progam and i want to have this DLL as an extension to the program, so that if the DLL is not present some features are disabled.
now, if i includelib the lib file then the DLL is loaded at startup and if it is not present the program terminates with an error.
my question is: is it possible to load the DLL dynamically (meaning when I decide inside the program) and still be able to use invoke?
blues
i wrote my own DLL so i have a fully invokable .lib... that's good.
now i am writing a progam and i want to have this DLL as an extension to the program, so that if the DLL is not present some features are disabled.
now, if i includelib the lib file then the DLL is loaded at startup and if it is not present the program terminates with an error.
my question is: is it possible to load the DLL dynamically (meaning when I decide inside the program) and still be able to use invoke?
blues
blues4u,
Yes it can be done, there is a macro in the MASM32 macro file called DDPROTO that is designed for that task.
Yes it can be done, there is a macro in the MASM32 macro file called DDPROTO that is designed for that task.
thanks, i'll give it a look!
blues
blues
M$ LINK, from version 6 (MASM32 uses v5.12.8078) has the nice option /DELAYLOAD which takes advantage of the "Delayed Import Address Table" Directory Entry in PE header.
In practical terms, you do not have to change your source code at all, but simply add to LINK command "/DELAYLOAD:yourdll.dll delayimp.lib", where DELAYIMP.LIB is an helper library which comes with MSVC.
I wonder if such a trick can work also with MASM32, replacing LINK.EXE and adding DELAYIMP.LIB...
Regards, bilbo
In practical terms, you do not have to change your source code at all, but simply add to LINK command "/DELAYLOAD:yourdll.dll delayimp.lib", where DELAYIMP.LIB is an helper library which comes with MSVC.
I wonder if such a trick can work also with MASM32, replacing LINK.EXE and adding DELAYIMP.LIB...
Regards, bilbo
Also look at LoadLibrary the win32 api.
It more programatic than MASM centric.
It more programatic than MASM centric.
x bilbo
your comment is very interesting... unfortunately i don't have MSVC, still it would be interesting to try it.
blues
your comment is very interesting... unfortunately i don't have MSVC, still it would be interesting to try it.
blues
As for LINK.EXE (632 K) please google for the free M$ version "VCToolkitSetup.exe" (32 M): it comes with LINK version 7.10...
As for static library DELAYIMP.LIB (only 33K) I can email it to you or, if you give me some time, I can work out a (legal) replacement for it (I am too interested to the matter). In the meantime you could try the new LINK.EXE with MASM32 stuff.
Regards, bilbo
As for static library DELAYIMP.LIB (only 33K) I can email it to you or, if you give me some time, I can work out a (legal) replacement for it (I am too interested to the matter). In the meantime you could try the new LINK.EXE with MASM32 stuff.
Regards, bilbo
Delay-load libraries, while nice, probably aren't the best solution here - you should familiarize yourself with LoadLibrary and GetProcAddress, it's the way to go if you want a flexibly plugin framework.
x f0dder
yes, it was my intention to use LoadLibrary with GetProcAddress, so if LoadLibrary fails i can disable the "extensions".
i was just asking if it is possible thereafter to use invoke thanks to the prototypes or not...
blues
yes, it was my intention to use LoadLibrary with GetProcAddress, so if LoadLibrary fails i can disable the "extensions".
i was just asking if it is possible thereafter to use invoke thanks to the prototypes or not...
blues
in Tasm you could simply do:
----
I read topics like this from time to time, and I'm starting to think that TASM is even better than I thought :lol: It's much more intuitive, and much easier to learn, IMHO ;)
.data
libname?? ? db "bla.dll",0
procname db "coolproc",0
.udata
hMylib? ? ? ?dd ?
myproc? ? ?dd ?
.code
? ? call? ? LoadLibrary, offset libname
? ? call? ? GetProcAddress, eax, offset procname
? ? mov? , eax? ? ;? ?<-- store the address
? ? call? ? eax, 1, 2, 3? ? ? ?;? ?<-- call it with 3 arguments (we still have the pointer in eax)
? ? call? ? , 4, 5, 6;? ?<--call it with 3 arguments (pointer stored in memory)
----
I read topics like this from time to time, and I'm starting to think that TASM is even better than I thought :lol: It's much more intuitive, and much easier to learn, IMHO ;)
i gave a look to the macros in masm32 distribution and DDPROTO seems to do what i need.
i didn't try it yet but i will when i reach that stage in my project.
blues
i didn't try it yet but i will when i reach that stage in my project.
blues
I read topics like this from time to time, and I'm starting to think that TASM is even better than I thought
Too bad this way doesn't have any argument checking, so you can "call eax, 1, 2, 3, 4" and wonder why you get straaaaange results.
subjective matter - i started programming in IDEAL mode and programmed ONLY in IDEAL mode. The only reason i hate C++ is because of argument type checking (and funny stuff like "4-contiguous bytes is something different than LONG and it's something different than HANDLE, and different than HRESULT, etc etc) ;) _I_ know what i am doing, so the compiler doesnt have to play smart :P if something goes wrong - first i check the function parameters, then - the function itself. no type checking is required here :)
Sounds like you haven't worked on any large project, but whatever floats your boat ;)
I can live with or without parameter checks, RadASM will display the parameters for any call I make so it is a bit redundant to have the assembler do it as well. Also it allows me to mix pushes and invoke...
push param3
add D, 5
invoke Function, param1, param2
Ofcourse I could just push all of the parameters instead but I'm lazy :)
push param3
add D, 5
invoke Function, param1, param2
Ofcourse I could just push all of the parameters instead but I'm lazy :)