Systemcluster / wrappe

Packer for creating self-contained single-binary applications from executables and directories. Distribute your application without the need for an installer, with smaller file size and faster startup than many alternatives 📦

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Usage on Windows causes shell prompt issues

Silic0nS0ldier opened this issue · comments

Bug description
Invocations of wrapper output on Windows don't play well with the shell prompt. It appears at least once for the initial process creation (startpe 0.0.0 ...), appears multiple times when batch scripts are used (may be just how batch scripts work, I know little about them), and the prompt for the next command is missing but has stdin appear at the correct indent level.

Reproduction steps
Run generated wrapper on Windows via PowerShell, Cmd, etc.

image

Note the odd prompt presence.

Additional context
Nope

commented

On Windows this is a bit tricky. Windows programs are either console subsystem programs, which will work properly in a console but always create a console window on start when started from the explorer, or windows subsystem programs, in which they don't create one either way. See here for more details. Currently the Windows runners are all compiled for the windows subsystem and either manually attach to a console when available, or create a new one when packed with the show-console argument.

AttachConsole with windows subsystem programs doesn't work as one might hope; As the child program is detached, while its outputs are redirected to the parent console the parent console acts like the child isn't running. So I assume this issue is caused by outputs of the child program intermingling with the parent console.

One option to work around this would be compiling an additional runner for the console subsystem as a choice next to the windows subsystem one. This still leaves the issue with .wait()/stdin though.

commented

Actually it seems like .wait() doesn't preclude the child process from accessing stdin, just the parent process from accessing it. So a console-subsystem runner would solve this.

I'm currently working on a PE file resource editor to include in wrappe, which would allow just setting a flag in the windows header while packing without needing two separate runners. Until then I'm alright with switching the Windows runner to the console subsystem and accept a console window flashing up when starting a GUI application.

commented

The runner in the latest snapshot now waits on the spawned child process. Could you check if that solves the problem for you? It should also solve the issue on the other platforms 😄

Working MUCH better now, prompt is showing up only where it would be expected.

One thing I will note. .wait() will terminate stdin (to avoid deadlocks in normal usage). This can be avoided by taking ownership of the stdin handle before calling .wait().

See https://docs.rs/tokio/1.18.1/tokio/process/struct.Child.html#:~:text=If%20the%20caller%20wishes%20to%20explicitly%20control%20when%20the%20child%E2%80%99s%20stdin%20handle%20is%20closed%2C%20they%20may%20.take()%20it%20before%20calling%20.wait()%3A