Exporting objects from exe and importing them on DLL. Is it normal?

[Fadey]

Hello everyone!

I discovered it to be unusual and found
very little information about on the internet.
On visual studio, when we export an object

__declspec(dllexport)

Then exe will be compiled along with the lib. Thought to myself, if I have a lib of my exe and would load an dynamic library (dll) then in it, I should
be able to use exe's exported functions and other objects.
This is correct. In fact it worked exactly like I would expect it to work in
visual studio 2017.


First question comes why do everyone recommend using an exe as a simple way to launch that very first function on dll and use that dll to export/import objects rather than the exe?

It would basically leave an exe the size of a 40kb and dll with few mb, exe purpose seems very little to exist in a first place.


Second question and the reason why we're in General,
how to do same in linux, if we should?

Instead of having .lib file, we link the .so (linux equivalent of .dll) when creating executable file what uses the dynamic library.
What do I do when I want that dynamic library to use executable's exported objects?

Thank you!

[helios]

Then exe will be compiled along with the lib. Thought to myself, if I have a lib of my exe and would load an dynamic library (dll) then in it, I should
be able to use exe's exported functions and other objects.

Yes, this can be done, but aren't you then tightly coupling your DLL to your EXE? Your EXE requires the DLL to work, right? And the DLL requires your EXE to work, right? If that's the case, then what's the point of putting them in separate modules? Why not just put all the functions in the EXE?

Instead of having .lib file, we link the .so (linux equivalent of .dll) when creating executable file what uses the dynamic library.

No, if using import-based dynamic-linking, you link to a .a file, which contains the code to link to the .so when the program runs. If using purely dynamic linking, you call dlopen(), which is analogous to LoadLibrary().

[Fadey]

then what's the point of putting them in separate modules? Why not just put all the functions in the EXE?

To leave a possibility for modding later on (by other perhaps).
When building something like this:
.......(EXE)
............I
........(DLL) <--- main DLL
......../......\
.(DLL)......(DLL) <--- Mods
Mods importing main DLL's objects while main dll is importing only few from mods.
This is how I've seen it mostly been recommended but why? Why can't that main DLL
be EXE if it .. can?

No, if using import-based dynamic-linking, you link to a .a file, which contains the code to link to the .so when the program runs. If using purely dynamic linking, you call dlopen(), which is analogous to LoadLibrary().

To be completely honest then I've never done dynamic libraries in linux. Haven't gotten that far however this guy in this video doesn't seem to link .a files:
https://www.youtube.com/watch?v=nnP81fMdWcg

[helios]

I'm not a Linux expert by any means, but as far as I know the way that guy is doing it is not the canonical method, so to speak. I'm not saying it's *wrong* to pass the SO to the linker, just that it's unusual.

Alright, as part of a plugin system the way you're doing it makes sense and is fairly common. Are you using GetProcAddress() or is the plugin DLL linking to the .lib produced from the main executable? Linking to the .lib saves you the hassle of having to manually obtain pointers to symbols in the executable.
Be careful if you're passing around objects across DLL boundaries. Separate modules maintain separate CRTs and separate heaps, so it's unsafe to release in one module an object that was allocated by a different module.

I couldn't tell you why those people recommended the alternative linking method. I would need to see what they said exactly, in the context that they said it.

[jonnin]

One reason to put things in libraries instead of a monolithic executable is for updates. Its easier (on the server sending out if nothing else) to send one small library or a small executable than one huge executable, for very large programs. They are still tightly coupled, but even so, it could be that 2 similar programs share the code (think, game engine and game client share it, maybe, as an example of this, even if its not really very generic or generally re-usable).

Could be something else too, like another language. I had a project where we bought and used 1 copy of visual fortran just to wrap a LOT of high quality code into a dll to use with C++, which involved passing an 'object' to and from the library. We may have been able to link the object files into one, but it felt like a dll was safer (the fortan changed, slowly, but there were occasional updates).

The above may not apply to your code, but I am giving a few examples of why you might see weird use of the library concepts. One usually thinks of a library as reusable code that belongs together, but from time to time a library is used for other things, and the above are just a couple of examples of doing that.