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
Posted on 2005-06-07 04:58:20 by blues4u
blues4u,

Yes it can be done, there is a macro in the MASM32 macro file called DDPROTO that is designed for that task.
Posted on 2005-06-07 07:31:18 by hutch--
thanks, i'll give it a look!

blues
Posted on 2005-06-07 07:49:40 by blues4u
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
Posted on 2005-06-07 11:04:31 by bilbo
Also look at LoadLibrary the win32 api.
It more programatic than MASM centric.
Posted on 2005-06-07 16:10:57 by James_Ladd
x bilbo
your comment is very interesting... unfortunately i don't have MSVC, still it would be interesting to try it.

blues
Posted on 2005-06-08 06:47:50 by blues4u
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
Posted on 2005-06-08 10:23:18 by 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.
Posted on 2005-06-08 18:23:03 by f0dder
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
Posted on 2005-06-09 03:22:09 by blues4u
in Tasm you could simply do:

.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 ;)
Posted on 2005-06-09 08:40:35 by ti_mo_n
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
Posted on 2005-06-09 09:18:32 by blues4u

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.
Posted on 2005-06-10 09:23:17 by f0dder
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 :)
Posted on 2005-06-12 11:56:26 by ti_mo_n
Sounds like you haven't worked on any large project, but whatever floats your boat ;)
Posted on 2005-06-12 12:02:22 by f0dder
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 :)
Posted on 2005-06-12 12:13:35 by donkey