On Tue, Jan 26, 2021 at 02:12:17PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> On Monday, 25 January 2021 at 21:48:10 UTC, Vitalii wrote:
> > Q: Why filling assoc.array in shared library freeze execution?
> 
> D exes loading D dlls are very broken on Windows. You can kinda make it work but there's a lot of bad design and showstopper bugs.
[...]

Just out of curiosity, what are some of the showstoppers?  I'd have expected D exe's loading D dll's should be the first priority in making Windows dll's work in D.  I'm surprised there are still obvious problems.


T

-- 
Frank disagreement binds closer than feigned agreement.

On Tuesday, 26 January 2021 at 17:39:50 UTC, H. S. Teoh wrote:
> On Tue, Jan 26, 2021 at 02:12:17PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
>> On Monday, 25 January 2021 at 21:48:10 UTC, Vitalii wrote:
>> > Q: Why filling assoc.array in shared library freeze execution?
>> 
>> D exes loading D dlls are very broken on Windows. You can kinda make it work but there's a lot of bad design and showstopper bugs.
> [...]
>
> Just out of curiosity, what are some of the showstoppers?  I'd have expected D exe's loading D dll's should be the first priority in making Windows dll's work in D.  I'm surprised there are still obvious problems.
>
>
> T

The biggest one for me, is that RTTI isn't "shared" across boundaries.

So typeid(int) in your .exe isn't compatible with typeid(int) from a .dll

I found out the hard way, since sdlang-d was giving me a very strange type mismatch error which was caused due to this issue in typeid.

Am I wrong in saying that it was fixed at some point though, or at least, someone was attempting a fix?

It's kind of discouraging to hear from Adam that there's actually even *more* issues regarding DLLs.

I've crossed them out of my mind entirely at this point though, since Windows in general doesn't seem to get much love in certain parts of D (e.g. the makefile for Phobos didn't support things that the posix makefile did).

On Wednesday, 27 January 2021 at 13:39:32 UTC, SealabJaster wrote:
> I've crossed them out of my mind entirely at this point though, since Windows in general doesn't seem to get much love in certain parts of D (e.g. the makefile for Phobos didn't support things that the posix makefile did).

Should just quickly clarify that these "certain parts of D" are usually minor/niche parts and things.

On Wednesday, 27 January 2021 at 13:39:32 UTC, SealabJaster wrote:
> The biggest one for me, is that RTTI isn't "shared" across boundaries.

Yeah, that's a big one. Exception handling tables are also not properly merged leading to random behavior even if you do manage to catch the exception (I wrote a PR for that but it isn't theoretically sound https://github.com/dlang/druntime/pull/2874# ), the GC proxy is done wrong - but there might be a chance to fix that - and there's a bug with static data not being scanned. Possibly related to the GC proxy, not sure.

It is all related to the same root problem - on Windows, unlike Linux, symbols are not automatically merged. More info

http://dconf.org/2016/talks/thaut.html

Yes, from 2016. And a branch aiming to fix it: https://github.com/ingrater/dmd/tree/DllSupportD


So what happens is if you have a global variable in the dll and exe, each one has their own copy of it. So typeid are not merged, GC meta is not merged. druntime tries to hack around this but it doesn't do a good job.

But then in user libs the same thing happens and they almost never make any attempt to handle it, so if you using other stuff, there be dragons. It might be perfectly fine, separate copies of data is often not fatal at all. But if they expect sharing - you can get separate singletons and such - you're in some trouble.

Technically what dmd does for dlls isn't wrong. That is the way the underlying operating system works. But since it is more useful to handle these things and the Microsoft C++ compilers paper over this with auto-generated indirection, even Windows programmers might not realize it and it just seems completely broken.

(btw as for me fixing it myself, there's a number of subtleties that I don't even know. Maybe i could figure them out but the fact is it is prolly gonna be a buggy transition. But the most discouraging part is seeing all that talk and code from 2016 just sitting there, ignored. What's the point of even trying if it is just going to rot again.)

On Wednesday, 27 January 2021 at 14:36:16 UTC, Adam D. Ruppe wrote:
> (btw as for me fixing it myself

oh edit, I should point out it also requires some degree of language change to match what Microsoft's C++ does. They do dllimport and dllexport annotations to help the compiler generate the stuff. So that prolly is another complication to actually merge it. "Breaking" changes lololololol as if it can get more broken than it is now.

On Wed, Jan 27, 2021 at 02:39:08PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
> On Wednesday, 27 January 2021 at 14:36:16 UTC, Adam D. Ruppe wrote:
> > (btw as for me fixing it myself
> 
> oh edit, I should point out it also requires some degree of language change to match what Microsoft's C++ does. They do dllimport and dllexport annotations to help the compiler generate the stuff. So that prolly is another complication to actually merge it. "Breaking" changes lololololol as if it can get more broken than it is now.

I'm surprised this stuff hasn't been fixed yet, considering Walter (mostly?) works on Windows. Has he never run into these issues before?


T

-- 
One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"

On Wednesday, 27 January 2021 at 15:25:17 UTC, H. S. Teoh wrote:
> I'm surprised this stuff hasn't been fixed yet, considering Walter (mostly?) works on Windows. Has he never run into these issues before?

It had a dconf talk spell it all out.

But it can be difficult to reproduce the nasty cases in a reduced test. Well, the exception catching ones are trivial to reproduce, it just plain doesn't work. But the GC and EH tables not lining up are harder to find. The EH table one rears its head once you fix the typeinfo problem that prevents the catch in the first place.

But then the GC one is just hard to trigger. Unless you're using dll plugins in my day job project. (but even there it only happens after like 100 iterations of stuff, just the day job scripts run hundreds of times a day so you see it regularly... just can't fix it...)

On Wednesday, 27 January 2021 at 16:38:07 UTC, Adam D. Ruppe wrote:
> ...

Yikes! Ok, I thought DLLs were just "sort of" unusable due to the RTTI issue, but now I'm convinced that they're almost completely useless in their current state unless you want to live in a world of hurt and pain.

It's almost comical.

At least the underlying issue is complicated, instead of it rather being a case of "no one's worked on it at all".

Unfortunately, the underlying issue is complicated, so I don't have the greatest faith in DLLs becoming useable anytime soon.

Thanks for the explanation.

On Thursday, 28 January 2021 at 07:51:06 UTC, SealabJaster wrote:
> On Wednesday, 27 January 2021 at 16:38:07 UTC, Adam D. Ruppe wrote:
>> ...
>
> Yikes! Ok, I thought DLLs were just "sort of" unusable due to the RTTI issue, but now I'm convinced that they're almost completely useless in their current state unless you want to live in a world of hurt and pain.

At least at Windows 10, DLLs are "working" except you can't throw exceptions and must use some form of exception proxy and wrapper to not ending in "illegal instructions". I can also compare TypeInfos by using the string representation which works fine.

Update. Something is broken in DLL support in druntime for Win7.

I take previous working in Win10 binary and try run it in virtual Windows 7 SP1 x64.
Got this
C:\Proj\dtest>test_dll_exe.exe

object.Exception@test_dll_exe.d(7): Enforcement failed
----------------
0x00000001400013A3
0x00000001400012CC
0x0000000140001074
0x0000000140004123
0x0000000140003FAC
0x000000014000408B
0x0000000140003FAC
0x0000000140003EF3
0x00000001400019D0
0x0000000140001114
0x000000014002F60E
0x00000000771359CD in BaseThreadInitThunk
0x000000007736A561 in RtlUserThreadStart

Then i modify program, just removing DLL, copying TestFun() in main module and it runs.
Same compiler -m64 target.