fix: allocate console and set stderr to 2 for subsequent logging
For this issue:
- https://github.com/shmocz/ra2yrcpp/issues/14#issuecomment-2809660941
Please test!
Refs:
- https://github.com/ocaml/ocaml/issues/9252#issuecomment-576383814
- AllocConsole: backspace and newline characters incorrectly printed after "system" call https://web.archive.org/web/20230601042758/https://social.msdn.microsoft.com/Forums/windows/en-US/286059e8-9163-4679-9663-efc63c5d9c53/allocconsole-backspace-and-newline-characters-incorrectly-printed-after-quotsystemquot-call?forum=vcgeneral#68a73761-7a40-4d4c-a15e-90902a1244ee-isAnswer
.
Putting things in header file is painful, so the current code looks that awkward.
Well, I may need to create a "logging.cpp"... Are our executables able to use that?
Thanks!
The problem has been mitigated in https://github.com/shmocz/ra2yrcpp/commit/4141a8276e7b062d9137d58f004590601362f3a3. Technically it doesn't fix writing to stderr, but just enforces that everything's logged to a file instead of stderr.
At the moment, I'm not sure if the benefits from this fix outweigh the added complexity:
- This makes logging functions dependent on Windows API, but the issue concerns just in-game logging (
stderrworks just fine in tests). - If logging to file is enabled, what should the behavior be like? Open the console AND write to file? Not open the console at all, which is essentially the current behaviour?
- What if another DLL (e.g.
yrpp-spawner,Phobos) allocates a console? Is the behaviour well defined?
Thank you for the detailed reply. Let me explain:
- This makes logging functions dependent on Windows API, but the issue concerns just in-game logging (
stderrworks just fine in tests).
Hmm, we are trying to use CUI in a GUI program (i.e., the game). that's normal and natural on Linux, but a bit inconvenient on Windows:
- How can I output to the parent console window from a Win32 C++ application? - Stack Overflow https://stackoverflow.com/q/52825867
- Problem using AllocConsole() and marshalling - Stack Overflow https://stackoverflow.com/q/4349187
- Adding Console I/O to a Win32 GUI App https://web.archive.org/web/20070513064449/http://www.halcyon.com/%7East/dload/guicon.htm
I'm sorry I haven't run any tests until now. I guess those tests are able to run without a game. Hence, I need to make things more clear, that is:
- Writing logs to
stderron any platforms. - Calling Windows API to set
stderrto 2 on Windows in the first place.
- If logging to file is enabled, what should the behavior be like? Open the console AND write to file? Not open the console at all, which is essentially the current behaviour?
We can define the behaviour. I think we can support both two log sinks. For example:
-
logFilename: filenane, writing logs to a file. -
consoleLog: boolean, writing logs to the console.
- What if another DLL (e.g.
yrpp-spawner,Phobos) allocates a console? Is the behaviour well defined?
It should be fine if their implementation is the same as "CnCNet/yr-patches". ^1 Subsequent AllocConsole() calls in other programs will fail, but it does not mean that the terminal is broken, but means that the current process has already allocated a console. In our use cases, we've taken that job.
Unfortunately, Phobos' implementation may need to be modified before using my new code if they allocate console after us. ^2 I haven't digged into Phobos, though.
At the moment, I'm not sure if the benefits from this fix outweigh the added complexity:
...
Let me refactor my new code based on the latest codebase. I need to redesign it.
It deserves a fix.
Furthermore, recently I also did something about AllocConsole() in "CnCNet/yr-patches" to make console happy. [^3]
[^3]: Support writing logs to Git-Bash mintty terminal; reduce the number of "GetStdHandle()" calls https://github.com/CnCNet/yr-patches/pull/35