extern(Windows, "user32.dll")

[Vladimir Panteleev via Digitalmars-d]

On Sunday, 1 February 2015 at 11:10:21 UTC, Benjamin Thaut wrote:
> Am 01.02.2015 um 11:45 schrieb Vladimir Panteleev:
>> On Sunday, 1 February 2015 at 10:40:06 UTC, Benjamin Thaut 
>> wrote:
>>> Please no. Import libraries are the way it was designed
>>
>> Delphi does without them just fine.
>
> C++ does with them just fine.

And this is a valid argument, how?

> I don't care what you are suggesting. If you want a 
> implementation of Dll support without import libraries do it 
> yourself.

Nice.

> And lets just say it is required to link against druntime 
> correctly. I don't want to give you a 4 page text explanation 
> why.

So you expect us to just trust you, then?

I also did not say that we should replace all usage of import 
libraries in Druntime.

> I hardly doubt that. If you link against a dll the windows 
> binary loader is just doing the work for you. But the symbols 
> are looked up in the dll by string either way.

I believe this hasn't been true for a few Windows versions now. 
AFAIK static imports are cached by the PE loader.

Either way, a heap allocation during initialization could force a 
rebase.

> Also, proof of concept: http://dpaste.dzfl.pl/efbd54314a69

This is nothing new. Derelict does this. I have it implemented 
myself in my library.

It won't work in DLLs. You can't call LoadLibrary in DllMain. The 
runtime is initialized in DllMain, so static constructors run 
there too. Even if you defer the LoadLibrary call until the 
function is first called, that still leaves you the problem that 
the functions are unusable in static constructors.

It also won't work with TLS (i.e. all D DLLs) except on recent 
Windows versions.

> The real issue here is, that dmd simply does not come with all 
> neccessary import libraries when using optlink. As soon as you 
> switch to the microsoft linkers this becomes a non issue.

It literally *can't* come with *all* necessary import libraries.