extern(Windows, "user32.dll")

[Benjamin Thaut via Digitalmars-d]

>
>> 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?

No, you just need to wait like everyone else until I do the PR for dmd / 
druntime / phobos for a full explanation. If you don't want to wait 
until then just read the source code: 
https://github.com/Ingrater/dmd/tree/DllSupport

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

Sorry, I did jump over the "not" in :

 > Why? I'm not suggesting to remove import library support.

> 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.

Thats why its called a proof of concept, it doesn't mean its perfect ;-)

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

But the TLS issues are going to remain no matter if the dll is loaded 
via LoadLibrary or not. Also there are TLS fixes in core.sys.windows.dll 
for Windows XP. And we officially don't support anything before XP.

>
>> 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.

But still, adding a feature for the sole purpose to link against Windows 
System Dlls is just overkill.

But feel free to go ahead and try getting it past Andrei and Walter. 
Just don't expect my support. Recently even the int[$] = [1,2,3,4] 
feature was killed off because it could be implemneted in a library. So 
I highly doubt that they are OK with adding a feature for importing 
Windows System Dlls only.