Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change Windows OS to support default terminal [defterm] #492

Closed
Tracked by #5000
dhrdlicka opened this issue May 7, 2019 · 33 comments · Fixed by #7489
Closed
Tracked by #5000

Change Windows OS to support default terminal [defterm] #492

dhrdlicka opened this issue May 7, 2019 · 33 comments · Fixed by #7489
Assignees
Labels
Area-Server Down in the muck of API call servicing, interprocess communication, eventing, etc. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Tag-Fix Doesn't match tag requirements Product-Conhost For issues in the Console codebase Work-Item It's being tracked by an actual work item internally. (to be removed soon)
Milestone

Comments

@dhrdlicka
Copy link

dhrdlicka commented May 7, 2019

This issue tracks the work required to add "default terminal" support to Windows.

This is not terminal-specific, but Windows Terminal will benefit from it.

original content

This bug-tracker is monitored by Windows Console development team and other technical types. We like detail!

If you have a feature request, please post to the UserVoice.

Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues. Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible

  • Your Windows build number: Microsoft Windows [Version 10.0.18885.1001]

  • What you're doing and what's happening: When I type start in a command prompt session in the Windows Terminal, the new command prompt window opens in a new conhost window.

  • What's wrong / what should be happening instead: The new command prompt should open in a new tab in the existing Terminal window.

@zadjii-msft
Copy link
Member

This is by design.

We have plans to support setting another application as the "default terminal" on Windows, but those plans are still very rough and in the works.

@zadjii-msft zadjii-msft added the Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. label May 7, 2019
@zadjii-msft zadjii-msft added this to the Backlog milestone May 7, 2019
@miniksa
Copy link
Member

miniksa commented May 9, 2019

This will require an OS feature. I'm updating the title to represent the default terminal OS change.

@miniksa miniksa added the Work-Item It's being tracked by an actual work item internally. (to be removed soon) label May 9, 2019
@miniksa miniksa changed the title cmd's start command opens a new conhost window instead of a new Terminal tab Change Windows OS to support default terminal May 9, 2019
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label May 17, 2019
@miniksa miniksa added Area-Server Down in the muck of API call servicing, interprocess communication, eventing, etc. Product-Cmd.exe The issue is related to the legacy command interpreter, CMD.exe. and removed Mass-Chaos labels May 17, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 18, 2019
@miniksa miniksa added Needs-Tag-Fix Doesn't match tag requirements Product-Conhost For issues in the Console codebase and removed Product-Cmd.exe The issue is related to the legacy command interpreter, CMD.exe. labels May 18, 2019
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label May 18, 2019
@DHowett-MSFT DHowett-MSFT changed the title Change Windows OS to support default terminal Change Windows OS to support default terminal [defterm] Jul 8, 2019
@DHowett-MSFT
Copy link
Contributor

I'm renaming this to add the [defterm] keyword to the end so that we can find it easily in searches. The words "default" and, well, "terminal" come up alarmingly often in this repository. 😄

@LukePrior
Copy link

I hope this gets added sooner rather than later, are there any working unofficial workarounds?

@DHowett
Copy link
Member

DHowett commented May 19, 2020

Rest assured that this issue would have had hundreds of community comments making up all sorts of crazy workarounds if there were any ;)

@asche910
Copy link

I have a idea for some basic bat file:
run your bat file in background and then close the default cmd window

START /B  wt cmd /c yourfile.bat
exit

@shauniv
Copy link

shauniv commented May 25, 2020

Rest assured that this issue would have had hundreds of community comments making up all sorts of crazy workarounds if there were any ;)

I have been starting cmd (and now powershell) from Win+R for decades, but I am painfully retraining myself to type wt instead. I guess you can teach an old dog new tricks. Slowly. 😁

This works thanks to the app execution alias wt.exe in %userprofile%\AppData\Local\Microsoft\WindowsApps

@Karl-WE
Copy link

Karl-WE commented May 25, 2020

