stdout_sink raises exception in GUI (non-console) Windows App

[dgehri]

Regression after fix for Issue #1675 : With this fix, creating a stdout_sink in an GUI (non-console) application now throws an exception, because the call ::_get_osfhandle(::fileno(file)); now fails, whereas the previous version would allow the sink to be created.

So where a GUI app previously would log to the debugging console, it now throws an Exception. This is a regression.

[tt4g]

IMO.

This is the design of the Microsoft Windows operating system.
The STDOUT (STD_OUTPUT_HANDLE) is not attached to GUI applications.
If we need STDOUT in GUI application, you have to attach a console by calling AllocConsole().

Quote: https://docs.microsoft.com/en-us/windows/console/getstdhandle

Console processes must start with the standard handles filled or they will be filled automatically with appropriate handles to a new console. Graphical user interface (GUI) applications can be started without the standard handles and they will not be automatically filled.

Calling AllocConsole() in a GUI application will attach a console, which will be the standard output destination (on most machines, cmd.exe will be launched).
This is undesirable behavior for many programmers, and the library should not call AllocConsole().

[gabime]

I tend to fix this since it is not very easy to cope with (e.g when spdlog used through a 3rd party dependency), and indeed it breaks backward compatibility.

[gabime]

Fixed in 5efccfa