Call to Runtime.unloadLibrary corrupts stdout and stderr

[Rainer Schuetze via Digitalmars-d]

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 http://dconf.org/2016/talks/thaut.html
>>
>> In the mean time, I prefer keeping DLL resources completely separate, 
>> as shown in 
>> https://wiki.dlang.org/Win32_DLLs_in_D#DLLs_with_a_C_Interface
>>
>>> [...]
>>
>> You are probably hitting 
>> https://issues.dlang.org/show_bug.cgi?id=1550, 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 
source.