Hi team, users, since wt has now very good set of options and a preset settings json and a user defineable part which also includes the setting, which console is the default console to be opened when launching wt - I thought it would be sufficient to pick up all the rough plans (#492 (comment)) to pick up at least the following attempt:

Integration of Win+X.

How I think you can accomplish this:

  • connect with Jennifer Gentlemen and team for settings

  • add a new settings item that is able to replace or update the following setting to launch wt instead powershell or cmd

  • update the ADMX file accordingly so it can be set via GPO, too

  • caveat: wt needs to be installed by the user

  • the user can use the default console option to specify which shall be opened by default from there

like
"profiles": [ "defaultProfile": "{574e775e-4f2a-5b96-ac1e-a2962a402336}" { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell 7", "source": "Windows.Terminal.PowershellCore", "useAcrylic": true }, ],

Settings > Personalisation > Taskbar

"replace Win+X cmd with powershell"

replace-command-prompt

Maybe it is a naive point of view of a user, yet I cannot imagine that it is possible to switch cmd to Powershell at this point for years now, but not making the small step forward to replace these two items again with wt. And yes it would make sense this way having wt with and without admin rights, as per default it is also unelevated like every other console (with few exceptions)

show-windows-powershell

Can you please elaborate why this is so much work to do? It would be a beginning.

Having the choice of a default terminal application in Settings > Apps and Features > Default app - I can understand this requires more under the hood work. I double checked with NirSoft ShellExView that this can not be that easily achieved at the moment.

However changing the Win+X setting mentioned above is already something that is there.
Please mind there is even a 3rd party tool that can change the Win+X menu to anyones liking but the download source I would nowadays rather rate untrusted.

You can find the tool here but use at your own risk
Win+X Menu Editor
Created by Sergey "Happy Bulldozer" Tkachenko
http://winaero.com
This software uses the hashlnk tool source code
hashlnk was created by Rafael Rivera
http://www.withinwindows.com/

Hope I am allowed to post this reference otherwise please remove it. If I may upload the app as a zip or Onedrive please let me know. There is no hint that it is not allowed to mirror it elsewhere.

@Karl-WE
Copy link

Karl-WE commented May 25, 2020

p.s. I've tried myself to Add wt into a new group in Win+X menu but for some unclear reason it fails to do so. Permissions seem about right. I can add any file as a link except things from
%localappdata%Microsoft\WindowsApps (even with full path).

wt

I am curious what prevents this by design. It seems because the apps there are 0 kb sized files and some kind of symlink? In Task Manager you also cannot "open the location" of a wt process. I suspect this is the nature of app virtualization of MS apps. Also applies to other like Edge Chromium, notepadS etc.

Given this information and circumstances I might now grasp why it is so hard to accomplish this change. You cannot access it from explorer, but you can launch it from Win+R / search. How weird.

@thlac
Copy link

thlac commented May 25, 2020

You can't add wt.exe directly, as it's not a "real file", but if you create a shortcut to wt.exe, the tool will be able to add it and it'll work just fine.

You can read more about it here: https://www.hanselman.com/blog/TotallyUnsupportedHacksAddWindowsTerminalToTheWinXShortcutMenu.aspx

@Karl-WE
Copy link

Karl-WE commented May 25, 2020

If I understand the function of WinX correctly Windows does not do links by path only, probably to prevent spoofing but also generating a hash of the file. Since all "apps" have zero filesize the "cannot open" might be due to not being able to generate the hash, probably not because not being able to access / read it.

Thanks for the reference thlac @shanselman this makes it even harder to understand why there is no official way. Ofc having a shortcut to a file exposes a risk of tampering it, what seems to contradict the original design idea of WinX not being easily tampered.
The risk is infact that PUA / malware could change targets in this menu.

@skrysmanski
Copy link

@Karl-WE Just wanted to make sure everyone is on the same page here. Windows Terminal is a terminal/console application - not a shell. Cmd and PowerShell are shells. (See also: https://www.hanselman.com/blog/WhatsTheDifferenceBetweenAConsoleATerminalAndAShell.aspx)

So the Win+X setting is (IMHO) irrelevant for this issue (as it just determines the shell, not the terminal application).

@Karl-WE
Copy link

Karl-WE commented May 25, 2020

I understand your definition. At the end, given the many same requests, WinX does help to make Windows Terminal

  • more prominent, which can only aid its success and spread and ultimately honor the work spent.

  • help users to make their favourite default shell more accessible.
    Which might be not cmd or PoSh 5.1 as configurable at the moment.

Seeing it in this light, I still agree with your noted difference but in the end the goal is to help making a shell easier to access while having the better features of terminal compared to the default console.

@DHowett
Copy link
Member

DHowett commented Jun 13, 2020

@nu8 you’ll probably agree that “replacing your system conhost with the version of conhost built out of this repository” and “having Windows launch an instance of Terminal automatically” are vastly different things ;)

This repository hosts both the console host and the Terminal. One builds on the other, but they are certainly not the same.

@Karl-WE
Copy link

Karl-WE commented Jun 15, 2020

@nu8 given the vast amount of things @DHowett has to review and triage sometimes there maybe differences. As you quoted it is clear that 492 in timeline came before 1817 and things can change.
it would be more irritating if he posted it other way around. But however:

the good news is: it is on the schedule, no longer in the backlog

see

1 | Default terminal | If a command-line application is spawned, it should open in Windows Terminal (if installed) or your preferred terminal
Issue: #492
Spec: #2080

source: https://github.com/microsoft/terminal/blob/master/doc/terminal-v2-roadmap.md

@electronic-dk
Copy link

@DHowett thank you for your work around here, I have a small question:
Do you think we could expect this to roll out in 20h2 or 21h1 windows' update? Are you aware of any internal work (on OS level) going in this direction?
I understand that plans may change, but I'm still curious :)

@zadjii-msft
Copy link
Member

We're the team that would have to do the OS-level work to enable this feature, so I'd be very surprised if we weren't aware of work being done to enable this.

We're still just getting past the 1.0 release of the Terminal, so we haven't really gotten a start on this quite yet. I'd say it's unlikely to land in 20H2 or 21H1, considering we'd probably have to have the feature done (or at least prototyped) by now to get it in to either of those releases.

@lightrow

This comment has been minimized.

@DHowett
Copy link
Member

DHowett commented Jun 24, 2020

Because this issue has so many subscribers, I'm going to lock it.
If you have something to contribute that will impact the engineering direction for this feature, please e-mail me at the address on my GitHub profile.

@microsoft microsoft locked as off-topic and limited conversation to collaborators Jun 24, 2020
@miniksa miniksa self-assigned this Aug 14, 2020
@ghost ghost added the Needs-Tag-Fix Doesn't match tag requirements label Mar 26, 2021
DHowett pushed a commit that referenced this issue Mar 26, 2021
- Implements the default application behavior and handoff mechanisms
  between console and terminal. The inbox portion is done already. This
  adds the ability for our OpenConsole.exe to accept the incoming server
  connection from the Windows OS, stand up a PTY session, start the
  Windows Terminal as a listener for an incoming connection, and then
  send it the incoming PTY connection for it to launch a tab.
- The tab is launched with default settings at the moment.
- You must configure the default application using the `conhost.exe`
  propsheet or with the registry keys. Finishing the setting inside
  Windows Terminal will be a todo after this is complete. The OS
  Settings panel work to surface this setting is a dependency delivered
  by another team and you will not see it here.

## Validation Steps Performed
- [x] Manual adjust of registry keys to the delegation conhost/terminal
  behavior
- [x] Adjustment of the delegation options with the propsheet
- [x] Launching things from the run box manually and watching them show
  in Terminal
- [x] Launching things from shortcuts and watching them show in the
  Terminal   

Documentation on how it works will be a TODO post completion in #9462

References #7414 - Default Terminal spec

Closes #492
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Area-Server Down in the muck of API call servicing, interprocess communication, eventing, etc. Issue-Feature Complex enough to require an in depth planning process and actual budgeted, scheduled work. Needs-Tag-Fix Doesn't match tag requirements Product-Conhost For issues in the Console codebase Work-Item It's being tracked by an actual work item internally. (to be removed soon)
Projects
None yet
Development

Successfully merging a pull request may close this issue.