Hey guys,
Well I finished coding my dll, and I wanted to communicate with it, using my .exe... I know between processess you can use pipes but I'm kinda lost right know, can you use pipes between Dll's and exe's? Or is there a better way of doing it?
Thanks
LoadLibrary
GetProcAddress
FreeLibrary
one way...or
Use the .lib created from your DLL and just use the functions prototypes in your exe and link it
* PC: Intel Core 2 DUO E6550 @ 2.33 GHz with 2 GB RAM: Archlinux-i686 with xfce4.
* Laptop: Intel Core 2 DUO T6600 @ 2.20 GHz with 4 GB RAM: Archlinux-x86-64 with xfce4.
Yeah well I forgot to mention, that I inject the DLL onto a process and then I want to communicate with it. I believe the 2nd option would work, but I just found out that you can use pipes also.
wouldn't #2 imply static linking, pretty much rendering the 'D' part of your DLL pointless...
No. The DLL is still a separate file that can be shared between processes, easily replaced without affecting other parts of your application, and so on.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
no, you statically link to the LIB import library that is generated for the DLL, then you can just call the functions form your application directly adn teh LIB handles all the loading adn linking functionality. You can still update the DLL at any time without breaking the application, so long as you dont remove any of the functions it uses.Originally Posted by @nthony
Is the code for the above DLL linking generated at compile time? So if you stat-link foo.lib and call foo(x), will the foo(x) call then be replaced with:
in the compiled object file? or does the LIB actually need to be present alongside the binary to perform the above steps on demand, whenever you run it?Code:LoadLibrary(foo.dll) GetProcAddress(foo(x)) FreeLibrary(foo.dll)
If it is the former case, then why do people even bother using manual library loading for DLLs they create, when it could be done automatically for them just by using a static lib for that DLL?
Actually, linking against the static library means that the DLL will be added in the dependencies section of the executable, and thus the loader will load it. No explicit LoadLibrary call anywhere. No GetProcAddress either - the loader does that, too. And of course the FreeLibrary is resolved.
So not only is using the LIB more convenient, it typically is faster, too. Less indirection. But the LIB doesn't need to be present after you've compiled the whole thing.
So why do people manually load libraries? There are a few reasons.
1) They want to discover libraries at run time. This is typically done for plug-in systems.
2) They don't have a LIB. That happens, too.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Hey thanks, I think I understand now. I was confusing "dynamic-linking" with its subset "run-time linking". Although I've read the Wiki: DLL page many times before in the past, reading it again in light of what you said seemed to bring out that finer point that I seemed to have been overlooking before... you learn something new everytime.
