[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2018-02-28 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17326

Rainer Schuetze  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Rainer Schuetze  ---
gcstub has been removed, so I guess we can close this.

--


[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17326

--- Comment #7 from Rainer Schuetze  ---
Benjamin Thaut has prototyped it and showed it at Dconf
http://dconf.org/2016/talks/thaut.html. 
Development seems to have stalled at the moment, though. Latest version should
be this: https://github.com/Ingrater/dmd/tree/DllSupportD2

--


[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17326

werero...@gmail.com changed:

   What|Removed |Added

 CC||werero...@gmail.com

--- Comment #6 from werero...@gmail.com ---
I'd be lovely to have a doc on how it should be used in the complex cases - if
it works at all :/

--


[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17326

--- Comment #5 from Rainer Schuetze  ---
That's why I've been saying for years that
https://wiki.dlang.org/Win32_DLLs_in_D#D_code_calling_D_code_in_DLLs needs a
big red warning that it doesn't work but in very simple cases.

--


[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-10-07 Thread d-bugmail--- via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17326

--- Comment #4 from Walter Bright  ---
Coming up again:

http://www.digitalmars.com/d/archives/digitalmars/D/learn/DLL_hell_S_96980.html

--


[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-04-18 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17326

--- Comment #3 from Walter Bright  ---
The problem is I cannot get the DLL test cases into the autotester test suite,
which is why DLL support regularly breaks.

--


[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-04-15 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17326

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #2 from Rainer Schuetze  ---
DLLs with clear separation of ownership work fine (e.g. Visual D is a DLL).

As said repeatedly, the GC proxy mechanism is no good but for very simple use
cases. Threads need to be shared, too, so the GC can stop and analyze them.
Anything happening in a destructor needs to be executed against the correct
runtime library, including the C runtime.

Despite that, the proxy mechanism is still there, you can use it as shown in
https://wiki.dlang.org/Win32_DLLs_in_D#D_code_calling_D_code_in_DLLs: export
gc_setProxy by the DLL and use Runtime.loadLibrary instead of LoadLibraryA to
load it.

It's unfortunate that gcstub/gc.d has not been updated (or better removed). You
can now select something similar by embedding 

  extern(C) __gshared string[] rt_options = [ "gcopt=gc:manual" ]

into the binary. See http://dlang.org/spec/garbage.html#gc_config

--


[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-04-14 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17326

Walter Bright  changed:

   What|Removed |Added

   Keywords||dll

--


[Issue 17326] 2.072 gc changes broke 32 bit Windows DLLs

2017-04-14 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=17326

Walter Bright  changed:

   What|Removed |Added

Summary|2.072 gc changes totally|2.072 gc changes broke 32
   |broke 32 bit Windows DLLs   |bit Windows DLLs

--