Though I've been enjoying WT, there are some limitations that have bit me:
1) As a 'Store' app, it can be a pain to install in locked-down corpo networks that block Windows Store. Winget can be a workaround, or you can extract the exe from packages, but an installer would be nice.
2) Since it's a UWP app, there's no way to launch it as another user-identity (i.e. runas)
How do you get that to work? I've tried changing the settings to open new terminal windows using a different identity (runas), but they are then separate from the terminal app.
I basically would just like to be able to dock that new window in the existing terminal tabs, as otherwise, I might as well just launch a PoSH prompt.
> Since it's a UWP app, there's no way to launch it as another user-identity (i.e. runas)
This is possible, the only issue is that the app needs to also be installed on the other user’s profile. Once installed for the user you can use runas.exe to start wt.exe as another user. I believe the UX from the right menu needs improvement but it is possible.
Note: Windows Terminal requires Windows 10 2004 (build 19041) or later
Microsoft Store [Recommended]
Install the Windows Terminal from the Microsoft Store. This allows you to always be on the latest version when we release new builds with automatic upgrades.
This is our preferred method.
Other install methods
Via GitHub
For users who are unable to install Windows Terminal from the Microsoft Store, released builds can be manually downloaded from this repository's Releases page.
Download the Microsoft.WindowsTerminal_<versionNumber>.msixbundle file from the Assets section. To install the app, you can simply double-click on the .msixbundle file, and the app installer should automatically run. If that fails for any reason, you can try the following command at a PowerShell prompt:<<
I am glad to see scoop called out in the list of installation methods. I use scoop and like the idea behind scoop. Applications should install in my user_profile when possible and should only require sudo when it isn't possible.
All new application in $current_year should install as $current_user_scope by default. I hate how applications (looking at you, Google Chrome) try to install a scheduled task to keep itself updated. All of this should be up to the package manager. If I want to update the client application, I will do so myself.
And the winget version updates automatically with the Microsoft Store (not that that matters much if you are into using scoop/choco, since you know to just scoop upgrade)
Apple should follow MS's example and open source its Terminal.app
It's a decent terminal emulator, but could use several enhancements and the community could help.
For some reason I haven't changed to iTerm yet, even though it's been objectively better in every way for years.
Even the minor gripe I had with font rendering is fixed.
There's something about using default apps as much as possible that appeals to me. But Terminal.app is lagging compared to the competition.
> It's a decent terminal emulator, but could use several enhancements and the community could help.
It's the only modern terminal that passes the VT torture test. It supports double width and double height characters (great for terminal error messages).
It doesn't support overline (which is awesome for status lines at the bottom of the screen) and requires font support for line drawing and block graphics (Unicode 13 introduced 2x3 blocks and the next one will introduce 2x4s).
> There's something about using default apps as much as possible that appeals to me
For me it's one less thing to distract my distraction-prone brain.
Better keyboard only text selection, vertical/horizontal splits (I know about tmux, I still prefer scrolling and searching on true app), true color support, image visualizing would be nice.
> Apple should follow MS's example and open source its Terminal.app
This is bellyaching about nothing. Instead, Microsoft should follow Apple's example and open source the operating system. The only part of macOS that is not open source is the GUI, i.e. Quartz Compositor, and the gui applications. Microsoft, meanwhile, is an incredible slouch when it comes to open source, only very recently changing their hostile "embrace, extend, extinguish" stance towards OSS.
>Microsoft should follow Apple's example and open source the operating system
1. Apple did not open-source MacOS. Hell, I can't even buy a copy of it and run it on a PC but instead I have to buy Apple HW to get it, while at least I can download a copy of Windows and run it (even unregistered) on any cheap PC HW and develop SW for it, without paying for Microsoft hardware, or even for the OS itself (gray legal area), unlike Apple where the only way I can run MacOS and develop SW for it is by buying Apple hardware which is a far more restrictive way, from a monetary perspective, to get someone on board
2. Microsoft cannot open-source Windows as it contains a lot of third party code for which it has no licensing rights to open source. They've explained this multiple times. I assume the same applies to modern MacOS.
I was a Terminal.app user since Tiger, only recently had to switch to iTerm 2 as since Big Sur it forces anti-aliasing on non-HiDPI displays, even when turned off in the settings (I like non anti-aliased Monaco 10pt). It looks like a bug, but hasn't been fixed since.
If you use a font which doesn't have outline data Terminal.app and you set the rendered size to whatever is the native size of the font, Terminal.app will show you the unadulterated bitmap (if you use a multiple of the size, Terminal.app should scale it up without anti-aliasing).
I generate a .dfont without outline data based on a tweaked version of my favorite bitmap font, in Font Forge.
Now, if there is a way you can pre-render your favorite outline font to a bitmap and write it as a .dfont without outlines (other extensions may be fine, not sure though), you could switch back to Terminal.app. But font tools on GitHub etc. are very very few and never work that well, if they even do what they advertise at all.
There's an excellent blog post by the product manager I believe that explains the history of the CMD command, how terminal emulation works in Windows, and the work they were doing.
The way I understand this project is essentially "an interface" to the new ConPTY they developed (which IIRC is closed source, naturally).
That doesn't make it any lesser. I've used it since a build was available, 4 years ago or something. I love it.
So, one of the cool things about this repository (Hi! I’m the engineering lead for the Terminal/Console/… team. I’m biased!) is that it also contains the source for ConPTY and the rest of the Windows console host[1]. Every change made here flows back into Windows, and vice-versa.
In this repo, you can find some of our terrible secrets and workarounds and debugging hooks and perhaps even some explanation for why things work the way they do. Or don't work the way they should.
If you’re looking for a good[2] way to spend a few minutes, search for “LOAD BEARING” :)
[1]: If you build the “Host.EXE” project and copy the resulting OpenConsole.exe over %WINDIR%\System32\conhost.exe, it’ll work just fine and you’ll pick up a bunch of the console changes we’ve made in the past few years.
[2] Goodness not guaranteed, void where prohibited, etc.
EDIT: Oh, kaelinl mentioned this in a sibling comment to yours. Sorry about that! I've also reworded parts of the main comment body to flow better.
There are multiple projects in this repo. Windows Terminal, which the other commenters focus on, is a relatively new standalone app and not (yet?) bundled with the OS. They opted to open source it from the start, more or less. The other part is conhost, which is the classical terminal that has existed in Windows for decades. Some of the layout and rendering logic was pulled out of conhost to be shared with Terminal, and the two projects are maintained by the same team, so they open-sourced both. As I understand it, they then ship conhost and its shared components in Windows releases.
Probably the same reason they've opened sourced some other components lately: community feedback and updates.
There are a bunch of bugs in Windows core that I can't even get anyone to look at (and I'm an MVP). With these little bits they've opened sourced you can actively participate in helping the team fix the bugs, and add features as needed.
I know the team on Terminal had a whole muddle of problems to do with rendering recently that probably still needs some outside input. Even Microsoft's developers can't and don't know all the best ways to carry out tasks with their own APIs - there is just too much to learn.
Why pay employees to fix bugs when some random can fix it for free? It makes perfect corporate business sense. (Not saying its a good thing, but it does make sense from a business POV)
Not sure I'd really call this a component of the OS. It is a new app that works with various shells (including cmd, powershell, and WSL) to create a better experience using them including tabbed view so you can have multiple terminals from a single window.
the code has been open since the beginning of the project, IIRC... back when it was announced first, to get it to build, you needed to build it locally...
It might have vulnerabilities that a motivated attacker could discover by reading the source code. It might contain copied code that Microsoft doesn't have the right to distribute.
Not saying these are good reasons, but in a company whose main products are closed-source software, I'd expect some PM to make these objections.
> When did people stop calling them terminal emulators?
I don’t know when, but since their features have increasingly become divorced from any terminal (other than similar software) that they might be “emulating”, it makes sense.
It shall be noted, that it does not work on Windows Server up to and including 2019.
I would also like to add, that I am puzzled, that Microsoft has not been able to deliver a proper shell, that is comparable to …sh and delivers remote access like ssh. Yes, Powershell, but not by a long shot. And for some things you still need cmd!
Readit News
1) As a 'Store' app, it can be a pain to install in locked-down corpo networks that block Windows Store. Winget can be a workaround, or you can extract the exe from packages, but an installer would be nice.
2) Since it's a UWP app, there's no way to launch it as another user-identity (i.e. runas)
`choco install microsoft-windows-terminal`
Terminal itself can't be runas but e.g. cmd.exe or pwsh.exe inside of it can be.
I basically would just like to be able to dock that new window in the existing terminal tabs, as otherwise, I might as well just launch a PoSH prompt.
This is possible, the only issue is that the app needs to also be installed on the other user’s profile. Once installed for the user you can use runas.exe to start wt.exe as another user. I believe the UX from the right menu needs improvement but it is possible.
Deleted Comment
https://github.com/microsoft/terminal/releases/tag/v1.12.109...
>>Installing and running Windows Terminal
Microsoft Store [Recommended]Install the Windows Terminal from the Microsoft Store. This allows you to always be on the latest version when we release new builds with automatic upgrades.
This is our preferred method.
Other install methods
Via GitHub
For users who are unable to install Windows Terminal from the Microsoft Store, released builds can be manually downloaded from this repository's Releases page.
Download the Microsoft.WindowsTerminal_<versionNumber>.msixbundle file from the Assets section. To install the app, you can simply double-click on the .msixbundle file, and the app installer should automatically run. If that fails for any reason, you can try the following command at a PowerShell prompt:<<
All new application in $current_year should install as $current_user_scope by default. I hate how applications (looking at you, Google Chrome) try to install a scheduled task to keep itself updated. All of this should be up to the package manager. If I want to update the client application, I will do so myself.
It's a decent terminal emulator, but could use several enhancements and the community could help.
For some reason I haven't changed to iTerm yet, even though it's been objectively better in every way for years. Even the minor gripe I had with font rendering is fixed.
There's something about using default apps as much as possible that appeals to me. But Terminal.app is lagging compared to the competition.
It's the only modern terminal that passes the VT torture test. It supports double width and double height characters (great for terminal error messages).
It doesn't support overline (which is awesome for status lines at the bottom of the screen) and requires font support for line drawing and block graphics (Unicode 13 introduced 2x3 blocks and the next one will introduce 2x4s).
> There's something about using default apps as much as possible that appeals to me
For me it's one less thing to distract my distraction-prone brain.
This is bellyaching about nothing. Instead, Microsoft should follow Apple's example and open source the operating system. The only part of macOS that is not open source is the GUI, i.e. Quartz Compositor, and the gui applications. Microsoft, meanwhile, is an incredible slouch when it comes to open source, only very recently changing their hostile "embrace, extend, extinguish" stance towards OSS.
1. Apple did not open-source MacOS. Hell, I can't even buy a copy of it and run it on a PC but instead I have to buy Apple HW to get it, while at least I can download a copy of Windows and run it (even unregistered) on any cheap PC HW and develop SW for it, without paying for Microsoft hardware, or even for the OS itself (gray legal area), unlike Apple where the only way I can run MacOS and develop SW for it is by buying Apple hardware which is a far more restrictive way, from a monetary perspective, to get someone on board
2. Microsoft cannot open-source Windows as it contains a lot of third party code for which it has no licensing rights to open source. They've explained this multiple times. I assume the same applies to modern MacOS.
I generate a .dfont without outline data based on a tweaked version of my favorite bitmap font, in Font Forge.
Now, if there is a way you can pre-render your favorite outline font to a bitmap and write it as a .dfont without outlines (other extensions may be fine, not sure though), you could switch back to Terminal.app. But font tools on GitHub etc. are very very few and never work that well, if they even do what they advertise at all.
(iterm2 is great too)
The way I understand this project is essentially "an interface" to the new ConPTY they developed (which IIRC is closed source, naturally).
That doesn't make it any lesser. I've used it since a build was available, 4 years ago or something. I love it.
EDIT: Found it ! https://devblogs.microsoft.com/commandline/windows-command-l...
In this repo, you can find some of our terrible secrets and workarounds and debugging hooks and perhaps even some explanation for why things work the way they do. Or don't work the way they should.
If you’re looking for a good[2] way to spend a few minutes, search for “LOAD BEARING” :)
[1]: If you build the “Host.EXE” project and copy the resulting OpenConsole.exe over %WINDIR%\System32\conhost.exe, it’ll work just fine and you’ll pick up a bunch of the console changes we’ve made in the past few years.
[2] Goodness not guaranteed, void where prohibited, etc.
EDIT: Oh, kaelinl mentioned this in a sibling comment to yours. Sorry about that! I've also reworded parts of the main comment body to flow better.
There are a bunch of bugs in Windows core that I can't even get anyone to look at (and I'm an MVP). With these little bits they've opened sourced you can actively participate in helping the team fix the bugs, and add features as needed.
I know the team on Terminal had a whole muddle of problems to do with rendering recently that probably still needs some outside input. Even Microsoft's developers can't and don't know all the best ways to carry out tasks with their own APIs - there is just too much to learn.
Not saying these are good reasons, but in a company whose main products are closed-source software, I'd expect some PM to make these objections.
There are only positive outcomes here
And tmux works.
When Windows Terminal is running cmd or Powershell underneath, there is zero emulation going on.
I don’t know when, but since their features have increasingly become divorced from any terminal (other than similar software) that they might be “emulating”, it makes sense.
I would also like to add, that I am puzzled, that Microsoft has not been able to deliver a proper shell, that is comparable to …sh and delivers remote access like ssh. Yes, Powershell, but not by a long shot. And for some things you still need cmd!