Generate import library for exported function of the main executable file about flexdll HOT 5 OPEN

Thanks for posting your experience with this! I have two questions with it, which I haven't looked into the detail. IIRC, generating .def files for the executable is brittle in that the executable can't be renamed - is that still the case? The other issue is data symbols (which we use for OCaml) - does this still only work for functions?

from flexdll.

Thanks for posting your experience with this! I have two questions with it, which I haven't looked into the detail. IIRC, generating .def files for the executable is brittle in that the executable can't be renamed - is that still the case?

You mean if a dll is linked to an exe, for example. b.dll is linked to a.exe (the b.dll will loaded by running a.exe), I can't rename the a.exe to x.exe?

My guess is this is correct, but I haven't tried it.

The other issue is data symbols (which we use for OCaml) - does this still only work for functions?

I haven't tried it, so I can't say whether some data symbol(for example, the global variable) can be shared, I will tried it.
In my test, the C function and C++ function can be exported by exe, and later be called from the dll.

from flexdll.

The renaming part is the "killer" requirement (albeit subtly) for how FlexDLL is used in OCaml. In this case, we need DLLs which can be loaded by any executable (via LoadLibrary) and can access symbols from the main executable, regardless of its name. Before FlexDLL (if I remember correctly - it's a long time ago!) OCaml on Windows put the runtime into a DLL with a fixed name precisely so this could "work".

The Windows loader expects all the symbols in the DLL being loaded to be resolved by import libraries specified in the DLL only - FlexDLL extends that to allow the symbols to come directly from what's already running with the need to specify the import libraries (which makes the behaviour closer to dlopen). You can of course emulate that entirely in code with a registration API - flexlink makes it slightly more efficient by rewriting the code pages with the actual locations (so it removes the pointer indirections, just like the loader does).

from flexdll.

Thanks for posting your experience with this! I have two questions with it, which I haven't looked into the detail. IIRC, generating .def files for the executable is brittle in that the executable can't be renamed - is that still the case?

You mean if a dll is linked to an exe, for example. b.dll is linked to a.exe (the b.dll will loaded by running a.exe), I can't rename the a.exe to x.exe?

My guess is this is correct, but I haven't tried it.

I have just tested it, and I can change the exe file name, and when I run the exe file, the dll file can still be loaded correctly, and it can call the function inside the exe. This means the "rename" feature is OK in my method.

from flexdll.

The other issue is data symbols (which we use for OCaml) - does this still only work for functions?

I haven't tried it, so I can't say whether some data symbol(for example, the global variable) can be shared, I will tried it. In my test, the C function and C++ function can be exported by exe, and later be called from the dll.

I have just tested it. I can correctly export a global variable from the exe, and the dll can access the global variable.

So, I think the exported feature from exe file works correctly for both functions and variables.

from flexdll.