size_t shall be printed with %Iu
* i had a conflict for size_t on my local machine vs. build pipeline build32
you should use %\<uppercase I\>u for size_t (that will work on both 32 & 64bit), and no need to cast integer
Is ENABLE_VIRTUAL_TERMINAL_PROCESSING the correct bit?
yes
It is not checked for other sequences like \\t or \\n
this should be handled by another bit in the output mode about auto folding lines larger than console IIRC reusing `SET_CONSOLE_OUTPUT_INFO_ATT`R what I mean here is there are basically different types of console APIs: * old ones (referring eg to screen buffer) * new ones, closer to unix pty:s and escape seq when you use `SET_CONSOLE_OUTPUT_INFO_ATTR` it's like setting the default screen buffer color in old console APIs what should be tested is something like: * write esc seq to change current color in red * don't emit esc seq to go back to default color * use old API to get screen buffer color and check the result (GetConsoleScreenBufferInfo)
`What do you mean by share current ANSI color? each screenbuffer stores its color per character/data, this should not conflict between multiple consoles`
you can have several programs attached to the same console (and screen buffer)
that's what happens eg when you start mc.exe from cmd.exe; they both will be attached to the same console (yes, cmd suspends itself when mc runs, but that's just cmd's behavior; both programs could read/write to the console at the same time)
how can i test unix console?
running ./wine foo.exe from a unix shell will run foo.exe into a unix console running ./wine wineconsole foo (from a unix shell) will run foo.exe into a (user32) console
Should i push additional commits to the branch or should i rebase and fix the already existing commits?
rebase -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9973#note_128116