https://issues.dlang.org/show_bug.cgi?id=17326
Rainer Schuetze <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Rainer Schuetze <[email protected]> --- 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 --
