On 02.12.2013 05:59, Manu wrote:
Just a comment on other aspects of this thread... There's all this debate around dllimport vs dllexport. And this is probably my ignorance, but I have to wonder why dllimport even exists? I've been using DLL's for a long time, and I've never used dllimport (that I'm aware of). I either statically link an import lib (which binds to the exports in a nice efficient way), or I call LoadLibrary and find symbols manually... I'm not really even sure what dllimport does. Why is it so important, and why is it causing so much fuss?
For function imports, not using dllimport magically works, but adding it to the declaration can avoid one jump when calling the imported function.
Imports to data variables don't have that magic, it can either be accessed directly, or it has to be accessed by an indirection through the import table. The dllimport specifies which code has to be generated.
I actually have an implementation, that patches the data accesses as a secondary relocation step, circumventing the indirection through the import table. Unfortunately it does not work on 64-bit. The problem here is that dmd generated code only uses 32-bit relative addressing, but that disallows accessing data in another shared library directly.
The respective discussion where this approach was rejected by Walter is supposed to be here: http://forum.dlang.org/thread/8bd42b4e-8c3b-42a6-9f00-2081b1329...@me.com , but it seems it is somehow reduced to a single post.
