How to do non-buffered writes to stdout? - windows

Question

I need 20 'H' characters to appear at 1 second intervals. This program displays nothing till the end
use std::io::Write;
use std::time::Duration;
fn main() {
let ch = 'H' as u8;
for _ in 0..20 {
let buff = vec![ch];
std::io::stdout().write(&buff).unwrap();
std::io::stdout().flush().unwrap();
std::thread::sleep(Duration::from_millis(1000));
}
}
This equivalent C++ program works fine
#include <iostream>
#include <Windows.h>
int main()
{
for(int i = 0; i < 20; i++)
{
std::cout << (char)'H';
std::cout.flush();
Sleep(1000);
}
}
I tried crossterm and could not make that work but it looks really interesting. I tried crossterm_winapi which has direct calls to WriteConsoleW in it, but then I got no output at all.

Answer 1

I am going to answer my own question because I went through a lot of discovery here and I am sure other will find it useful.
BTW - the original question got derailed in the comments section explaining why my c++ equivalent (without flush) worked / didnt work / shouldnt work / might work. Lets ignore that - I added flush.
Firstly Debuggers
vscode and Vs2019 do stuff with stdout in order to try to be helpful. Most of the time it is helpful but not in this case
vscode steals stdout to make it appear in the terminal window. Normally this would be directed to a console window. It also imposes its own buffering regardless of what you do with flushing etc.
The real end for my rust code is a c# gui application calling the rust code as a cdylib. Originally this dll was written in c++. When running a GUI app vs2019 also steals stdout (not the case for console apps, nothing to do with my mini c++ code above) so that it can display it the 'output' window.
Both these behaviors disappear if the app is run outside the debugger of course. But that makes debugging tough.
This of course confused a lot of my investigation because I was not seeing output in various cases because I was looking in the wrong place.
Solution 1
The original code in my question actually works fine if you run it via cargo run from a console window. Excellent. vscode buffers it all up if ran from inside it - so dont do that.
Problem 2, no console window
Windows gui app launch 'knows' that this program doesnt need a console window so stdout is piped to a bitbucket. I had the same issue in the c# -> c++ version. The secret here is to create a console window and reattach stdout to it.
solution 2
Reaches for winapi crate.
unsafe {
let ff = winapi::um::wincon::FreeConsole();
let ret = winapi::um::consoleapi::AllocConsole();
let err = winapi::um::errhandlingapi::GetLastError();
};
FreeConsole just to detach if we are connected to something weird. Then AllocConsole creates a console window and connects the process to it, not wired up to anything yet though. So now wire the new console window to stdout:
let file = OpenOptions::new().write(true).read(true).open("CONOUT$").unwrap();
unsafe{
let err = winapi::um::processenv::SetStdHandle(winapi::um::winbase::STD_OUTPUT_HANDLE, file.as_raw_handle());
}
CONOUT$ is special name for the output buffer of the connected console window. SetStdHandle connects it to stdout.
Now a new window pops up next to the gui and all stdout writes appear there - whoo hoo.
This also works for vscode debugging. A new 'dos' window appears and the stdout appears there. An added bonus
Problem 3 need lower level access
In my original PDP engine in c++ I was not happy still using std::cout, I needed to get as close the the windows console subsystem as possible (I am emulating the behavior of a raw physical device for the PDP). So I decided to use direct windows IO in this new version
Solution 3
So still AllocConsole and open CONOUT$ but call the Console write directly
let buff: [u8; 1] = [ch];
let ptr: *const c_void = buff.as_ptr() as *const _ as *const c_void;
let mut cells_written: u32 = 0;
// write to console
unsafe {
WriteConsoleA(
file.as_raw_handle(),
ptr,
1,
&mut cells_written,
NULL,
) ;
};
file is the handle return by open of CONOUT$
Works nicely. I know I will need to do the same for stdin / CONIN$ at some point