Emulating DLL

[Ethan]

On Tuesday, 19 March 2019 at 19:50:15 UTC, Craig wrote:
> For example, with windows I could simply compile to a dll then 
> extract the code, or just use LoadLibrary and it effectively 
> does all the work(steps 1 & 2 & 3).

LoadLibrary performs steps 1 and part of step 2. The DllMain 
function of a library is called separately by Windows for each 
thread in your system, which is where the bulk of step 2 is 
handled. Step 3 isn't handled at all by LoadLibrary, and is 
instead entirely up to you to deal with via the GetProcAddress 
function.

If you want DLLs to operate in that step 1-2-3 manner, then the 
compiler can generate a static library that handles that all for 
you. But, as you might expect, that removes the hot reloading 
capability as that is all handled before WinMain is entered.

If you expect hot reloading to work without effort, you're going 
to have to compile your DLLs with -betterC. The D Runtime is not 
yet in a standalone DLL (unless I've missed an announcement over 
the last couple of months). Each DLL you build will require the D 
runtime to be embedded. Things get really tricky from there.

If you ever use your DLL for more than calling functions with 
basic types, or value aggregates (structs) containing basic 
types, then be aware that without -betterC that there is 
potential for the moduleinfo and typeinfo systems to go a bit 
screwy. Especially once druntime lives in its own DLL, as 
druntime expects those systems to be initialised once at startup. 
POSIX libraries will have the same issues, but I have nod had a 
need to investigate further over the last few months.

> LoadLibrary is not portable though and seems excessive to do 
> something that should be rather simple unless there is 
> something I'm missing that has to be done that is complex.

LoadLibrary is the equivalent to dlopen on POSIX systems, with 
one very important difference: Windows does not provide lazy 
symbol evaluation. As such, extra work is required to handle 
that. The average usecase is covered by the mentioned static lib, 
but any hot reloading is handled in a custom manner by every 
Windows codebase you'll encounter.

The static lib I mention, in fact, redirects every cross-DLL call 
to a jump table. And cross-DLL data sharing gets hairy in 
Windows. Function parameters aren't a problem, but Windows 
explicitly disallows thread local variables to cross the DLL 
boundary for example (even if you expose it for export and 
perform a symbol lookup, it won't work and you'll get garbage 
back).

As I said, it's not a simple thing by any means. My work has 
attempted to hide all that complexity by boiling it all down to 
"include these headers/modules, link this lib, and get on with 
life". If you find the resulting code too complex (and I freely 
admit that I haven't got the integration in to as foolproof a 
manner as I am aiming for) then very definitely read through the 
presentations to get a clear idea of why something that should be 
so simple really isn't.