elgonzo

cmd.exe works fine as far as i can tell. That's where i did all my testing before i did some checks in PS. PS also works fine unless you do a cls beforehand. I didn't notice it earlier, because i didn't do a cls while testing in PS. Only now when i was dealing with the puts replacement in the RestoreConsolePrompt function that i mentioned earlier i stumbled over the weird PS thing triggered by cls... UPDATE: "PS also works fine unless [...]" my arse!!! Piping works fine PS, like .\foo.exe | more,...

cmd.exe works fine as far as i can tell. That's where i did all my testing before i did some checks in PS. PS also works fine unless you do a cls beforehand. I didn't notice it earlier, because i didn't do a cls while testing in PS. Only now when i was dealing with the puts replacement in the RestoreConsolePrompt function that i mentioned earlier i stumbled over the weird PS thing triggered by cls... UPDATE: "PS also works fine unless [...]" my arse!!! Piping works fine PS, like .\foo.exe | more,...

cmd.exe works fine as far as i can tell. That's where i did all my testing before i did some checks in PS. PS also works fine unless you do a cls beforehand. I didn't notice it earlier, because i didn't do a cls while testing in PS. Only now when i was dealing with the puts replacement in the RestoreConsolePrompt function that i mentioned earlier i stumbled over the weird PS thing triggered by cls...

One more update re BackupAndRemoveConsolePrompt and RestoreConsolePrompt functions. I just noticed some strange issue triggered by the cls command in Powershell. Issuing a cls and then running my demo program (as shown in the gist), outputs correctly, with RestoreConsolePrompt placing the prompt and cursor at the right position correctly, as it is supposed to be. However doing cls before leads to PS now believing the input position to be the old cursor position before the cursor position has been...

One more update re BackupAndRemoveConsolePrompt and RestoreConsolePrompt functions. I just noticed some issue with triggered by the cls command in Powershell. Issuing a cls and then runnging my demo program (as shown in the gist), RestoreConsolePrompt places the prompt and cursor at the right position correctly. However doing cls before leads to PS now believing the input position to be the old cursor position before the cursor position has been changed by `RestoreConsolePrompt. Which means, now...

One more update re BackupAndRemoveConsolePrompt and RestoreConsolePrompt functions. I just noticed that for some (so far unknown) reason, despite RestoreConsolePrompt placing the prompt and cursor at the right position correctly, PS seems to track the input positions separately from the cursor position. Which means, typing (or recalling a command from the history) appears at the old unadjusted cursor position. Weird. I therefore would suggest to not use BackupAndRemoveConsolePrompt and RestoreConsolePromptas...

Here i am going to outline a solution to have working console output while also having working stdout/stderr redirects without needing "magic" CLI incantations such as -no-redirect-streams. Unfortunately, i am currently ill-equipped to get the tool-chain running for building VICE from source, hence why i also currently unable to submit my code suggestion as a diff or PR. And i don't know when i would be able to find enough time to get it all set up properly, so for the time being it's just me here...

I just noticed a mistake i made in the implementation of RestoreConsolePrompt. I used puts there to output a newline (can't manipulate the cursor position directly here, as the last output might be at the end/bottom of the console buffer, hence have to ensure a possibly needed shift of the lines in the console buffer). Which is fine if stdout is not redirected. But if stdout is redirected and stderr is not, RestoreConsolePrompt can't use puts, obviously. Need to replace it with a call to the WinApi...