My work on dll support for D continues. There is another iteration I need help testing with.

Getting started tutorial: http://stuff.benjamin-thaut.de/D/getting_started.html
The DIP can again found be here: https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md
The DIP is not up to date. The tutorial is more recent. If the DIP and the tutorial contradict each other trust the tutorial. Its still useful to read the dip for context, especially as how to use "export" in code.

This time around the shared version of phobos should have all required symbols exported. This means when you link against the shared version of phobos and find a linker error, please report that here. Ideally with a reduced repro case.

A binary distribution is provided, see the tutorial for details.

On 09/02/2018 8:34 PM, Benjamin Thaut wrote:
> My work on dll support for D continues. There is another iteration I need help testing with.
> 
> Getting started tutorial: http://stuff.benjamin-thaut.de/D/getting_started.html
> The DIP can again found be here: https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md
> The DIP is not up to date. The tutorial is more recent. If the DIP and the tutorial contradict each other trust the tutorial. Its still useful to read the dip for context, especially as how to use "export" in code.
> 
> This time around the shared version of phobos should have all required symbols exported. This means when you link against the shared version of phobos and find a linker error, please report that here. Ideally with a reduced repro case.
> 
> A binary distribution is provided, see the tutorial for details.

-import switch makes me a little concerned, what exactly is it changing that makes it required?

On Saturday, 10 February 2018 at 02:24:58 UTC, rikki cattermole wrote:
> On 09/02/2018 8:34 PM, Benjamin Thaut wrote:
>
> -import switch makes me a little concerned, what exactly is it changing that makes it required?

Thank you Rikki for derailing this topic with the first post. As you might noticed, the title says "testers needed" not "concerns needed". And if you absolutly have to voice your concerns at least do it in a usefull way. Give a propper reason for your concerns, ideally a technical one. Not just "I'm concerned about x".

Did you Read DIP 45 in its current state? Did you watch my DConf Talk about Dll support? Did you understand how the shared library menchanism works on windows? If you did then the details behind the -import switch should be very self explanatory. If you didn't -import is needed for the compiler to know when to dllimport a symbol. If you need more detail you will have to wait until I updated DIP 45. With the little time I have at the moment I can't re-explain the full details of the implemenation to everyone in person, that would be very bad use of my time.

So if you want to help, download the binary distribution and give it a try. Try to find a corner case with dlls that my implementation doesn't cover. That would be useful.

Kind Regards
Benjamin Thaut

On Saturday, 10 February 2018 at 12:34:03 UTC, Benjamin Thaut wrote:
> On Saturday, 10 February 2018 at 02:24:58 UTC, rikki cattermole wrote:
>> On 09/02/2018 8:34 PM, Benjamin Thaut wrote:
>>
>> -import switch makes me a little concerned, what exactly is it changing that makes it required?
>
> Thank you Rikki for derailing this topic with the first post. As you might noticed, the title says "testers needed" not "concerns needed". And if you absolutly have to voice your concerns at least do it in a usefull way. Give a propper reason for your concerns, ideally a technical one. Not just "I'm concerned about x".
>
> Did you Read DIP 45 in its current state? Did you watch my DConf Talk about Dll support? Did you understand how the shared library menchanism works on windows? If you did then the details behind the -import switch should be very self explanatory. If you didn't -import is needed for the compiler to know when to dllimport a symbol. If you need more detail you will have to wait until I updated DIP 45. With the little time I have at the moment I can't re-explain the full details of the implemenation to everyone in person, that would be very bad use of my time.
>
> So if you want to help, download the binary distribution and give it a try. Try to find a corner case with dlls that my implementation doesn't cover. That would be useful.
>
> Kind Regards
> Benjamin Thaut

lol, come on man!!! WTF?!?!?! You know D is filled with people who have to whine about "breaking changes" It's always either to whine than work.

I might give this a try if I ever get back in to D programming... as of now D is to screwed up for me to invest any more time. Great concept, poor implementation. Too much of a hodge podge of things without really thinking the consequences through.  It's not necessary bad but when you couple it with all the lame tooling and IDE's that offer no real efficiency it becomes an issue. Easier just to use a modern well equipped compiler with good documentation and good IDE's and good libraries.

It's kinda like someone invented a great car engine but forgot to put AC in it, manual windows, etc. Some people will love it just because of the engine... others are more balanced in there analysis and realize the engine isn't car and rather ride in style at the cost of a few HP than suffering in the heat just to get to their destination 0.53 min faster. Unfortunately D seems to be made up of people who only care about the engine.

On Friday, 9 February 2018 at 20:34:33 UTC, Benjamin Thaut wrote:
> My work on dll support for D continues. There is another iteration I need help testing with.
>
> Getting started tutorial: http://stuff.benjamin-thaut.de/D/getting_started.html
>
> A binary distribution is provided, see the tutorial for details.

