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

On Sunday, 1 February 2015 at 11:50:21 UTC, Benjamin Thaut wrote:
> Sorry, I did jump over the "not" in :

OK, I'm glad that was just a misunderstanding.

> 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

OK, the explanation is no longer relevant.

But I haven't heard of this project before. In a few words, what does this do? Or a link to a DIP or existing discussion?

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

OK, but you can't solve these problems without using DLL imports, can you?

> But the TLS issues are going to remain no matter if the dll is loaded via LoadLibrary or not.

That's not how I understood it.

> Also there are TLS fixes in core.sys.windows.dll for Windows XP.

Cool, didn't know that. That argument isn't relevant, then.

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

But it's not just system Windows libraries, but all DLLs with a C interface. You won't need to mess with import libraries to load curl, or OpenSSL, or SQLite...

Am 01.02.2015 um 13:02 schrieb Vladimir Panteleev:

> But I haven't heard of this project before. In a few words, what does
> this do? Or a link to a DIP or existing discussion?

The last discussion is over a year old, the resulting DIP was DIP 45:
http://wiki.dlang.org/DIP45

The currently blocking issue for this implementation is, that export both means "public" and "dllexport" which is discussed here:
http://forum.dlang.org/thread/m9lhc3$1r1v$1@digitalmars.com

>
>> Thats why its called a proof of concept, it doesn't mean its perfect ;-)
>
> OK, but you can't solve these problems without using DLL imports, can you?

most likely not.


> But it's not just system Windows libraries, but all DLLs with a C
> interface. You won't need to mess with import libraries to load curl, or
> OpenSSL, or SQLite...

Yeah, but the problem is, that as soon as you do that you are limiting yourself to DLL versions of that library. If you for example want to link curl statically this will no longer work. And in my opinion its bad to hardcode in the sourcecode if your expecting a static or shared version of the library.

Thats also the nice thing about import libraries in my opinion. If you ship a library you can simply create two folders .e.g. one called static and the other called shared. Both contain .lib files with the same name. So the only thing a user as to do when he wants to switch between statically and dynamically linking against your library is changing the search directory passed to the linker.

On Sunday, 1 February 2015 at 12:09:56 UTC, Benjamin Thaut wrote:
> http://wiki.dlang.org/DIP45

OK, so I understand it's mostly about D DLLs.

This bit though:

"In an import library the original symbol is redifined as trampoline that simply dereferences the _imp_ pointer to the DLL function. Thus calling an exported function will be compatible with both import libraries and static libraries, in the later case without indirection."

Is this different from how things are now?

Also, how does this conflict with my proposal? If the compiler knows the function to be in a DLL, it can elide generating a trampoline at all, and reference the __imp__ symbol directly.

> Yeah, but the problem is, that as soon as you do that you are limiting yourself to DLL versions of that library. If you for example want to link curl statically this will no longer work. And in my opinion its bad to hardcode in the sourcecode if your expecting a static or shared version of the library.

That's a good point. It would be possible to define my proposal so that it would be easy to switch between the two with a -version switch. On one hand, you trade one compiler switch (static.lib or import.lib) for another (-version=static). On the other hand, for the DLL case, you skip the headache of import libraries.

Am 01.02.2015 um 14:27 schrieb Vladimir Panteleev:
> On Sunday, 1 February 2015 at 12:09:56 UTC, Benjamin Thaut wrote:
>> http://wiki.dlang.org/DIP45
>
> OK, so I understand it's mostly about D DLLs.

Yes of course. Because they are still not supported.

>
> This bit though:
>
> "In an import library the original symbol is redifined as trampoline
> that simply dereferences the _imp_ pointer to the DLL function. Thus
> calling an exported function will be compatible with both import
> libraries and static libraries, in the later case without indirection."
>
> Is this different from how things are now?

No its not. I'm sticking with the additional indirection. But linking against a Dll directly would still be possbile. The linker has to generate the additional indirection anyway, no matter if a import library was used or not. This must be done because otherwise the code generated by the compiler, which assumes a additional indirection, would no longer be working (in case of data symbols only, function symbols would work without the indirection).

>
> Also, how does this conflict with my proposal?

It does not. The only conflict would be if we would ban import libraries completely, which I misunderstood.

> If the compiler knows the
> function to be in a DLL, it can elide generating a trampoline at all,
> and reference the __imp__ symbol directly.

Yes it could.

> That's a good point. It would be possible to define my proposal so that
> it would be easy to switch between the two with a -version switch. On
> one hand, you trade one compiler switch (static.lib or import.lib) for
> another (-version=static). On the other hand, for the DLL case, you skip
> the headache of import libraries.

Your proposal could also be translated to:

pragma(lib, "kernel32.dll");
extern(dll) DWORD GetVersion();

You just want a way to tell the compiler that that function is definitly located in a dll. The additional benefit of the above example would be, that you don't have to repeat which library the symbol is in for each symbol. The problem I see here is that walter didn't want to have a seperation between export and import. So he designed export to mean both. So I don't know how happy he will be if you want to add in a dllimport equivalent keyword. You could do however:


pragma(lib, "wininet.dll");
export extern(Windows) HINTERNET InternetOpen(
  LPCTSTR lpszAgent,
  DWORD dwAccessType,
  LPCTSTR lpszProxyName,
  LPCTSTR lpszProxyBypass,
  DWORD dwFlags
);

The fun thing is, this would work with the current dmd. If export is applied to a function declaration, it means "dllimport". That means during linktime it would look for the __imp_InternetOpen symbol.
The only thing that doesn't work yet is pragma(lib, "kernel32.dll");
So what you should actually request is pragma(lib, "kernel32.dll") to be implemented. Although the only way this could work is, that the compiler actually calls implib for you (or the msvc equivalent) and then actually links against that. The issue that ketmar originally had would remain though, this would only work with libraries that behave nicely and don't change function mangling in their import library. (like wininet does)