fix(shim): allow GUI applications to attach to the shell's console when launched using the GUI shim

[spider2048]

Description

Allows patched GUI shims to access the shell's console window.

Motivation and Context

Fixes issues described in #5559 (for the scoopcs shim type)

How Has This Been Tested?

The new shim code only tries to AttachConsole to the parent process, so that it gets the console handles (when it doesn't find a console window). Now, the target process which the shim starts can also request for the same console handles and it can write to the shell's terminal.

Validation steps:
Let's use alacritty.
We know that, alacritty.exe is a GUI application, but we have:

$ &(scoop which alacritty) -V
alacritty 0.12.3 (5efb069)

If we don't use this PR, we would not have this output, because the target process (alacritty) fails to get handles to the shell's console.

$ alacritty -h

But, if we use this PR:

$ scoop config shim scoopcs
$ scoop update -f alacritty
$ alacritty -V
alacritty 0.12.3 (5efb069)

This PR would restore the behaviour of GUI+CLI applications and avoids the need to implement new flags or adjust the manifests.

Checklist:

• I have read the Contributing Guide.
• I have ensured that I am targeting the develop branch.
• I have updated the documentation accordingly.
• I have updated the tests accordingly.
• I have added an entry in the CHANGELOG.

[goyalyashpal]

is it released? if yes, then to which version or with what indication?

i am asking as i want to confirm if the non-confirmant thing i am seeing applies or not.

[spider2048]

@goyalyashpal It is merged in to develop, will be merged to master in 0.4.0. You can track the progress of the release in #5424. And what do you mean by a non-confirmant thing?

[goyalyashpal]

what do you mean by a non-confirmant thing?

glad u asked 😄

quote

Validation steps: Let's use alacritty. We know that, alacritty.exe is a GUI application, but we have:

$ &(scoop which alacritty) -V
alacritty 0.12.3 (5efb069)

If we don't use this PR, we would not have this output, because the target process (alacritty) fails to get handles to the shell's console.

$ alacritty -h

@ spider2048 at #5721 (comment)

i guess i am seeing the behaviour which is shown as output of this pr already in v0.3 :

$ which alacritty
/d/UserFiles/scoop/shims/alacritty

$ alacritty -V
alacritty 0.13.1 (fe2a3c5)

$ $(scoop which alacritty) -V
alacritty 0.13.1 (fe2a3c5)

$ alacritty -h
A fast, cross-platform, OpenGL terminal emulator
...

$ scoop -V
Current Scoop version:
v0.3.1 - Released at 2022-11-15

[spider2048]

@goyalyashpal seems like you are on the master branch. If you don't have this problem, you would have the shim blocking your CLI.

[goyalyashpal]

seems like you are on the master branch

how can i confirm that?

you would have the shim blocking your CLI.

but it does with some other GUI applications. i always used to think that this blocking behaviour is application dependent.

for examples (these all are scoop installed pplications:)

• run alacritty -> launches alacritty GUI, blocks CLI
• wezterm -> launches wezterm GUI, blocks
• wezterm -V -> performs within CLI
• notepad3 <file> -> launches GUI, blocks

non-scoop application:

• codium <file> -> launches GUI, still non-blocking

the notepad3, and wezterm behaved same (blocking in GUI) when it was non-scoop application too.
and i'd bet that vscodium would stay the same too (non-blocking GUI) despite getting installed with scoop.

$ which notepad3 alacritty wezterm codium
/d/UserFiles/scoop/shims/notepad3
/d/UserFiles/scoop/shims/alacritty
/d/UserFiles/scoop/shims/wezterm
/c/Program Files/VSCodium/bin/codium

[spider2048]

@goyalyashpal

how can i confirm that?

By using scoop config

% scoop config
last_update           : 25-03-2024 01:31:18 AM
aria2-warning-enabled : False
shim                  : scoopcs
scoop_repo            : https://github.com/ScoopInstaller/Scoop
scoop_branch          : develop

You can switch to the develop branch by:

$ scoop config scoop_branch develop
$ scoop update

but it does with some other GUI applications. i always used to think that this blocking behaviour is application dependent.

It depends on the shim as we use the shim to launch applications. Now, the default shim in the master branch is a CLI shim, which would always have a terminal window. The nature of the application is characterized by the Subsystem flag in the PE File Format.

for examples (these all are scoop installed pplications:) ...

Let's look at your examples:

1. alacritty is a GUI binary - it should not be supposed to have a CLI window
2. wezterm is a CLI binary, you are supposed to use wezterm-gui if it should not block
3. wezterm -V should perform within CLI as it is a CLI binary
4. notepad3 is a GUI binary, and should not be supposed to block

To fix apps which should not be blocking, my PRs would correct the Subsystem field in the shim binary. So, ideally, if you are using the develop branch, you should be having only the CLI binaries to block and GUI binaries to detach. #5559

Just in case if a GUI app wants to write to a console using

AttachConsole(-1);

It won't be able to obtain handles to our shell which we used to launch. So, this PR would solve this issue in the scoopcs shim type, as we don't have direct access to the kiennq shim type.

I would advise you to avoid the kiennq shim, as it just had memory issues while parsing a 100+ character long string in the arguments. (comments in #1606)

Coming to codium or code, they are shell scripts:

$ which code
D:\Tools\Sceoop\apps\vscode\current\bin\code.cmd

So they would always have a console window until they start the actual application.

Finally, move to the develop branch. The version which you are using seems to be too old and as scoop has not yet issued a release.

[goyalyashpal]

seems like you are on the master branch
By using scoop config

on point 👍 😃

$ scoop config | yq .scoop_branch,.scoop_repo
master
https://github.com/ScoopInstaller/Scoop

4. notepad3 is a GUI binary, and should not be supposed to block
To fix apps which should not be blocking, my PRs would correct the Subsystem field in the shim binary. So, ideally, if you are using the develop branch, you should be having only the CLI binaries to block and GUI binaries to detach. #5559

ohkayh. awesome.

I would advise you to avoid the kiennq shim

i am very novice to scoop and shims. so, i don't even know what these types are or how to configure anything about it. but i'll keep in mind when i gain more xp with scoop.

Finally, move to the develop branch. The version which you are using seems to be too old and as scoop has not yet issued a release.

thanks for rec. i will in some days 😄

---

ps:

we both should be sleeping deep at this odd hour of night lol. hopefully big fest today day 😆💦🔫🌊🎈