DIP 45 - approval discussion

[Rainer Schuetze]

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-2081b1329cd2@me.com , 
but it seems it is somehow reduced to a single post.