On Sunday, 25 April 2021 at 15:01:25 UTC, cc wrote:

I cannot reproduce this on Windows 10. It would be just interesting to know your compiler version and OS and if you have installed any Visual Studio tools or Visual C runtimes, thanks.

On Monday, 26 April 2021 at 13:44:19 UTC, frame wrote:

Win10 64-bit
DMD32 D Compiler v2.096.0-dirty
Sublime Text 3.1.1 Build 3176
Visual Studio 2019 is installed, as well as... quite a few runtimes, multiple for Visual C++ 2005, 2008, 2010, 2012, 2013, 2015-2019.

The buffering also happens under cygwin shells (I'm not building with cygwin, I just like using their bash shell). If I run a D program through the basic cmd.exe, it runs with no stdout buffering. However any other situation (shell, sublime build+output capture, etc) buffering somehow gets enabled, unless I explicitly disable it in code or wrap the write* functions with stdout.flush() wrappers. This has happened for me for many versions of the dmd compiler stretching back years, building both 32-bit and 64-bit executables.

On Monday, 26 April 2021 at 14:44:53 UTC, cc wrote:

You'll find the same thing with C programs, since it is actually the C standard library that does this buffering rather than D.

If it is writing to a character device (the only one I've ever seen in practice is the Windows console, directly, not through a pipe meaning this doesn't occur for terminal replacements or IDEs or similar), it line buffers. Otherwise, it block buffers.

On Monday, 26 April 2021 at 14:44:53 UTC, cc wrote:

like me

Does it also buffer if you run the .exe directly via explorer too?

I have no issues with v2.096.0. Must be really a specific problem with your runtimes or Windows (I stopped updating at version 1903 :P)

On Monday, 26 April 2021 at 14:44:53 UTC, cc wrote:

So that's the difference, then. I ran my test through cmd.exe. Have you tried running a similar C setup through those other shells?