I'm currently back on dll support and I'm applying finishing touches to my dll support PR. Now I want to know if I missed any corner cases and it would be great if a few more people gave the dll support a try.

-To try it out you will need to build dmd, druntime and phobos yourself. I'm not going to provide a binary distribution.
-You will need to target the microsoft linker. E.g. either use -m64 or -m32mscoff when compiling your programs.
-be warned, the state of the dll support is not final and subject to change. There is no garantuee that there won't be any breaking changes to dll support.

You can find a quick start guide here: http://stuff.benjamin-thaut.de/D/getting_started.html
If you need more information and examples take a look here: https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md

Not all of phobos/druntime has correct export annotations yet as this is not the goal of my initial pull request. If you use a function from druntime/phobos that does not have a correct export annotation you will get a linker error. I'm not interrested in those. I'm interrested in cases where export is correctly used and you will still get linker errors / incorrect program behavior. So if you encounter a linker error first check if the declaration has a export annotation or not. Try adding it and see if the error goes away. If it does not go away, report it here or send me an e-mail to code at benjamin-thaut.de

If you find anything, small repro cases would be appreciated as it makes my life a lot easier.

-- 
Kind Regards
Benjamin Thaut

Looks good. If you want testers though, providing binaries would be beneficial. Compiling dmd/druntime/phobos on Windows can be a pain.

+infinity

Few things I would like answered:

- Why -useShared and not -fPIC?
  - If -useShared why not use it on *nix to turn on -fPIC?
- Why isn't DllIsUsedFromC.no automatically detected?

Regarding C-runtime, yes we need to distribute every version that we support on Windows. The compiler will pick the latest (or the installer I guess) to use, but we should be able to switch between them. Either that or we ship a static lib of Phobos to be linked into a dll upon first request of a specific C-runtime.

Am 07.01.2018 um 03:57 schrieb rikki cattermole:
> +infinity
>
> Few things I would like answered:
>
> - Why -useShared and not -fPIC?
>    - If -useShared why not use it on *nix to turn on -fPIC?

Because the DIP says that -useshared and -fPIC are loosley comparable. This does not mean that they are the same or interchangeable. In fact they are not. On linux when building a executable that uses a shared library -fPIC is not neccessary, unless your distribution requires position independend code everywhere. On windows on the other hand you will need to pass -useshared when building a executable that uses shared libraries.

> - Why isn't DllIsUsedFromC.no automatically detected?

Because its not possible. I don't know of any way to detect wether a dll is loaded by a c-executable or d-executable. As a result the user has to specify it. The main problem here is that currently D Dlls hijack all threads. This is neccessary because currently there is no shared version of phobos, so the information about the threads can't be shared between multiple D dlls. One possibility would also be to remove the thread hijacking alltogether and require the user to manually add threads that have been created from C. This is also the current state on linux if I'm not mistaken. But doing so would break backwards compatibility.

> Regarding C-runtime, yes we need to distribute every version that we support on Windows. The compiler will pick the latest (or the installer I guess) to use, but we should be able to switch between them. Either that or we ship a static lib of Phobos to be linked into a dll upon first request of a specific C-runtime.

That really is a problem I'm not going to solve. It is more a problem of distributing dmd and building the installer which is beyond the scope of my current PR.

-- 
Kind Regards
Benjamin Thaut

On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote:
> You can find a quick start guide here: http://stuff.benjamin-thaut.de/D/getting_started.html
> If you need more information and examples take a look here: https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md

Does the implementation support dynamically loaded dlls?

Am 07.01.2018 um 00:42 schrieb Rubn:
> Looks good. If you want testers though, providing binaries would be beneficial. Compiling dmd/druntime/phobos on Windows can be a pain.

I made a binary distribution. I updated http://stuff.benjamin-thaut.de/D/getting_started.html with the details.

-- 
Kind Regards
Benjamin Thaut

Am 07.01.2018 um 15:08 schrieb MrSmith:

> Does the implementation support dynamically loaded dlls?

Yes. There is even a test for it

-- 
Kind Regards
Benjamin Thaut

On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote:
> I'm currently back on dll support and I'm applying finishing touches to my dll support PR. Now I want to know if I missed any corner cases and it would be great if a few more people gave the dll support a try.
>
> -To try it out you will need to build dmd, druntime and phobos yourself. I'm not going to provide a binary distribution.
> -You will need to target the microsoft linker. E.g. either use -m64 or -m32mscoff when compiling your programs.
> -be warned, the state of the dll support is not final and subject to change. There is no garantuee that there won't be any breaking changes to dll support.
>
> You can find a quick start guide here: http://stuff.benjamin-thaut.de/D/getting_started.html
> If you need more information and examples take a look here: https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md
>
> Not all of phobos/druntime has correct export annotations yet as this is not the goal of my initial pull request. If you use a function from druntime/phobos that does not have a correct export annotation you will get a linker error. I'm not interrested in those. I'm interrested in cases where export is correctly used and you will still get linker errors / incorrect program behavior. So if you encounter a linker error first check if the declaration has a export annotation or not. Try adding it and see if the error goes away. If it does not go away, report it here or send me an e-mail to code at benjamin-thaut.de
>
> If you find anything, small repro cases would be appreciated as it makes my life a lot easier.

I would volunteer, but I don't know how much I can do in my exam session. Maybe in February, until then not much.

Am 08.01.2018 um 00:06 schrieb solidstate1991:
> On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote:
> 
> I would volunteer, but I don't know how much I can do in my exam session. Maybe in February, until then not much.

Just do some testing whenever you find time, keep monitoring this thread foor upates.

-- 
Kind Regards
Benjamin Thaut

On Monday, 8 January 2018 at 09:01:29 UTC, Benjamin Thaut wrote:
> Am 08.01.2018 um 00:06 schrieb solidstate1991:
>> On Saturday, 6 January 2018 at 19:32:51 UTC, Benjamin Thaut wrote:
>> 
>> I would volunteer, but I don't know how much I can do in my exam session. Maybe in February, until then not much.
>
> Just do some testing whenever you find time, keep monitoring this thread foor upates.

I'm waiting on VS2015 and Windows SDK to install. Once that's done, I'll begin testing.

Also, thanks a tonne for doing this.