Played a bit with your binaries, here are some issues.

Importing non-compiled modules works ok.
However when doing manual library loading(both WinAPI LoadLibrary and Runtime.loadLibrary) things is the same as in vanilla DMD/LDC - casting not working.

Classes(incl. abstract) works in a hacky way (first cast to void* - then to actual class), again same as plain DMD, no changes here.

Interfaces doesn't work at all, doing the hack above on interface-derived object messes up vtbl/offsets, resulting in wrong function called.

-import switch seems to do the trick, but how to deal with dynamic loading?

On Saturday, 10 February 2018 at 02:24:58 UTC, rikki cattermole wrote:
> -import switch makes me a little concerned, what exactly is it changing that makes it required?

I remember that we figured out that the MS Linker can optimize away the indirection when linking statically, so the paragraph seems a bit alarming https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md#-useshared-compiler-flag.

On Friday, 9 February 2018 at 20:34:33 UTC, Benjamin Thaut wrote:
> My work on dll support for D continues. There is another iteration I need help testing with.
>
> Getting started tutorial: http://stuff.benjamin-thaut.de/D/getting_started.html
> The DIP can again found be here: https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md
> The DIP is not up to date. The tutorial is more recent. If the DIP and the tutorial contradict each other trust the tutorial. Its still useful to read the dip for context, especially as how to use "export" in code.

Glad to see some progress.
Given that the goal of DIP45 was seemless DLL support given just export annotations, the need for explicit -import module lists indeed requires an explanation. Looks like a classical dllexport/-import scheme now.

On 21/03/2018 07:46, evilrat wrote:
> On Friday, 9 February 2018 at 20:34:33 UTC, Benjamin Thaut wrote:
>> My work on dll support for D continues. There is another iteration I need help testing with.
>>
>> Getting started tutorial: http://stuff.benjamin-thaut.de/D/getting_started.html
>>
>> A binary distribution is provided, see the tutorial for details.
> 
> Played a bit with your binaries, here are some issues.
> 
> Importing non-compiled modules works ok.
> However when doing manual library loading(both WinAPI LoadLibrary and Runtime.loadLibrary) things is the same as in vanilla DMD/LDC - casting not working.
> 
> Classes(incl. abstract) works in a hacky way (first cast to void* - then to actual class), again same as plain DMD, no changes here.
> 
> Interfaces doesn't work at all, doing the hack above on interface-derived object messes up vtbl/offsets, resulting in wrong function called.
> 
> -import switch seems to do the trick, but how to deal with dynamic loading?
> 

I guess you want to cast to a class that is only defined in the dynamically loaded DLL? The problem is that casting needs a reference to the class info of the target class which only exists in the referenced DLL, which needs static DLL linkage.

One suggestion would be to export a common class/interface definition from a DLL that is referenced by both the dynamic DLL and the loading executable.

On 21/03/2018 14:08, Martin Nowak wrote:
> On Friday, 9 February 2018 at 20:34:33 UTC, Benjamin Thaut wrote:
>> My work on dll support for D continues. There is another iteration I need help testing with.
>>
>> Getting started tutorial: http://stuff.benjamin-thaut.de/D/getting_started.html
>> The DIP can again found be here: https://github.com/Ingrater/DIPs/blob/ReviveDIP45/DIPs/DIP45.md
>> The DIP is not up to date. The tutorial is more recent. If the DIP and the tutorial contradict each other trust the tutorial. Its still useful to read the dip for context, especially as how to use "export" in code.
> 
> Glad to see some progress.
> Given that the goal of DIP45 was seemless DLL support given just export annotations, the need for explicit -import module lists indeed requires an explanation. Looks like a classical dllexport/-import scheme now.

AFAICT -import was an idea proposed by Walter because he didn't like -useshared that is still in the DIP.

A previous version of the DLL support implemented -useshared and worked quite well in my tests. For simplicity I prefer -useshared although it might incur a minor performance penalty when adding an indirection to a library that is actually linked statically (not sure about the linker optimization you mentioned in the other response).

On Saturday, 31 March 2018 at 08:33:19 UTC, Rainer Schuetze wrote:
>
> I guess you want to cast to a class that is only defined in the dynamically loaded DLL? The problem is that casting needs a reference to the class info of the target class which only exists in the referenced DLL, which needs static DLL linkage.
>
> One suggestion would be to export a common class/interface definition from a DLL that is referenced by both the dynamic DLL and the loading executable.

Common class defined in static lib linked with both exe & dll.

Cast to classes seems to be working when done through void* first. But unfortunattely interface casts didn't work correctly(vtable issues).