On Thursday, 28 January 2021 at 12:42:09 UTC, Siemargl wrote:
> 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

You can't expect that a Win10 build also runs on Win7.

On Thursday, 28 January 2021 at 16:46:40 UTC, frame wrote:
> On Thursday, 28 January 2021 at 12:42:09 UTC, Siemargl wrote:
>> 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
>
> You can't expect that a Win10 build also runs on Win7.

Why not?

Only VS2013 runtime is prereq for DMD programs

On Thursday, 28 January 2021 at 17:00:35 UTC, Siemargl wrote:
> On Thursday, 28 January 2021 at 16:46:40 UTC, frame wrote:
>> On Thursday, 28 January 2021 at 12:42:09 UTC, Siemargl wrote:
>>> 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
>>
>> You can't expect that a Win10 build also runs on Win7.
>
> Why not?
>
> Only VS2013 runtime is prereq for DMD programs

* you shouln't assume

I just guess that the library loading code is different between 7 and 10. I get the same error if I try to load a LDC compiled DLL in a DMD executable.

Did you try to compile the DLL on Win 7 too?

On Thursday, 28 January 2021 at 12:42:09 UTC, Siemargl wrote:
> 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.

Ups. Sorry, I just forget copy test_dll.dll inside VM :-)

So, program runs in Win7, but hangs after printing i:64511

On Friday, 29 January 2021 at 00:45:12 UTC, Siemargl wrote:

>> Then i modify program, just removing DLL, copying TestFun() in main module and it runs.
>> Same compiler -m64 target.
>
> Ups. Sorry, I just forget copy test_dll.dll inside VM :-)
>
> So, program runs in Win7, but hangs after printing i:64511

I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears.

But 2.092 + MSVC2013 libs also hangs. Not every time, but

On Friday, 29 January 2021 at 01:23:20 UTC, Siemargl wrote:
> On Friday, 29 January 2021 at 00:45:12 UTC, Siemargl wrote:
>
>>> Then i modify program, just removing DLL, copying TestFun() in main module and it runs.
>>> Same compiler -m64 target.
>>
>> Ups. Sorry, I just forget copy test_dll.dll inside VM :-)
>>
>> So, program runs in Win7, but hangs after printing i:64511
>
> I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears.
>
> But 2.092 + MSVC2013 libs also hangs. Not every time, but

You should really try to use a debugger to see what error is thrown in first chance. It also helps to identify a possible hidden problem that is not reproducable on other machines.

On Wednesday, 27 January 2021 at 15:25:17 UTC, H. S. Teoh wrote:
> 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

Anyone knows what it would take to fix it?

On Fri, Jan 29, 2021 at 12:45:02PM +0000, Imperatorn via Digitalmars-d-learn wrote:
> On Wednesday, 27 January 2021 at 15:25:17 UTC, H. S. Teoh wrote:
> > 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?
[...]
> Anyone knows what it would take to fix it?

Somebody who (1) knows enough of compiler internals to be able to fix
this, (2) is intimately familiar with how Windows dlls work, (3) is
desperate enough to do the work himself instead of waiting for someone
else to do it, and (4) is stubborn enough to push it through in spite of
any resistance.


T

-- 
Never wrestle a pig. You both get covered in mud, and the pig likes it.

On Friday, 29 January 2021 at 12:45:02 UTC, Imperatorn wrote:
>
> Anyone knows what it would take to fix it?

This may help to narrow down the problem.

Disable garbage collect
Configuring the Garbage Collector
https://dlang.org/spec/garbage.html
https://stackoverflow.com/questions/472133/turning-off-the-d-garbage-collector

Or change it so that there is only one thread
Parallel marking
https://dlang.org/spec/garbage.html

On Friday, 29 January 2021 at 10:10:56 UTC, frame wrote:
> On Friday, 29 January 2021 at 01:23:20 UTC, Siemargl wrote:
>> On Friday, 29 January 2021 at 00:45:12 UTC, Siemargl wrote:
>>
>>>> Then i modify program, just removing DLL, copying TestFun() in main module and it runs.
>>>> Same compiler -m64 target.
>>>
>>> Ups. Sorry, I just forget copy test_dll.dll inside VM :-)
>>>
>>> So, program runs in Win7, but hangs after printing i:64511
>>
>> I downgrade DMD to 2.090.1 + MSVC2013 libs and problem disappears.
>>
>> But 2.092 + MSVC2013 libs also hangs. Not every time, but
>
> You should really try to use a debugger to see what error is thrown in first chance. It also helps to identify a possible hidden problem that is not reproducable on other machines.

Sorry, there are many problems debugging D x64 on Windows.

All i can get, is call stack from crash dump

ntdll!ZwWaitForSingleObject+0xa
ntdll!RtlDeNormalizeProcessParams+0x5a8
ntdll!RtlDeNormalizeProcessParams+0x4a4
ntdll!RtlInitializeCriticalSectionEx+0x3b9
KERNELBASE!HeapDestroy+0x3a
KERNELBASE!GetModuleHandleExW+0x39
test_dll!TestFun+0x576b6
test_dll!TestFun+0x55bf3
test_dll!TestFun+0x4e315
test_dll!TestFun+0x4d86f
test_dll!TestFun+0x4bdb5
test_dll!TestFun+0x507e1
test_dll!TestFun+0x4756b
test_dll!TestFun+0x22d1d
test_dll!TestFun+0x23d9a
test_dll!TestFun+0x1a1b9
test_dll!TestFun+0x93
test_dll_exe!D main+0xe5
test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ6runAllMFZ9__lambda1MFZv+0x33
test_dll_exe!D2rt6dmain212_d_run_main2UAAamPUQgZiZ7tryExecMFMDFZvZv+0x3c