[Issue 23312] Cannot use writeln with WinMain

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=23312

Mike Parker <aldacron at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |aldacron at gmail.com
         Resolution|---                         |INVALID

--- Comment #2 from Mike Parker <aldacron at gmail.com> ---
This is not specific to D. It's a Windows thing, and it happens in C and C++
programs as well.

The presence of WinMain in your source automatically tells most (all?) linkers
on Windows that you're building a "windows subsystem" executable. This means
standard I/O will be unavailable at startup since there's no console to write
to or read from. 

Andrej's suggestion of using main instead, which is automatically interpreted
as a "console subsystem" works, and is probably the best solution if you need
stdout/stderr/stdin. 

Windows linkers also support a flag that allows you to specify either the
windows or console subsystem (among others) no matter which entry point you
have (WinMain or main). The MS linker also has a flag, and requires its use, to
specify the entry point if it doesn't match the subsystem. You can find the
documentation for both at the following links (and remember, these are
specifically for the Microsoft linker; the LDC linker may support both or may
not require the entry specification, I don't know):

https://learn.microsoft.com/en-us/cpp/build/reference/subsystem-specify-subsystem?view=msvc-170

https://learn.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol?view=msvc-170

But there's no reason to use WinMain if you want a console, so I just use main.

Anyway, this isn't a D-specific issue, so I'm going to close this as invalid.
If there's not a way in the standard library to redirect standard I/O (to file,
or a console created via AttachConsole), there should be, but that should be a
separate issue from this one.

--