When I link the app with /subsystem:windows, and all writeln and writefln will cause a enforcement failed (stdio.d:2889).
I think this is unacceptable.

On Friday, 16 November 2018 at 17:36:01 UTC, Domain wrote:
> I think this is unacceptable.

Why?

You are asking it to write to a file that doesn't exist... you probably shouldn't be doing that...

On Friday, 16 November 2018 at 17:46:20 UTC, Adam D. Ruppe wrote:
> On Friday, 16 November 2018 at 17:36:01 UTC, Domain wrote:
>> I think this is unacceptable.
>
> Why?
>
> You are asking it to write to a file that doesn't exist... you probably shouldn't be doing that...

But I cannot control the 3rd library!

On Friday, 16 November 2018 at 17:49:06 UTC, Domain wrote:
> But I cannot control the 3rd library!

Hmm, I see.

So one possibility would be to reopen stdout (and maybe stderr) to a different file.

        stdout.reopen("log.txt", "wt");

when you start your program and before you call the library and it should no longer error - unless it can't create the file. Then you can look at the file if you do need the output.

BTW if you just want to ditch the output, you might be able to use "NUL" as the file name. I havent' tried tho.

On Friday, 16 November 2018 at 17:36:01 UTC, Domain wrote:
> When I link the app with /subsystem:windows, and all writeln and writefln will cause a enforcement failed (stdio.d:2889).
> I think this is unacceptable.

Another option is to enhance / correct the third party component if possible. You could create a github issue for the developer to make him/her aware of the issue.

Kind regards
Andre