Windows: Can't get past the `Logging in and updating...` screen

While steam-tui builds just fine on Windows nowadays, I can't get past this screen:

That screen shows up just after you type your Steam username and hit Enter.

It looks like steam-tui spawns steamcmd.exe just fine:

But my guess is that when steam-tui sends the login <user> command to steamcmd.exe, that doesn't actually work... And yes, I have followed what the README says.

I'm not a Windows programmer (though I occasionally use it for gaming), so I'm not sure how to debug this further...

Originally posted by @guihkx in #48 (comment)

Now-days? Did it work before? Try flushing your cache by deleting ~/.cache/steam-tui/*

I don't know if redirecting works on windows, but can you try steam-tui 2> error.log

Now-days? Did it work before?

As far as I know, previously steam-tui wouldn't even build on Windows, right?

So what I meant to say is that, currently, steam-tui builds cleanly on Windows without any modifications.

Try flushing your cache by deleting ~/.cache/steam-tui/*

That did nothing, unfortunately.

I don't know if redirecting works on windows, but can you try steam-tui 2> error.log

Redirecting stderr to a file works (with PowerShell 7, at least), because I've added some eprintln!() calls in some places and they showed up in the file, but unfortunately none of the log!() messages you've added show up.

But I suppose I can replace every log!() call by eprintln!() and see what happens. I'll do that shortly.

You can just update the log definition:

steam-tui/src/util/log.rs

Line 4 in f5d2a4f

eprintln!(concat!($(concat!(stringify!($elem), " - {:?}\n")),+), $($elem),+);

The conditional probably doesn't work on windows

You mean like this, correct?

diff --git a/src/util/log.rs b/src/util/log.rs
index 6f2c41e..994d3c5 100644
--- a/src/util/log.rs
+++ b/src/util/log.rs
@@ -1,8 +1,6 @@
 macro_rules! log{
     ($($elem: expr),+ ) => {
-        if !atty::is(atty::Stream::Stderr) {
-            eprintln!(concat!($(concat!(stringify!($elem), " - {:?}\n")),+), $($elem),+);
-        }
+        eprintln!(concat!($(concat!(stringify!($elem), " - {:?}\n")),+), $($elem),+);
     };
 }

Unfortunately, error.log is empty...

Yep!

I've added this:

diff --git a/src/interface/steam_cmd.rs b/src/interface/steam_cmd.rs
index 2c7abad..d64d4c1 100644
--- a/src/interface/steam_cmd.rs
+++ b/src/interface/steam_cmd.rs
@@ -39,10 +39,12 @@ impl SteamCmd {
         let mut cmd = SteamCmd::with_args_and_seperator(args, 0x1b)?;

         // Send start up data I guess yeah?
+        eprintln!("calling next() 4 times...");
         cmd.next();
         cmd.next();
         cmd.next();
         cmd.next();
+        eprintln!("done calling next() 4 times.");

         Ok(cmd)
     }

And the log file only shows the first message, and never the second one, even after I waited a couple of minutes.

Do you think the issue is somehow related to that?

Oh, it's empty. Are you using cargo run?

So the program is a little brittle. It's basically just writing and reading from steamcmd, and there's a chance it can hang if it doesn't think that it's received everything it should have from steamcmd.

The windows prompt response might be different in terms of line endings or special characters or something else. This is probably the most important log, since it should just show what the steamcmd output is:

steam-tui/src/client.rs

Line 427 in f5d2a4f

log!(prompt);

Are you using cargo run?

Nope, I'm building with cargo build and then running like .\target\debug\steam-tui.exe 2> err.txt

and there's a chance it can hang if it doesn't think that it's received everything it should have from steamcmd.

Hmmm, I see.

The windows prompt response might be different in terms of line endings or special characters or something else

That's actually a good guess! But I'll have look it up because I have no idea how the Windows console works.

log!(prompt);

Yeah, that doesn't show up in the log file at all...

Definitely a line scrubbing issue. Try putting a print between each. If the first one is failing, then remove the whole block?

You might be able to find the separator character in windows. The 0x1b is what's used in linux and is the escape character: http://www.csc.villanova.edu/~tway/resources/ascii-table.html

steam-tui/src/interface/steam_cmd.rs

Line 39 in f5d2a4f

let mut cmd = SteamCmd::with_args_and_seperator(args, 0x1b)?;

If you can invoke steamcmd, play around with it (examine some game IDs) and send me the raw file, I might be able to help you further. I'm just guessing as is

does power shell have tee https://stackoverflow.com/questions/52970939/right-usage-of-21-tee-or-tee-with-powershell?

Thank you for all the suggestions!

After investigating and learning a bit more about Windows, I'm afraid this will not be feasible with only std::process::Command + std::io:BufReader.

I might be off on the actual technical details, but from what I understand, the issue was never about lack of support for ANSI escape characters, as those were added in Windows 10. Instead, the issue is related to how processes are spawned and handled on Windows compared to Linux.

Windows 10 introduced ConPTY, which I think is aimed to behave closer to what we have on Linux.

This is just my guess, but this won't work without ConPTY because whatever Windows uses to spawn processes by default, causes stdout to be buffered until a new line character gets outputted, and so that's why we never reach the Steam> prompt on Windows.

I've been experimenting with this dependency, and I wrote a test program that spawns steamcmd on this ConPTY thing, and at least now the Steam> prompt can be seen, and therefore we can jump to the 0x1b separator character as well.

Anyway, I'm still not 100% sure if this will work, but it does looks very promising.

The next step, I suppose, is implementing conpty on steam-tui itself. I can give it a shot, but I'm also not a very good Rust programmer, so it's very likely it will be a crap implementation. :)

Hmmm, very interesting.

I say go for it, learning rust is fun and a good skill to have.

I do have a suggestion that's a bit more of a hack:
Input a new line before every read kind of like this block that just keeps writing "" until it gets the it detects the prompt. Maybe experiment with writing new lines too.

Nvm, looks like conpty is part of this https://github.com/zhiburt/expectrl?tab=readme-ov-file
I think this could be a better solution to the handrolled code I have right now.

Happy to review any conpty solutions - but this might be a quick work around.