2f60cf0e91
## Summary of the Pull Request Fix a bug where the `Renderer::PaintFrame` method: 1. is not called until the next `RenderThread::NotifyThread` call but needs to be called because there the terminal was updated (theoretical bug) 2. is called twice but needs to be called only once (verified bug) ## References The bug was introduced by #3511. ## PR Checklist * [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA ## Detailed Description of the Pull Request / Additional comments ### Before #### First bug In the original code, `_fNextFrameRequested` is set to `true` in render thread because `std::atomic_flag::test_and_set` is called. This is wrong because it means that the render thread will render the terminal again even if there is no change after the last render. I think the the goal was to load the boolean value for `_fNextFrameRequested` to check whether the thread should sleep or not. The problem is that there is no method on `std::atomic_flag` to load its boolean value. I guess what happened was that the "solution" that was found was to use `std::atomic_flag::test_and_set`, followed by `std::atomic_flag::clear` if the value was `false` originally (if `std::atomic_flag::test_and_set` returned `false`) to restore the original value. I guess that this was believed to be equivalent to just a simple load, without doing any change to the value because it restores it at the end. But it's not: this is dangerous because if the value is changed to `true` between the call to `std::atomic_flag::test_and_set` and the call to `std::atomic_flag::clear`, then the value ends up being `false` at the end which is wrong because we don't want to change it! And if that value ends up being `false`, it means that we miss a render because we will wait on `_hEvent` during the next iteration on the render thread. Well actually, here, this not even a problem because when that code is ran, `_fPainting` is `false` which means that the other thread that modifies the `_fNextFrameRequested` value through `RenderThread::NotifyPaint` will not actually modify `_fNextFrameRequested` but rather call `SetEvent` (see the method's body). But wait! There is a problem there too! `std::atomic_flag::test_and_set` is called for `_fPainting` which sets its value to `true`. It was probably unintended. So actually, the next call to `RenderThread::NotifyPaint` _will_ end up modifying `_fNextFrameRequested` which means that the data race I was talking about _might_ happen! #### Second bug Let's go back a little bit in my explanation. I was talking about the fact that: > I guess what happened was that the "solution" that was found was to use `std::atomic_flag::test_and_set`, followed by `std::atomic_flag::clear` if the value was `false` originally (if `std::atomic_flag::test_and_set` returned `false`) to restore the original value. The problem is that the reverse was done in the implementation: `std::atomic_flag::clear` is called if the value was _`true`_ originally! So at this point, if the value of `_fNextFrameRequested` was `false`, then `std::atomic_flag::test_and_set` sets its is set to `true` and returns `false`. So for the next iteration, `_fNextFrameRequested` is `true` and the render thread will re-render but that was not needed. ### After I used `std::atomic<bool>` instead of `std::atomic_flag` for `_fNextFrameRequested` and the other atomic field because it has a `load` and a `store` method so we can actually load the value without changing it. I also replaced `_fPainting` by `_fWaiting`, which is basically the opposite of `_fPainting` but stays `true` for a little shorter than `_fPainting` would stay `false`. Indeed, I think that it makes more sense to directly wrap/scope _just_ the call to `WaitForSingleObject` by setting my atomic variable to `true` _just_ before and to `false` _just_ after because: * It makes more sense while you're reading the code: it's easier IMO to understand what the purpose of `_fWaiting` is (that is, to call `SetEvent` from `RenderThread::NotifyPaint` if it's `true`). * It's probably a tiny bit better for performance because it will become `true` for a little shorter which means less calls to `SetEvent`. #### Warning I don't really understand [std::memory_order](https://en.cppreference.com/w/cpp/atomic/memory_order)s. So I used the default one (`std::memory_order_seq_cst`) which is the safest. I believe that if no read or write are reordered in the two threads (`RenderThread::NotifyPaint` and `RenderThread::_ThreadProc`), then the code I wrote will behave correctly. I think that `std::memory_order_seq_cst` enforces that so it should be fine, but I'm not sure. ## Validation Steps Performed **I tried to reproduce the second bug that I described in the first section of this PR.** I put a breakpoint on `RenderThread::NotifyPaint` and on `Renderer::PaintFrame`. Initially they are disabled. Then I ran the terminal in Release mode, waited a bit for the prompt to display and the cursor to start blinking. Then I enabled the breakpoints. ### Before Each `RenderThread::NotifyPaint` is followed by 2 `Renderer::PaintFrame` calls. ❌ ### After Each `RenderThread::NotifyPaint` is followed by 1 `Renderer::PaintFrame` call. ✔️ |
||
---|---|---|
.github | ||
.nuget | ||
build | ||
dep | ||
doc | ||
res | ||
samples | ||
src | ||
tools | ||
.clang-format | ||
.editorconfig | ||
.gitattributes | ||
.gitignore | ||
.gitmodules | ||
.vsconfig | ||
CODE_OF_CONDUCT.md | ||
common.openconsole.props | ||
consolegit2gitfilters.json | ||
CONTRIBUTING.md | ||
custom.props | ||
dirs | ||
LICENSE | ||
NOTICE.md | ||
NuGet.Config | ||
OpenConsole.sln | ||
README.md | ||
SECURITY.md |
Welcome to the Windows Terminal, Console and Command-Line repo
This repository contains the source code for:
- Windows Terminal
- The Windows console host (
conhost.exe
) - Components shared between the two projects
- ColorTool
- Sample projects that show how to consume the Windows Console APIs
Related repositories include:
Installing and running Windows Terminal
👉 Note: Windows Terminal requires Windows 10 1903 (build 18362) 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 Terminal from the Microsoft Store, Terminal builds can be manually downloaded from this repository's Releases page.
⚠ Note: If you install Terminal manually:
- Be sure to install the Desktop Bridge VC++ v14 Redistributable Package otherwise Terminal may not install and/or run and may crash at startup
- Terminal will not auto-update when new builds are released so you will need to regularly install the latest Terminal release to receive all the latest fixes and improvements!
Via Chocolatey (unofficial)
Chocolatey users can download and install the latest Terminal release by installing the microsoft-windows-terminal
package:
choco install microsoft-windows-terminal
To upgrade Windows Terminal using Chocolatey, run the following:
choco upgrade microsoft-windows-terminal
If you have any issues when installing/upgrading the package please go to the Windows Terminal package page and follow the Chocolatey triage process
Project Build Status
Project | Build Status |
---|---|
Terminal | |
ColorTool |
Windows Terminal v1.0 Roadmap
The plan for delivering Windows Terminal v1.0 is described here, and will be updated as the project proceeds.
Terminal & Console Overview
Please take a few minutes to review the overview below before diving into the code:
Windows Terminal
Windows Terminal is a new, modern, feature-rich, productive terminal application for command-line users. It includes many of the features most frequently requested by the Windows command-line community including support for tabs, rich text, globalization, configurability, theming & styling, and more.
The Terminal will also need to meet our goals and measures to ensure it remains fast and efficient, and doesn't consume vast amounts of memory or power.
The Windows Console Host
The Windows Console host, conhost.exe
, is Windows' original command-line user experience. It also hosts Windows' command-line infrastructure and the Windows Console API server, input engine, rendering engine, user preferences, etc. The console host code in this repository is the actual source from which the conhost.exe
in Windows itself is built.
Since taking ownership of the Windows command-line in 2014, the team added several new features to the Console, including background transparency, line-based selection, support for ANSI / Virtual Terminal sequences, 24-bit color, a Pseudoconsole ("ConPTY"), and more.
However, because Windows Console's primary goal is to maintain backward compatibility, we have been unable to add many of the features the community (and the team) have been wanting for the last several years including tabs, unicode text, and emoji.
These limitations led us to create the new Windows Terminal.
You can read more about the evolution of the command-line in general, and the Windows command-line specifically in this accompanying series of blog posts on the Command-Line team's blog.
Shared Components
While overhauling Windows Console, we modernized its codebase considerably, cleanly separating logical entities into modules and classes, introduced some key extensibility points, replaced several old, home-grown collections and containers with safer, more efficient STL containers, and made the code simpler and safer by using Microsoft's Windows Implementation Libraries - WIL.
This overhaul resulted in several of Console's key components being available for re-use in any terminal implementation on Windows. These components include a new DirectWrite-based text layout and rendering engine, a text buffer capable of storing both UTF-16 and UTF-8, a VT parser/emitter, and more.
Creating the new Windows Terminal
When we started planning the new Windows Terminal application, we explored and evaluated several approaches and technology stacks. We ultimately decided that our goals would be best met by continuing our investment in our C++ codebase, which would allow us to reuse several of the aforementioned modernized components in both the existing Console and the new Terminal. Further, we realized that this would allow us to build much of the Terminal's core itself as a reusable UI control that others can incorporate into their own applications.
The result of this work is contained within this repo and delivered as the Windows Terminal application you can download from the Microsoft Store, or directly from this repo's releases.
Resources
For more information about Windows Terminal, you may find some of these resources useful and interesting:
- Command-Line Blog
- Command-Line Backgrounder Blog Series
- Windows Terminal Launch: Terminal "Sizzle Video"
- Windows Terminal Launch: Build 2019 Session
- Run As Radio: Show 645 - Windows Terminal with Richard Turner
- Azure Devops Podcast: Episode 54 - Kayla Cinnamon and Rich Turner on DevOps on the Windows Terminal
- Microsoft Ignite 2019 Session: The Modern Windows Command Line: Windows Terminal - BRK3321
FAQ
I built and ran the new Terminal, but it looks just like the old console
Cause: You're launching the incorrect solution in Visual Studio.
Solution: Make sure you're building & deploying the CascadiaPackage
project in Visual Studio.
⚠ Note:
OpenConsole.exe
is just a locally-builtconhost.exe
, the classic Windows Console that hosts Windows' command-line infrastructure. OpenConsole is used by Windows Terminal to connect to and communicate with command-line applications (via ConPty).
Documentation
All project documentation is located in the ./doc
folder. If you would like to contribute to the documentation, please submit a pull request.
Contributing
We are excited to work alongside you, our amazing community, to build and enhance Windows Terminal!
BEFORE you start work on a feature/fix, please read & follow our Contributor's Guide to help avoid any wasted or duplicate effort.
Communicating with the Team
The easiest way to communicate with the team is via GitHub issues.
Please file new issues, feature requests and suggestions, but DO search for similar open/closed pre-existing issues before creating a new issue.
If you would like to ask a question that you feel doesn't warrant an issue (yet), please reach out to us via Twitter:
- Kayla Cinnamon, Program Manager: @cinnamon_msft
- Rich Turner, Program Manager: @richturn_ms
- Dustin Howett, Engineering Lead: @dhowett
- Michael Niksa, Senior Developer: @michaelniksa
- Mike Griese, Developer: @zadjii
- Carlos Zamora, Developer: @cazamor_msft
- Leon Liang, Developer: @leonmsft
Developer Guidance
Prerequisites
- You must be running Windows 1903 (build >= 10.0.18362.0) or later to run Windows Terminal
- You must enable Developer Mode in the Windows Settings app to locally install and run Windows Terminal
- You must have the Windows 10 1903 SDK installed
- You must have at least VS 2019 installed
- You must install the following Workloads via the VS Installer. Note: Opening the solution in VS 2019 will prompt you to install missing components automatically:
- Desktop Development with C++
- Universal Windows Platform Development
- The following Individual Components
- C++ (v142) Universal Windows Platform Tools
Building the Code
This repository uses git submodules for some of its dependencies. To make sure submodules are restored or updated, be sure to run the following prior to building:
git submodule update --init --recursive
OpenConsole.sln may be built from within Visual Studio or from the command-line using a set of convenience scripts & tools in the /tools directory:
Building in PowerShell
Import-Module .\tools\OpenConsole.psm1
Set-MsBuildDevEnvironment
Invoke-OpenConsoleBuild
Building in Cmd
.\tools\razzle.cmd
bcz
Running & Debugging
To debug the Windows Terminal in VS, right click on CascadiaPackage
(in the Solution Explorer) and go to properties. In the Debug menu, change "Application process" and "Background task process" to "Native Only".
You should then be able to build & debug the Terminal project by hitting F5.
👉 You will not be able to launch the Terminal directly by running the WindowsTerminal.exe. For more details on why, see #926, #4043
Coding Guidance
Please review these brief docs below about our coding practices.
👉 If you find something missing from these docs, feel free to contribute to any of our documentation files anywhere in the repository (or write some new ones!)
This is a work in progress as we learn what we'll need to provide people in order to be effective contributors to our project.
- Coding Style
- Code Organization
- Exceptions in our legacy codebase
- Helpful smart pointers and macros for interfacing with Windows in WIL
Code of Conduct
This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.