printfs do not get flushed to console allocated via AllocConsole()

[spinykipod]

Hello everyone,
I've recently upgraded from wine 8.0.2 to the 9 release candidate. I am using a dll that gets loaded into a graphical application, calls AllocConsole(), then redirects both stdout and stderr to it, for diagnostic information. Under windows, each printf(), puts() etc was immediately printed, under wine it is not the case.
In the older version, 8.0.2, the stdout appeared directly in the terminal i invoked the program from, and that was sufficient. Unfortunately, after upgrading, a new console pops up and the messages are displayed only after 2 or 4k characters have been printed (so, no flushing).
I have changed the printfs into fprintf(stderr,...) and there is nochange - buffering still occurs.
How can I solve the problem? Either of these would work for me:
- make the printfs be flushed after an '\n'
- make printfs appear directly on the terminal i invoked wine from
- make my dll wine aware (I've got the source code of the dll), so that i can invoke some kind of "wine_printf()" - I couldn't find much info about this, though.

Best regards and happy holidays.

[DarkShadow44]

Can you provide a minimal sample to reproduce the issue with?

[spinykipod]

I've spent over an hour debugging it, to my surprise a minimal example worked out of the box. It turns out this printf buffering occurs only for dlls that I build with CMake!! I went and crafted exactly the same dll via a command line (clang++ main,cpp -shared -o foo.dll) and the buffering was gone! It must have been the CMake setting about shared/static vc runtime (cmake produces 36 kb dll, clang 170kb). Still it does not explain why the buffering occurs under wine and not on win (with dll built with CMake), but for now the solution works. And by the way, I discovered a second bizzare behavior where piping the wine game.exe to cat (yes, | cat) makes the text in the extra console be unbuffered with the "wrong dll".