windows: Set CREATE_NO_WINDOW for commands

[JunkuiZhang]

• Closes: [Windows] Multiple open and closed terminals at startup #18371

Release Notes:

• N/A

[CharlesChen0823]

I think the best method should be introduce an file name command in util crate, in here, create new_std_command and new_smol_command with set CREATE_NO_WINDOW. we can use the two function everywhere, don't need hacky everywhere.

[JunkuiZhang]

I think the best method should be introduce an file name command in util crate, in here, create new_std_command and new_smol_command with set CREATE_NO_WINDOW. we can use the two function everywhere, don't need hacky everywhere.

That's my next move. The idea of this draft PR is that making a quick demo to see if it could fix the issue. If so, then I'm gonna refactor the codes.

[SomeoneToIgnore]

Is it really the only way we can enable window-less command invocations in Windows?
Feels very fragile, as every other plugin that forgets about Windows and this behavior, will bring the pop-ups back.

[CharlesChen0823]

Is it really the only way we can enable window-less command invocations in Windows? Feels very fragile, as every other plugin that forgets about Windows and this behavior, will bring the pop-ups back.

I think this is only way

[SomeoneToIgnore]

This is very very odd, but then I think #19018 is not that bad if it's a documented single entry for all such plugin invocations.

I'll leave the review (and the choice) to the person who knows things better than me though.

[JunkuiZhang]

Is it really the only way we can enable window-less command invocations in Windows? Feels very fragile, as every other plugin that forgets about Windows and this behavior, will bring the pop-ups back.

I'm afraid this is indeed the case. std::process::Command::new(...).spawn() internally calls CreateProcess, as seen here:

cvt(c::CreateProcessW(
    program.as_ptr(),
    cmd_str.as_mut_ptr(),
    ptr::null_mut(),
    ptr::null_mut(),
    c::TRUE,
    flags,
    envp,
    dirp,
    si_ptr,
    &mut pi,
))

According to Microsoft's documentation, if you don't want the window to appear, you can set dwCreationFlags to include CREATE_NO_WINDOW, or configure other settings. But in any case, we always need to set some variables.

Moreover, in Windows programming, whether a window is displayed by default when calling CreateProcess depends on the parent process. If the parent process already has a console window, then the call to CreateProcess will not create a new window but will reuse the existing one. This explains the behavior when compiling Zed in debug mode—Zed is treated as a console app and thus has a console window. As a result, std::process::Command does not create a new window. In release mode, however, Zed doesn't have a console window, so std::process::Command always creates a new one.

[JunkuiZhang]

I referenced VSCode's code here to introduce util::command::new_std_command and util::command::new_smol_command. If we decide not to proceed with this approach, we can easily revert to the previous commit.

Additionally, since VSCode's code is under the MIT license and the crate util uses the APACHE license, would there be any issue?

[MrSubidubi]

Suggested change

	const CREATE_NO_WINDOW: u32 = 134217728u32;
	const CREATE_NO_WINDOW: u32 = 0x08000000;

Small nitpick, but I believe this to be the more readable and understandable representation for the flag.

[JunkuiZhang]

Thx!

[MrSubidubi]

No worries, thank you for all your awesome contributions for the community!

[kelvinchin12070811]

Just let them do their work, seems like they are too busy at ssh remote dev and no time for other issues. JunkuiZhang seems to be the only Windows dev that they have which is currently active and he's human too, and there's still a lot of issues for him to fix.

[eternalphane]

Can we have this merged please, so annoying to have those terminal popups exploding like fireworks on my face every time I use Zed

@teknalb You can cherry-pick this PR and build it by yourself if you're really concerned

[teknalb]

You can cherry-pick this PR and build it by yourself

@eternalphane Yep, that's exactly what I ended up doing.

[shenjackyuanjie]

It looks like we need tokio::process::Command wrapper @JunkuiZhang

[JunkuiZhang]

It looks like we need tokio::process::Command wrapper @JunkuiZhang

I'll to continue with this PR once the Zed team has decided on which approach to take.

[shenjackyuanjie]

for anyone who want to use this branch's work, check out https://github.com/shenjackyuanjie/zed-win-build/releases
and I am maintaining a temporary branch https://github.com/shenjackyuanjie/zed/tree/temp/cmdfix

[codecooker1]

Seems cool. There doesn't seems to be any malicious code hidden (I think) :P

[mikayla-maki]

Thank you!