Call to Runtime.unloadLibrary corrupts stdout and stderr

Rainer Schuetze via Digitalmars-d digitalmars-d at
Sun Sep 3 13:07:26 PDT 2017

On 03.09.2017 20:21, Markus Pursche wrote:
> On Sunday, 3 September 2017 at 13:41:33 UTC, Rainer Schuetze wrote:
>> On 02.09.2017 23:38, Markus Pursche wrote:
>>> [...]
>> Unfortunately, this section only applies to simple programs (no 
>> multi-threading, no sharing of other resources than GC-memory, not 
>> even malloc'ed memory). I think there should be a big red warning at 
>> the beginning of that section.
>> Proper DLL support for Windows (with a shared phobos library) is 
>> slowly being worked on, see
>> In the mean time, I prefer keeping DLL resources completely separate, 
>> as shown in 
>>> [...]
>> You are probably hitting 
>>, so try the workaround: 
>> import std.stdio and add "_fcloseallp = null;"
>> somewhere in your DllMain.
> This worked! So, is there any chance that you could tell me why this 
> isn't the default behavior from the start? Like is there a reason for it 
> not to be there automatically, like a performance loss or a leak or 
> something?

This workaround has side effects, i.e. it doesn't automatically close 
any file still open by the DLLs' instance of the C runtime, so it might 
cause incomplete files if someone relies on these being automatically 
flushed and closed.

It's a bug in the dmc runtime. Only Walter can fix it as it is closed 

More information about the Digitalmars-d mailing list