Migrate spelling-0.0.21 changes from main

Another attempt at fixing nearby font loading (#12904 )
The original research for a solution all the way back in #11032 contained an unfortunate flaw. The nearby font loading code was written under the assumption that Cascadia is missing in the system font collection, leading to our issues. Adding nearby fonts last into the collection would thus ensure that we use the system fonts whenever possible, but only have nearby fonts as a fallback. This didn't work and we figured that we'd have to always prefer loading nearby fonts over system fonts. #12554 tried to achieve this, but failed to change the order in which the font set is built. In order to prefer nearby fonts over system ones, we have to add the system font collection last. ## PR Checklist * [x] Closes #11648 * [x] I work here * [x] Tests added/passed * [x] Embarrassment for my incompetence ## Validation Steps Performed * Put Jetbrains Mono into the AppX directory of the Debug build * Jetbrains Mono shows up in the font selector and is useable Additionally a more complex mini-test was built: Using FontForge I've cloned arial.ttf and removed all characters except for the letter "0". Afterwards I've build a custom font collection the same way we do it in Terminal, extracted a `FontFace` named "Arial" and called `IDWriteFont::HasCharacter` for the letter "1". Loading the system font collection first results in `TRUE` and loading it last results in `FALSE` (since my custom arial.ttf doesn't have the letter "1"). This confirms that we need to load the system font collection last. (cherry picked from commit eeb8970c6c) Service-Card-Id: 80641213 Service-Version: 1.12
2026-04-06 22:29:43 +00:00 · 2022-04-15 00:05:33 +02:00 · 2022-04-21 17:06:35 -05:00 · 2022-04-08 14:07:12 -05:00 · 2022-04-08 12:30:12 -05:00 · 2022-04-07 15:24:53 -05:00
1267 changed files with 31952 additions and 43243 deletions
--- a/.clang-format
+++ b/.clang-format
@@ -11,7 +11,7 @@ AlignOperands: true
 AlignTrailingComments: false
 AllowAllParametersOfDeclarationOnNextLine: false
 AllowShortBlocksOnASingleLine: Never
-AllowShortFunctionsOnASingleLine: All
+AllowShortFunctionsOnASingleLine: Inline
 AllowShortCaseLabelsOnASingleLine: false
 AllowShortIfStatementsOnASingleLine: Never
 #AllowShortLambdasOnASingleLine: Inline
--- a/.github/ISSUE_TEMPLATE/Bug_Report.yml
+++ b/.github/ISSUE_TEMPLATE/Bug_Report.yml
@@ -1,6 +1,5 @@
 name: "Bug report 🐛"
 description: Report errors or unexpected behavior
-labels: [Issue-Bug]
 body:
 - type: markdown
  attributes:
@@ -11,21 +10,14 @@ body:

 - type: input
  attributes:
-    label: Windows Terminal version
-    placeholder: "1.7.3651.0"
+    label: Windows Terminal version (or Windows build number)
+    placeholder: "10.0.19042.0, 1.7.3651.0"
    description: |
-      You can find the version in the about dialog, or by running `wt -v` at the commandline.
+      If you are reporting an issue in Windows Terminal, you can find the version in the about dialog.
+
+      If you are reporting an issue with the Windows Console, please run `ver` or `[Environment]::OSVersion`.
  validations:
-    required: false
-    
- type: input
-  attributes:
-    label: Windows build number
-    placeholder: "10.0.19042.0"
-    description: |
-      Please run `ver` or `[Environment]::OSVersion`.
-  validations:
-    required: false
+    required: true

 - type: textarea
  attributes:
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@@ -94,11 +94,7 @@
        "xlocinfo": "cpp",
        "xmemory": "cpp",
        "xstddef": "cpp",
-        "xtr1common": "cpp",
-        "coroutine": "cpp",
-        "format": "cpp",
-        "forward_list": "cpp",
-        "latch": "cpp"
+        "xtr1common": "cpp"
    },
    "files.exclude": {
        "**/bin/**": true,
--- a/.vsconfig
+++ b/.vsconfig
@@ -17,7 +17,7 @@
    "Microsoft.Net.Component.4.5.TargetingPack",
    "Microsoft.VisualStudio.Component.DiagnosticTools",
    "Microsoft.VisualStudio.Component.Debugger.JustInTime",
-    "Microsoft.VisualStudio.Component.Windows11SDK.22000",
+    "Microsoft.VisualStudio.Component.Windows10SDK.19041",
    "Microsoft.VisualStudio.ComponentGroup.UWP.Support",
    "Microsoft.VisualStudio.Component.VC.CoreIde",
    "Microsoft.VisualStudio.ComponentGroup.NativeDesktop.Core",
@@ -25,7 +25,6 @@
    "Microsoft.VisualStudio.Component.VC.Redist.14.Latest",
    "Microsoft.VisualStudio.Component.VC.Tools.x86.x64",
    "Microsoft.VisualStudio.Component.VC.Tools.ARM64",
-    "Microsoft.VisualStudio.Component.VC.ASAN",
    "Microsoft.VisualStudio.Component.VC.v142.x86.x64",
    "Microsoft.VisualStudio.Component.VC.v142.ARM64",
    "Microsoft.VisualStudio.ComponentGroup.UWP.VC",
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -99,29 +99,15 @@ If you don't have any additional info/context to add but would like to indicate

 ## Contributing fixes / features

-If you're able & willing to help fix issues and/or implement features, we'd love your contribution!
-
-The best place to start is the list of ["Easy Starter"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22+label%3A%22Easy+Starter%22+) issues. These are bugs or tasks that we on the team believe would be easier to implement for someone without any prior experience in the codebase. Once you're feeling more comfortable in the codebase, feel free to just use the ["Help Wanted"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Help+Wanted%22+) label, or just find an issue your interested in and hop in!
-
-Generally, we categorize issues in the following way, which is largely derived from our old internal work tracking system:
-* ["Bugs"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Issue-Bug%22+) are parts of the Terminal & Console that are not quite working the right way. There's code to already support some scenario, but it's not quite working right. Fixing these is generally a matter of debugging the broken functionality and fixing the wrong code.
-* ["Tasks"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Issue-Task%22+) are usually new pieces of functionality that aren't yet implemented for the Terminal/Console. These are usually smaller features, which we believe
-  - could be a single, atomic PR
-  - Don't require much design consideration, or we've already written the spec for the larger feature they belong to.
-* ["Features"](https://github.com/microsoft/terminal/issues?q=is%3Aopen+is%3Aissue+label%3A%22Issue-Feature%22+) are larger pieces of new functionality. These are usually things we believe would require larger discussion of how they should be implemented, or they'll require some complicated new settings. They might just be features that are composed of many individual tasks. Often times, with features, we like to have a spec written before development work is started, to make sure we're all on the same page (see below).
-
-Bugs and tasks are obviously the easiest to get started with, but don't feel afraid of features either! We've had some community members contribute some amazing "feature"-level work to the Terminal (albeit, with lots of discussion 😄).
-
-
-Often, we like to assign issues that generally belong to somebody's area of expertise to the team member that owns that area. This doesn't mean the community can't jump in -- they should reach out and have a chat with the assignee to see if it'd okay to take. If an issue's been assigned more than a month ago, there's a good chance it's fair game to try yourself.
+For those able & willing to help fix issues and/or implement features ...

 ### To Spec or not to Spec

 Some issues/features may be quick and simple to describe and understand. For such scenarios, once a team member has agreed with your approach, skip ahead to the section headed "Fork, Branch, and Create your PR", below.

-Small issues that do not require a spec will be labelled `Issue-Bug` or `Issue-Task`.
+Small issues that do not require a spec will be labelled Issue-Bug or Issue-Task.

-However, some issues/features will require careful thought & formal design before implementation. For these scenarios, we'll request that a spec is written and the associated issue will be labeled `Issue-Feature`. More often than not, we'll add such features to the ["Specification Tracker" project](https://github.com/microsoft/terminal/projects/1).
+However, some issues/features will require careful thought & formal design before implementation. For these scenarios, we'll request that a spec is written and the associated issue will be labeled Issue-Feature.

 Specs help collaborators discuss different approaches to solve a problem, describe how the feature will behave, how the feature will impact the user, what happens if something goes wrong, etc. Driving towards agreement in a spec, before any code is written, often results in simpler code, and less wasted effort in the long run.

--- a/NOTICE.md
+++ b/NOTICE.md
@@ -276,43 +276,6 @@ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
 ```

-## ConEmu
-**Source**: [https://github.com/Maximus5/ConEmu](https://github.com/Maximus5/ConEmu)
-
-### License
-
-```
-BSD 3-Clause License
-
-Copyright (c) 2009-2017, Maximus5 <ConEmu.Maximus5@gmail.com>
-All rights reserved.
-
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions are met:
-
-* Redistributions of source code must retain the above copyright notice, this
-  list of conditions and the following disclaimer.
-
-* Redistributions in binary form must reproduce the above copyright notice,
-  this list of conditions and the following disclaimer in the documentation
-  and/or other materials provided with the distribution.
-
-* Neither the name of the copyright holder nor the names of its
-  contributors may be used to endorse or promote products derived from
-  this software without specific prior written permission.
-
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
-AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
-DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
-SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
-CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
-OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-```
-
 # Microsoft Open Source

 This product also incorporates source code from other Microsoft open source projects, all licensed under the MIT license.
--- a/OpenConsole.sln
+++ b/OpenConsole.sln
@@ -1,6 +1,7 @@
+
 Microsoft Visual Studio Solution File, Format Version 12.00
-# Visual Studio Version 17
-VisualStudioVersion = 17.2.32422.2
+# Visual Studio Version 16
+VisualStudioVersion = 16.0.29001.49
 MinimumVisualStudioVersion = 10.0.40219.1
 Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Terminal", "Terminal", "{59840756-302F-44DF-AA47-441A9D673202}"
 EndProject
@@ -289,12 +290,9 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Common Props", "Common Prop
 		src\common.build.post.props = src\common.build.post.props
 		src\common.build.pre.props = src\common.build.pre.props
 		src\common.build.tests.props = src\common.build.tests.props
-		src\common.nugetversions.props = src\common.nugetversions.props
-		src\common.nugetversions.targets = src\common.nugetversions.targets
 		common.openconsole.props = common.openconsole.props
 		src\cppwinrt.build.post.props = src\cppwinrt.build.post.props
 		src\cppwinrt.build.pre.props = src\cppwinrt.build.pre.props
-		dep\nuget\packages.config = dep\nuget\packages.config
 		src\wap-common.build.post.props = src\wap-common.build.post.props
 		src\wap-common.build.pre.props = src\wap-common.build.pre.props
 	EndProjectSection
@@ -336,8 +334,6 @@ Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WpfTerminalTestNetCore", "s
 EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "wt", "src\cascadia\wt\wt.vcxproj", "{506FD703-BAA7-4F6E-9361-64F550EC8FCA}"
 EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "elevate-shim", "src\cascadia\ElevateShim\elevate-shim.vcxproj", "{416FD703-BAA7-4F6E-9361-64F550EC8FCA}"
-EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.Terminal.Settings.Editor", "src\cascadia\TerminalSettingsEditor\Microsoft.Terminal.Settings.Editor.vcxproj", "{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}"
 	ProjectSection(ProjectDependencies) = postProject
 		{CA5CAD1A-082C-4476-9F33-94B339494076} = {CA5CAD1A-082C-4476-9F33-94B339494076}
@@ -402,18 +398,6 @@ Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "WindowsTerminal.UIA.Tests",
 EndProject
 Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "api-ms-win-core-synch-l1-2-0", "src\api-ms-win-core-synch-l1-2-0\api-ms-win-core-synch-l1-2-0.vcxproj", "{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}"
 EndProject
-Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Utils", "Utils", "{61901E80-E97D-4D61-A9BB-E8F2FDA8B40C}"
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererAtlas", "src\renderer\atlas\atlas.vcxproj", "{8222900C-8B6C-452A-91AC-BE95DB04B95F}"
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InteractivityOneCore", "src\interactivity\onecore\lib\onecore.LIB.vcxproj", "{06EC74CB-9A12-428C-B551-8537EC964726}"
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererWddmCon", "src\renderer\wddmcon\lib\wddmcon.vcxproj", "{75C6F576-18E9-4566-978A-F0A301CAC090}"
-EndProject
-Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Audio", "Audio", "{40BD8415-DD93-4200-8D82-498DDDC08CC8}"
-EndProject
-Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "MidiAudio", "src\audio\midi\lib\midi.vcxproj", "{3C67784E-1453-49C2-9660-483E2CC7F7AD}"
-EndProject
 Global
 	GlobalSection(SolutionConfigurationPlatforms) = preSolution
 		AuditMode|Any CPU = AuditMode|Any CPU
@@ -1210,11 +1194,11 @@ Global
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x86.Build.0 = Debug|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|Any CPU.ActiveCfg = Debug|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|ARM.ActiveCfg = Debug|Win32
-		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|ARM64.ActiveCfg = Debug|ARM64
-		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|DotNet_x64Test.ActiveCfg = Debug|Win32
+		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
+		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|DotNet_x86Test.ActiveCfg = Debug|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|x64.ActiveCfg = Debug|x64
-		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|x86.ActiveCfg = Debug|Win32
+		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|Any CPU.ActiveCfg = Release|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|ARM.ActiveCfg = Release|Win32
 		{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|ARM64.ActiveCfg = Release|ARM64
@@ -1281,6 +1265,7 @@ Global
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
+		{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|x64.Build.0 = Fuzzing|x64
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|Any CPU.ActiveCfg = Release|Win32
 		{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|ARM.ActiveCfg = Release|Win32
@@ -2774,43 +2759,6 @@ Global
 		{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x64.Build.0 = Release|x64
 		{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x86.ActiveCfg = Release|Win32
 		{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x86.Build.0 = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x64.Build.0 = AuditMode|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x86.Build.0 = AuditMode|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|Any CPU.ActiveCfg = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|ARM.ActiveCfg = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|ARM64.Build.0 = Debug|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x64.ActiveCfg = Debug|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x64.Build.0 = Debug|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x86.ActiveCfg = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x86.Build.0 = Debug|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|Any CPU.ActiveCfg = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|ARM.ActiveCfg = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|ARM64.ActiveCfg = Release|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|ARM64.Build.0 = Release|ARM64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x64.ActiveCfg = Release|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x64.Build.0 = Release|x64
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x86.ActiveCfg = Release|Win32
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x86.Build.0 = Release|Win32
 		{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|Any CPU.ActiveCfg = Release|x64
 		{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|Any CPU.Build.0 = Release|x64
 		{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|Any CPU.Deploy.0 = Release|x64
@@ -3252,10 +3200,13 @@ Global
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
+		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
+		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|x64.Build.0 = Fuzzing|x64
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
+		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Fuzzing|x86.Build.0 = Fuzzing|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|Any CPU.ActiveCfg = Release|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|ARM.ActiveCfg = Release|Win32
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|ARM64.ActiveCfg = Release|ARM64
@@ -3329,6 +3280,7 @@ Global
 		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
 		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
 		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
+		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|x64.Build.0 = Fuzzing|x64
 		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
 		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|x86.Build.0 = Fuzzing|Win32
 		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|Any CPU.ActiveCfg = Release|Win32
@@ -3343,156 +3295,6 @@ Global
 		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|x64.Build.0 = Release|x64
 		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|x86.ActiveCfg = Release|Win32
 		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|x86.Build.0 = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|x64.Build.0 = AuditMode|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.AuditMode|x86.Build.0 = AuditMode|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|Any CPU.ActiveCfg = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|ARM.ActiveCfg = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|ARM64.Build.0 = Debug|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|x64.ActiveCfg = Debug|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|x64.Build.0 = Debug|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|x86.ActiveCfg = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Debug|x86.Build.0 = Debug|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|x64.Build.0 = Fuzzing|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Fuzzing|x86.Build.0 = Fuzzing|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|Any CPU.ActiveCfg = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|ARM.ActiveCfg = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|ARM64.ActiveCfg = Release|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|ARM64.Build.0 = Release|ARM64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|x64.ActiveCfg = Release|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|x64.Build.0 = Release|x64
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|x86.ActiveCfg = Release|Win32
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F}.Release|x86.Build.0 = Release|Win32
-		{06EC74CB-9A12-428C-B551-8537EC964726}.AuditMode|Any CPU.ActiveCfg = AuditMode|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.AuditMode|ARM.ActiveCfg = AuditMode|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.AuditMode|x64.Build.0 = AuditMode|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Debug|Any CPU.ActiveCfg = Debug|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Debug|ARM.ActiveCfg = Debug|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Debug|ARM64.Build.0 = Debug|ARM64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Debug|DotNet_x86Test.ActiveCfg = Debug|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Debug|x64.ActiveCfg = Debug|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Debug|x64.Build.0 = Debug|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Debug|x86.ActiveCfg = Debug|Win32
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Debug|x86.Build.0 = Debug|Win32
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Fuzzing|ARM.ActiveCfg = Fuzzing|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Release|Any CPU.ActiveCfg = Release|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Release|ARM.ActiveCfg = Release|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Release|ARM64.ActiveCfg = Release|ARM64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Release|ARM64.Build.0 = Release|ARM64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Release|DotNet_x64Test.ActiveCfg = Release|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Release|DotNet_x86Test.ActiveCfg = Release|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Release|x64.ActiveCfg = Release|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Release|x64.Build.0 = Release|x64
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Release|x86.ActiveCfg = Release|Win32
-		{06EC74CB-9A12-428C-B551-8537EC964726}.Release|x86.Build.0 = Release|Win32
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.AuditMode|Any CPU.ActiveCfg = AuditMode|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.AuditMode|ARM.ActiveCfg = AuditMode|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Debug|Any CPU.ActiveCfg = Debug|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Debug|ARM.ActiveCfg = Debug|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Debug|ARM64.Build.0 = Debug|ARM64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Debug|DotNet_x86Test.ActiveCfg = Debug|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Debug|x64.ActiveCfg = Debug|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Debug|x64.Build.0 = Debug|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Debug|x86.ActiveCfg = Debug|Win32
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Debug|x86.Build.0 = Debug|Win32
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Fuzzing|ARM.ActiveCfg = Fuzzing|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Fuzzing|x64.Build.0 = Fuzzing|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Release|Any CPU.ActiveCfg = Release|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Release|ARM.ActiveCfg = Release|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Release|ARM64.ActiveCfg = Release|ARM64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Release|ARM64.Build.0 = Release|ARM64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Release|DotNet_x64Test.ActiveCfg = Release|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Release|DotNet_x86Test.ActiveCfg = Release|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Release|x64.ActiveCfg = Release|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Release|x64.Build.0 = Release|x64
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Release|x86.ActiveCfg = Release|Win32
-		{75C6F576-18E9-4566-978A-F0A301CAC090}.Release|x86.Build.0 = Release|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.AuditMode|x64.ActiveCfg = AuditMode|x64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.AuditMode|x64.Build.0 = AuditMode|x64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.AuditMode|x86.ActiveCfg = AuditMode|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.AuditMode|x86.Build.0 = AuditMode|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Debug|Any CPU.ActiveCfg = Debug|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Debug|ARM.ActiveCfg = Debug|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Debug|ARM64.ActiveCfg = Debug|ARM64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Debug|ARM64.Build.0 = Debug|ARM64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Debug|x64.ActiveCfg = Debug|x64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Debug|x64.Build.0 = Debug|x64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Debug|x86.ActiveCfg = Debug|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Debug|x86.Build.0 = Debug|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Fuzzing|x64.Build.0 = Fuzzing|x64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Fuzzing|x86.Build.0 = Fuzzing|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Release|Any CPU.ActiveCfg = Release|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Release|ARM.ActiveCfg = Release|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Release|ARM64.ActiveCfg = Release|ARM64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Release|ARM64.Build.0 = Release|ARM64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Release|x64.ActiveCfg = Release|x64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Release|x64.Build.0 = Release|x64
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Release|x86.ActiveCfg = Release|Win32
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD}.Release|x86.Build.0 = Release|Win32
 	EndGlobalSection
 	GlobalSection(SolutionProperties) = preSolution
 		HideSolutionNode = FALSE
@@ -3557,7 +3359,7 @@ Global
 		{CA5CAD1A-9A12-429C-B551-8562EC954746} = {59840756-302F-44DF-AA47-441A9D673202}
 		{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
 		{48D21369-3D7B-4431-9967-24E81292CF63} = {05500DEF-2294-41E3-AF9A-24E580B82836}
-		{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE} = {61901E80-E97D-4D61-A9BB-E8F2FDA8B40C}
+		{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE} = {59840756-302F-44DF-AA47-441A9D673202}
 		{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
 		{A22EC5F6-7851-4B88-AC52-47249D437A52} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
 		{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
@@ -3569,11 +3371,10 @@ Global
 		{D3EF7B96-CD5E-47C9-B9A9-136259563033} = {04170EEF-983A-4195-BFEF-2321E5E38A1E}
 		{95B136F9-B238-490C-A7C5-5843C1FECAC4} = {05500DEF-2294-41E3-AF9A-24E580B82836}
 		{024052DE-83FB-4653-AEA4-90790D29D5BD} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
-		{067F0A06-FCB7-472C-96E9-B03B54E8E18D} = {61901E80-E97D-4D61-A9BB-E8F2FDA8B40C}
+		{067F0A06-FCB7-472C-96E9-B03B54E8E18D} = {59840756-302F-44DF-AA47-441A9D673202}
 		{6BAE5851-50D5-4934-8D5E-30361A8A40F3} = {81C352DB-1818-45B7-A284-18E259F1CC87}
 		{1588FD7C-241E-4E7D-9113-43735F3E6BAD} = {4DAF0299-495E-4CD1-A982-9BAC16A45932}
-		{506FD703-BAA7-4F6E-9361-64F550EC8FCA} = {61901E80-E97D-4D61-A9BB-E8F2FDA8B40C}
-		{416FD703-BAA7-4F6E-9361-64F550EC8FCA} = {61901E80-E97D-4D61-A9BB-E8F2FDA8B40C}
+		{506FD703-BAA7-4F6E-9361-64F550EC8FCA} = {59840756-302F-44DF-AA47-441A9D673202}
 		{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32} = {77875138-BB08-49F9-8BB1-409C2150E0E1}
 		{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {77875138-BB08-49F9-8BB1-409C2150E0E1}
 		{CA5CAD1A-082C-4476-9F33-94B339494076} = {77875138-BB08-49F9-8BB1-409C2150E0E1}
@@ -3592,12 +3393,6 @@ Global
 		{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
 		{F19DACD5-0C6E-40DC-B6E4-767A3200542C} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
 		{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
-		{61901E80-E97D-4D61-A9BB-E8F2FDA8B40C} = {59840756-302F-44DF-AA47-441A9D673202}
-		{8222900C-8B6C-452A-91AC-BE95DB04B95F} = {05500DEF-2294-41E3-AF9A-24E580B82836}
-		{06EC74CB-9A12-428C-B551-8537EC964726} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
-		{75C6F576-18E9-4566-978A-F0A301CAC090} = {05500DEF-2294-41E3-AF9A-24E580B82836}
-		{40BD8415-DD93-4200-8D82-498DDDC08CC8} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
-		{3C67784E-1453-49C2-9660-483E2CC7F7AD} = {40BD8415-DD93-4200-8D82-498DDDC08CC8}
 	EndGlobalSection
 	GlobalSection(ExtensibilityGlobals) = postSolution
 		SolutionGuid = {3140B1B7-C8EE-43D1-A772-D82A7061A271}
--- a/README.md
+++ b/README.md
@@ -21,7 +21,7 @@ Related repositories include:

 ## Installing and running Windows Terminal

-> 🔴 Note: Windows Terminal requires Windows 10 2004 (build 19041) or later
+> 🔴 Note: Windows Terminal requires Windows 10 1903 (build 18362) or later

 ### Microsoft Store [Recommended]

@@ -111,10 +111,10 @@ repository.

 ---

-## Windows Terminal Roadmap
+## Windows Terminal 2.0 Roadmap

-The plan for the Windows Terminal [is described here](/doc/roadmap-2022.md) and
-will be updated as the project proceeds.
+The plan for delivering Windows Terminal 2.0 [is described
+here](/doc/terminal-v2-roadmap.md) and will be updated as the project proceeds.

 ## Project Build Status

@@ -214,7 +214,7 @@ resources useful and interesting:
 * Windows Terminal Launch: [Build 2019
  Session](https://www.youtube.com/watch?v=KMudkRcwjCw)
 * Run As Radio: [Show 645 - Windows Terminal with Richard
-  Turner](https://www.runasradio.com/Shows/Show/645)
+  Turner](http://www.runasradio.com/Shows/Show/645)
 * Azure Devops Podcast: [Episode 54 - Kayla Cinnamon and Rich Turner on DevOps
  on the Windows
  Terminal](http://azuredevopspodcast.clear-measure.com/kayla-cinnamon-and-rich-turner-on-devops-on-the-windows-terminal-team-episode-54)
@@ -272,8 +272,11 @@ If you would like to ask a question that you feel doesn't warrant an issue
 * Kayla Cinnamon, Program Manager:
  [@cinnamon\_msft](https://twitter.com/cinnamon_msft)
 * Dustin Howett, Engineering Lead: [@dhowett](https://twitter.com/DHowett)
-* Mike Griese, Senior Developer: [@zadjii](https://twitter.com/zadjii)
+* Michael Niksa, Senior Developer:
+  [@michaelniksa](https://twitter.com/MichaelNiksa)
+* Mike Griese, Developer: [@zadjii](https://twitter.com/zadjii)
 * Carlos Zamora, Developer: [@cazamor_msft](https://twitter.com/cazamor_msft)
+* Leon Liang, Developer: [@leonmsft](https://twitter.com/leonmsft)
 * Pankaj Bhojwani, Developer
 * Leonard Hecker, Developer: [@LeonardHecker](https://twitter.com/LeonardHecker)

@@ -281,14 +284,14 @@ If you would like to ask a question that you feel doesn't warrant an issue

 ## Prerequisites

-* You must be running Windows 10 2004 (build >= 10.0.19041.0) or later to run
+* 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](https://docs.microsoft.com/en-us/windows/uwp/get-started/enable-your-device-for-development)
  to locally install and run Windows Terminal
 * You must have [PowerShell 7 or later](https://github.com/PowerShell/PowerShell/releases/latest) installed
-* You must have the [Windows 11 (10.0.22000.0)
-  SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-sdk/)
+* You must have the [Windows 10 1903
+  SDK](https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk)
  installed
 * You must have at least [VS
  2019](https://visualstudio.microsoft.com/downloads/) installed
@@ -299,7 +302,6 @@ If you would like to ask a question that you feel doesn't warrant an issue
  * Universal Windows Platform Development
  * **The following Individual Components**
    * C++ (v142) Universal Windows Platform Tools
-* You must install the [.NET Framework Targeting Pack](https://docs.microsoft.com/dotnet/framework/install/guide-for-developers#to-install-the-net-framework-developer-pack-or-targeting-pack) to build test projects

 ## Building the Code

@@ -337,9 +339,7 @@ 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
-<kbd>F5</kbd>. Make sure to select either the "x64" or the "x86" platform - the
-Terminal doesn't build for "Any Cpu" (because the Terminal is a C++ application,
-not a C# one).
+<kbd>F5</kbd>.

 > 👉 You will _not_ be able to launch the Terminal directly by running the
 > WindowsTerminal.exe. For more details on why, see
--- a/Scratch.sln
+++ b/Scratch.sln
@@ -1,4 +1,4 @@
-
+
 Microsoft Visual Studio Solution File, Format Version 12.00
 # Visual Studio Version 16
 VisualStudioVersion = 16.0.31205.134
--- a/build/Fuzz/notifications-ado.json
+++ b/build/Fuzz/notifications-ado.json
@@ -1,34 +0,0 @@
-{
-  "config": {
-    "base_url": "https://dev.azure.com/microsoft/os",
-    "auth_token": "INSERT_PAT_HERE",
-    "project": "OpenConsole",
-    "type": "Bug",
-    "unique_fields": [
-      "Microsoft.VSTS.Common.CustomString03"
-    ],
-    "comment": "<a href='{{ input_url }}'>This input</a> caused the <a href='{{ target_url }}'>fuzz target</a> {{ report.executable }} to crash. The faulting input SHA256 hash is {{ report.input_sha256 }} <br>",
-    "ado_fields": {
-      "System.AssignedTo": "INSERT_ASSIGNED_HERE",
-      "System.Tags": "OneFuzz",
-      "System.AreaPath": "OS\\WDX\\DXP\\WinDev\\Terminal",
-      "OSG.Watson.Telemetry14DaysInMarketHits": "1",
-      "System.IterationPath": "OS\\Future",
-      "Microsoft.VSTS.Common.CustomString01": "{{ job.project }}",
-      "Microsoft.VSTS.Common.CustomString02": "{{ job.name }}",
-      "Microsoft.VSTS.Common.CustomString03": "{{ report.minimized_stack_function_lines_sha256}}",
-      "System.Title": "[Fuzzing] - {{ report.crash_site }}",
-      "Microsoft.VSTS.CMMI.HowFound": "Security: Fuzzing",
-      "OSG.SecurityImpact": "Security Triage Requested",
-      "OSG.SDLSeverity": "Moderate",
-      "Microsoft.VSTS.TCM.ReproSteps": "The fuzzing target ({{ job.project }} {{ job.name }} {{ job.build }}) reported a crash. <br> {%if report.asan_log %} AddressSanitizer reported the following details: <br> <pre> {{ report.asan_log }} </pre> {% else %} Faulting call stack: <ul> {% for item in report.call_stack %} <li> {{ item }} </li> {% endfor %} </ul> <br> {% endif %} You can reproduce the issue remotely in OneFuzz by running the following command: <pre> {{ repro_cmd }} </pre>"
-    },
-    "on_duplicate": {
-      "set_state": {"Resolved": "Active", "Closed": "Active"},
-      "ado_fields": {
-        "System.IterationPath": "OS\\Future"
-      },
-      "increment": ["OSG.Watson.Telemetry14DaysInMarketHits"]
-    }
-  }
-}
--- a/build/Helix/EnsureMachineState.ps1
+++ b/build/Helix/EnsureMachineState.ps1
@@ -1,4 +1,4 @@
-$scriptDirectory = $script:MyInvocation.MyCommand.Path | Split-Path -Parent
+$scriptDirectory = $script:MyInvocation.MyCommand.Path | Split-Path -Parent

 # List all processes to aid debugging:
 Write-Host "All processes running:"
--- a/build/Helix/HelixTestHelpers.cs
+++ b/build/Helix/HelixTestHelpers.cs
@@ -1,4 +1,4 @@
-using System;
+using System;
 using System.Collections.Generic;
 using System.IO;
 using System.Linq;
--- a/build/config/ESRPSigning_ConPTY.json
+++ b/build/config/ESRPSigning_ConPTY.json
@@ -1,51 +0,0 @@
-{
-    "Version": "1.0.0",
-    "UseMinimatch": false,
-    "SignBatches": [
-        {
-            "MatchedPath": [
-                "conpty.dll",
-                "OpenConsole.exe"
-            ],
-            "SigningInfo": {
-                "Operations": [
-                    {
-                        "KeyCode": "CP-230012",
-                        "OperationSetCode": "SigntoolSign",
-                        "Parameters": [
-                            {
-                                "parameterName": "OpusName",
-                                "parameterValue": "Microsoft"
-                            },
-                            {
-                                "parameterName": "OpusInfo",
-                                "parameterValue": "http://www.microsoft.com"
-                            },
-                            {
-                                "parameterName": "FileDigest",
-                                "parameterValue": "/fd \"SHA256\""
-                            },
-                            {
-                                "parameterName": "PageHash",
-                                "parameterValue": "/NPH"
-                            },
-                            {
-                                "parameterName": "TimeStamp",
-                                "parameterValue": "/tr \"http://rfc3161.gtm.corp.microsoft.com/TSS/HttpTspServer\" /td sha256"
-                            }
-                        ],
-                        "ToolName": "sign",
-                        "ToolVersion": "1.0"
-                    },
-                    {
-                        "KeyCode": "CP-230012",
-                        "OperationSetCode": "SigntoolVerify",
-                        "Parameters": [],
-                        "ToolName": "sign",
-                        "ToolVersion": "1.0"
-                    }
-                ]
-            }
-        }
-    ]
-}
--- a/build/packages.config
+++ b/build/packages.config
@@ -3,6 +3,4 @@
  <package id="MUXCustomBuildTasks" version="1.0.48" targetFramework="native" />
  <package id="Microsoft.Taef" version="10.60.210621002" targetFramework="native" />
  <package id="Microsoft.Internal.PGO-Helpers.Cpp" version="0.2.34" targetFramework="native" />
-  <!-- This cannot be included in another project that depends on XAML (as it would be a duplicate package ID) -->
-  <package id="Microsoft.UI.Xaml" version="2.7.0" targetFramework="native" />
 </packages>
--- a/build/pgo/Terminal.PGO.props
+++ b/build/pgo/Terminal.PGO.props
@@ -9,7 +9,7 @@

  <PropertyGroup>
    <!-- Optional, defaults to main.  Name of the branch which will be used for calculating branch point. -->
-    <PGOBranch>main</PGOBranch>
+    <PGOBranch>release-1.12</PGOBranch>

    <!-- Mandatory.  Name of the NuGet package which will contain PGO databases for consumption by build system. -->
    <PGOPackageName>Microsoft.Internal.Windows.Terminal.PGODatabase</PGOPackageName>
--- a/build/pipelines/ci.yml
+++ b/build/pipelines/ci.yml
@@ -38,7 +38,6 @@ stages:
      - template: ./templates/build-console-audit-job.yml
        parameters:
          platform: x64
-
  - stage: Build_x64
    displayName: Build x64
    dependsOn: []
@@ -62,32 +61,6 @@ stages:
      - template: ./templates/build-console-ci.yml
        parameters:
          platform: ARM64
-
-  - stage: Test_x64
-    displayName: Test x64
-    dependsOn: [Build_x64]
-    condition: succeeded()
-    jobs:
-      - template: ./templates/test-console-ci.yml
-        parameters:
-          platform: x64
-  - stage: Test_x86
-    displayName: Test x86
-    dependsOn: [Build_x86]
-    jobs:
-      - template: ./templates/test-console-ci.yml
-        parameters:
-          platform: x86
-
-  - stage: Helix_x64
-    displayName: Helix x64
-    dependsOn: [Build_x64]
-    condition: and(succeeded(), not(eq(variables['Build.Reason'], 'PullRequest')))
-    jobs:
-      - template: ./templates/console-ci-helix-job.yml
-        parameters:
-          platform: x64
-
  - stage: Scripts
    displayName: Code Health Scripts
    dependsOn: []
@@ -95,10 +68,3 @@ stages:
    jobs:
      - template: ./templates/check-formatting.yml

-
-  - stage: CodeIndexer
-    displayName: Github CodeNav Indexer
-    dependsOn: [Build_x64]
-    condition: and(succeeded(), not(eq(variables['Build.Reason'], 'PullRequest')))
-    jobs:
-      - template: ./templates/codenav-indexer.yml
--- a/build/pipelines/feature-flag-ci.yml
+++ b/build/pipelines/feature-flag-ci.yml
@@ -1,29 +0,0 @@
-trigger: none
-
-pr:
-  branches:
-    include:
-      - main
-  paths:
-    include:
-      - src/features.xml
-
-variables:
-  - name: runCodesignValidationInjectionBG
-    value: false
-
-parameters:
-  - name: buildBrandings
-    type: object
-    default:
-      - Release
-      - Preview
-      # Dev is built automatically
-      # WindowsInbox does not typically build with VS.
-
-jobs:
-  - ${{ each branding in parameters.buildBrandings }}:
-    - template: ./templates/build-console-ci.yml
-      parameters:
-        platform: x64
-        branding: ${{ branding }}
--- a/build/pipelines/fuzz.yml
+++ b/build/pipelines/fuzz.yml
@@ -1,59 +0,0 @@
-trigger:
-  batch: true
-  branches:
-    include:
-      - main
-  paths:
-    exclude:
-      - docs/*
-      - samples/*
-      - tools/*
-
-pr: none
-
-#     0.0.yyMM.dd##
-#     0.0.1904.0900
-name: 0.0.$(Date:yyMM).$(Date:dd)$(Rev:rr)
-
-stages:
-  - stage: Build_Fuzz_Config
-    displayName: Build Fuzzers
-    dependsOn: []
-    condition: succeeded()
-    jobs:
-    - template: ./templates/build-console-fuzzing.yml
-      parameters:
-        platform: x64
-  - stage: OneFuzz
-    displayName: Submit OneFuzz Job
-    dependsOn: ['Build_Fuzz_Config']
-    condition: succeeded()
-    pool:
-      vmImage: 'ubuntu-latest'
-    variables:
-      artifactName: fuzzingBuildOutput
-    jobs:
-    - job:
-      steps:
-      - task: DownloadBuildArtifacts@0
-        inputs:
-          artifactName: $(artifactName)
-          downloadPath: $(Build.ArtifactStagingDirectory)
-      - task: UsePythonVersion@0
-        inputs:
-          versionSpec: '3.x'
-          addToPath: true
-          architecture: 'x64'
-      - bash: |
-          set -ex
-          pip -q install onefuzz
-          onefuzz config --endpoint $(endpoint) --client_id $(client_id) --authority $(authority) --tenant_domain $(tenant_domain) --client_secret $(client_secret)
-          sed -i s/INSERT_PAT_HERE/$(ado_pat)/ build/Fuzz/notifications-ado.json
-          sed -i s/INSERT_ASSIGNED_HERE/$(ado_assigned_to)/ build/Fuzz/notifications-ado.json
-        displayName: Configure OneFuzz
-      - bash: |
-          onefuzz template libfuzzer basic --colocate_all_tasks --vm_count 1 --target_exe $target_exe_path --notification_config @./build/Fuzz/notifications-ado.json OpenConsole $test_name $(Build.SourceVersion) default
-        displayName: Submit OneFuzz Job
-        env:
-          target_exe_path: $(Build.ArtifactStagingDirectory)/$(artifactName)/Fuzzing/x64/test/OpenConsoleFuzzer.exe
-          test_name: WriteCharsLegacy
--- a/build/pipelines/release.yml
+++ b/build/pipelines/release.yml
@@ -30,10 +30,6 @@ parameters:
    displayName: "Build Windows Terminal VPack"
    type: boolean
    default: false
-  - name: buildConPTY
-    displayName: "Build ConPTY NuGet"
-    type: boolean
-    default: false
  - name: buildWPF
    displayName: "Build Terminal WPF Control"
    type: boolean
@@ -64,35 +60,6 @@ parameters:

 variables:
  TerminalInternalPackageVersion: "0.0.7"
-  # If we are building a branch called "release-*", change the NuGet suffix
-  # to "preview". If we don't do that, XES will set the suffix to "release1"
-  # because it truncates the value after the first period.
-  # We also want to disable the suffix entirely if we're Release branded while
-  # on a release branch.
-  # main is special, however. XES ignores main. Since we never produce actual
-  # shipping builds from main, we want to force it to have a beta label as
-  # well.
-  #
-  # In effect:
-  # BRANCH / BRANDING | Release                    | Preview
-  # ------------------|----------------------------|-----------------------------
-  # release-*         | 1.12.20220427              | 1.13.20220427-preview
-  # main              | 1.14.20220427-experimental | 1.14.20220427-experimental
-  # all others        | 1.14.20220427-mybranch     | 1.14.20220427-mybranch
-  ${{ if startsWith(variables['Build.SourceBranchName'], 'release-') }}:
-    ${{ if eq(parameters.branding, 'Release') }}:
-      NoNuGetPackBetaVersion: true
-    ${{ else }}:
-      NuGetPackBetaVersion: preview
-  ${{ elseif eq(variables['Build.SourceBranchName'], 'main') }}:
-    NuGetPackBetaVersion: experimental
-  # The NuGet packages have to use *somebody's* DLLs. We used to force them to
-  # use the Win10 build outputs, but if there isn't a Win10 build we should use
-  # the Win11 one.
-  ${{ if containsValue(parameters.buildWindowsVersions, 'Win10') }}:
-    TerminalBestVersionForNuGetPackages: Win10
-  ${{ else }}:
-    TerminalBestVersionForNuGetPackages: Win11

 name: $(BuildDefinitionName)_$(date:yyMM).$(date:dd)$(rev:rrr)
 resources:
@@ -133,7 +100,28 @@ jobs:
        If ($Arch -Eq "x86") { $Arch = "Win32" }

        Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"
-  - template: .\templates\restore-nuget-steps.yml
+  - task: NuGetToolInstaller@1
+    displayName: Use NuGet 5.10
+    inputs:
+      versionSpec: 5.10
+  - task: NuGetAuthenticate@0
+  # In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
+  # This should be `task: NuGetCommand@2`
+  - task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
+    displayName: Restore NuGet packages for extraneous build actions
+    inputs:
+      command: restore
+      feedsToUse: config
+      configPath: NuGet.config
+      restoreSolution: build/packages.config
+      restoreDirectory: '$(Build.SourcesDirectory)\packages'
+  - task: NuGetCommand@2
+    displayName: NuGet custom
+    inputs:
+      command: custom
+      selectOrConfig: config
+      nugetConfigPath: NuGet.Config
+      arguments: restore OpenConsole.sln -SolutionDirectory $(Build.SourcesDirectory)
  # Pull the Windows SDK for the developer tools like the debuggers so we can index sources later
  - template: .\templates\install-winsdk-steps.yml
  - task: UniversalPackages@0
@@ -226,15 +214,6 @@ jobs:
        msbuildArgs: /p:WindowsTerminalOfficialBuild=true /p:WindowsTerminalBranding=${{ parameters.branding }};PGOBuildMode=${{ parameters.pgoBuildMode }} /p:WindowsTerminalReleaseBuild=true /t:Terminal\wpf\PublicTerminalCore
        platform: $(BuildPlatform)
        configuration: $(BuildConfiguration)
-  - ${{ if eq(parameters.buildConPTY, true) }}:
-    - task: VSBuild@1
-      displayName: Build solution **\OpenConsole.sln for ConPTY
-      inputs:
-        solution: '**\OpenConsole.sln'
-        vsVersion: 16.0
-        msbuildArgs: /p:WindowsTerminalOfficialBuild=true /p:WindowsTerminalBranding=${{ parameters.branding }};PGOBuildMode=${{ parameters.pgoBuildMode }} /p:WindowsTerminalReleaseBuild=true /t:Conhost\Host_EXE;Conhost\winconpty_DLL
-        platform: $(BuildPlatform)
-        configuration: $(BuildConfiguration)
  - task: PowerShell@2
    displayName: Source Index PDBs
    inputs:
@@ -279,24 +258,6 @@ jobs:
      inputs:
        PathtoPublish: $(Build.ArtifactStagingDirectory)/appx
        ArtifactName: appx-$(BuildPlatform)-$(BuildConfiguration)-$(TerminalTargetWindowsVersion)
-  - ${{ if eq(parameters.buildConPTY, true) }}:
-    - task: CopyFiles@2
-      displayName: Copy ConPTY to Artifacts
-      inputs:
-        Contents: |-
-          $(Build.SourcesDirectory)/bin/**/conpty.dll
-          $(Build.SourcesDirectory)/bin/**/conpty.lib
-          $(Build.SourcesDirectory)/bin/**/conpty.pdb
-          $(Build.SourcesDirectory)/bin/**/OpenConsole.exe
-          $(Build.SourcesDirectory)/bin/**/OpenConsole.pdb
-        TargetFolder: $(Build.ArtifactStagingDirectory)/conpty
-        OverWrite: true
-        flattenFolders: true
-    - task: PublishBuildArtifacts@1
-      displayName: Publish Artifact (ConPTY)
-      inputs:
-        PathtoPublish: $(Build.ArtifactStagingDirectory)/conpty
-        ArtifactName: conpty-dll-$(BuildPlatform)-$(BuildConfiguration)-$(TerminalTargetWindowsVersion)
  - ${{ if eq(parameters.buildWPF, true) }}:
    - task: CopyFiles@2
      displayName: Copy PublicTerminalCore.dll to Artifacts
@@ -340,7 +301,6 @@ jobs:
    steps:
    - checkout: self
      clean: true
-      fetchDepth: 1
      submodules: true
      persistCredentials: True
    - task: PkgESSetupBuild@12
@@ -403,97 +363,6 @@ jobs:
        PathtoPublish: $(System.ArtifactsDirectory)
        ArtifactName: appxbundle-signed-$(TerminalTargetWindowsVersion)

- ${{ if eq(parameters.buildConPTY, true) }}:
-  - job: PackageAndSignConPTY
-    strategy:
-      matrix:
-        ${{ each config in parameters.buildConfigurations }}:
-          ${{ config }}:
-            BuildConfiguration: ${{ config }}
-    displayName: Create NuGet Package (ConPTY)
-    dependsOn: Build
-    steps:
-    - checkout: self
-      clean: true
-      fetchDepth: 1
-      submodules: true
-      persistCredentials: True
-    - task: PkgESSetupBuild@12
-      displayName: Package ES - Setup Build
-      inputs:
-        disableOutputRedirect: true
-    - ${{ each platform in parameters.buildPlatforms }}:
-      - task: DownloadBuildArtifacts@0
-        displayName: Download ${{ platform }} ConPTY binaries
-        inputs:
-          artifactName: conpty-dll-${{ platform }}-$(BuildConfiguration)-$(TerminalBestVersionForNuGetPackages)
-          downloadPath: bin\${{ platform }}\$(BuildConfiguration)\
-          extractTars: false
-    - task: PowerShell@2
-      displayName: Move downloaded artifacts around
-      inputs:
-        targetType: inline
-        # Find all artifact files and move them up a directory. Ugh.
-        script: |-
-          Get-ChildItem bin -Recurse -Directory -Filter conpty-dll-* | % {
-            $_ | Get-ChildItem -Recurse -File | % {
-              Move-Item -Verbose $_.FullName $_.Directory.Parent.FullName
-            }
-          }
-          Move-Item bin\x86 bin\Win32
-
-    - task: EsrpCodeSigning@1
-      displayName: Submit ConPTY libraries and OpenConsole for code signing
-      inputs:
-        ConnectedServiceName: 9d6d2960-0793-4d59-943e-78dcb434840a
-        FolderPath: '$(Build.SourcesDirectory)/bin'
-        signType: batchSigning
-        batchSignPolicyFile: '$(Build.SourcesDirectory)\build\config\ESRPSigning_ConPTY.json'
-
-    - task: NuGetToolInstaller@1
-      displayName: Use NuGet 5.10.0
-      inputs:
-        versionSpec: 5.10.0
-    - task: NuGetCommand@2
-      displayName: NuGet pack
-      inputs:
-        command: pack
-        packagesToPack: $(Build.SourcesDirectory)\src\winconpty\package\winconpty.nuspec
-        packDestination: '$(Build.ArtifactStagingDirectory)/nupkg'
-        versioningScheme: byEnvVar
-        versionEnvVar: XES_PACKAGEVERSIONNUMBER
-    - task: EsrpCodeSigning@1
-      displayName: Submit *.nupkg to ESRP for code signing
-      inputs:
-        ConnectedServiceName: 9d6d2960-0793-4d59-943e-78dcb434840a
-        FolderPath: $(Build.ArtifactStagingDirectory)/nupkg
-        Pattern: '*.nupkg'
-        UseMinimatch: true
-        signConfigType: inlineSignParams
-        inlineOperation: >-
-          [
-              {
-                  "KeyCode": "CP-401405",
-                  "OperationCode": "NuGetSign",
-                  "Parameters": {},
-                  "ToolName": "sign",
-                  "ToolVersion": "1.0"
-              },
-              {
-                  "KeyCode": "CP-401405",
-                  "OperationCode": "NuGetVerify",
-                  "Parameters": {},
-                  "ToolName": "sign",
-                  "ToolVersion": "1.0"
-              }
-          ]
-    - task: PublishBuildArtifacts@1
-      displayName: Publish Artifact (nupkg)
-      inputs:
-        PathtoPublish: $(Build.ArtifactStagingDirectory)\nupkg
-        ArtifactName: conpty-nupkg-$(BuildConfiguration)
-
-
 - ${{ if eq(parameters.buildWPF, true) }}:
  - job: PackageAndSignWPF
    strategy:
@@ -506,7 +375,6 @@ jobs:
    steps:
    - checkout: self
      clean: true
-      fetchDepth: 1
      submodules: true
      persistCredentials: True
    - task: PkgESSetupBuild@12
@@ -517,7 +385,7 @@ jobs:
      - task: DownloadBuildArtifacts@0
        displayName: Download ${{ platform }} PublicTerminalCore
        inputs:
-          artifactName: wpf-dll-${{ platform }}-$(BuildConfiguration)-$(TerminalBestVersionForNuGetPackages)
+          artifactName: wpf-dll-${{ platform }}-$(BuildConfiguration)-Win10
          itemPattern: '**/*.dll'
          downloadPath: bin\${{ platform }}\$(BuildConfiguration)\
          extractTars: false
@@ -672,7 +540,6 @@ jobs:
    steps:
    - checkout: self
      clean: true
-      fetchDepth: 1
      submodules: true
    - task: PkgESSetupBuild@12
      displayName: Package ES - Setup Build
--- a/build/pipelines/templates/build-console-audit-job.yml
+++ b/build/pipelines/templates/build-console-audit-job.yml
@@ -8,7 +8,7 @@ jobs:
  variables:
    BuildConfiguration: AuditMode
    BuildPlatform: ${{ parameters.platform }}
-  pool:
+  pool: 
    ${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
      name: WinDevPoolOSS-L
    ${{ if ne(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
@@ -19,9 +19,33 @@ jobs:
  - checkout: self
    submodules: true
    clean: true
-    fetchDepth: 1

-  - template: restore-nuget-steps.yml
+  - task: NuGetToolInstaller@0
+    displayName: Ensure NuGet 4.8.1
+    inputs:
+      versionSpec: 4.8.1
+
+  # In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
+  # This should be `task: NuGetCommand@2`
+  - task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
+    displayName: Restore NuGet packages for extraneous build actions
+    inputs:
+      command: restore
+      feedsToUse: config
+      configPath: NuGet.config
+      restoreSolution: build/packages.config
+      restoreDirectory: '$(Build.SourcesDirectory)\packages'
+
+  # In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
+  # This should be `task: NuGetCommand@2`
+  - task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
+    displayName: Restore NuGet packages
+    inputs:
+      command: restore
+      feedsToUse: config
+      configPath: NuGet.config
+      restoreSolution: OpenConsole.sln
+      restoreDirectory: '$(Build.SourcesDirectory)\packages'

  - task: VSBuild@1
    displayName: 'Build solution **\OpenConsole.sln'
--- a/build/pipelines/templates/build-console-ci.yml
+++ b/build/pipelines/templates/build-console-ci.yml
@@ -1,17 +1,16 @@
 parameters:
  configuration: 'Release'
-  branding: 'Dev'
  platform: ''
  additionalBuildArguments: ''
+  minimumExpectedTestsExecutedCount: 10  # Sanity check for minimum expected tests to be reported
+  rerunPassesRequiredToAvoidFailure: 5

 jobs:
- job: Build${{ parameters.platform }}${{ parameters.configuration }}${{ parameters.branding }}
-  displayName: Build ${{ parameters.platform }} ${{ parameters.configuration }} ${{ parameters.branding }}
+- job: Build${{ parameters.platform }}${{ parameters.configuration }}
+  displayName: Build ${{ parameters.platform }} ${{ parameters.configuration }}
  variables:
    BuildConfiguration: ${{ parameters.configuration }}
    BuildPlatform: ${{ parameters.platform }}
-    WindowsTerminalBranding: ${{ parameters.branding }}
-    EnableRichCodeNavigation: true
  pool: 
    ${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
      name: WinDevPoolOSS-L
@@ -29,3 +28,21 @@ jobs:
  - task: ms.vss-governance-buildtask.governance-build-task-component-detection.ComponentGovernanceComponentDetection@0
    displayName: 'Component Detection'
    condition: and(succeededOrFailed(), not(eq(variables['Build.Reason'], 'PullRequest')))
+
+- template: helix-runtests-job.yml
+  parameters:
+    name: 'RunTestsInHelix'
+    dependsOn: Build${{ parameters.platform }}${{ parameters.configuration }}
+    condition: and(succeeded(), and(eq('${{ parameters.platform }}', 'x64'), not(eq(variables['Build.Reason'], 'PullRequest')))) 
+    testSuite: 'DevTestSuite'
+    platform: ${{ parameters.platform }}
+    configuration: ${{ parameters.configuration }}
+    rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
+    
+- template: helix-processtestresults-job.yml
+  parameters:
+    dependsOn:
+    - RunTestsInHelix
+    condition: and(succeededOrFailed(), and(eq('${{ parameters.platform }}', 'x64'), not(eq(variables['Build.Reason'], 'PullRequest')))) 
+    rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
+    minimumExpectedTestsExecutedCount: ${{ parameters.minimumExpectedTestsExecutedCount }}
--- a/build/pipelines/templates/build-console-compliance-job.yml
+++ b/build/pipelines/templates/build-console-compliance-job.yml
@@ -30,7 +30,28 @@ jobs:
        If ($Arch -Eq "x86") { $Arch = "Win32" }

        Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"
-  - steps: restore-nuget-steps.yml
+  - task: NuGetToolInstaller@1
+    displayName: Use NuGet 5.10
+    inputs:
+      versionSpec: 5.10
+  - task: NuGetAuthenticate@0
+  # In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
+  # This should be `task: NuGetCommand@2`
+  - task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
+    displayName: Restore NuGet packages for extraneous build actions
+    inputs:
+      command: restore
+      feedsToUse: config
+      configPath: NuGet.config
+      restoreSolution: build/packages.config
+      restoreDirectory: '$(Build.SourcesDirectory)\packages'
+  - task: NuGetCommand@2
+    displayName: NuGet custom
+    inputs:
+      command: custom
+      selectOrConfig: config
+      nugetConfigPath: NuGet.Config
+      arguments: restore OpenConsole.sln -SolutionDirectory $(Build.SourcesDirectory)
  - task: UniversalPackages@0
    displayName: Download terminal-internal Universal Package
    inputs:
--- a/build/pipelines/templates/build-console-fuzzing.yml
+++ b/build/pipelines/templates/build-console-fuzzing.yml
@@ -1,91 +0,0 @@
-parameters:
-  configuration: 'Fuzzing'
-  platform: ''
-  additionalBuildArguments: ''
-
-jobs:
- job: Build${{ parameters.platform }}${{ parameters.configuration }}
-  displayName: Build ${{ parameters.platform }} ${{ parameters.configuration }}
-  variables:
-    BuildConfiguration: ${{ parameters.configuration }}
-    BuildPlatform: ${{ parameters.platform }}
-  pool: 
-    ${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPoolOSS-L
-    ${{ if ne(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPool-L
-    demands: ImageOverride -equals WinDevVS16-latest
-
-  steps:
-  - checkout: self
-    submodules: true
-    clean: true
-
-  - template: restore-nuget-steps.yml
-
-  # The environment variable VCToolsInstallDir isn't defined on lab machines, so we need to retrieve it ourselves.
-  - script: |
-      "%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -Latest -requires Microsoft.Component.MSBuild -property InstallationPath > %TEMP%\vsinstalldir.txt
-      set /p _VSINSTALLDIR15=<%TEMP%\vsinstalldir.txt
-      del %TEMP%\vsinstalldir.txt
-      call "%_VSINSTALLDIR15%\Common7\Tools\VsDevCmd.bat"
-      echo VCToolsInstallDir = %VCToolsInstallDir%
-      echo ##vso[task.setvariable variable=VCToolsInstallDir]%VCToolsInstallDir%
-    displayName: 'Retrieve VC tools directory'
-  
-  - task: VSBuild@1
-    displayName: 'Build solution **\OpenConsole.sln'
-    inputs:
-      solution: '**\OpenConsole.sln'
-      vsVersion: 16.0
-      platform: '$(BuildPlatform)'
-      configuration: '$(BuildConfiguration)'
-      msbuildArgs: "${{ parameters.additionalBuildArguments }}"
-      clean: true
-      maximumCpuCount: true
-
-  - task: PowerShell@2
-    displayName: 'Rationalize build platform'
-    inputs:
-      targetType: inline
-      script: |
-        $Arch = "$(BuildPlatform)"
-        If ($Arch -Eq "x86") { $Arch = "Win32" }
-        Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"
-
-  - task: CopyFiles@2
-    displayName: 'Copy result logs to Artifacts'
-    inputs:
-      Contents: |
-       **/*.wtl
-       **/*onBuildMachineResults.xml
-       ${{ parameters.testLogPath }}
-      TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test'
-      OverWrite: true
-      flattenFolders: true
-
-  - task: CopyFiles@2
-    displayName: 'Copy outputs needed for test runs to Artifacts'
-    inputs:
-      Contents: |
-       $(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.exe
-       $(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.dll
-       $(Build.SourcesDirectory)/bin/$(RationalizedBuildPlatform)/$(BuildConfiguration)/*.xml
-       **/Microsoft.VCLibs.*.appx
-       **/TestHostApp/*.exe
-       **/TestHostApp/*.dll
-       **/TestHostApp/*.xml
-       !**/*.pdb
-       !**/*.ipdb
-       !**/*.obj
-       !**/*.pch
-      TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test'
-      OverWrite: true
-      flattenFolders: true
-    condition: succeeded()
-
-  - task: PublishBuildArtifacts@1
-    displayName: 'Publish All Build Artifacts'
-    inputs:
-      PathtoPublish: '$(Build.ArtifactStagingDirectory)'
-      ArtifactName: 'fuzzingBuildOutput'
--- a/build/pipelines/templates/build-console-steps.yml
+++ b/build/pipelines/templates/build-console-steps.yml
@@ -1,13 +1,38 @@
 parameters:
  additionalBuildArguments: ''
+  testLogPath: '$(Build.BinariesDirectory)\$(BuildPlatform)\$(BuildConfiguration)\testsOnBuildMachine.wtl'

 steps:
 - checkout: self
  submodules: true
  clean: true
-  fetchDepth: 1

- template: restore-nuget-steps.yml
+- task: NuGetToolInstaller@0
+  displayName: 'Use NuGet 5.2.0'
+  inputs:
+    versionSpec: 5.2.0
+
+- task: NuGetAuthenticate@0
+
+# In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
+# This should be `task: NuGetCommand@2`
+- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
+  displayName: Restore NuGet packages for extraneous build actions
+  inputs:
+    command: restore
+    feedsToUse: config
+    configPath: NuGet.config
+    restoreSolution: build/packages.config
+    restoreDirectory: '$(Build.SourcesDirectory)\packages'
+
+- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
+  displayName: Restore NuGet packages for solution
+  inputs:
+    command: restore
+    feedsToUse: config
+    configPath: NuGet.config
+    restoreSolution: OpenConsole.sln
+    restoreDirectory: '$(Build.SourcesDirectory)\packages'

 # The environment variable VCToolsInstallDir isn't defined on lab machines, so we need to retrieve it ourselves.
 - script: |
@@ -64,6 +89,55 @@ steps:
      If ($Arch -Eq "x86") { $Arch = "Win32" }
      Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"

+- task: PowerShell@2
+  displayName: 'Run Unit Tests'
+  inputs:
+    targetType: filePath
+    filePath: build\scripts\Run-Tests.ps1
+    arguments: -MatchPattern '*unit.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}'
+  condition: and(and(succeeded(), ne(variables['PGOBuildMode'], 'Instrument')), or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
+
+- task: PowerShell@2
+  displayName: 'Run Feature Tests (x64 only)'
+  inputs:
+    targetType: filePath
+    filePath: build\scripts\Run-Tests.ps1
+    arguments: -MatchPattern '*feature.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}'
+  condition: and(and(succeeded(), ne(variables['PGOBuildMode'], 'Instrument')), eq(variables['BuildPlatform'], 'x64'))
+
+- task: PowerShell@2
+  displayName: 'Convert Test Logs from WTL to xUnit format'
+  inputs:
+    targetType: filePath
+    filePath: build\Helix\ConvertWttLogToXUnit.ps1
+    arguments: -WttInputPath '${{ parameters.testLogPath }}' -WttSingleRerunInputPath 'unused.wtl' -WttMultipleRerunInputPath 'unused2.wtl' -XUnitOutputPath 'onBuildMachineResults.xml' -TestNamePrefix '$(BuildConfiguration).$(BuildPlatform)'
+  condition: and(ne(variables['PGOBuildMode'], 'Instrument'),or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
+
+- task: PublishTestResults@2
+  displayName: 'Upload converted test logs'
+  condition: ne(variables['PGOBuildMode'], 'Instrument')
+  inputs:
+    testResultsFormat: 'xUnit' # Options: JUnit, NUnit, VSTest, xUnit, cTest
+    testResultsFiles: '**/onBuildMachineResults.xml'
+    #searchFolder: '$(System.DefaultWorkingDirectory)' # Optional
+    #mergeTestResults: false # Optional
+    #failTaskOnFailedTests: false # Optional
+    testRunTitle: 'On Build Machine Tests' # Optional
+    buildPlatform: $(BuildPlatform) # Optional
+    buildConfiguration: $(BuildConfiguration) # Optional
+    #publishRunAttachments: true # Optional
+
+- task: CopyFiles@2
+  displayName: 'Copy result logs to Artifacts'
+  inputs:
+    Contents: |
+     **/*.wtl
+     **/*onBuildMachineResults.xml
+     ${{ parameters.testLogPath }}
+    TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test'
+    OverWrite: true
+    flattenFolders: true
+
 - task: CopyFiles@2
  displayName: 'Copy *.appx/*.msix to Artifacts (Non-PR builds only)'
  inputs:
@@ -103,7 +177,7 @@ steps:
  displayName: 'Publish All Build Artifacts'
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)'
-    ArtifactName: 'drop'
+    ArtifactName: 'drop'  

 - task: CopyFiles@2
  displayName: 'Copy PGO databases needed for PGO instrumentation run'
@@ -124,7 +198,7 @@ steps:

 - task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: binlog'
-  condition: always()
+  condition: failed()
  continueOnError: True
  inputs:
    PathtoPublish: $(Build.SourcesDirectory)\msbuild.binlog
--- a/build/pipelines/templates/codenav-indexer.yml
+++ b/build/pipelines/templates/codenav-indexer.yml
@@ -1,22 +0,0 @@
-parameters:
-  artifactName: 'drop'
-
-jobs:
- job: CodeNavIndexer
-  displayName: Run Github CodeNav Indexer
-  pool: { vmImage: windows-2019 }
-
-  steps:
-  - checkout: self
-    fetchDepth: 1
-    submodules: false
-    clean: true
-
-  - task: DownloadBuildArtifacts@0
-    inputs:
-      artifactName: ${{ parameters.artifactName }}
-
-  - task: RichCodeNavIndexer@0
-    inputs:
-      languages: 'cpp,csharp'
-    continueOnError: true
--- a/build/pipelines/templates/console-ci-helix-job.yml
+++ b/build/pipelines/templates/console-ci-helix-job.yml
@@ -1,25 +0,0 @@
-parameters:
-  configuration: 'Release'
-  platform: ''
-  minimumExpectedTestsExecutedCount: 10  # Sanity check for minimum expected tests to be reported
-  rerunPassesRequiredToAvoidFailure: 5
-
-jobs:
- template: helix-runtests-job.yml
-  parameters:
-    name: 'RunTestsInHelix'
-    # We're not setting dependsOn as we want to rely on the "stage" dependency above us
-    testSuite: 'DevTestSuite'
-    platform: ${{ parameters.platform }}
-    configuration: ${{ parameters.configuration }}
-    rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
-    
- template: helix-processtestresults-job.yml
-  parameters:
-    dependsOn:
-    - RunTestsInHelix
-    # the default condition is succeededOrFailed(), and the "stage" condition ensures we only run as needed
-    platform: ${{ parameters.platform }}
-    configuration: ${{ parameters.configuration }}
-    rerunPassesRequiredToAvoidFailure: ${{ parameters.rerunPassesRequiredToAvoidFailure }}
-    minimumExpectedTestsExecutedCount: ${{ parameters.minimumExpectedTestsExecutedCount }}
--- a/build/pipelines/templates/helix-processtestresults-job.yml
+++ b/build/pipelines/templates/helix-processtestresults-job.yml
@@ -8,7 +8,6 @@ parameters:

 jobs:
 - job: ProcessTestResults
-  displayName: Process Helix Results ${{ parameters.platform }} ${{ parameters.configuration }}
  condition: ${{ parameters.condition }}
  dependsOn: ${{ parameters.dependsOn }}
  pool:
--- a/build/pipelines/templates/helix-runtests-job.yml
+++ b/build/pipelines/templates/helix-runtests-job.yml
@@ -19,7 +19,6 @@ parameters:

 jobs:
 - job: ${{ parameters.name }}
-  displayName: Submit Helix ${{ parameters.platform }} ${{ parameters.configuration }}
  dependsOn: ${{ parameters.dependsOn }}
  condition: ${{ parameters.condition }}
  pool:
--- a/build/pipelines/templates/restore-nuget-steps.yml
+++ b/build/pipelines/templates/restore-nuget-steps.yml
@@ -1,36 +0,0 @@
-steps:
- task: NuGetToolInstaller@0
-  displayName: 'Use NuGet 5.2.0'
-  inputs:
-    versionSpec: 5.2.0
-
- task: NuGetAuthenticate@0
-
-# In the Microsoft Azure DevOps tenant, NuGetCommand is ambiguous.
-# This should be `task: NuGetCommand@2`
- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
-  displayName: Restore NuGet packages for extraneous build actions
-  inputs:
-    command: restore
-    feedsToUse: config
-    configPath: NuGet.config
-    restoreSolution: build/packages.config
-    restoreDirectory: '$(Build.SourcesDirectory)\packages'
-
- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
-  displayName: Restore NuGet packages for solution
-  inputs:
-    command: restore
-    feedsToUse: config
-    configPath: NuGet.config
-    restoreSolution: OpenConsole.sln
-    restoreDirectory: '$(Build.SourcesDirectory)\packages'
-
- task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b@2
-  displayName: Restore NuGet packages for global nuget
-  inputs:
-    command: restore
-    feedsToUse: config
-    configPath: NuGet.config
-    restoreSolution: dep/nuget/packages.config
-    restoreDirectory: '$(Build.SourcesDirectory)\packages'
--- a/build/pipelines/templates/test-console-ci.yml
+++ b/build/pipelines/templates/test-console-ci.yml
@@ -1,90 +0,0 @@
-parameters:
-  configuration: 'Release'
-  platform: ''
-  additionalBuildArguments: ''
-  artifactName: 'drop'
-  testLogPath: '$(Build.BinariesDirectory)\$(BuildPlatform)\$(BuildConfiguration)\testsOnBuildMachine.wtl'
-
-jobs:
- job: Test${{ parameters.platform }}${{ parameters.configuration }}
-  displayName: Test ${{ parameters.platform }} ${{ parameters.configuration }}
-  variables:
-    BuildConfiguration: ${{ parameters.configuration }}
-    BuildPlatform: ${{ parameters.platform }}
-  pool: 
-    ${{ if eq(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPoolOSS-L
-    ${{ if ne(variables['System.CollectionUri'], 'https://dev.azure.com/ms/') }}:
-      name: WinDevPool-L
-    demands: ImageOverride -equals WinDevVS16-latest
-
-  steps:
-  - checkout: self
-    submodules: true
-    clean: true
-    fetchDepth: 1
-
-  - task: DownloadBuildArtifacts@0
-    inputs:
-      artifactName: ${{ parameters.artifactName }}
-
-  - task: PowerShell@2
-    displayName: 'Rationalize build platform'
-    inputs:
-      targetType: inline
-      script: |
-        $Arch = "$(BuildPlatform)"
-        If ($Arch -Eq "x86") { $Arch = "Win32" }
-        Write-Host "##vso[task.setvariable variable=RationalizedBuildPlatform]${Arch}"
-
-  - task: PowerShell@2
-    displayName: 'Run Unit Tests'
-    inputs:
-      targetType: filePath
-      filePath: build\scripts\Run-Tests.ps1
-      arguments: -MatchPattern '*unit.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}' -Root "$(System.ArtifactsDirectory)\\${{ parameters.artifactName }}\\$(BuildConfiguration)\\$(BuildPlatform)\\test"
-    condition: and(and(succeeded(), ne(variables['PGOBuildMode'], 'Instrument')), or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
-
-  - task: PowerShell@2
-    displayName: 'Run Feature Tests (x64 only)'
-    inputs:
-      targetType: filePath
-      filePath: build\scripts\Run-Tests.ps1
-      arguments: -MatchPattern '*feature.test*.dll' -Platform '$(RationalizedBuildPlatform)' -Configuration '$(BuildConfiguration)' -LogPath '${{ parameters.testLogPath }}' -Root "$(System.ArtifactsDirectory)\\${{ parameters.artifactName }}\\$(BuildConfiguration)\\$(BuildPlatform)\\test"
-    condition: and(and(succeeded(), ne(variables['PGOBuildMode'], 'Instrument')), eq(variables['BuildPlatform'], 'x64'))
-
-  - task: PowerShell@2
-    displayName: 'Convert Test Logs from WTL to xUnit format'
-    inputs:
-      targetType: filePath
-      filePath: build\Helix\ConvertWttLogToXUnit.ps1
-      arguments: -WttInputPath '${{ parameters.testLogPath }}' -WttSingleRerunInputPath 'unused.wtl' -WttMultipleRerunInputPath 'unused2.wtl' -XUnitOutputPath 'onBuildMachineResults.xml' -TestNamePrefix '$(BuildConfiguration).$(BuildPlatform)'
-    condition: and(ne(variables['PGOBuildMode'], 'Instrument'),or(eq(variables['BuildPlatform'], 'x64'), eq(variables['BuildPlatform'], 'x86')))
-
-  - task: PublishTestResults@2
-    displayName: 'Upload converted test logs'
-    condition: ne(variables['PGOBuildMode'], 'Instrument')
-    inputs:
-      testResultsFormat: 'xUnit' # Options: JUnit, NUnit, VSTest, xUnit, cTest
-      testResultsFiles: '**/onBuildMachineResults.xml'
-      #searchFolder: '$(System.DefaultWorkingDirectory)' # Optional
-      #mergeTestResults: false # Optional
-      #failTaskOnFailedTests: false # Optional
-      testRunTitle: 'On Build Machine Tests' # Optional
-      buildPlatform: $(BuildPlatform) # Optional
-      buildConfiguration: $(BuildConfiguration) # Optional
-      #publishRunAttachments: true # Optional
-
-  - task: CopyFiles@2
-    displayName: 'Copy result logs to Artifacts'
-    inputs:
-      Contents: |
-       **/*.wtl
-       **/*onBuildMachineResults.xml
-       ${{ parameters.testLogPath }}
-      TargetFolder: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test-logs'
-      OverWrite: true
-      flattenFolders: true
-
-  - publish: '$(Build.ArtifactStagingDirectory)/$(BuildConfiguration)/$(BuildPlatform)/test-logs'
-    artifact: TestLogs$(BuildPlatform)$(BuildConfiguration)
--- a/build/rules/GenerateFeatureFlags.proj
+++ b/build/rules/GenerateFeatureFlags.proj
@@ -63,14 +63,8 @@
    Outputs="$(OpenConsoleCommonOutDir)\inc\TilFeatureStaging.h"
    DependsOnTargets="_GenerateBranchAndBrandingCache">
    <MakeDir Directories="$(OpenConsoleCommonOutDir)\inc" />
-    <!-- This commandline is escaped like:
-
-    powershell -Command "&'$(SolutionDir)\tools\Generate-FeatureStagingHeader.ps1' -Path '%(FeatureFlagFile.FullPath)'' -Branding $(_WTBrandingName)"
-
-    which was the only way I could find to get it to obey spaces in the SolutionDir
-    -->
    <Exec
-      Command="powershell -NoLogo -NoProfile -NonInteractive -ExecutionPolicy ByPass -Command &quot;&amp;&apos;$(SolutionDir)\tools\Generate-FeatureStagingHeader.ps1&apos; -Path &apos;%(FeatureFlagFile.FullPath)&apos; -Branding $(_WTBrandingName)&quot;"
+      Command="powershell -NoLogo -NoProfile -NonInteractive -ExecutionPolicy ByPass -Command &quot;$(SolutionDir)\tools\Generate-FeatureStagingHeader.ps1&quot; -Path &quot;%(FeatureFlagFile.FullPath)&quot; -Branding $(_WTBrandingName)"
      ConsoleToMsBuild="true"
      StandardOutputImportance="low">
      <Output TaskParameter="ConsoleOutput" ItemName="_FeatureFlagFileLines" />
--- a/build/scripts/Create-AppxBundle.ps1
+++ b/build/scripts/Create-AppxBundle.ps1
@@ -22,7 +22,7 @@ Param(
    [Parameter(HelpMessage="Path to makeappx.exe")]
    [ValidateScript({Test-Path $_ -Type Leaf})]
    [string]
-    $MakeAppxPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\MakeAppx.exe"
+    $MakeAppxPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x86\MakeAppx.exe"
 )

 If ($null -Eq (Get-Item $MakeAppxPath -EA:SilentlyContinue)) {
--- a/build/scripts/Run-Tests.ps1
+++ b/build/scripts/Run-Tests.ps1
@@ -3,11 +3,10 @@ Param(
    [Parameter(Mandatory=$true, Position=0)][string]$MatchPattern,
    [Parameter(Mandatory=$true, Position=1)][string]$Platform,
    [Parameter(Mandatory=$true, Position=2)][string]$Configuration,
-    [Parameter(Mandatory=$false, Position=3)][string]$LogPath,
-    [Parameter(Mandatory=$false)][string]$Root = ".\bin\$Platform\$Configuration"
+    [Parameter(Mandatory=$false, Position=3)][string]$LogPath
 )

-$testdlls = Get-ChildItem -Path "$Root" -Recurse -Filter $MatchPattern
+$testdlls = Get-ChildItem -Path ".\bin\$Platform\$Configuration" -Recurse -Filter $MatchPattern


 $args = @();
@@ -20,7 +19,7 @@ if ($LogPath)
    Write-Host "Wtt Logging Enabled";
 }

-&"$Root\te.exe" $args $testdlls.FullName
+&".\bin\$Platform\$Configuration\te.exe" $args $testdlls.FullName

 if ($lastexitcode -Ne 0) { Exit $lastexitcode }

--- a/build/scripts/Test-WindowsTerminalPackage.ps1
+++ b/build/scripts/Test-WindowsTerminalPackage.ps1
@@ -8,7 +8,7 @@ Param(
    [Parameter(HelpMessage="Path to Windows Kit")]
    [ValidateScript({Test-Path $_ -Type Leaf})]
    [string]
-    $WindowsKitPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0"
+    $WindowsKitPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0"
 )

 $ErrorActionPreference = "Stop"
--- a/common.openconsole.props
+++ b/common.openconsole.props
@@ -15,15 +15,11 @@
    For the Windows 10 build, we're targeting the prerelease version of Microsoft.UI.Xaml.
    This version emits every XAML DLL directly into our package.
    This is a workaround for us not having deliverable MSFT-21242953 on this version of Windows.
-
-    This version should be tracked in all project packages.config files for projects that depend on Xaml.
    -->
    <TerminalMUXVersion>2.7.2-prerelease.220406002</TerminalMUXVersion>
    <!--
    For the Windows 11-specific build, we're targeting the public version of Microsoft.UI.Xaml.
    This version emits a package dependency instead of embedding the dependency in our own package.
-
-    This version should be tracked in build/packages.config.
    -->
    <TerminalMUXVersion Condition="'$(TerminalTargetWindowsVersion)'=='Win11'">2.7.1</TerminalMUXVersion>
  </PropertyGroup>
--- a/consolegit2gitfilters.json
+++ b/consolegit2gitfilters.json
@@ -11,7 +11,6 @@
    "/packages/",
    "/ipch/",
    "/dep/",
-    "/doc/",
    "/.vs/",
    "/build/",
    "/src/cascadia/",
@@ -25,10 +24,6 @@
    "/doc/cascadia/",
    "/doc/user-docs/",
    "/src/tools/MonarchPeasantSample/",
-    "/src/tools/MonarchPeasantPackage/",
-    "/src/api-ms-win-core-synch-l1-2-0/",
-    "/src/tools/ansi-color/",
-    "/src/tools/ColorTool/",
    "/scratch/",
    "Scratch.sln",
  ],
--- a/custom.props
+++ b/custom.props
@@ -15,9 +15,9 @@
    <VersionBuildRevision Condition="'$(TerminalTargetWindowsVersion)'=='Win11' and '$(VersionBuildRevision)'!=''">$([MSBuild]::Add($(VersionBuildRevision), 1))</VersionBuildRevision>

    <XesUseOneStoreVersioning>true</XesUseOneStoreVersioning>
-    <XesBaseYearForStoreVersion>2022</XesBaseYearForStoreVersion>
+    <XesBaseYearForStoreVersion>2021</XesBaseYearForStoreVersion>
    <VersionMajor>1</VersionMajor>
-    <VersionMinor>15</VersionMinor>
+    <VersionMinor>12</VersionMinor>
    <VersionInfoProductName>Windows Terminal</VersionInfoProductName>
  </PropertyGroup>
 </Project>
--- a/dep/CLI11/CLI11.hpp
+++ b/dep/CLI11/CLI11.hpp
@@ -1,11 +1,11 @@
 #pragma once

-// CLI11: Version 1.9.1
+// CLI11: Version 1.9.0
 // Originally designed by Henry Schreiner
 // https://github.com/CLIUtils/CLI11
 //
 // This is a standalone header file generated by MakeSingleHeader.py in CLI11/scripts
-// from: v1.9.1
+// from: v1.9.0
 //
 // From LICENSE:
 //
@@ -60,14 +60,14 @@
 #include <utility>
 #include <vector>

-// Verbatim copy from Version.hpp:
+// Verbatim copy from CLI/Version.hpp:

 #define CLI11_VERSION_MAJOR 1
 #define CLI11_VERSION_MINOR 9
-#define CLI11_VERSION_PATCH 1
-#define CLI11_VERSION "1.9.1"
+#define CLI11_VERSION_PATCH 0
+#define CLI11_VERSION "1.9.0"

-// Verbatim copy from Macros.hpp:
+// Verbatim copy from CLI/Macros.hpp:

 // The following version macro is very similar to the one in PyBind11
 #if !(defined(_MSC_VER) && __cplusplus == 199711L) && !defined(__INTEL_COMPILER)
@@ -102,7 +102,7 @@
 #define CLI11_DEPRECATED(reason) __attribute__((deprecated(reason)))
 #endif

-// Verbatim copy from Validators.hpp:
+// Verbatim copy from CLI/Validators.hpp:

 // C standard library
 // Only needed for existence checking
@@ -114,14 +114,7 @@
 #else
 #include <filesystem>
 #if defined __cpp_lib_filesystem && __cpp_lib_filesystem >= 201703
-#if defined _GLIBCXX_RELEASE && _GLIBCXX_RELEASE >= 9
 #define CLI11_HAS_FILESYSTEM 1
-#elif defined(__GLIBCXX__)
-// if we are using gcc and Version <9 default to no filesystem
-#define CLI11_HAS_FILESYSTEM 0
-#else
-#define CLI11_HAS_FILESYSTEM 1
-#endif
 #else
 #define CLI11_HAS_FILESYSTEM 0
 #endif
@@ -136,11 +129,11 @@
 #include <sys/types.h>
 #endif

-// From Version.hpp:
+// From CLI/Version.hpp:

-// From Macros.hpp:
+// From CLI/Macros.hpp:

-// From StringTools.hpp:
+// From CLI/StringTools.hpp:

 namespace CLI
 {
@@ -577,7 +570,7 @@ namespace CLI

 } // namespace CLI

-// From Error.hpp:
+// From CLI/Error.hpp:

 namespace CLI
 {
@@ -851,11 +844,11 @@ public:
    {
        CLI11_ERROR_DEF(ParseError, ArgumentMismatch)
        CLI11_ERROR_SIMPLE(ArgumentMismatch)
-        ArgumentMismatch(std::string name, int expected, std::size_t received) :
+        ArgumentMismatch(std::string name, int expected, std::size_t recieved) :
            ArgumentMismatch(expected > 0 ? ("Expected exactly " + std::to_string(expected) + " arguments to " + name +
-                                             ", got " + std::to_string(received)) :
+                                             ", got " + std::to_string(recieved)) :
                                            ("Expected at least " + std::to_string(-expected) + " arguments to " + name +
-                                             ", got " + std::to_string(received)),
+                                             ", got " + std::to_string(recieved)),
                             ExitCodes::ArgumentMismatch) {}

        static ArgumentMismatch AtLeast(std::string name, int num, std::size_t received)
@@ -956,7 +949,7 @@ public:

 } // namespace CLI

-// From TypeTools.hpp:
+// From CLI/TypeTools.hpp:

 namespace CLI
 {
@@ -1244,26 +1237,16 @@ namespace CLI
        };

        /// Convert an object to a string (directly forward if this can become a string)
-        template<typename T, enable_if_t<std::is_convertible<T, std::string>::value, detail::enabler> = detail::dummy>
+        template<typename T, enable_if_t<std::is_constructible<std::string, T>::value, detail::enabler> = detail::dummy>
        auto to_string(T&& value) -> decltype(std::forward<T>(value))
        {
            return std::forward<T>(value);
        }

-        /// Construct a string from the object
-        template<typename T,
-                 enable_if_t<std::is_constructible<std::string, T>::value && !std::is_convertible<T, std::string>::value,
-                             detail::enabler> = detail::dummy>
-        std::string to_string(const T& value)
-        {
-            return std::string(value);
-        }
-
        /// Convert an object to a string (streaming must be supported for that type)
        template<typename T,
-                 enable_if_t<!std::is_convertible<std::string, T>::value && !std::is_constructible<std::string, T>::value &&
-                                 is_ostreamable<T>::value,
-                             detail::enabler> = detail::dummy>
+                 enable_if_t<!std::is_constructible<std::string, T>::value && is_ostreamable<T>::value, detail::enabler> =
+                     detail::dummy>
        std::string to_string(T&& value)
        {
            std::stringstream stream;
@@ -1641,7 +1624,7 @@ namespace CLI
        // Lexical cast

        /// Convert a flag into an integer value  typically binary flags
-        inline std::int64_t to_flag_value(std::string val)
+        inline int64_t to_flag_value(std::string val)
        {
            static const std::string trueString("true");
            static const std::string falseString("false");
@@ -1654,12 +1637,12 @@ namespace CLI
                return -1;
            }
            val = detail::to_lower(val);
-            std::int64_t ret;
+            int64_t ret;
            if (val.size() == 1)
            {
                if (val[0] >= '1' && val[0] <= '9')
                {
-                    return (static_cast<std::int64_t>(val[0]) - '0');
+                    return (static_cast<int64_t>(val[0]) - '0');
                }
                switch (val[0])
                {
@@ -2144,7 +2127,7 @@ namespace CLI
                 enable_if_t<std::is_integral<T>::value && std::is_unsigned<T>::value, detail::enabler> = detail::dummy>
        void sum_flag_vector(const std::vector<std::string>& flags, T& output)
        {
-            std::int64_t count{ 0 };
+            int64_t count{ 0 };
            for (auto& flag : flags)
            {
                count += detail::to_flag_value(flag);
@@ -2161,7 +2144,7 @@ namespace CLI
                 enable_if_t<std::is_integral<T>::value && std::is_signed<T>::value, detail::enabler> = detail::dummy>
        void sum_flag_vector(const std::vector<std::string>& flags, T& output)
        {
-            std::int64_t count{ 0 };
+            int64_t count{ 0 };
            for (auto& flag : flags)
            {
                count += detail::to_flag_value(flag);
@@ -2172,7 +2155,7 @@ namespace CLI
    } // namespace detail
 } // namespace CLI

-// From Split.hpp:
+// From CLI/Split.hpp:

 namespace CLI
 {
@@ -2324,7 +2307,7 @@ namespace CLI
    } // namespace detail
 } // namespace CLI

-// From ConfigFwd.hpp:
+// From CLI/ConfigFwd.hpp:

 namespace CLI
 {
@@ -2453,7 +2436,7 @@ namespace CLI
    };
 } // namespace CLI

-// From Validators.hpp:
+// From CLI/Validators.hpp:

 namespace CLI
 {
@@ -2521,7 +2504,7 @@ namespace CLI
                }
            }
            return retstring;
-        }
+        };

        /// This is the required operator for a Validator - provided to help
        /// users (CLI11 uses the member `func` directly)
@@ -2529,7 +2512,7 @@ namespace CLI
        {
            std::string value = str;
            return (active_) ? func_(value) : std::string{};
-        }
+        };

        /// Specify the type string
        Validator& description(std::string validator_desc)
@@ -2593,14 +2576,14 @@ namespace CLI
        {
            application_index_ = app_index;
            return *this;
-        }
+        };
        /// Specify the application index of a validator
        Validator application_index(int app_index) const
        {
            Validator newval(*this);
            newval.application_index_ = app_index;
            return newval;
-        }
+        };
        /// Get the current value of the application index
        int get_application_index() const { return application_index_; }
        /// Get a boolean if the validator is active
@@ -2716,7 +2699,7 @@ namespace CLI
        /// CLI enumeration of different file types
        enum class path_type
        {
-            nonexistent,
+            nonexistant,
            file,
            directory
        };
@@ -2729,13 +2712,13 @@ namespace CLI
            auto stat = std::filesystem::status(file, ec);
            if (ec)
            {
-                return path_type::nonexistent;
+                return path_type::nonexistant;
            }
            switch (stat.type())
            {
            case std::filesystem::file_type::none:
            case std::filesystem::file_type::not_found:
-                return path_type::nonexistent;
+                return path_type::nonexistant;
            case std::filesystem::file_type::directory:
                return path_type::directory;
            case std::filesystem::file_type::symlink:
@@ -2766,7 +2749,7 @@ namespace CLI
                return ((buffer.st_mode & S_IFDIR) != 0) ? path_type::directory : path_type::file;
            }
 #endif
-            return path_type::nonexistent;
+            return path_type::nonexistant;
        }
 #endif
        /// Check for an existing file (returns error message if check fails)
@@ -2778,7 +2761,7 @@ namespace CLI
            {
                func_ = [](std::string& filename) {
                    auto path_result = check_path(filename.c_str());
-                    if (path_result == path_type::nonexistent)
+                    if (path_result == path_type::nonexistant)
                    {
                        return "File does not exist: " + filename;
                    }
@@ -2800,7 +2783,7 @@ namespace CLI
            {
                func_ = [](std::string& filename) {
                    auto path_result = check_path(filename.c_str());
-                    if (path_result == path_type::nonexistent)
+                    if (path_result == path_type::nonexistant)
                    {
                        return "Directory does not exist: " + filename;
                    }
@@ -2822,7 +2805,7 @@ namespace CLI
            {
                func_ = [](std::string& filename) {
                    auto path_result = check_path(filename.c_str());
-                    if (path_result == path_type::nonexistent)
+                    if (path_result == path_type::nonexistant)
                    {
                        return "Path does not exist: " + filename;
                    }
@@ -2840,7 +2823,7 @@ namespace CLI
            {
                func_ = [](std::string& filename) {
                    auto path_result = check_path(filename.c_str());
-                    if (path_result != path_type::nonexistent)
+                    if (path_result != path_type::nonexistant)
                    {
                        return "Path already exists: " + filename;
                    }
@@ -3327,7 +3310,7 @@ namespace CLI
            // if the type does not have first_type and second_type, these are both value_type
            using element_t = typename detail::element_type<T>::type; // Removes (smart) pointers if needed
            using item_t = typename detail::pair_adaptor<element_t>::first_type; // Is value_type if not a map
-            using local_item_t = typename IsMemberType<item_t>::type; // Will convert bad types to good ones
+            using local_item_t = typename IsMemberType<item_t>::type; // This will convert bad types to good ones
                // (const char * to std::string)

            // Make a local copy of the filter function, using a std::function if not one already
@@ -3398,9 +3381,10 @@ namespace CLI
            // if the type does not have first_type and second_type, these are both value_type
            using element_t = typename detail::element_type<T>::type; // Removes (smart) pointers if needed
            using item_t = typename detail::pair_adaptor<element_t>::first_type; // Is value_type if not a map
-            using local_item_t = typename IsMemberType<item_t>::type; // Will convert bad types to good ones
+            using local_item_t = typename IsMemberType<item_t>::type; // This will convert bad types to good ones
                // (const char * to std::string)
-            using iteration_type_t = typename detail::pair_adaptor<element_t>::value_type; // the type of the object pair
+            using iteration_type_t = typename detail::pair_adaptor<element_t>::value_type; // the type of the object pair //
+                // the type of the object pair

            // Make a local copy of the filter function, using a std::function if not one already
            std::function<local_item_t(local_item_t)> filter_fn = filter_function;
@@ -3641,7 +3625,7 @@ namespace CLI
    class AsSizeValue : public AsNumberWithUnit
    {
    public:
-        using result_t = std::uint64_t;
+        using result_t = uint64_t;

        /// If kb_is_1000 is true,
        /// interpret 'kb', 'k' as 1000 and 'kib', 'ki' as 1024
@@ -3737,7 +3721,7 @@ namespace CLI

 } // namespace CLI

-// From FormatterFwd.hpp:
+// From CLI/FormatterFwd.hpp:

 namespace CLI
 {
@@ -3751,9 +3735,9 @@ namespace CLI

    enum class AppFormatMode
    {
-        Normal, ///< The normal, detailed help
-        All, ///< A fully expanded help
-        Sub, ///< Used when printed as part of expanded subcommand
+        Normal, //< The normal, detailed help
+        All, //< A fully expanded help
+        Sub, //< Used when printed as part of expanded subcommand
    };

    /// This is the minimum requirements to run a formatter.
@@ -3913,7 +3897,7 @@ namespace CLI

 } // namespace CLI

-// From Option.hpp:
+// From CLI/Option.hpp:

 namespace CLI
 {
@@ -4457,7 +4441,7 @@ namespace CLI
        template<typename T = App>
        Option* needs(std::string opt_name)
        {
-            auto opt = static_cast<T*>(parent_)->get_option_no_throw(opt_name);
+            auto opt = dynamic_cast<T*>(parent_)->get_option_no_throw(opt_name);
            if (opt == nullptr)
            {
                throw IncorrectConstruction::MissingOption(opt_name);
@@ -4508,7 +4492,7 @@ namespace CLI
        template<typename T = App>
        Option* excludes(std::string opt_name)
        {
-            auto opt = static_cast<T*>(parent_)->get_option_no_throw(opt_name);
+            auto opt = dynamic_cast<T*>(parent_)->get_option_no_throw(opt_name);
            if (opt == nullptr)
            {
                throw IncorrectConstruction::MissingOption(opt_name);
@@ -4554,7 +4538,7 @@ namespace CLI
            if (!ignore_case_ && value)
            {
                ignore_case_ = value;
-                auto* parent = static_cast<T*>(parent_);
+                auto* parent = dynamic_cast<T*>(parent_);
                for (const Option_p& opt : parent->options_)
                {
                    if (opt.get() == this)
@@ -4586,7 +4570,7 @@ namespace CLI
            if (!ignore_underscore_ && value)
            {
                ignore_underscore_ = value;
-                auto* parent = static_cast<T*>(parent_);
+                auto* parent = dynamic_cast<T*>(parent_);
                for (const Option_p& opt : parent->options_)
                {
                    if (opt.get() == this)
@@ -4714,9 +4698,9 @@ namespace CLI
        /// Will include / prefer the positional name if positional is true.
        /// If all_options is false, pick just the most descriptive name to show.
        /// Use `get_name(true)` to get the positional name (replaces `get_pname`)
-        std::string get_name(bool positional = false, ///< Show the positional name
-                             bool all_options = false ///< Show every option
-        ) const
+        std::string get_name(bool positional = false, //<[input] Show the positional name
+                             bool all_options = false //<[input] Show every option
+                             ) const
        {
            if (get_group().empty())
                return {}; // Hidden
@@ -5016,7 +5000,7 @@ namespace CLI
                {
                    if (!default_str_.empty())
                    {
-                        // _add_results takes an rvalue only
+                        //_add_results takes an rvalue only
                        _add_result(std::string(default_str_), res);
                        _validate_results(res);
                        results_t extra;
@@ -5395,7 +5379,7 @@ namespace CLI

 } // namespace CLI

-// From App.hpp:
+// From CLI/App.hpp:

 namespace CLI
 {
@@ -6237,9 +6221,8 @@ namespace CLI
        }

        /// Vector version to capture multiple flags.
-        template<
-            typename T,
-            enable_if_t<!std::is_assignable<std::function<void(std::int64_t)>, T>::value, detail::enabler> = detail::dummy>
+        template<typename T,
+                 enable_if_t<!std::is_assignable<std::function<void(int64_t)>, T>::value, detail::enabler> = detail::dummy>
        Option* add_flag(std::string flag_name,
                         std::vector<T>& flag_results, ///< A vector of values with the flag results
                         std::string flag_description = "")
@@ -6277,11 +6260,11 @@ namespace CLI

        /// Add option for callback with an integer value
        Option* add_flag_function(std::string flag_name,
-                                  std::function<void(std::int64_t)> function, ///< A function to call, void(int)
+                                  std::function<void(int64_t)> function, ///< A function to call, void(int)
                                  std::string flag_description = "")
        {
            CLI::callback_t fun = [function](const CLI::results_t& res) {
-                std::int64_t flag_count = 0;
+                int64_t flag_count = 0;
                detail::sum_flag_vector(res, flag_count);
                function(flag_count);
                return true;
@@ -6293,7 +6276,7 @@ namespace CLI
 #ifdef CLI11_CPP14
        /// Add option for callback (C++14 or better only)
        Option* add_flag(std::string flag_name,
-                         std::function<void(std::int64_t)> function, ///< A function to call, void(std::int64_t)
+                         std::function<void(int64_t)> function, ///< A function to call, void(int64_t)
                         std::string flag_description = "")
        {
            return add_flag_function(std::move(flag_name), std::move(function), std::move(flag_description));
@@ -6469,7 +6452,7 @@ namespace CLI
        template<typename T = Option_group>
        T* add_option_group(std::string group_name, std::string group_description = "")
        {
-            auto option_group = std::make_shared<T>(std::move(group_description), group_name, this);
+            auto option_group = std::make_shared<T>(std::move(group_description), group_name, nullptr);
            auto ptr = option_group.get();
            // move to App_p for overload resolution on older gcc versions
            App_p app_ptr = std::dynamic_pointer_cast<App>(option_group);
@@ -6478,7 +6461,7 @@ namespace CLI
        }

        ///@}
-        /// @name Subcommands
+        /// @name Subcommmands
        ///@{

        /// Add a subcommand. Inherits INHERITABLE and OptionDefaults, and help flag
@@ -6854,16 +6837,16 @@ namespace CLI
        int exit(const Error& e, std::ostream& out = std::cout, std::ostream& err = std::cerr) const
        {
            /// Avoid printing anything if this is a CLI::RuntimeError
-            if (e.get_name() == "RuntimeError")
+            if (dynamic_cast<const CLI::RuntimeError*>(&e) != nullptr)
                return e.get_exit_code();

-            if (e.get_name() == "CallForHelp")
+            if (dynamic_cast<const CLI::CallForHelp*>(&e) != nullptr)
            {
                out << help();
                return e.get_exit_code();
            }

-            if (e.get_name() == "CallForAllHelp")
+            if (dynamic_cast<const CLI::CallForAllHelp*>(&e) != nullptr)
            {
                out << help("", AppFormatMode::All);
                return e.get_exit_code();
@@ -7097,12 +7080,7 @@ namespace CLI
        /// Access the config formatter as a configBase pointer
        std::shared_ptr<ConfigBase> get_config_formatter_base() const
        {
-            // This is safer as a dynamic_cast if we have RTTI, as Config -> ConfigBase
-#if defined(__cpp_rtti) || (defined(__GXX_RTTI) && __GXX_RTTI) || (defined(_HAS_STATIC_RTTI) && (_HAS_STATIC_RTTI == 0))
            return std::dynamic_pointer_cast<ConfigBase>(config_formatter_);
-#else
-            return std::static_pointer_cast<ConfigBase>(config_formatter_);
-#endif
        }

        /// Get the app or subcommand description
@@ -8930,21 +8908,6 @@ namespace CLI
        /// This class is simply to allow tests access to App's protected functions
        struct AppFriend
        {
-#ifdef CLI11_CPP14
-            /// Wrap _parse_short, perfectly forward arguments and return
-            template<typename... Args>
-            static decltype(auto) parse_arg(App* app, Args&&... args)
-            {
-                return app->_parse_arg(std::forward<Args>(args)...);
-            }
-
-            /// Wrap _parse_subcommand, perfectly forward arguments and return
-            template<typename... Args>
-            static decltype(auto) parse_subcommand(App* app, Args&&... args)
-            {
-                return app->_parse_subcommand(std::forward<Args>(args)...);
-            }
-#else
            /// Wrap _parse_short, perfectly forward arguments and return
            template<typename... Args>
            static auto parse_arg(App* app, Args&&... args) ->
@@ -8960,7 +8923,6 @@ namespace CLI
            {
                return app->_parse_subcommand(std::forward<Args>(args)...);
            }
-#endif
            /// Wrap the fallthrough parent function to make sure that is working correctly
            static App* get_fallthrough_parent(App* app) { return app->_get_fallthrough_parent(); }
        };
@@ -8968,7 +8930,7 @@ namespace CLI

 } // namespace CLI

-// From Config.hpp:
+// From CLI/Config.hpp:

 namespace CLI
 {
@@ -9398,7 +9360,7 @@ namespace CLI

 } // namespace CLI

-// From Formatter.hpp:
+// From CLI/Formatter.hpp:

 namespace CLI
 {
--- a/dep/CLI11/README.md
+++ b/dep/CLI11/README.md
@@ -1,4 +1,5 @@
 # CLI11

-Taken from [release v1.9.1](https://github.com/CLIUtils/CLI11/releases/tag/v1.9.1), source commit
-[5cb3efa](https://github.com/CLIUtils/CLI11/commit/5cb3efabce007c3a0230e4cc2e27da491c646b6c)
+Taken from [release v1.9.0](https://github.com/CLIUtils/CLI11/releases/tag/v1.9.0), source commit
+[dd0d8e4](https://github.com/CLIUtils/CLI11/commit/dd0d8e4fe729e5b1110232c7a5c9566dad884686)
+
--- a/dep/Console/ConIoSrv.h
+++ b/dep/Console/ConIoSrv.h
@@ -1,76 +0,0 @@
-/*++
-Copyright (c) Microsoft Corporation.
-Licensed under the MIT license.
--*/
-
-#pragma once
-
-#include <ntlpcapi.h>
-
-#define CIS_ALPC_PORT_NAME           L""
-
-#define CIS_EVENT_TYPE_INPUT         (0)
-#define CIS_EVENT_TYPE_FOCUS         (1)
-#define CIS_EVENT_TYPE_FOCUS_ACK     (2)
-
-#define CIS_MSG_TYPE_GETDISPLAYSIZE  (3)
-#define CIS_MSG_TYPE_GETFONTSIZE     (4)
-#define CIS_MSG_TYPE_SETCURSOR       (5)
-#define CIS_MSG_TYPE_UPDATEDISPLAY   (6)
-
-#define CIS_MSG_ATTR_FLAGS           (0)
-
-#define CIS_MSG_ATTR_BUFFER_SIZE     (1024)
-
-#define CIS_DISPLAY_MODE_NONE        (0)
-#define CIS_DISPLAY_MODE_BGFX        (1)
-#define CIS_DISPLAY_MODE_DIRECTX     (2)
-
-typedef struct {
-    PORT_MESSAGE AlpcHeader;
-    UCHAR Type;
-
-    union {
-        struct {
-            CD_IO_DISPLAY_SIZE DisplaySize;
-
-            NTSTATUS ReturnValue;
-        } GetDisplaySizeParams;
-
-        struct {
-            CD_IO_FONT_SIZE FontSize;
-
-            NTSTATUS ReturnValue;
-        } GetFontSizeParams;
-
-        struct {
-            CD_IO_CURSOR_INFORMATION CursorInformation;
-
-            NTSTATUS ReturnValue;
-        } SetCursorParams;
-
-        struct {
-            SHORT RowIndex;
-
-            NTSTATUS ReturnValue;
-        } UpdateDisplayParams;
-
-        struct {
-            USHORT DisplayMode;
-        } GetDisplayModeParams;
-    };
-} CIS_MSG, *PCIS_MSG;
-
-typedef struct {
-    UCHAR Type;
-
-    union {
-        struct {
-            INPUT_RECORD Record;
-        } InputEvent;
-
-        struct {
-            BOOLEAN IsActive;
-        } FocusEvent;
-    };
-} CIS_EVENT, *PCIS_EVENT;
--- a/dep/Console/conapi.h
+++ b/dep/Console/conapi.h
@@ -1,6 +1,5 @@
 /*++
-Copyright (c) Microsoft Corporation.
-Licensed under the MIT license.
+Copyright (c) Microsoft Corporation

 Module Name:
 - conapi.h
--- a/dep/Console/condrv.h
+++ b/dep/Console/condrv.h
@@ -1,7 +1,6 @@
 /*++

 Copyright (c) Microsoft Corporation. All rights reserved.
-Licensed under the MIT license.

 Module Name:

@@ -158,8 +157,8 @@ typedef struct _CD_IO_DISPLAY_SIZE {
 } CD_IO_DISPLAY_SIZE, *PCD_IO_DISPLAY_SIZE;

 typedef struct _CD_IO_CHARACTER {
-    WCHAR Character;
-    USHORT Attribute;
+    WCHAR Character; 
+    USHORT Atribute;
 } CD_IO_CHARACTER, *PCD_IO_CHARACTER;

 typedef struct _CD_IO_ROW_INFORMATION {
@@ -175,11 +174,6 @@ typedef struct _CD_IO_CURSOR_INFORMATION {
    BOOLEAN IsVisible;
 } CD_IO_CURSOR_INFORMATION, *PCD_IO_CURSOR_INFORMATION;

-typedef struct _CD_IO_FONT_SIZE {
-    ULONG Width;
-    ULONG Height;
-} CD_IO_FONT_SIZE, *PCD_IO_FONT_SIZE;
-
 #define IOCTL_CONDRV_READ_IO \
    CTL_CODE(FILE_DEVICE_CONSOLE, 1, METHOD_OUT_DIRECT, FILE_ANY_ACCESS)

@@ -218,6 +212,3 @@ typedef struct _CD_IO_FONT_SIZE {

 #define IOCTL_CONDRV_LAUNCH_SERVER \
    CTL_CODE(FILE_DEVICE_CONSOLE, 13, METHOD_NEITHER, FILE_ANY_ACCESS)
-
-#define IOCTL_CONDRV_GET_FONT_SIZE \
-    CTL_CODE(FILE_DEVICE_CONSOLE, 14, METHOD_NEITHER, FILE_ANY_ACCESS)
--- a/dep/Console/conmsgl1.h
+++ b/dep/Console/conmsgl1.h
@@ -1,7 +1,6 @@
 /*++

 Copyright (c) Microsoft Corporation. All rights reserved.
-Licensed under the MIT license.

 Module Name:

--- a/dep/Console/conmsgl2.h
+++ b/dep/Console/conmsgl2.h
@@ -1,7 +1,6 @@
 /*++

 Copyright (c) Microsoft Corporation. All rights reserved.
-Licensed under the MIT license.

 Module Name:

--- a/dep/Console/conmsgl3.h
+++ b/dep/Console/conmsgl3.h
@@ -1,7 +1,6 @@
 /*++

-Copyright (c) 1985 - 1999, Microsoft Corporation.
-Licensed under the MIT license.
+Copyright (c) 1985 - 1999, Microsoft Corporation

 Module Name:

--- a/dep/Console/csrmsg.h
+++ b/dep/Console/csrmsg.h
@@ -1,24 +0,0 @@
-/*++
-Copyright (c) Microsoft Corporation.
-Licensed under the MIT license.
--*/
-
-#pragma once
-
-#include <ntcsrmsg.h>
-
-typedef enum _USER_API_NUMBER {
-    UserpEndTask,
-} USER_API_NUMBER, *PUSER_API_NUMBER;
-
-typedef struct _ENDTASKMSG {
-    HANDLE ProcessId;
-    ULONG ConsoleEventCode;
-    ULONG ConsoleFlags;
-} ENDTASKMSG, *PENDTASKMSG;
-
-typedef struct _USER_API_MSG {
-    union {
-        ENDTASKMSG EndTask;
-    } u;
-} USER_API_MSG, *PUSER_API_MSG;
--- a/dep/Console/ntcon.h
+++ b/dep/Console/ntcon.h
@@ -1,6 +1,5 @@
 //
 //    Copyright (C) Microsoft.  All rights reserved.
-//    Licensed under the MIT license.
 //
 #ifndef _NTCON_
 #define _NTCON_
--- a/dep/Console/ntcsrdll.h
+++ b/dep/Console/ntcsrdll.h
@@ -1,15 +0,0 @@
-/*++
-Copyright (c) Microsoft Corporation.
-Licensed under the MIT license.
--*/
-
-#pragma once
-
-#include <ntcsrmsg.h>
-
-NTSTATUS CsrClientCallServer(
-    PCSR_API_MSG m,
-    PCSR_CAPTURE_HEADER CaptureBuffer OPTIONAL,
-    ULONG ApiNumber,
-    ULONG ArgLength
-);
--- a/dep/Console/ntcsrmsg.h
+++ b/dep/Console/ntcsrmsg.h
@@ -1,16 +0,0 @@
-/*++
-Copyright (c) Microsoft Corporation.
-Licensed under the MIT license.
--*/
-
-#pragma once
-
-#include <ntlpcapi.h>
-
-typedef struct _CSR_CAPTURE_HEADER {
-} CSR_CAPTURE_HEADER, *PCSR_CAPTURE_HEADER;
-
-typedef struct _CSR_API_MSG {
-} CSR_API_MSG, *PCSR_API_MSG;
-
-#define CSR_MAKE_API_NUMBER(DllIndex, ApiIndex) 0
--- a/dep/Console/ntlpcapi.h
+++ b/dep/Console/ntlpcapi.h
@@ -1,126 +0,0 @@
-/*++
-Copyright (c) Microsoft Corporation.
-Licensed under the MIT license.
--*/
-
-#pragma once
-
-#define OB_FILE_OBJECT_TYPE 1
-
-typedef struct _PORT_MESSAGE {
-    union {
-        struct {
-            SHORT DataLength;
-            SHORT TotalLength;
-        } s1;
-    } u1;
-    union {
-        ULONG ZeroInit;
-    } u2;
-    union {
-        CLIENT_ID ClientId;
-    };
-    ULONG MessageId;
-} PORT_MESSAGE, *PPORT_MESSAGE;
-
-#define ALPC_MSGFLG_SYNC_REQUEST            0
-#define ALPC_PORFLG_ACCEPT_DUP_HANDLES      1
-#define ALPC_PORFLG_ACCEPT_INDIRECT_HANDLES 2
-
-typedef struct _ALPC_DATA_VIEW_ATTR {
-    PVOID  ViewBase;
-    SIZE_T ViewSize;
-} ALPC_DATA_VIEW_ATTR, *PALPC_DATA_VIEW_ATTR;
-
-typedef struct _ALPC_CONTEXT_ATTR {
-} ALPC_CONTEXT_ATTR, *PALPC_CONTEXT_ATTR;
-
-#define ALPC_INDIRECT_HANDLE_MAX 512
-
-typedef struct _ALPC_HANDLE_ATTR {
-    union {
-        ULONG HandleCount;
-    };
-} ALPC_HANDLE_ATTR, *PALPC_HANDLE_ATTR;
-
-#define ALPC_FLG_MSG_DATAVIEW_ATTR 1
-#define ALPC_FLG_MSG_HANDLE_ATTR   2
-
-typedef struct _ALPC_MESSAGE_ATTRIBUTES {
-} ALPC_MESSAGE_ATTRIBUTES, *PALPC_MESSAGE_ATTRIBUTES;
-
-typedef struct _ALPC_PORT_ATTRIBUTES {
-    ULONG Flags;
-    SECURITY_QUALITY_OF_SERVICE SecurityQos;
-    SIZE_T MaxMessageLength;
-    SIZE_T MemoryBandwidth;
-    SIZE_T MaxPoolUsage;
-    SIZE_T MaxSectionSize;
-    SIZE_T MaxViewSize;
-    SIZE_T MaxTotalSectionSize;
-    ULONG DupObjectTypes;
-#ifdef _WIN64
-    ULONG Reserved;
-#endif
-} ALPC_PORT_ATTRIBUTES, *PALPC_PORT_ATTRIBUTES;
-
-typedef enum _ALPC_MESSAGE_INFORMATION_CLASS {
-    AlpcMessageHandleInformation
-} ALPC_MESSAGE_INFORMATION_CLASS;
-
-typedef struct _ALPC_MESSAGE_HANDLE_INFORMATION {
-    ULONG Index;
-    ULONG Handle;
-} ALPC_MESSAGE_HANDLE_INFORMATION, *PALPC_MESSAGE_HANDLE_INFORMATION;
-
-NTSTATUS AlpcInitializeMessageAttribute(
-    ULONG AttributeFlags,
-    PALPC_MESSAGE_ATTRIBUTES Buffer,
-    SIZE_T BufferSize,
-    PSIZE_T RequiredBufferSize
-);
-
-PVOID AlpcGetMessageAttribute(
-    PALPC_MESSAGE_ATTRIBUTES Buffer,
-    ULONG AttributeFlag
-);
-
-#define ALPC_GET_DATAVIEW_ATTRIBUTES(MsgAttr) \
-    ((PALPC_DATA_VIEW_ATTR)AlpcGetMessageAttribute(MsgAttr, ALPC_FLG_MSG_DATAVIEW_ATTR))
-
-#define ALPC_GET_HANDLE_ATTRIBUTES(MsgAttr) \
-    ((PALPC_HANDLE_ATTR)AlpcGetMessageAttribute(MsgAttr, ALPC_FLG_MSG_HANDLE_ATTR))
-
-NTSTATUS NtAlpcConnectPort(
-    PHANDLE PortHandle,
-    PUNICODE_STRING PortName,
-    POBJECT_ATTRIBUTES ObjectAttributes,
-    PALPC_PORT_ATTRIBUTES PortAttributes,
-    ULONG Flags,
-    PSID RequiredServerSid,
-    PPORT_MESSAGE ConnectionMessage,
-    PSIZE_T BufferLength,
-    PALPC_MESSAGE_ATTRIBUTES OutMessageAttributes,
-    PALPC_MESSAGE_ATTRIBUTES InMessageAttributes,
-    PLARGE_INTEGER Timeout
-);
-
-NTSTATUS NtAlpcSendWaitReceivePort(
-    HANDLE PortHandle,
-    ULONG Flags,
-    PPORT_MESSAGE SendMessage,
-    PALPC_MESSAGE_ATTRIBUTES SendMessageAttributes,
-    PPORT_MESSAGE ReceiveMessage,
-    PSIZE_T BufferLength,
-    PALPC_MESSAGE_ATTRIBUTES ReceiveMessageAttributes,
-    PLARGE_INTEGER Timeout
-);
-
-NTSTATUS NtAlpcQueryInformationMessage(
-    HANDLE PortHandle,
-    PPORT_MESSAGE PortMessage,
-    ALPC_MESSAGE_INFORMATION_CLASS MessageInformationClass,
-    PVOID MessageInformation,
-    ULONG Length,
-    PULONG ReturnLength
-);
--- a/dep/Console/winconp.h
+++ b/dep/Console/winconp.h
@@ -1,7 +1,3 @@
-/*++
-Copyright (c) Microsoft Corporation.
-Licensed under the MIT license.
--*/

 #ifndef _WINCONP_
 #define _WINCONP_
--- a/dep/NT/ntioapi_x.h
+++ b/dep/NT/ntioapi_x.h
@@ -1,8 +1,3 @@
-/*++
-Copyright (c) Microsoft Corporation.
-Licensed under the MIT license.
--*/
-
 #pragma once

 #define FILE_SYNCHRONOUS_IO_NONALERT            0x00000020
--- a/dep/Win32K/winuserp.h
+++ b/dep/Win32K/winuserp.h
@@ -1,7 +1,4 @@
 /*
- * Copyright (c) Microsoft Corporation.
- * Licensed under the MIT license.
- *
 * Reserved console space.
 *
 * This was moved from the console code so that we can localize it
--- a/dep/nuget/packages.config
+++ b/dep/nuget/packages.config
@@ -1,22 +0,0 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- The packages.config acts as the global version for all of the NuGet packages contained within. -->
-<packages>
-  <!-- Native packages -->
-  <package id="Microsoft.Toolkit.Win32.UI.XamlApplication" version="6.1.3" targetFramework="native" />
-  <package id="Microsoft.Internal.PGO-Helpers.Cpp" version="0.2.34" targetFramework="native" />
-  <package id="Microsoft.Taef" version="10.60.210621002" targetFramework="native" />
-  <package id="Microsoft.Windows.CppWinRT" version="2.0.210825.3" targetFramework="native" />
-  <package id="vcpkg-cpprestsdk" version="2.10.14" targetFramework="native" />
-  <package id="Microsoft.VCRTForwarders.140" version="1.0.4" targetFramework="native" />
-  <package id="Microsoft.Internal.Windows.Terminal.ThemeHelpers" version="0.6.220404001" targetFramework="native" />
-  <package id="Microsoft.VisualStudio.Setup.Configuration.Native" version="2.3.2262" targetFramework="native" developmentDependency="true" />
-  <package id="Microsoft.UI.Xaml" version="2.7.2-prerelease.220406002" targetFramework="native" />
-  <package id="Microsoft.Windows.ImplementationLibrary" version="1.0.220201.1" targetFramework="native" developmentDependency="true" />
-
-  <!-- Managed packages -->
-  <package id="Appium.WebDriver" version="3.0.0.2" targetFramework="net45" />
-  <package id="Castle.Core" version="4.1.1" targetFramework="net45" />
-  <package id="Newtonsoft.Json" version="12.0.3" targetFramework="net45" />
-  <package id="Selenium.Support" version="3.5.0" targetFramework="net45" />
-  <package id="Selenium.WebDriver" version="3.5.0" targetFramework="net45" />
-</packages>
--- a/dep/wil
+++ b/dep/wil
--- a/doc/EXCEPTIONS.md
+++ b/doc/EXCEPTIONS.md
@@ -4,7 +4,7 @@
 Introducing exceptions to an existing non-exception-based codebase can be perilous. The console was originally written
 in C at a time when C++ was relatively unused in the Windows operating system. As part of our project to modernize the
 Windows console, we converted to use C++, but still had an aversion to using exception-based error handling in
-our code for fear that it might introduce unexpected failures. However, the STL and other libraries like it are so useful that
+our code for fear that it introduce unexpected failures. However, the STL and other libraries like it are so useful that
 sometimes it's significantly simpler to use them. Given that, we have a set of rules that we follow when considering
 exception use.

--- a/doc/Niksa.md
+++ b/doc/Niksa.md
@@ -163,7 +163,7 @@ Given that we're using Xaml islands to host a modern UI and stitching a DirectX

 Now, the obvious followup question is _"why can't you have one elevated connection in a tab next to a non-elevated connection?"_ This is where @sba923 should pick up reading (:smile:). I'm probably going to cover some things that you (@robomac) know already.

-[2] When you have two windows on the same desktop in the same window station, they can communicate with each other. I can use `SendKeys` easily through `WScript.Shell` to send keyboard input to any window that the shell can see.
+[2] When you have two windows on the same desktop in the same window station, they can communicate with eachother. I can use `SendKeys` easily through `WScript.Shell` to send keyboard input to any window that the shell can see.

 Running a process elevated _severs_ that connection. The shell can't see the elevated window. No other program at the same integrity level as the shell can see the elevated window. Even if it has its window handle, it can't really interact with it. This is also why you can't drag/drop from explorer into notepad if notepad is running elevated. Only another elevated process can interact with another elevated window.

--- a/doc/building.md
+++ b/doc/building.md
@@ -64,16 +64,7 @@ Openconsole has three configuration types:

 AuditMode is an experimental mode that enables some additional static analysis from CppCoreCheck.

-## Updating Nuget package references - Globally versioned
-Most Nuget package references in this project are centralized in a single configuration so that there is a single canonical version for everything.  This canonical version is restored before builds by the build pipeline, environment initialization scripts, or Visual Studio (as appropriate).
-
-The canonical version numbers are defined in dep/nuget/packages.config.  That defines what will be downloaded by nuget.exe.  Most Nuget packages also have a .props and/or .targets file that must be imported by every project that consumes it.  Those import statements are consolidated in:
- src/common.nugetversions.props
- src/common.nugetversions.targets
-
-When a globally managed version changes all three of those files must be changed in unison.
-
-## Updating Nuget package references - Locally versioned
+## Updating Nuget package references
 Certain Nuget package references in this project, like `Microsoft.UI.Xaml`, must be updated outside of the Visual Studio NuGet package manager. This can be done using the snippet below.
 > Note that to run this snippet, you need to use WSL as the command uses `sed`.
 To update the version of a given package, use the following snippet
@@ -96,46 +87,3 @@ If you want to use .nupkg files instead of the downloaded Nuget package, you can
 2. Create the folder /dep/packages
 3. Put your .nupkg files in /dep/packages
 4. If you are using different versions than those already being used, you need to update the references as well. How to do that is explained under "Updating Nuget package references".
-
-
-## Building the Terminal package from the commandline
-
-The Terminal is bundled as an `.msix`, which is produced by the `CascadiaPackage.wapproj` project. To build that project from the commandline, you can run the following (from a window you've already run `tools\razzle.cmd` in):
-
-```cmd
-"%msbuild%" "%OPENCON%\OpenConsole.sln" /p:Configuration=%_LAST_BUILD_CONF% /p:Platform=%ARCH% /p:AppxSymbolPackageEnabled=false /t:Terminal\CascadiaPackage /m
-```
-
-This takes quite some time, and only generates an `msix`. It does not install the msix. To deploy the package:
-
-```powershell
-# If you haven't already:
-Import-Module tools\OpenConsole.psm1;
-Set-MsBuildDevEnvironment;
-
-# The Set-MsBuildDevEnvironment call is needed for finding the path to
-# makeappx. It also takes a little longer to run. If you're sticking in powershell, best to do that.
-
-Set-Location -Path src\cascadia\CascadiaPackage\AppPackages\CascadiaPackage_0.0.1.0_x64_Debug_Test;
-if ((Get-AppxPackage -Name 'WindowsTerminalDev*') -ne $null) {
-Remove-AppxPackage 'WindowsTerminalDev_0.0.1.0_x64__8wekyb3d8bbwe'
-};
-New-Item ..\loose -Type Directory -Force;
-makeappx unpack /v /o /p .\CascadiaPackage_0.0.1.0_x64_Debug.msix /d ..\Loose\;
-Add-AppxPackage -Path ..\loose\AppxManifest.xml -Register -ForceUpdateFromAnyVersion -ForceApplicationShutdown
-```
-
-Or the cmd.exe version:
-```cmd
-@rem razzle.cmd doesn't set:
-@rem set WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\
-@rem vsdevcmd.bat does a lot of logic to find that.
-@rem
-@rem I'm gonna hard code it below:
-
-powershell -Command Set-Location -Path %OPENCON%\src\cascadia\CascadiaPackage\AppPackages\CascadiaPackage_0.0.1.0_x64_Debug_Test;if ((Get-AppxPackage -Name 'WindowsTerminalDev*') -ne $null) { Remove-AppxPackage 'WindowsTerminalDev_0.0.1.0_x64__8wekyb3d8bbwe'};New-Item ..\loose -Type Directory -Force;C:\'Program Files (x86)'\'Windows Kits'\10\bin\10.0.19041.0\x64\makeappx unpack /v /o /p .\CascadiaPackage_0.0.1.0_x64_Debug.msix /d ..\Loose\;Add-AppxPackage -Path ..\loose\AppxManifest.xml -Register -ForceUpdateFromAnyVersion -ForceApplicationShutdown
-```
-
-(yes, the cmd version is just calling powershell to do the powershell version. Too lazy to convert the rest by hand, I'm already copying from `.vscode\tasks.json`)
-
-Building the package from VS generates the loose layout to begin with, and then registers the loose manifest, skipping the msix stop. It's a lot faster than the commandline inner loop here, unfortunately.
--- a/doc/cascadia/Unittesting-CppWinRT-Xaml.md
+++ b/doc/cascadia/Unittesting-CppWinRT-Xaml.md
@@ -268,7 +268,7 @@ this:
  </ItemDefinitionGroup>
 ```

-Again, verify the correct paths to your dependent C++/WinRT dlls, as they may be
+Again, verify the correct paths to your dependant C++/WinRT dlls, as they may be
 different than the above

 #### Activating the manifest from TAEF
@@ -380,7 +380,7 @@ Here's the AppxManifest we're using:
  </Properties>

  <Dependencies>
-    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.22000.0" />
+    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.19041.0" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.27023.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.27027.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
  </Dependencies>
@@ -517,7 +517,7 @@ This is because of a few key lines we already put in the appxmanifest:

 ```xml
  <Dependencies>
-    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.22000.0" />
+    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.18362.0" MaxVersionTested="10.0.19041.0" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.27023.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.27027.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
  </Dependencies>
--- a/doc/cascadia/profiles.schema.json
+++ b/doc/cascadia/profiles.schema.json
@@ -54,24 +54,6 @@
        }
      ]
    },
-    "BellSound": {
-      "default": "",
-      "description": "Sets the file location of the sound played when the application emits a BEL character. If the path is invalid no sound will be played. This property also accepts an array of sounds and the terminal will pick one at random.",
-      "oneOf": [
-      {
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      {
-        "type": "array",
-        "items": {
-          "type": "string"
-        }
-      }
-      ]
-    }, 
    "AppearanceConfig": {
      "properties": {
        "colorScheme": {
@@ -206,10 +188,6 @@
          ],
          "type": "string"
        },
-        "adjustIndistinguishableColors": {
-          "description": "When set to true, we will (when necessary) adjust the foreground color to make it more visible, based on the background color.",
-          "type": "boolean"
-        },
        "experimental.retroTerminalEffect": {
          "description": "When set to true, enable retro terminal effects when unfocused. This is an experimental feature, and its continued existence is not guaranteed.",
          "type": "boolean"
@@ -299,7 +277,6 @@
    "ShortcutActionName": {
      "enum": [
        "adjustFontSize",
-        "clearBuffer",
        "closeOtherTabs",
        "closePane",
        "closeTab",
@@ -308,7 +285,6 @@
        "commandPalette",
        "copy",
        "duplicateTab",
-        "exportBuffer",
        "find",
        "findMatch",
        "focusPane",
@@ -318,7 +294,6 @@
        "moveFocus",
        "movePane",
        "swapPane",
-        "markMode",
        "moveTab",
        "multipleActions",
        "newTab",
@@ -351,19 +326,13 @@
        "tabSearch",
        "toggleAlwaysOnTop",
        "toggleFocusMode",
-        "selectAll",
-        "setFocusMode",
        "toggleFullscreen",
-        "setFullScreen",
-        "setMaximized",
        "togglePaneZoom",
        "toggleSplitOrientation",
        "toggleReadOnlyMode",
        "toggleShaderEffects",
        "wt",
        "quit",
-        "adjustOpacity",
-        "restoreLastClosed",
        "unbound"
      ],
      "type": "string"
@@ -457,14 +426,6 @@
      ],
      "type": "string"
    },
-    "ClearBufferType": {
-      "enum": [
-        "all",
-        "screen",
-        "scrollback"
-      ],
-      "type": "string"
-    },
    "NewTerminalArgs": {
      "properties": {
        "commandline": {
@@ -500,11 +461,6 @@
        "colorScheme": {
          "description": "The name of a color scheme to use, instead of the one specified by the profile",
          "type": "string"
-        },
-        "elevate": {
-          "type": "boolean",
-          "default": false,
-          "description": "This will override the profile's `elevate` setting."
        }
      },
      "type": "object"
@@ -863,66 +819,6 @@
        "colorScheme"
      ]
    },
-    "SetFocusModeAction": {
-      "description": "Arguments for a setFocusMode action",
-      "allOf": [
-        {
-          "$ref": "#/$defs/ShortcutAction"
-        },
-        {
-          "properties": {
-            "action": {
-              "type": "string",
-              "const": "setFocusMode"
-            },
-            "isFocusMode": {
-              "type": "boolean",
-              "description": "whether focus mode is enabled"
-            }
-          }
-        }
-      ]
-    },
-    "SetFullScreenAction": {
-      "description": "Arguments for a setFullScreen action",
-      "allOf": [
-        {
-          "$ref": "#/$defs/ShortcutAction"
-        },
-        {
-          "properties": {
-            "action": {
-              "type": "string",
-              "const": "setFullScreen"
-            },
-            "isFullScreen": {
-              "type": "boolean",
-              "description": "whether the window should be full screen"
-            }
-          }
-        }
-      ]
-    },
-    "SetMaximizedAction": {
-      "description": "Arguments for a setMaximized action",
-      "allOf": [
-        {
-          "$ref": "#/$defs/ShortcutAction"
-        },
-        {
-          "properties": {
-            "action": {
-              "type": "string",
-              "const": "setMaximized"
-            },
-            "isMaximized": {
-              "type": "boolean",
-              "description": "whether the window should be maximized"
-            }
-          }
-        }
-      ]
-    },
    "WtAction": {
      "description": "Arguments corresponding to a wt Action",
      "allOf": [
@@ -1297,48 +1193,6 @@
        }
      ]
    },
-    "ClearBufferAction": {
-      "description": "Arguments corresponding to a clearBuffer Action",
-      "allOf": [
-        {
-          "$ref": "#/$defs/ShortcutAction"
-        },
-        {
-          "properties": {
-            "action": {
-              "type": "string",
-              "const": "clearBuffer"
-            },
-            "clear": {
-              "$ref": "#/$defs/ClearBufferType",
-              "default": "all",
-              "description": "What to clear. Accepts one of `screen`, `scrollback` or `all` (for both)."
-            }
-          }
-        }
-      ]
-    },
-    "ExportBufferAction": {
-      "description": "Arguments corresponding to a exportBuffer Action",
-      "allOf": [
-        {
-          "$ref": "#/$defs/ShortcutAction"
-        },
-        {
-          "properties": {
-            "action": {
-              "type": "string",
-              "const": "exportBuffer"
-            },
-            "path": {
-              "type": "string",
-              "default": "",
-              "description": "The path to export the text buffer to. If left blank, the Terminal will open a file picker to choose the path."
-            }
-          }
-        }
-      ]
-    },
    "GlobalSummonAction": {
      "description": "This is a special action that works globally in the OS, rather than only in the context of the terminal window. When pressed, this action will summon the terminal window.",
      "allOf": [
@@ -1406,34 +1260,6 @@
        }
      ]
    },
-    "AdjustOpacityAction": {
-      "description": "Changes the opacity of the active Terminal window. If `relative` is specified, then this action will increase/decrease relative to the current opacity.",
-      "allOf": [
-        {
-          "$ref": "#/$defs/ShortcutAction"
-        },
-        {
-          "properties": {
-            "action": {
-              "type": "string",
-              "const": "adjustOpacity"
-            },
-            "opacity": {
-              "type": "integer",
-              "minimum": -100,
-              "maximum": 100,
-              "default": 0,
-              "description": "How opaque the terminal should become or how much the opacity should be changed by, depending on the value of `relative`"
-            },
-            "relative": {
-              "type": "boolean",
-              "default": true,
-              "description": "If true, then adjust the current opacity by the given `opacity` parameter, additively. If false, set the opacity to exactly that value."
-            }
-          }
-        }
-      ]
-    },
    "Keybinding": {
      "additionalProperties": false,
      "properties": {
@@ -1530,21 +1356,12 @@
            {
              "$ref": "#/$defs/FocusPaneAction"
            },
-            {
-              "$ref": "#/$defs/ExportBufferAction"
-            },
-            {
-              "$ref": "#/$defs/ClearBufferAction"
-            },
            {
              "$ref": "#/$defs/GlobalSummonAction"
            },
            {
              "$ref": "#/$defs/QuakeModeAction"
            },
-            {
-              "$ref": "#/$defs/AdjustOpacityAction"
-            },
            {
              "type": "null"
            }
@@ -1653,15 +1470,10 @@
          "$ref": "#/$defs/CopyFormat"
        },
        "trimBlockSelection": {
-          "default": true,
+          "default": false,
          "description": "When set to true, trailing white-spaces will be removed from text in rectangular (block) selection while copied to your clipboard. When set to false, the white-spaces will be preserved.",
          "type": "boolean"
        },
-        "trimPaste": {
-          "default": true,
-          "description": "When enabled, the Terminal will automatically trim trailing whitespace characters when pasting text",
-          "type": "boolean"
-        },
        "experimental.detectURLs": {
          "default": true,
          "description": "When set to true, URLs will be detected by the Terminal. This will cause URLs to underline on hover and be clickable by pressing Ctrl.",
@@ -1709,11 +1521,6 @@
          "description": "Force the terminal to use the legacy input encoding. Certain keys in some applications may stop working when enabling this setting.",
          "type": "boolean"
        },
-        "experimental.useBackgroundImageForWindow": {
-          "default": false,
-          "description": "When set to true, the background image for the currently focused profile is expanded to encompass the entire window, beneath other panes.",
-          "type": "boolean"
-        },
        "initialCols": {
          "default": 120,
          "description": "The number of columns displayed in the window upon first load. If \"launchMode\" is set to \"maximized\" (or \"maximizedFocus\"), this property is ignored.",
@@ -1786,7 +1593,7 @@
        },
        "useAcrylicInTabRow": {
          "default": false,
-          "description": "When set to true, the tab row will have an acrylic material background with 50% opacity.",
+          "description": "When set to true, the tab row will have an acrylic background with 50% opacity.",
          "type": "boolean"
        },
        "actions": {
@@ -2071,15 +1878,6 @@
          ],
          "type": "string"
        },
-        "elevate": {
-          "type": "boolean",
-          "default": false,
-          "description": "When true, this profile should always open in an elevated context. If the window isn't running as an Administrator, then a new elevated window will be created."
-        },
-        "experimental.connection.passthroughMode": {
-          "description": "When set to true, directs the PTY for this connection to use pass-through mode instead of the original Conhost PTY simulation engine. This is an experimental feature, and its continued existence is not guaranteed.",
-          "type": "boolean"
-        },
        "experimental.retroTerminalEffect": {
          "description": "When set to true, enable retro terminal effects. This is an experimental feature, and its continued existence is not guaranteed.",
          "type": "boolean"
@@ -2088,11 +1886,6 @@
          "description": "Use to set a path to a pixel shader to use with the Terminal. Overrides `experimental.retroTerminalEffect`. This is an experimental feature, and its continued existence is not guaranteed.",
          "type": "string"
        },
-        "experimental.useAtlasEngine": {
-          "description": "Enable using the experimental new rendering engine for this profile. This is an experimental feature, and its continued existence is not guaranteed.",
-          "type": "boolean",
-          "default": false
-        },
        "fontFace": {
          "default": "Cascadia Mono",
          "description": "[deprecated] Define 'face' within the 'font' object instead.",
@@ -2186,10 +1979,6 @@
            }
          ]
        },
-        "adjustIndistinguishableColors": {
-          "description": "When set to true, we will (when necessary) adjust the foreground color to make it more visible, based on the background color.",
-          "type": "boolean"
-        },
        "scrollbarState": {
          "default": "visible",
          "description": "Defines the visibility of the scrollbar.",
@@ -2253,7 +2042,7 @@
        },
        "useAcrylic": {
          "default": false,
-          "description": "When set to true, the window will have an acrylic material background. When set to false, the window will have a plain, untextured background.",
+          "description": "When set to true, the window will have an acrylic background. When set to false, the window will have a plain, untextured background.",
          "type": "boolean"
        }
      },
--- a/doc/fuzzing.md
+++ b/doc/fuzzing.md
@@ -1,60 +0,0 @@
-# Fuzzing
-
-## Setting up a fuzzer locally
-
-OpenConsole can be built with a `Fuzzing` configuration. To set up a fuzzer, you'll need an `LLVMFuzzerTestOneInput` function. This serves as a way for the fuzzer to attach itself and inject tests into your fuzz target.
-
-To build the fuzzer locally, build the OpenConsole solution in the `Fuzzing` configuration. This should output an executable that runs the fuzzer on the provided test case. In the case of PR #9604, the desired executable is located at `bin\x64\Fuzzing\OpenConsoleFuzzer.exe`.
-
-### Resources
- [LibFuzzer Docs](https://www.llvm.org/docs/LibFuzzer.html)
- [#9604](https://github.com/microsoft/terminal/pull/9604)
-
-## Setting up OneFuzz
-
-OneFuzz allows us to run our fuzzers in CI and be alerted of new bugs found in this endeavor.
-
-### Installing OneFuzz
-
-You can download the latest OneFuzz CLI on their [releases page](https://github.com/microsoft/onefuzz/releases).
-
-### Configuring OneFuzz
-
-To run OneFuzz locally, you'll need to configure its endpoint, client ID, and client secret. Windows has a preset configuration available; this can be found at [this tutorial](https://www.osgwiki.com/wiki/Fuzzing_Service_-_Azure_Edge_and_Platform#Configure_OneFuzz_CLI) on osgwiki. 
-
-
-
-`onefuzz config --endpoint $(endpoint) --client_id $(client_id) --authority $(authority) --tenant_domain $(tenant_domain)`
-
-**NOTE**: Our pipeline is already set up with these variables, so you don't need to worry about this when running this on Azure DevOps.
-
-### Running a job on OneFuzz
-
-You should now be able to run a job using the following command:
-
-`onefuzz template libfuzzer basic <project> <name> <build> <pool> --target_exe <exe_path>`
-
- `project`: the name of the project
- `name`: the name of the test
- `build`: the identifier for the build (i.e. commit SHA1)
- `pool`: the VM pool to run this on
- `exe_path`: the fuzzer executable output from building your project
-
-This should also output more information (i.e. job ID) about the newly created job in a JSON format.
-
-### Enabling notifications
-
-**NOTE**: Our pipeline is already set up with this functionality. However, here is a quick guide on how to get it set up and modify it to our liking.
-
-OneFuzz supports multiple notification systems at once including MS Teams and Azure DevOps. See the resources below to learn more about setting these up.
-
-Our pipeline has been set up to create Azure DevOps work items.
-
-### Resources
- [OneFuzz GitHub](https://github.com/microsoft/onefuzz)
-    - [Getting started using OneFuzz](https://github.com/microsoft/onefuzz/blob/main/docs/getting-started.md)
-    - [Releases Page](https://github.com/microsoft/onefuzz/releases)
- [Notifications](https://github.com/microsoft/onefuzz/blob/main/docs/notifications.md)
-    - [MS Teams](https://github.com/microsoft/onefuzz/blob/main/docs/notifications/teams.md)
-    - [Azure DevOps](https://github.com/microsoft/onefuzz/blob/main/docs/notifications/ado.md)
- [OSG Wiki - OneFuzz](https://www.osgwiki.com/wiki/Fuzzing_Service_-_Azure_Edge_and_Platform)
--- a/doc/roadmap-2022.md
+++ b/doc/roadmap-2022.md
@@ -1,128 +0,0 @@
-# Terminal 2022 Roadmap
-
-## Overview 
-
-This document outlines the roadmap of features we're planning for the Windows Terminal during 2022. This serves as a successor to the [Terminal v2 Roadmap], to reflect changes to our planning going forward.
-
-Initially we had planned on a discrete "Terminal v2" goal, but over the last 18 months it's become clear to the team that we don't need a strict "2.0" release. We can continue serving the community effectively with continual, incremental updates. Should a future release warrant a substantial change to the Terminal worthy of the "2.0" moniker, we can re-evaluate then.
-
-In 2022, we're going to try tracking our overall work with two "semester" milestones, "[22H1]" and "[22H2]", which roughly align with internal deadlines. Although the Windows Terminal ships updates out-of-band from the rest of the OS, we still have commitments to fixing bugs in the broader console ecosystem. Those changes need to be made in sync with the rest of the OS. Aligning our external milestones with those deadlines should help make sure we get bugs resolved in a timely fashion and checked into the OS.
-
-These have additionally inherited the remainder of the work that was originally targeting the Terminal v2 milestone. As we burn down the features and bugs in these milestones, we'll draw new features into them from the "[Up Next]" milestone, which is itself populated from the highest-priority elements of the [Backlog].
-
-## Milestones
-
-Windows Terminal is engineered and delivered as a set of 6-week milestones. New features will go into [Windows Terminal Preview](https://aka.ms/terminal-preview) first, then a month after they've been in Preview, those features will move into [Windows Terminal](https://aka.ms/terminal). These timelines are rough estimates, not strict rules.
-
-## Terminal Roadmap / Timeline
-
-Below is the schedule for when milestones will be included in release builds of Windows Terminal and Windows Terminal Preview. The dates are rough estimates and are subject to change.
-
-
-| Milestone End Date | Milestone Name | Preview Release Blog Post |
-| ------------------ | -------------- | ------------------------- |
-| 2020-06-18 | [1.1] in Windows Terminal Preview | [Windows Terminal Preview 1.1 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-1-release/) |
-| 2020-07-31 | [1.2] in Windows Terminal Preview<br>[1.1] in Windows Terminal | [Windows Terminal Preview 1.2 Release] |
-| 2020-08-31 | [1.3] in Windows Terminal Preview<br>[1.2] in Windows Terminal | [Windows Terminal Preview 1.3 Release] |
-| 2020-09-30 | [1.4] in Windows Terminal Preview<br>[1.3] in Windows Terminal | [Windows Terminal Preview 1.4 Release] |
-| 2020-11-30 | [1.5] in Windows Terminal Preview<br>[1.4] in Windows Terminal | [Windows Terminal Preview 1.5 Release] |
-| 2021-01-31 | [1.6] in Windows Terminal Preview<br>[1.5] in Windows Terminal | [Windows Terminal Preview 1.6 Release] |
-| 2021-03-01 | [1.7] in Windows Terminal Preview<br>[1.6] in Windows Terminal | [Windows Terminal Preview 1.7 Release] |
-| 2021-04-14 | [1.8] in Windows Terminal Preview<br>[1.7] in Windows Terminal | [Windows Terminal Preview 1.8 Release] |
-| 2021-05-31 | [1.9] in Windows Terminal Preview<br>[1.8] in Windows Terminal | [Windows Terminal Preview 1.9 Release] |
-| 2021-07-14 | [1.10] in Windows Terminal Preview<br>[1.9] in Windows Terminal | [Windows Terminal Preview 1.10 Release] |
-| 2021-08-31 | [1.11] in Windows Terminal Preview<br>[1.10] in Windows Terminal | [Windows Terminal Preview 1.11 Release] |
-| 2021-10-20 | [1.12] in Windows Terminal Preview<br>[1.11] in Windows Terminal | [Windows Terminal Preview 1.12 Release] |
-| 2022-02-03 | [1.13] in Windows Terminal Preview<br>[1.12] in Windows Terminal | [Windows Terminal Preview 1.13 Release] |
-| 2022-05-24 | [1.14] in Windows Terminal Preview<br>[1.13] in Windows Terminal | [Windows Terminal Preview 1.14 Release] |
-|  | [1.15] in Windows Terminal Preview<br>[1.14] in Windows Terminal |  |
-|  | [1.16] in Windows Terminal Preview<br>[1.15] in Windows Terminal |  |
-|  | [1.17] in Windows Terminal Preview<br>[1.16] in Windows Terminal |  |
-
-
-### Release outline
-
-Below is a VERY vague outline of the remaining calendar year that was drafted late May 2022. This was drafted for internal planning purposes, as a guide. It is not meant to represent official dates. More often than not, releases are synced to official features landing, rather than arbitrary dates. Drift from this initial draft is entirely expected.
-
-```mermaid
-gantt
-    title Proposed Terminal Releases 1.14-1.18
-    dateFormat  YYYY-MM-DD
-    axisFormat  %d %b
-    section Terminal 1.14
-        Lock down & bake        :done, 2022-05-06, 2w
-        Release 1.14            :milestone, 2022-05-24
-    section Terminal 1.15
-        Features                :done, a1, 2022-05-06, 4w
-        Bugfix                  :active, a2, after a1  , 1w
-        Lock down & bake        :after a2  , 1w
-        Release 1.15            :milestone, 2022-06-21, 0
-        1.15 becomes Stable     :milestone, after b3, 0
-    section Terminal 1.16
-        Features                :b1, after a2, 4w
-        Bugfix                  :b2, after b1  , 2w
-        Lock down & bake        :b3, after b2  , 2w
-        Release 1.16            :milestone, after b3, 0
-        1.16 becomes Stable     :milestone, after c3, 0
-    section Terminal 1.17
-        Features                :c1, after b2, 4w
-        Bugfix                  :c2, after c1  , 2w
-        Lock down & bake        :c3, after c2  , 2w
-        Release 1.17            :milestone, after c3, 0
-        1.17 becomes Stable     :milestone, after d3, 0
-    section Terminal 1.18
-        Features                :d1, after c2, 4w
-        Bugfix                  :d2, after d1  , 2w
-        Lock down & bake        :d3, after d2  , 2w
-        Release 1.18            :milestone, after d3, 0
-```
-
-## Issue Triage & Prioritization
-
-Incoming issues/asks/etc. are triaged several times a week, labeled appropriately, and assigned to a milestone in priority order:
-
-* P0 (serious crashes, data loss, etc.) issues are scheduled to be dealt with ASAP. These go in the current release milestone (e.g. at time of writing, these would go into 1.13).
-* P1 issues/features/asks are typically assigned to the current or the following release milestone.
-* P2 & P3 issues will typically go in the second semester for the year.
-* Accessibility and Console issues that need to go into the Windows OS typically go into the current semester.
-* Issues/features/asks not related to existing features in the 22H1/22H2 semesters are assigned to the [Backlog] for subsequent triage, prioritization & scheduling.
-
-
-[1.1]: https://github.com/microsoft/terminal/milestone/24
-[1.2]: https://github.com/microsoft/terminal/milestone/25
-[1.3]: https://github.com/microsoft/terminal/milestone/26
-[1.4]: https://github.com/microsoft/terminal/milestone/28
-[1.5]: https://github.com/microsoft/terminal/milestone/30
-[1.6]: https://github.com/microsoft/terminal/milestone/31
-[1.7]: https://github.com/microsoft/terminal/milestone/32
-[1.8]: https://github.com/microsoft/terminal/milestone/33
-[1.9]: https://github.com/microsoft/terminal/milestone/34
-[1.10]: https://github.com/microsoft/terminal/milestone/35
-[1.11]: https://github.com/microsoft/terminal/milestone/36
-[1.12]: https://github.com/microsoft/terminal/milestone/38
-[1.13]: https://github.com/microsoft/terminal/milestone/39
-[1.14]: https://github.com/microsoft/terminal/milestone/41
-[1.15]: https://github.com/microsoft/terminal/milestone/47
-[1.16]: https://github.com/microsoft/terminal/milestone/48
-[1.17]: https://github.com/microsoft/terminal/milestone/49
-
-[22H1]: https://github.com/microsoft/terminal/milestone/43
-[22H2]: https://github.com/microsoft/terminal/milestone/44
-[Up Next]: https://github.com/microsoft/terminal/milestone/37
-[Backlog]: https://github.com/microsoft/terminal/milestone/45
-
-[Terminal v2 Roadmap]: https://github.com/microsoft/terminal/tree/main/doc/terminal-v2-roadmap.md
-
-[Windows Terminal Preview 1.2 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-2-release/
-[Windows Terminal Preview 1.3 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-3-release/
-[Windows Terminal Preview 1.4 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-4-release/
-[Windows Terminal Preview 1.5 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-5-release/
-[Windows Terminal Preview 1.6 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-6-release/
-[Windows Terminal Preview 1.7 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-7-release/
-[Windows Terminal Preview 1.8 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-8-release/
-[Windows Terminal Preview 1.9 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-9-release/
-[Windows Terminal Preview 1.10 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-10-release/
-[Windows Terminal Preview 1.11 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-11-release/
-[Windows Terminal Preview 1.12 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-12-release/
-[Windows Terminal Preview 1.13 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-13-release/
-[Windows Terminal Preview 1.14 Release]: https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-14-release/
--- a/doc/specs/#12570
+++ b/doc/specs/#12570
@@ -1,370 +0,0 @@
---
-author: Michael Niksa @miniksa
-created on: 2022-02-24
-last updated: 2022-02-24
-issue id: 12570
---
-
-# Show Hide operations on GetConsoleWindow via PTY
-
-## Abstract
-
-To maintain compatibility with command-line tools, utilities, and tests that desire to
-manipulate the final presentation window of their output through retrieving the raw
-console window handle and performing `user32` operations against it like [ShowWindow](https://docs.microsoft.com//windows/win32/api/winuser/nf-winuser-showwindow),
-we will create a compatibility layer that captures this intent and translates it into
-the nearest equivalent in the cross-platform virtual terminal language and implement the
-understanding of these sequences in our own Windows Terminal.
-
-## Inspiration
-
-When attempting to enable the Windows Terminal as the default terminal application on Windows
-(to supersede the execution of command-line utilities inside the classic console host window),
-we discovered that there were a bunch of automated tests, tools, and utilities that relied on
-showing and hiding the console window using the `::GetConsoleWindow()` API in conjunction with
-`::ShowWindow()`.
-
-When we initially invented the ConPTY, we worked to ensure that we built to the common
-denominator that would work cross-platform in all scenarios, avoiding situations that were
-dependent on Windows-isms like `user32k` including the full knowledge of how windowing occurs
-specific to the Windows platform.
-
-We also understood that on Windows, the [**CreateProcess**](https://docs.microsoft.com/windows/win32/procthread/process-creation-flags) API provides ample flags specifically
-for command-line applications to command the need for (or lack thereof) a window on startup
-such as `CREATE_NEW_CONSOLE`, `CREATE_NO_WINDOW`, and `DETACHED_PROCESS`. The understanding
-was that people who didn't need or want a window, or otherwise needed to manipulate the
-console session, would use those flags on process creation to dictate the session. Additionally,
-the `::CreateProcess` call will accept information in `STARTUPINFO` or `STARTUPINFOEX` that
-can dictate the placement, size, and visibility of a window... including some fields specific
-to console sessions. We had accepted those as ways applications would specify their intent.
-
-Those assumptions have proven incorrect. Because it was too easy to just `::CreateProcess` in
-the default manner and then get access to the session after-the-fact and manipulate it with
-APIs like `::GetConsoleWindow()`, tooling and tests organically grew to make use of this process.
-Instead of requesting up front that they didn't need a window or the overhead of a console session,
-they would create one anyway by default and then manipulate it afterward to hide it, move it off-
-screen, or otherwise push it around. Overall, this is terrible for their performance and overall
-reliability because they've obscured their intent by not asking for it upfront and impacted their
-performance by having the entire subsystem spin up interactive work when they intend to not use it.
-But Windows is the place for compatibility, so we must react and compensate for the existing
-non-ideal situation.
-
-We will implement a mechanism to compensate for these that attempts to capture the intent of the
-requests from the calling applications against the ConPTY and translates them into the "universal"
-Virtual Terminal language to the best of its ability to make the same effects as prior to the
-change to the new PTY + Terminal platform.
-
-## Solution Design
-
-Overall, there are three processes involved in this situation:
-
-1. The client command-line application utility, tool, or test that will manipulate the window.
-1. The console host (`conhost.exe` or `openconsole.exe`) operating in PTY mode.
-1. The terminal (`windowsterminal.exe` when it's Windows Terminal, but could be a third party).
-
-The following diagram shows the components and how they will interact.
-
-```txt
-   ┌─────────────────┐                   ┌──────────────────┐                   ┌──────────────────────┐
-   │                 │       1           │                  │                   │                      │
-   │   Command-Line  ├─────────────────► │   Console Host   │                   │   Windows Terminal   │
-   │   Tool or       │                   │   as ConPTY      │                   │   Backend            │
-   │   Utility       │       2           │                  │        6          │                      │
-   │                 │ ◄─────────────────┤                  ├─────────────────► │                      │
-   │                 │                   │                  │                   │                      │
-   │                 │                   │                  │                   │                      │
-   │                 │                   │                  │         9         │                      │
-   │                 │                   │                  │ ◄─────────────────┤                      │
-   │                 │                   │                  │                   │                      │
-   └─────┬───────────┘                   └───────────┬──────┘                   └─────────────────┬────┘
-         │                                        ▲  │                                   ▲        │
-         │                                        │  │                                   │        │
-         │                                        │  │10                                 │        │7
-         │3                                      5│  │                                   │8       │
-         │                                        │  ▼                                   │        ▼
-         │                                    ┌───┴────┐                              ┌──┴────┬───────┬─────────────────────────┐
-         ▼                                    │ Hidden │                              │       │       │                      v^x│
-   ┌─────────────────┐                        │ Fake   │                              ├───────┴───────┴─────────────────────────┤
-   │                 │          4             │ PTY    │                              │                                         │
-   │                 ├──────────────────────► │ Window │                              │                                         │
-   │   user32.dll    │                        └────────┘                              │      Windows Terminal                   │
-   │   Window APIs   │                                                                │      Displayed Window                   │
-   │                 │                                                                │                                         │
-   │                 │                                                                │                                         │
-   └─────────────────┘                                                                │                                         │
-                                                                                      │                                         │
-                                                                                      │                                         │
-                                                                                      │                                         │
-                                                                                      │                                         │
-                                                                                      │                                         │
-                                                                                      │                                         │
-                                                                                      │                                         │
-                                                                                      │                                         │
-                                                                                      │                                         │
-                                                                                      └─────────────────────────────────────────┘
-```
-
-1. The command-line tool calls `::GetConsoleWindow()` on the PTY host
-2. The PTY host returns the raw `HWND` to the *Hidden Fake PTY Window* in its control
-3. The command-line tool calls `::ShowWindow()` on the `user32.dll` API surface to manipulate that window.
-4. `user32.dll` sends a message to the window message queue on the *Fake PTY Window*
-5. The PTY host retrieves the message from the queue and translates it to a virtual terminal message
-6. The Windows Terminal connection layer receives the virtual terminal message and decodes it into a window operation.
-7. The true displayed *Windows Terminal Window* is told to change its status to show or hide.
-8. The changed Show/Hide status is returned to the back-end on completion.
-9. The Windows Terminal connection layer returns that information to the PTY host so it can remain in-the-know.
-10. The PTY updates its *Fake PTY Window* status to match the real one so it continues to receive appropriate messages from `user32`.
-
-This can be conceptually understood in a few phases:
-
- The client application grabs a handle and attempts to send a command via a back-channel through user32.
- User32 decides what message to send based on the window state of the handle.
- The message is translated by the PTY and propagated to the true visible window.
- The visible window state is returned back to the hidden/fake window to remain in synchronization so the next call to user32 can make the correct decision.
-
-The communication between the PTY and the hosting terminal application occurs with a virtual terminal sequence.
-Fortunately, *xterm* had already invented and implemented one for this behavior called **XTWINOPS** which means
-we should be able to utilize that one and not worry about inventing our own Microsoft-specific thing. This ensures
-that there is some precedence for what we're doing, guarantees a major third party terminal can support the same
-sequence, and induces a high probability of other terminals already using it given *xterm* is the defacto standard
-for terminal emulation.
-
-Information about **XTWINOPS** can be found at [Xterm control sequences](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html). Search for *XTWINOPS*.
-The sequence is **CSI** *Ps*; *Ps*; *Ps* **t**. It starts with the common "control sequence initiator" of `ESC [` (`0x1B 0x5B`).
-Then between 1 and 3 numerical parameters are given, separated by semicolons (`0x3B`).
-And finally, the sequence is terminated with `t` (`0x74`).
-
-Specifically, the two parameter commands of `1` for *De-iconify window* and `2` for *Iconify window* appear relevant to our interests.
-In `user32` parlance, "iconify" traditionally corresponds to minimize/restore state and is a good proxy for overall visibility of the window.
-
-The theory then is to detect when the assorted calls to `::ShowWindow()` against the *Fake PTY Window* are asking for a command that
-maps to either "iconify" or "deiconify" and translate them into the corresponding message over the VT channel to the attached terminal.
-
-To detect this, we need to use some heuristics inside the [window procedure](https://docs.microsoft.com/windows/win32/winmsg/window-procedures) for the window owned by the PTY.
-Unfortunately, calls to `::ShowWindow()` on research with the team that owns `user32` do not go straight into the window message queue. Instead, they're dispatched straight into `win32k` to be analyzed and then trigger an array of follow on window messages into the queue depending on the `HWND`'s current state. Most specifically, they vary based on the `WS_VISIBLE` state of the `HWND`. (See [Window Styles](https://docs.microsoft.com/windows/win32/winmsg/window-styles) for details on the `WS_VISIBLE` flag.)
-
-I evaluated a handful of messages with the help of the IXP Essentials team to see which ones would telegraph the changes from `::ShowWindow()` into our window procedure:
-
- [WM_QUERYOPEN](https://docs.microsoft.com/windows/win32/winmsg/wm-queryopen) - This one allows us to accept/reject a minimize/restore call. Not really useful for finding out current state
- [WM_SYSCOMMAND](https://docs.microsoft.com/windows/win32/menurc/wm-syscommand) - This one is what is called when the minimize, maximize/restore, and exit buttons are called in the window toolbar. But apparently it is not generated for these requests coming from outside the window itself through the `user32` APIs.
- [WM_SHOWWINDOW](https://docs.microsoft.com/windows/win32/winmsg/wm-showwindow) - This one provides some insight in certain transitions, specifically around force hiding and showing. When the `lParam` is `0`, we're supposed to know that someone explicitly called `::ShowWindow()` to show or hide with the `wParam` being a `BOOL` where `TRUE` is "show" and `FALSE` is "hide". We can translate that into *de-iconify* and *iconify* respectively.
- [WM_WINDOWPOSCHANGING](https://docs.microsoft.com/windows/win32/winmsg/wm-windowposchanging) - This one I evaluated extensively as it looked to provide us insight into how the window was about to change before it did so and offered us the opportunity to veto some of those changes (for instance, if we wanted to remain invisible while propagating a "show" message). I'll detail more about this one in a sub-heading below.
- [WM_SIZE](https://docs.microsoft.com/windows/win32/winmsg/wm-size) - This one has a `wParam` that specifically sends `SIZE_MINIMIZED` (`1`) and `SIZE_RESTORED` (`0`) that should translate into *iconify* and *de-iconify respectively.
-
-#### WM_WINDOWPOSCHANGING data
-
-In investigating `WM_WINDOWPOSCHANGING`, I built a table of some of the states I observed while receiving messages from an external caller that was using `::ShowWindow()`:
-
-|integer|constant|flags|Should Hide?|minimizing|maximizing|showing|hiding|activating|`0x8000`|`SWP_NOCOPYBITS`|`SWP_SHOWWINDOW`|`SWP_FRAMECHANGED`|`SWP_NOACTIVATE`|`SWP_NOZORDER`|`SWP_NOMOVE`|`SWP_NOSIZE`|
-|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-|0|`SW_HIDE`|?|YES|?|?|?|?|?|?|?|?|?|?|?|?|?|
-|1|`SW_NORMAL`|`0x43`|NO|F|F|T|F|T|||X||||X|X|
-|2|`SW_SHOWMINIMIZED`|`0x8160`|YES|T|F|T|F|T|X|X|X|X|||||
-|3|`SW_SHOWMAXIMIZED`|`0x8160`|NO|F|T|T|F|T|X|X|X|X|||||
-|4|`SW_SHOWNOACTIVATE`|`0x8070`|NO|F|F|T|F|F|X||X|X|X||||
-|5|`SW_SHOW`|`0x43`|NO|F|F|T|F|T|||X||||X|X|
-|6|`SW_MINIMIZE`|`0x8170`|YES|T|F|T|F|F|X|X|X|X|X||||
-|7|`SW_SHOWMINNOACTIVE`|`0x57`|YES|T|F|T|F|F|||X||X|X|X|X|
-|8|`SW_SHOWNA`|`0x53`|NO|F|F|T|F|F|||X||X||X|X|
-|9|`SW_RESTORE`|`0x8160`|NO|F|F|T|F|T|||X|X|||||
-|10|`SW_SHOWDEFAULT`|`0x43`|NO|F|F|T|F|T|||X||||X|X|
-|11|`SW_FORCEMINIMIZE`|?|YES|?|?|?|?|?|?|?|?|?|?|?|?|?|
-
-The headings are as follows:
-
- integer - The value of the Show Window constant `SW_*` (see [ShowWindow](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-showwindow))
- constant - The name of the Show Window constant
- flags - The `lParam` field is a pointer to a [**WINDOWPOS**](https://docs.microsoft.com/windows/win32/api/winuser/ns-winuser-windowpos) structure during this message. This the `UINT flags` field of that structure.
- Should Hide? - Whether or not I believe that the window should hide if this constant is seen. (Conversely, should show on the opposite.)
- minimizing - This is the `BOOL` response from a call to [**IsIconic()**](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-isiconic) during this message.
- maximizing - This is the `BOOL` response from a call to [**IsZoomed()**](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-iszoomed) during this message.
- showing - This is whether `SWP_SHOWWINDOW` is set on the `WINDOWPOS.flags` field during this message.
- hiding - This is whether `SWP_HIDEWINDOW` is set on the `WINDOWPOS.flags` field during this message.
- activating - This is the inverse of whether `SWP_NOACTIVATE` is set on the `WINDOWPOS.flags` field during this message.
- Remaining headings are `flags` values expanded to `X` is set and blank is unset. See [**SetWindowPos()**](https://docs.microsoft.com/windows/win32/api/winuser/nf-winuser-setwindowpos) for the definitions of all the flags.
-
-From this data collection, I noticed a few things:
-
- The data in this table was unstable. The fields varied depending on the order in which I called the various constants against `ShowWindow()`. This is just one particular capture.
- Some of the states, I wouldn't see any message data at all (`SW_HIDE` and `SW_FORCEMINIMIZE`).
- There didn't seem to be a definitive way to use this data to reliably decide when to show or hide the window. I didn't have a reliable way of pulling this together with my *Should Hide?* column.
-
-On further investigation, it became apparent that the values received were sometimes not coming through or varying because the `WS_VISIBLE` state of the `HWND` affected how `win32k` decided to dispatch messages and what values they contained. This is where I determined that steps #8-10 in the diagram above were going to be necessary: to report the state of the real window back to the *fake window* so it could report status to `user32` and `win32k` and receive state-appropriate messages.
-
-For reporting back #8-10, I initially was going to use the `XTWINOPS` call with parameter `11`. The PTY could ask the attached terminal for its state and expect to hear back an answer of either `1` or `2` in the same format message depending on the state. However, on further consideration, I realized that the real window could change at a moments notice without prompting from the PTY, so I instead wrote the PTY to always listen for this and had the Windows Terminal send this back down unprompted.
-
-#### Refined WM_SHOWWINDOW and WM_SIZE data
-
-Upon setting up the synchronization for #8-10, I then tried again to build the table using just the two window messages that were giving me reliable data: `WM_SHOWWINDOW` and `WM_SIZE`:
-
-|integer|constant|Should Hide?|`WM_SHOWWINDOW` OR `WM_SIZE` reported hide?|
-|---|---|---|---|
-|0|`SW_HIDE`|YES|YES|
-|1|`SW_NORMAL`|NO|NO|
-|2|`SW_SHOWMINIMIZED`|YES|YES|
-|3|`SW_SHOWMAXIMIZED`|NO|NO|
-|4|`SW_SHOWNOACTIVATE`|NO|NO|
-|5|`SW_SHOW`|NO|NO|
-|6|`SW_MINIMIZE`|YES|YES|
-|7|`SW_SHOWMINNOACTIVE`|YES|YES|
-|8|`SW_SHOWNA`|NO|NO|
-|9|`SW_RESTORE`|NO|NO|
-|10|`SW_SHOWDEFAULT`|NO|NO|
-|11|`SW_FORCEMINIMIZE`|YES|YES|
-
-Since this now matched up perfectly with what I was suspecting should happen *and* it was easier to implement than picking apart the `WM_WINDOWPOSCHANGING` message, it is what I believe the design should be.
-
-Finally, with the *fake window* changing state to and from `WS_VISIBLE`... it was appearing on the screen and showing up in the taskbar and alt-tab. To resolve this, I utilized [**DWMWA_CLOAK**](https://docs.microsoft.com//windows/win32/api/dwmapi/ne-dwmapi-dwmwindowattribute) which makes the window completely invisible even when in a normally `WS_VISIBLE` state. I then added the [**WS_EX_TOOLWINDOW**](https://docs.microsoft.com/windows/win32/winmsg/extended-window-styles) extended window style to hide it from alt-tab and taskbar.
-
-With this setup, the PTY now has a completely invisible window with a synchronized `WS_VISIBLE` state with the real terminal window, a bidirectional signal channel to adjust the state between the terminal and PTY, and the ability to catch `user32` calls being made against the *fake window* that the PTY stands up for the client command-line application.
-
-## UI/UX Design
-
-The visible change in behavior is that a call to `::ShowWindow()` against the `::GetConsoleWindow()`
-handle that is returned by the ConPTY will be propagated to the attached Terminal. As such, a
-user will see the entire window be shown or hidden if one of the underlying attached
-command-line applications requests a show or hide.
-
-At the initial moment, the fact that the Terminal contains tabbed and/or paned sessions and
-therefore multiple command-line clients on "different sessions" are attached to the same window
-is partially ignored. If one attached client calls "show", the entire window will be shown with
-all tabs. If another calls "hide", the entire window will be hidden including the other tab
-that just requested a show. In the opposite direction, when the window is shown, all attached
-PTYs for all tabs/panes will be alerted that they're now shown at once.
-
-## Capabilities
-
-### Accessibility
-
-Users of assistive devices will have the same experience that they did with the legacy Windows
-Console after this change. If a command-line application decides to show or hide the window
-through the API without their consent, they will receive notification of the showing/hiding
-window through our UIA framework.
-
-Prior to this change, the window would have always remained visible and there would be no
-action.
-
-Overall, the experience will be consistent between what is happening on-screen and what is
-presented through the UIA framework to assistive tools.
-
-For third party terminals, it will be up to them to decide what their reaction and experience is.
-
-### Security
-
-We will maintain the security and integrity of the Terminal application chosen for presentation
-by not revealing its true window handle information to the client process through the existing
-`::GetConsoleWindow()` API. Through our design for default terminal applications, the final
-presentation terminal could be Windows Terminal or it could be any third-party terminal that
-meets the same specifications for communication. Giving raw access to its `HWND` to a client
-application could disrupt its security.
-
-By maintaining a level of separation with this feature by generating a "fake window" in the
-ConPTY layer and only forwarding events, the attached terminal (whether ours or a 3rd party)
-maintains the final level of control on whether or not it processes the message. This is
-improved security over the legacy console host where the tool had full backdoor style access
-to all `user32` based window APIs.
-
-### Reliability
-
-This test doesn't improve overall reliability in the system because utilities that are relying
-on the behavior that this compatibility shim will restore are already introducing additional
-layers of complexity and additional processes into their operation than were strictly necessary
-simply by not stating their desires upfront at creation time.
-
-In some capacity, you could argue it increases reliability of the existing tests that were
-using this complex behavior in that they didn't work before and they will work now, but
-the entire process is fragile. We're just restoring the fragile process instead of having
-it not work at all.
-
-### Compatibility
-
-This change restores compatibility with existing applications that were relying on the behavior
-we had excluded from our initial designs.
-
-### Performance, Power, and Efficiency
-
-The performance of tooling that is leveraging this process to create a console and then hide
-or manipulate the session after the fact will be significantly worse when we enable the
-default Windows Terminal than it was with the old Windows Console. This is because the
-Terminal is significantly heavier weight (with its modern technologies like WinUI) and
-will take more time to start and more committed memory. Additionally, more processes
-will be in use because there will be the `conhost.exe` doing the ConPTY translation
-and then the `windowsterminal.exe` doing the presentation.
-
-However, this particular feature doesn't do anything to make that better or worse.
-
-The appropriate solution for any tooling, test, or scenario that has a need for
-performance and efficiency is to use the flags to `::CreateProcess` in the first place
-to specify that they did not need a console window session at all, or to direct its
-placement and visibility as a part of the creation call. We are working with
-Microsoft's test automation tooling (TAEF) as well as the Windows performance
-fundamentals (FUN) team to ensure that the test automation supports creating sessions
-without a console window and that our internal performance test suite uses those
-specifications on creation so we have accurate performance testing of the operating
-system.
-
-## Potential Issues
-
-### Multiple clients sharing the same window host
-
-With the initial design, multiple clients sharing the same window host will effectively
-share the window state. Two different tabs or panes with two different client applications
-could fight over the show/hide state of the window. In the initial revision, this is
-ignored because this feature is being driven by a narrow failure scenario in the test gates.
-In the reported scenario, a singular application is default-launched into a singular tab
-in a terminal window and then the application expects to be able to hide it after the creation.
-
-In the future, we may have to implement a conflict resolution or a graphical variance to
-compensate for multiple tabs.
-
-### Other verbs against the console window handle
-
-This scenario initially focuses on just the `::ShowWindow()` call against the window handle
-from `::GetConsoleWindow()`. Other functions from `user32` against the `HWND` will not
-necessarily be captured and forwarded to the attached terminal application. And even more
-specifically, we're focusing only on the Show and Hide state. Other state modifications that
-are subtle related to z-ordering, activation, maximizing, snapping, and so on are not considered.
-
-## Future considerations
-
-### Multiple clients
-
-If the multiple clients problem becomes more widespread, we may need to change the graphical
-behavior of the Windows Terminal window to only hide certain tabs or panes when a command
-comes in instead of hiding the entire window (unless of course there is only one tab/pane).
-
-We may also need to adjust that once consensus is reached among tabs/panes that it can then
-and only then propagate up to the entire window.
-
-We will decide on this after we receive feedback that it is a necessary scenario. Otherwise,
-we will hold for now.
-
-### Other verbs
-
-If it turns out that we discover tests/scenarios that need maximizing, activation, or other
-properties of the `::ShowWindow()` call to be propagated to maintain compatibility, we will
-be able to carry those through on the same channel and command. Most of them have an existing
-equivalent in `XTWINOPS`. Those that do not, we would want to probably avoid as they will not
-be implemented in any other terminal. We would extend the protocol as an absolute last resort
-and only after receiving feedback from the greater worldwide terminal community.
-
-### Z-ordering
-
-The channel we're establishing here to communicate information about the window and its
-placement may be useful for the z-ordering issues we have in #2988. In those scenarios,
-a console client application is attempting to launch and position a window on top of the
-terminal, wherever it is. Further synchronizing the state of the new fake-window in the
-ConPTY with the real window on the terminal side may enable those tools to function as
-they expect.
-
-This is another circumstance we didn't expect: having command-line applications create windows
-with a need for complex layout and ordering. These sorts of behaviors cannot be translated
-to a universal language and will not be available off the singular machine, so encouraged
-alternative methods like command-line based UI. However, for single-box scenarios, this
-behavior is engrained in some Windows tooling due to its ease of use.
-
-## Resources
-
- [Default Terminal spec](https://github.com/microsoft/terminal/pull/7414)
- [Z-ordering issue](https://github.com/microsoft/terminal/issues/2988)
- See all the embedded links in this document to Windows API resources
--- a/doc/specs/#1790
+++ b/doc/specs/#1790
@@ -60,7 +60,7 @@ Users will be able to add a new setting to their font objects (added in [#10433]
 There is one point to note here about clashing. For example, if a user has the old "weight" setting defined _as well as_ a "wght" axis defined, we will only use the "wght" axis value. We prioritize that value for a few reasons:

 1. It is the more recent addition to our settings model. Thus, it is likely that a user that has defined both values probably just forgot to remove the old value.
-2. It is the more precise value, it is a specific float value whereas the old "weight" setting is an enum (that eventually gets mapped to a float value).
+2. It is the more precise value, it is a specific float value whereas the the old "weight" setting is an enum (that eventually gets mapped to a float value).

 ## Capabilities

@@ -74,7 +74,7 @@ Should not affect security.

 ### Reliability

-Aside from additional parsing required for the settings file (which inherently offers more locations for parsing to fail), we need to be careful about badly formed/non-existent feature tags or axes specified in the user-defined dictionaries. We must make sure to ignore such declarations (perhaps alongside emitting a warning to the user) and only apply those that are correctly formed and exist.
+Aside from additional parsing required for the settings file (which inherently offers more locations for parsing to fail), we need to be careful about badly formed/non-existant feature tags or axes specified in the user-defined dictionaries. We must make sure to ignore such declarations (perhaps alongside emitting a warning to the user) and only apply those that are correctly formed and exist.

 ### Compatibility

--- a/Navigation/#2871
+++ b/Navigation/#2871
@@ -241,7 +241,7 @@ So `focusPane(target=1, direction=up)` will attempt to focus the pane above pane

 > 👉 **NOTE**: At this point, the author considered "Do we even want a separate
 > action to engage the tab switcher with panes expanded?" Perhaps panes being
-> visible in the tab switcher is just part of the tab switcher's behavior. Maybe
+> visible in the tab switcher is just part fo the tab switcher's behavior. Maybe
 > there shouldn't be a separate "open the tab switcher with the panes expanded
 > to the pane I'm currently on, and the panes listed in MRU order" action.

--- a/doc/specs/#4066
+++ b/doc/specs/#4066
@@ -1,79 +0,0 @@
---
-author: Ítalo Masserano arkthur/italo.masserano@gmail.com
-created on: 2022-03-02
-last updated: 2022-03-02
-issue id: 4066
---
-
-# Theme-controlled color scheme switch
-
-## Abstract
-
-The idea is for Windows Terminal to change automatically its color schemes according to what theme is selected, including the case where `system` theme is selected.
-
-## Inspiration
-
-I work remotely as a developer, so I have to spend a lot of hours in front of my PC screen. In my setup, right behind my desk I have a window, which is the only source of natural sunlight in my room.
-
-Normally I like dark modes in all the programs and apps I use, but when there's too much sunlight, it becomes annoying, and sometimes even painful, to work in dark mode. So, I have all the programs and apps I use (at least, those that can) set to switch their color themes to what the system has.
-
-The company I work for sent me a Macbook Pro, and my personal phone is an Android, both with automatic dark mode at sunset and light mode at sunrise, and in those devices it's been working relatively well. In Windows, as it is known, there's no such feature, so I manually change between dark and light mode when it's needed, and most of the programs and apps I use go along with this change. Windows Terminal, is not one of them.
-
-The theme changes just as expected, but in an app like this, this change only affects the top of the window, leaving almost all of the screen at the mercy of what the color scheme is, and it doesn't depend on the theme, which defeats any attempt to make a good use of the `system` theme feature.
-
-## Solution Design
-
-Could be implemented in the form of:
-
-```json
-"colorScheme": {
-    "light": "BlulocoLight",
-    "dark": "BlulocoDark"
-}
-```
-or:
-
-```json
-    "colorSchemeLight": "BlulocoLight",
-    "colorSchemeDark": "BlulocoDark"
-```
-
-## UI/UX Design
-
-In a first version it could look like the terminal in Visual Studio Code, and an improvement could be to have light mode specific color schemes, just like those already present in Windows terminal. A good idea could be to get an inspiration in Dark++ and Light++ VSCode color themes.
-
-A user could benefit from a more healthy light level contrast between the screen their looking at and the environment they are, reducing the risk of headache or developing/intensifying eye problems, and any other related eye conditions. Plus, it adds to a more consistent experience between different programs and apps, and the system itself.
-
-## Capabilities
-
-### Accessibility
-
-This feature improves accessibility more than any other capability, because the key is to be able to read and see anything better when the environment, both the external to the device, and the device's system itself, is in a certain mode (dark/light).
-
-### Security
-
-The proposed solution is based in the current way one sets Windows Terminal settings, so it isn't expected to add any security issues. 
-
-### Reliability
-
-Adding this feature would make Windows Terminal more reliable when it's expected that it changes it's visual theme/color scheme along with the whole system.
-
-### Compatibility
-
-The solution is not expected to break anything.
-
-### Performance, Power, and Efficiency
-
-It might increase the energy spent in the cases where people who were used to use the terminal in regular dark color schemes start using more light color schemes, but that is the case for any other program that shows lighter colors and I don't think the increment would be as high as to be even considered a downside.
-
-## Potential Issues
-
-Some users might not like the change in color schemes or be too used to the terminal being dark, but this may be avoided making the current schemes a default and adding this solution as an alternative setting.
-
-## Future considerations
-
-This solution might bring more attention to the color schemes setting, even more when considering light mode specific color schemes
-
-## Resources
-
-Inspired by what's been said in the issue comments. Credits to them.
--- a/Terminal/spec.md
+++ b/Terminal/spec.md
@@ -1,270 +0,0 @@
---
-author: Michael Niksa @miniksa
-created on: 2020-08-14
-last updated: 2022-01-13
-issue id: #492
---
-
-# Default Terminal Choice in Windows OS
-
-## Abstract
-
-Since the beginning, Windows has offered a single choice in default terminal hosting behavior. Specifically, the default terminal is defined as the one that the operating system will start on your behalf when a command-line application is started without a terminal attached. This specification intends to detail how we will offer customers the ultimate in choice among first and third party replacements for their default terminal experience.
-
-## Inspiration
-
-We've had a lot of success in the past several years on our terminal team journey. We updated the old console host user interface with long-desired features. We updated the console environment to bring Windows closer to Linux and Mac by implementing the client (receiving) end of Virtual Terminal sequences to unlock WSL, Docker, and other cross-platform command-line application compatibility. We then created the ConPTY to expose the server end of the console environment to first and third party applications to enable the hosting of any of those command-line clients within their own user interfaces by implementing the server (sending) end of Virtual Terminal sequences. And then we built Windows Terminal as our flagship implementation of the development environment on this model.
-
-Through all of this, the entrypoint for alternatives to the console host UX continued to be "Start your alternative terminal implementation first, then start the command-line application inside." For those familiar with Linux and Mac or for those using the broad ecosystem of alternative Windows Terminals like ConEmu, Cmder, Console2, and the like... that was natural. But Windows did it differently a long time ago allowing the starting of a command-line application directly from the shell or kernel without a terminal specified. On noticing the missing terminal, the system would just-in-time start and attach the one terminal it could count on as always present, `conhost.exe`.
-
-And so the inspiration of this is simple: We want to allow our customers to choose whichever terminal they want as the just-in-time terminal attached to an application without one present/specified on launch. This final move completes our journey to allow the ultimate in choice AND decouple the terminal experience from the operating system release schedule.
-
-## Solution Design
-
-There are three components to the proposed design:
-
-1. **Inbox console**: This is the `conhost.exe` that is resident inside every Windows installation.
-1. **Updated console**: This is the `openconsole.exe` that we ship with the Windows Terminal to provide a more up-to-date console server experience.
-1. **Terminal UX**: This is `WindowsTerminal.exe`, the new Terminal user interface that runs on VT sequences.
-
-And there are a few scenarios here to consider:
-
-1. Replacement console API server and replacement terminal UX.
-    1. This is the Windows Terminal scenario today. `OpenConsole.exe` is packed in the package to be the console API server and ConPTY environment for `WindowsTerminal.exe`.
-1. Replacement console API server and legacy terminal UX.
-    1. We don't explicitly distribute this today, but it's technically possible to just run `OpenConsole.exe` to accomplish this.
-1. Inbox console API server and replacement terminal UX.
-    1. The WSL environment does this when doing Windows interop and I believe VS Code does this too when told to use the ConPTY environment. (And since VS Code does it, anything using node-pty also does it, covering some 3rd party terminals as well).
-1. Inbox console API server and inbox terminal UX.
-    1. This is what we have today in `conhost.exe` running as the default application.
-
-The goal is to offer the ultimate in choice here where any of the components can be replaced as necessary for a 1st or 3rd party scenario.
-
-### Overview
-
-#### Inbox console
-
-The inbox console will be updated to support delegation of the incoming console client application connection to another console API server if one is registered and available.
-
-We leave the inbox console in-place and always available on the operating system for these reasons:
-
-1. A last chance fall-back should any of the delegation operations fail
-1. An ongoing host for applications that aren't going to need a window at all
-1. Continued support of our legacy `conhostv1.dll` environment, if chosen
-
-The general operation is as follows:
-
- A command-line client application is started (from the start menu, run box, or any other `CreateProcess` or `ShellExecute` route) without an existing console server attached
- The inbox console is launched from `C:\windows\system32\conhost.exe` as always by the initialization routines inside `kernelbase.dll`.
- The inbox console accepts the incoming initial connection and looks for the `ShowWindow` information on the connection packet, as received from the kernel's process creation routines based on the parameters given to the `CreateProcess` call. (See [CREATE_NO_WINDOW](https://docs.microsoft.com/en-us/windows/win32/procthread/process-creation-flags) flag for details.)
- If the session is about to create a window, check for registration of a delegated/updated console and hand-off to it if it exists.
- Otherwise, start normally.
-
-This workflow affords us several benefits:
-
- The only inbox component we have to change is `conhost.exe`, the one we already regularly update from open source on a regular basis. There is no change to the `kernelbase.dll` console initialization routines, `conclnt.lib` communication protocol, nor the `condrv.sys` driver.
- We should be able to make this change quickly, relatively easily, and the code delta should be relatively small
-    - This makes it easy to squeeze in early in the development of the solution and get it into the Windows OS product as soon as possible for self-hosting, validation, and potentially shipping in the OS before the remainder of the solution has shaken out
-    - This also makes it potentially possible to backport this portion of the code change to popular in-market versions of Windows 10. For instance, WSL2 has just backported to 1903 and 1909. The less churn and risk, the easier it is to sell a backport.
-
-*Potential future:*
- ~~If no updated console exists, potentially check for registration of a terminal UX that is willing to use the inbox ConPTY bits, start it, and transition to being a PTY instead.~~ 
- **CUT FROM v1**: To simplify the story for end-users, we're offering this as a package deal in the first revision. Explaining the difference between consoles and terminals to end users is very difficult.
-
-The registration would operate as follows:
- A registry key in `HKCU\Console\%%Startup` (format `REG_SZ`, name `DelegationConsole`) would specify ~~the path to ~~the replacement console that would be used to service the remainder of the connection process.
-    - Alternatively or additionally, this same `REG_SZ` could list a COM server ID that could be looked up in the classes root and invoked. **V1 NOTE:** This was what was done.
-        - Packaged applications and classic applications can easily register a COM server
-        - WinRT libraries should be able to be easily registered as the COM server as well (given WinRT is COM underneath)
-            - WinRT cannot be exposed outside of the package context itself, so the `conhost.exe` that is in the OS and is naturally outside the package cannot find it.
-    - **V1 NOTE:** The subkey `%%Startup` was chosen to separate these keys (this one and the `DelegationTerminal` one below) in case we needed to ACL them or protect them in some way. We want a per-user choice of which Terminal/Console are used, but we might need to take action to prevent these keys from being slammed at some point in the future. Why `%%`? The subkeys are traditionally used to resolve paths to client binaries that have their own console preferences set. The `%%` should never be resolvable as it won't lead to a valid path or expanded path variable.
-
-The delegation process would operate as follows:
- A method contract is established between the existing inbox console and any updated console (an interface). 
-    - `HRESULT ConsoleEstablishHandoff(HANDLE server, HANDLE driverInputEvent, const PortableConnectMessage* const msg, HANDLE signalPipe, HANDLE inboxProcess, HANDLE* process)`
-        - `HANDLE server`: This is the server side handle to the console driver, used with `DeviceIoControl` to receive/send messages with the client command-line application
-        - `HANDLE driverInputEvent`: The input event is created and assigned to the driver immediately on first connection, before any messages are read from the driver, to ensure that it can track a blocking state should first message be an input request that we do not yet have data to fill. As such, the inbox console will have created this and assigned it to the driver before pulling off the connection packet and determining that it wants to delegate. Therefore, we will transfer ownership of this event to the updated console.
-        - ~~`const PortableArguments* const args`: This contains the startup argument information that was passed in when the process was started including the original command line and the in/out handles.~~
-            - ~~The `ConsoleArguments` structure could technically change between versions, so we will make a version agnostic portable structure that just carries the communication from the old one to the new one.~~
-            - **CUT FROM V1**: The only arguments coming in from a default light-up are the server handle. Pretty much all the other arguments are related to the operation of the PTY. Since this feature is about "default application" launches where no arguments are specified, this was cut from the initial revision.
-        - `const PortableConnectMessage* const msg`:
-            - The `CONSOLE_API_MSG` structure contains both the actual packet data from the driver as well as some overhead/administration data related to the packet state, ordering, completion, errors, and buffers. It's a broad scope structure for every type of message we process and it can change over time as we improve the way the `conserver.lib` handles packets.
-            - This represents a version agnostic variant for ONLY the connect message that can pass along the initial connect information structure, the packet sequencing information, and other relevant payload only to that one message type. It will purposefully discard references to things like a specific set of API servicing routines because the point of handing off is to get updated routines, if necessary.
-            - **V1 NOTE:** This was named `CONSOLE_PORTABLE_ATTACH_MSG`
-        - `HANDLE signalPipe`: During authoring, it was identified that <kbd>Ctrl+C</kbd> and other similar signals need to make it back to the original `conhost.exe` application as the Operating System grants it special privilege over the originally attached client application. This privilege cannot be transferred to the delegated console. So this channel remains for the delegated one to send its signals back through the original one for commanding the underlying client. (This also implies the original `conhost.exe` inbox cannot close and must remain a part of the process tree for the life of the session to maintain this control.)
-        - `HANDLE inboxProcess`: Since we have to keep the inbox `conhost.exe` running for signal/ownership reasons, we also need to track its lifetime. If it disappears for whatever reason, we need to tear down the entire chain as part of our operation has been compromised.
-        - `HANDLE* process`: On the contrary to `inboxProcess`, we need to give our process handle back so it can also be tracked. After the inbox console delegates, it remains in a very limited capacity. If the delegation one disappears, the session will no longer function and needs to be torn down (and the client closed).
-        - *Return* `HRESULT`: This is one of the older style methods in the initialization. We moved them from mostly `NTSTATUS` to mostly `HRESULT` a while ago to take advantage of `wil`. This one will continue to follow the pattern and not move to exceptions. A return of `S_OK` will symbolize that the handoff worked and the inbox console can clean itself up and stop handling the session.
- When the connection packet is parsed for visibility information (see `srvinit.cpp`), we will attempt to resolve the registered handoff and call it.
-    - ~~In the initial revision here, I have this as a `LoadLibrary`/`GetProcAddress` to the above exported contract method from the updated console. This maintains the server session in the same process space and avoids:~~
-        1. ~~The issue of passing the server, event, and other handles into another process space. We're not entirely sure if the console driver will happily accept these things moving to a different process. It probably should, but unconfirmed.~~
-        1. ~~Some command-line client applications rely on spelunking the process tree to figure out who is their servicing application. Maintaining the delegated/updated console inside the same process space maintains some level of continuity for these sorts of applications.~~
-    - **Alternative:** We may make this just be a COM server/client contract. ~~An in-proc COM server should operate in much the same fashion here (loading the DLL into the process and running particular method) while being significantly more formal and customizable (version revisions, moving to out-of-proc, not really needing to know the binary path because the catalog knows).~~
-        - **V1 NOTE:** We landed on an out-of-proc COM server/client here. This maintains the isolation of the newly running code from the old code. Since we're maintaining the original `conhost.exe` for signaling purposes, we're no longer worried about the spelunking the process tree and not having the relationship for clients to find.
-    - **Not considering:** ~~WinRT. `conhost.exe` has no WinRT. Adding WinRT to it would significantly increase the complexity of compilation in the inbox and out of box code base. It would also significantly increase the compilation time, binary size, library link list, etc... unless we use just the ABI to access it. But I don't see an advantage to that over just using classic COM at that point. This is only one handoff method and a rather simplistic one at that. Every benefit WinRT provides is outweighed by the extra effort that would be required over just a classic COM server in this case.~~
- After delegation is complete, the inbox console will have to clean up any threads, handles, and state related to the session. We do a fairly good job with this normally, but some portions of the `conhost.exe` codebase are reliant on the process exiting for final cleanup. There may be a bit of extra effort to do some explicit cleanup here.
-    - **V1 NOTE:** The inbox one cleans up everything it can and sits in a state waiting for the child/delegated process handle to exit. It also maintains a thread listening for the signals to come through in case it needs to send a command to the client application using the privilege granted to it by the driver.
-
-#### Updated console
-
-The updated replacement console will have the same console API server capabilities as the inbox console, but will be a later, updated, or customized-to-the-scenario version of the API server generally revolving around improving ConPTY support for a Terminal application.
-
-On receiving the handoff from the method signature listed above, the updated console will:
- Establish its own set of IO threading, device communication infrastructure, and API messaging routines while storing the handles given
- ~~Re-parse the command line arguments, if necessary, and store them for guiding the remainder of launch~~
- Dispatch the attach message as if it were received normally
- Continue execution from there
-
-There will then either be a registration for a Terminal UX to take over the session by using ConPTY, ~~or the updated console will choose to launch its potentially updated version of the `conhost` UX~~.
-
-For registration, we repeat the dance above with another key:
- A registry key in `HKCU\Console\%%Startup` (format `REG_SZ`, name `DelegationTerminal`).
-
-The delegation repeats the same dance as above as well:
- A contract (interface) is established between the updated console and the terminal
-    - `HRESULT EstablishPtyHandoff(HANDLE in, HANDLE out, HANDLE signal, HANDLE ref, HANDLE server, HANDLE client)`
-        - `HANDLE in`: The handle to read client application output from the ConPTY and display on the Terminal
-        - `HANDLE out`: The handle to write user input from the Terminal to the ConPTY
-        - `HANDLE signal`: The signal handle for the ConPTY for out-of-band communication between PTY server and Terminal application
-        - ~~`COORD size`: The initial window size from the starting application, as it can be a preference in the connection structure. (A resize message may get sent back downward almost immediately from the Terminal as its dimensions could be different.)~~ **V1 NOTE:** This proved unnecessary as the resize operations sorted themselves out naturally.
-        - `HANDLE ref`: This is a "client reference handle" to the console driver and session. We hold onto a copy of this in the Terminal so the session will stay alive until we let go. (The other console hosts in the chain also hold one of these, as should the client.)
-        - `HANDLE server`: This is a process handle to the PTY we're attached to. We monitor this to know when the PTY is still alive from the Terminal side.
-        - `HANDLE client`: This is a process handle to the underlying client application. The terminal tracks this for exit handling.
-    - **Alternative:** This should likely just be a COM server/client contract as well. This would be consistent with the above and wouldn't require argument parsing or wink/nudge understanding of standard handle passing. It also conveys the same COM flexibility as described in the inbox console section. **V1 NOTE:** We used this alternative. We used COM, not a well-known exported function from the prototype.
- The contract is called and on success, responsibility of the UX is given over to the Terminal. The console sits in PTY mode.
-    - On failure, the console launches interactive.
-
-#### Terminal UX
-
-The terminal will be its own complete presentation and input solution on top of a ConPTY connection, separating the concerns between API servicing and the user experience.
-
-Today the Terminal knows how to start and then launches a ConPTY under it. The Terminal will need to be updated to accept a pre-existing ConPTY connection on launch (or when the multi-process model arrives, as an inbound connection), and connect that to a new tab/pane instead of using the `winconpty.lib` libraries to make its own.
-
-For now, I'm considering only the fresh-start scenario.
- The Terminal will have to detect the inbound connection through ~~its argument parsing (or through~~ a new entrypoint in the COM alternative ~~)~~ and store the PTY in/out/signal handles for that connection in the startup arguments information
- When the control is instantiated on a new tab, that initial creation where normally the "default profile" is launched will instead have to place the PTY in/out/signal handles already received into the `ConPtyConnection` object and use that as if it was already created.
- The Terminal can then let things run normally and the connection will come through and be hosted inside the session.
-
-There are several issues/concerns:
- Which profile/settings get loaded? We don't really know anything about the client that is coming in already-established. That makes it difficult to know what user preferences to apply to the inbound tab. We could:
-    - Use only the defaults for the incoming connection. Do not apply any profile-specific settings.
-    - Use the profile information from the default profile to some degree. This could cause some weird scenarios/mismatches if that profile has a particular icon or a color scheme that makes it recognizable to the user.
-    - Create some sort of "inbound profile" profile that is used for incoming connections
-    - Add a heuristic that attempts to match the name/path of the connecting client binary to a profile that exists and use those settings, falling back if one is not found.
-    - **Proposal:** Do the first one immediately for bootstrapping, then investigate the others as a revision going forward.
- The handles that are coming in are "raw" and "unpacked", not in the nice opaque `HPCON` structure that is usually provided to the `ConPtyConnection` object by the `winconpty.lib`.
-    - Add methods to `winconpty.lib` that allow for the packing of incoming raw handles into the `HPCON` structure so the rest of the lifetime can be treated the same
-    - Put the entrypoint for the COM server (or delegate the entrypoint for an argument) directly into this library so it can pack them up right away and hand of a ready-made `HPCON`.
-
-## UI/UX Design
-
-The user experience for this feature overall should be:
-
-1. The user launches a command-line client application through the Start Menu, Win+X menu, the Windows Explorer, the Run Dialog box (WinKey+R), or through another existing Windows application.
-1. Using the established settings, the console system transparently starts, delegates itself to the updated console, switches itself into ConPTY mode, and a copy of Windows Terminal launches with the first tab open to host the command-line client application.
-    - **NOTE:** I'm not precluding 3rd party registrations of either the delegation updated console nor the delegation terminal. It is our intention to allow either or both of these pieces to be replaced to the user's desires. The example is for brevity of our golden path and motivation for this scenario.
-1. The user is able to interact with the command-line client application as they would with the original console host.
-    - The user receives the additional benefit that short-running executions of a command-line application may not "blink in and disappear" as they do today when a user runs something like `ipconfig` from the run dialog. The Terminal's default states tend to leave the tab open and say that the client has exited. This would allow a Run Dialog `ipconfig` user an improved experience over the default console host state of disappearing quickly.
-1. If any portion of the delegation fails, we will progressively degrade back to a `conhost` style Win32+GDI UX and nothing will be different from before.
-
-The settings experience includes:
- Configuration of the delegation operations:
-    - Locations:
-        - With the registry
-            - This is what's going to be available first and will remain available. We will progress to some or all of the below after.
-            - We will need to potentially add specifications to this to both the default profile (for new installations of Windows) or to upgrade/migration profiles (for users coming from previous editions of Windows) to enable the delegation process, especially if we put a copy of Windows Terminal directly into the box.
-            - **V1 NOTE:** we didn't add additional migration logic here as `HKCU\Console*` and subkeys were already in the migration logic, so adding another should just carry along.
-        - Inside Windows Terminal
-            - Inside the new Settings UI, we will likely need a page that configures the delegation keys in `HKCU\Console\%%Startup` ~~or a link out to the Windows Settings panel, should we manage to get the settings configurable there~~.
-        - Inside the console property sheet
-            - Same as for Terminal but with `comctl` controls over XAML +/- a link to the Windows Settings panel
-        - Inside the Settings panel for Windows (probably on the developer settings page)
-            - The ultimate location for this is likely a panel directly inside Windows. This is the hardest one to accomplish because of the timelines of the Windows product. We may not get this in an initial revision, but it should likely be our ultimate goal. **V1 NOTE:** We did it!
-    - Operation:
-        - Specify paths/server IDs - This is the initial revision
-        - Offer a list of registered servers or discovered manifests from the app catalog - This is the ideal scenario where we search the installed app catalog +/- the COM catalog and offer a list of apps that conform to the contract in a drop-down.
-            - The final process was to use [App Extensions](https://docs.microsoft.com/windows/uwp/launch-resume/how-to-create-an-extension) inside the Terminal APPX package to declare the COM GUIDs that were available for the `DelegationConsole` and `DelegationTerminal` fields respectively. A configuration class `DelegationConfig` was added to `propslib.lib` that enables the lookup of these from the application state catalog and presents a list of them to choose from. It also manages reading and writing the registry keys.
-            - **V1 NOTE:** Our configuration options currently allow pairings of replacement consoles and terminals to be adjusted in lock-step from the UI. That's not to say further combinations are not possible or even necessarily inhibited by the code. We just went for minimal confusion in our first round.
-    
- Configuration of the legacy console state:
-    - ~~Since we could end up in an experience where the default launch experience gets you directly into Windows Terminal, we believe that the Terminal will likely need an additional setting or settings in the new Settings UI that will allow the toggling of some of the `HKCU\Console` values to do things like set/remove the legacy console state.~~ **V1 NOTE:** Cut as low priority. Switch back to console and configure it that way or use the existing property sheet or tamper with registry keys.
-    - We have left the per-launch debugging and advanced access hole of calling something like `conhost.exe cmd.exe` which will use the inbox conhost to launch `cmd.exe` even if there is a default specified.
-
-Concerns:
- State separation policy for Windows. I believe `HKCU\Console` is already specified as a part of the "user state" that should be mutable and carried forward on OS Swap, especially as we have been improving the OS swap experience.
- Ability for installers/elevated scripts to stomp the Delegation keys
-    - This was a long time problem for default app registrations and was limited in our OS. Are we about to run down the same path?
-    - What is the alternative here? To use a protocol handler? To store this configuration state data with other protected state in a registry area that is mutable, but only ACL'd to the `SYSTEM` user like some other things in the Settings control panel?
-        - **V1 NOTE:** We set ourselves up for some future ACL thing with the subkey, but we otherwise haven't enforced anything at this time.
-
-## Capabilities
-
-### Accessibility
-
-Accessibility applications are the most likely to resort to a method of spelunking the process tree or window handles to attempt to find content to read out. Presuming they have hardcoded rules for console-type applications, these algorithms could be surprised by the substitution of another terminal environment.
-
-The major players here that I am considering are NVDA, JAWS, and Narrator. As far as I am aware, all of these applications attempt to drive their interactivity through UI Automation where possible. And we have worked with all of these applications in the past in improving their support for both `conhost.exe` and the Windows Terminal product. I have relatively high confidence that we will be able to work with them again to help update these assistive products to understand the new UI delegation, if necessary.
-
-### Security
-
-Let's hit the elephant in the room. "You plan on pulling a completely different binary inside the `conhost.exe` process and just... delegating all activity to it?" Yes.
-
-(**V1 NOTE:** Well, it's out of proc now. But it is at the same privilege level as the original one thanks to the mechanics of COM.) 
-
-As far as I'm concerned, the `conhost.exe` that is started to host the command-line client application is running at the same integrity level as the client binary that is partially started and waiting for its server to be ready. This is the long-standing existing protection that we have from the Windows operating system. Anything running in the same integrity level is already expected to be able to tamper with anything else at the same integrity level. The delegated binary that we would be loading into our process space will also be at the same integrity level. Nothing really stops a malicious actor from launching that binary in any other way in the same integrity level as a part of the command-line client application's startup. 
-
-The mitigation here, if necessary, would be to use `WinVerifyTrust` to validate the certification path of the `OpenConsole.exe` binary to ensure that only one that is signed by Microsoft can be the substitute server host for the application. This doesn't stop third parties from redistributing our `OpenConsole.exe` off of GitHub if necessary with their products, but it would stop someone from introducing any random binary that met the signature interface of the delegation methods into `conhost.exe`. The only value I see this providing is stopping someone from being "tricked" into delegating their `conhost.exe` to another binary through the configuration methods we provide. It doesn't really stop someone (or an attacker) from taking ownership of the `conhost.exe` in System32 and replacing it directly. So this point might be moot. (It is expected that replacement of the System32 one is already protected, to some degree, by being owned by the SYSTEM account and requiring some measure of authority to replace.)
-
-### Reliability
-
-The change on its own may honestly improve reliability of the hosting system. The existing just-in-time startup of the console host application only had a single chance at initializing a user experience before it would give up and return that the command-line application could not be started.
-
-However, there are now several phases in the startup process that will have the opportunity to make multiple attempts at multiple versions or applications to find a suitable host for the starting application before giving up.
-
-One layer of this is where the `conhost.exe` baked into the operating system will be on the lookout for an `OpenConsole.exe` that will replace its server activities. The delegation binary loses a bit of reliability, theoretically, by the fact that loading another process during launch could have versioning/resolution/path/dependency issues, but it simultaneously offers us the opportunity for improved reliability by being able to service that binary quickly outside the Windows OS release cycle. Fixes can arrive in days instead of months to years.
-
-Another layer of this is where either `conhost.exe` or the delegated `OpenConsole.exe` server will search for a terminal user experience host, like `WindowsTerminal.exe` or another registered first or third party host, and split the responsibility of hosting the session with that binary. Again, there's a theoretical reliability loss with the additional process launch/load, but there's much to be gained by reducing the scope of what each binary must accomplish. Removing the need to handle user interaction from `conhost.exe` or `OpenConsole.exe` and delegating those activities means there is less surface area running and less chance for a UX interaction to interfere with API call servicing and vice versa. And again, having the delegation to external components means that they can be fixed on a timeline of days instead of months or years as when baked into the operating system.
-
-### Compatibility
-
-One particular scenario that this could break is an application that makes use of spelunking the process tree when a command-line application starts to identify the hosting terminal application window by HWND to inject input, extract output, or otherwise hook and bind to hosting services. As the default application UI that will launch may not have the `conhost.exe` name (for spelunking via searching processes) and the HWND located may either be the ConPTY fake HWND or an HWND belonging to a completely different UI, these applications might not work.
-
-Two considerations here:
-
-1. At a minimum, we must offer an opt-out of the delegation to another terminal for the default application.
-1. We may also want to offer a process-name, policy, manifest, or other per client application opt-out mechanism.
-
-**V1 NOTE:** There is no per-client specific way of doing this. The toggle is per-user and can be adjusted in 3 different places.
-
-### Performance, Power, and Efficiency
-
-I expect to take some degree of performance, power, and efficiency hit by implementing this replacement default app scenario just by it's nature. We will be loading multiple processes, performing tests and branches during startup, and we will likely need to load COM/WinRT and packaging data that was not loaded prior to resolve the final state of default application load. I would expect this to accrue to some failures in the performance and power gates inside the Windows product. Additionally, the efficiency of running pretty much everything through the ConPTY is lower than just rendering it directly to `conhost.exe`'s embedded GDI-powered UI itself thanks to the multiple levels of translation and parsing that occur in this scenario.
-
-The mitigations to these losses are as follows:
-
-1. We will delay load any of the interface load and packaging data lookup libraries to only be pulled into process space should we determine that the application is non-interactive. 
-    1. That should save us some of the commit and power costs for the sorts of non-interactive scripts and applications that typically run early in OS startup (and leverage `conhost.exe` as their host environment). 
-    1. We will still likely get hit with the on-disk commit cost for the additional export libraries linked as well as additional code. That would be a by-design change.
-
-1. We plan to begin Profile Guided Optimization across our `OpenConsole.exe` and `WindowsTerminal.exe` binaries. This should allow us to optimize the startup paths for this scenario and bias the `OpenConsole.exe` binary that we redistribute to focus its efforts and efficiency on the ConPTY role specifically, ignoring all of the interactive Win32/GDI portions that aren't typically used.
-    1. We may need to add a PGO scenario inside Windows to tune the optimization of `conhost.exe` especially if we're going to go full on Windows Terminal in the box default application. The existing PGO that occurs in the optimization branches is running on several `conhost.exe` interactive scenarios, none of which will be relevant here. We would probably want to update it to focus on the default app delegation routine AND on the non-interactive scenario for hosted applications (where delegation will not occur but Win32/GDI will still not be involved).
-
-## Potential Issues
-
-### Passing Handles with COM
-COM doesn't inherently expose a way for us to pass handles directly between processes with the existing contracts. We know this is possible because Windows does it all the time, but it doesn't appear to be public. We believe the mission forward is to expose this functionality to the public as if it's good enough for us internally and it is a requirement to build complex functionality like this... then it should be good enough for the public.
-
-**V1 NOTE:** We gained approval to open this up and documented it. [`system_handle` attribute](https://docs.microsoft.com/windows/win32/midl/system-handle). It didn't require any code changes because the public IDL compiler already recognized the existence of this attribute and did the correct thing. It just wasn't documented for use.
-
-## Future considerations
-
-* We additionally would like to leave the door open to distributing updated `OpenConsole.exe`s in their own app package as a dependency that others could rely on.
-    * This was one of the original management requests when we were opening the source of the console product as well as the Terminal back in spring of 2019. For the sake of ongoing servicing and maintainability, it was requested that we reach a point where our dependencies could be serviced potentially independently of the product as a whole static unit. We didn't achieve that goal initially, but this design would enable us to do something like this.
-    * One negative to this scenario is that dependency resolution and the installation of dependent packages through APPX is currently lacking in several ways. It's difficult/impossible to do in environments where the store or the internet is unavailable. And it's a problem often enough that the Windows Terminal package embeds the VC runtimes inside itself instead of relying on the dependency resolution of the app platform.
-
-## Resources
-
- [Windows Terminal Process Model 2.0 spec](https://github.com/microsoft/terminal/pull/7240)
- [Windows Terminal 2.0 Process Model Improvements](https://github.com/microsoft/terminal/issues/5000)
- [Console allocation policy specifications](https://github.com/microsoft/terminal/pull/7337)
- [Fine-grained console allocation policy feature](https://github.com/microsoft/terminal/issues/7335)
--- a/Improvements.md
+++ b/Improvements.md
@@ -75,7 +75,7 @@ Some things we considered during this investigation:
  - We could theoretically build an RPC tunnel between content and window
    processes, and use the RPC connection to marshal the content process to the
    elevated window. However, then _we_ would need to be responsible for
-    securing access the RPC endpoint, and we feel even less confident doing
+    securing access the the RPC endpoint, and we feel even less confident doing
    that.
  - Attempts were also made to use a window-broker-content architecture, with
    the broker process having a static CLSID in the registry, and having the
@@ -456,7 +456,7 @@ accessible.

 Unfortunately, these issues are OS bugs that are largely out of our own control.
 We will continue to apply pressure to the centennial app team internally as we
-encounter these issues. They are the team best equipped to resolve these issues.
+encounter these issues. They are are team best equipped to resolve these issues.

 ### Default Terminal & auto-elevation

@@ -552,7 +552,7 @@ following behaviors:
 * `false`: If the current window is elevated, try to create a new unelevated
  window to host this connection.

-We could always re-introduce this setting, to supersede `elevate`.
+We could always re-introduce this setting, to supercede `elevate`.

 ### Change profile appearance for elevated windows

--- a/doc/specs/#5000
+++ b/doc/specs/#5000
@@ -317,7 +317,7 @@ Some things we considered during this investigation:
  - We could theoretically build an RPC tunnel between content and window
    processes, and use the RPC connection to marshal the content process to the
    elevated window. However, then _we_ would need to be responsible for
-    securing access the RPC endpoint, and we feel even less confident doing
+    securing access the the RPC endpoint, and we feel even less confident doing
    that.
  - Attempts were also made to use a window-broker-content architecture, with
    the broker process having a static CLSID in the registry, and having the
@@ -1123,7 +1123,7 @@ elevated windows, when they trust the extension. We could have an additional set
 of settings the user could use to enable certain extensions in elevated windows.
 However, this setting cannot live in the normal `settings.json` or even
 `state.json` (see [#7972], since those files are writable by any medium-IL
-process. Instead, this setting would need to live in a separate file that's
+process. Instead, this setting would ned to live in a separate file that's
 protected to only be writable by elevated processes. This would ensure that an
 attacker could not just add their extension to the list of white-listed
 extensions. When the settings UI wants to modify that setting, it'll need to
--- a/doc/specs/#607
+++ b/doc/specs/#607
@@ -35,7 +35,7 @@ through commandline arguments.

 ## User Stories

-Lets consider some different ways that a user or developer might want to
+Lets consider some different ways that a user or developer might want want to
 use commandline arguments, to help guide the design.

 1. A user wants to open the Windows Terminal with their default profile.
--- a/doc/specs/#653
+++ b/doc/specs/#653
@@ -714,7 +714,7 @@ Docs regarding hiding a window from the taskbar:
 ### Footnotes

 <a name="footnote-1"><a>[1]: Quitting the terminal is different than closing the
-windows one-by-one. Quitting implies an atomic action, for closing all the
+windows one-by-one. Quiting implies an atomic action, for closing all the
 windows. Once [#766] lands, this will give us a chance to persist the state of
 _all_ open windows. This will allow us to re-open with all the user's windows,
 not just the one that happened to be closed last.
--- a/doc/specs/#6899
+++ b/doc/specs/#6899
@@ -26,7 +26,7 @@ This spec was largely inspired by the following diagram from @DHowett:
 ![figure 1](data-mockup.png)

 The goal is to introduce an `id` parameter by which actions could be uniquely
-referred to. If we'd ever like to use an action outside the list of `actions`, we
+refered to. If we'd ever like to use an action outside the list of `actions`, we
 can simply refer to the action's ID, allowing the user to only define the action
 _once_.

--- a/doc/specs/#885
+++ b/doc/specs/#885
@@ -230,7 +230,7 @@ def cloneGraph(oldSource, newSource, visited):
        for old in oldSource.adj:

            # Below check is for backtracking, so new
-            # nodes don't get initialized every time
+            # nodes don't get initialized everytime
            if clone is None or(clone is not None and clone.key != old.key):
                clone = Node(old.key, [])
            newSource.adj.append(clone)
@@ -268,7 +268,7 @@ Today, if the deserialization of `CascadiaSettings` encounters any errors, an ex
 To get around this issue, when `CascadiaSettings` encounters a serialization error, it must internally record
 any pertinent information for that error, and return the simple `CascadiaSettings` as if nothing happened.
 The consumer must then call `CascadiaSettings::GetErrors()` and `CascadiaSettings::GetWarnings()` to properly
- understand whether an error occurred and how to present that to the user.
+ understand whether an error ocurred and how to present that to the user.


 #### TerminalApp: Loading and Reloading Changes
--- a/doc/specs/TerminalSettings-spec.md
+++ b/doc/specs/TerminalSettings-spec.md
@@ -58,7 +58,7 @@ VS needs to be able to persist settings just as a simple set of global settings.
 When the application needs to retrieve these settings, they need to use them as a tripartite structure: frontend-component-terminal settings.

 Each frontend will have its own set of settings.
-Each component implementation will also need to have some settings that control it.
+Each component implementation will also ned to have some settings that control it.
 The terminal also will have some settings specific to the terminal.

 ### Globals and Profiles
--- a/doc/specs/drafts/#1256
+++ b/doc/specs/drafts/#1256
@@ -124,7 +124,7 @@ There's a few areas to study here.

 #### Communicating the launch
 For the parameters passing, I see a few options:
-1. `conhost.exe` can look up the package registration for `wt.exe` and call an entrypoint with arguments. This could be adapted to instead look up which package is registered as the default one instead of `wt.exe` for third party hosts. We would have to build provisions into the OS to select this, or use some sort of publicly documented registry key mechanism. Somewhat gross.
+1. `conhost.exe` can look up the package registration for `wt.exe` and call an entrypoint with arguments. This could be adapted to instead look up which package is registered as the default one instead of `wt.exe` for third party hosts. We would have to build provisions into the OS to select this, or use some sort of publically documented registry key mechanism. Somewhat gross.
 1. `conhost.exe` can call the execution alias with parameters. WSL distro launchers use this.
 1. We can define a protocol handler for these sorts of connections and let `wt.exe` register for it. Protocol handlers are already well supported and understood both by classic applications and by packaged/modern applications on Windows. They must have provisions to communicate at least some semblance of argument data as well. This is the route I'd probably prefer. `ms-term://incoming/<session-id>` or something like that. The receiving `wt.exe` can contact the manager process (or set one up if it is the first) and negotiate receiving the session that was specified into a new tab.

--- a/Non-Terminal-Panes.md
+++ b/Non-Terminal-Panes.md
@@ -77,7 +77,7 @@ is a bigger discussion than the feature at hand, however.
 ### Performance, Power, and Efficiency

 decide to host a WebView in a pane, then it surely could impact these measures.
-I don't believe this will have a noticeable impact _on its own_. Should the user
+I don't believe this will have a noticable impact _on its own_. Should the user
 However, I leave that discussion to the implementation of the actual alternative
 pane content itself.

--- a/doc/specs/drafts/576-ProfilesJumplistSpec.md
+++ b/doc/specs/drafts/576-ProfilesJumplistSpec.md
@@ -114,7 +114,7 @@ The jumplist will have to be saved each time a profile change occurs but the fre

 #### Should it open a new instance of the terminal or open in a new tab?

-#### What should happen if a non existent profile is launched
+#### What should happen if a non existant profile is launched
 The jumplist is only updated when the application is running so the profiles could be modified or deleted outside and the jumplist will not be updated. Handling will be done by whatever handles the command line parsing.

 ## Future considerations
--- a/doc/terminal-v2-roadmap.md
+++ b/doc/terminal-v2-roadmap.md
@@ -1,12 +1,8 @@
 # Terminal 2.0 Roadmap

-> **NOTE**
->
-> This document has been superseded by the [Terminal 2022 Roadmap]. Please refer to that document for the updated roadmap.
-
 ## Overview

-This document outlines the roadmap towards delivering Windows Terminal 2.0.
+This document outlines the roadmap towards delivering Windows Terminal 2.0 by Winter 2021.

 ## Milestones

@@ -35,7 +31,9 @@ Below is the schedule for when milestones will be included in release builds of
 | 2021-05-31 | [1.9] in Windows Terminal Preview<br>[1.8] in Windows Terminal | [Windows Terminal Preview 1.9 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-9-release/) |
 | 2021-07-14 | [1.10] in Windows Terminal Preview<br>[1.9] in Windows Terminal | [Windows Terminal Preview 1.10 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-10-release/) |
 | 2021-08-31 | [1.11] in Windows Terminal Preview<br>[1.10] in Windows Terminal | [Windows Terminal Preview 1.11 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-11-release/) |
-| 2021-10-20 | [1.12] in Windows Terminal Preview<br>[1.11] in Windows Terminal | [Windows Terminal Preview 1.12 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-12-release/) |
+| 2021-10-31 | 1.12 in Windows Terminal Preview<br>1.11 in Windows Terminal | |
+| 2021-11-30 | 2.0 RC in Windows Terminal Preview<br>2.0 RC in Windows Terminal | |
+| 2021-12-31 | [2.0] in Windows Terminal Preview<br>[2.0] in Windows Terminal | |

 ## Issue Triage & Prioritization

@@ -51,32 +49,28 @@ The following are a list of the key scenarios we're aiming to deliver for Termin

 > 👉 Note: There are many other features that don't fit within 2.0, but will be re-assessed and prioritized for 3.0, the plan for which will be published in 2021.

-| Priority\* | Scenario | Description/Notes | State |
-| ---------- | -------- | ----------------- | ----- |
-| 0 | Settings UI | A user interface that connects to settings.json. This provides a way for people to edit their settings without having to edit a JSON file.<br><br>Issue: [#1564]<br>Specs: [#6720], [#6904]<br>Implementation: [#7283], [#7370], [#8048] | ✔️ |
-| 0 | Command palette | A popup menu to list possible actions and commands.<br><br>Issues: [#5400], [#2046]<br>Spec: [#2193]<br>Implementation: [#6635] | ✔️ |
-| 1 | Tab tear-off | The ability to tear a tab out of the current window and spawn a new window or attach it to a separate window.<br><br>Issue: [#1256], [#5000]<br>Spec: [#2080], [#7240] | 📝 |
-| 1 | Clickable links | Hyperlinking any links that appear in the text buffer. When clicking on the link, the link will open in your default browser.<br><br>Issue: [#574]<br>Implementation: [#7251] | ✔️ |
-| 1 | Default terminal | If a command-line application is spawned, it should open in Windows Terminal (if installed) or your preferred terminal<br><br>Issue: [#492]<br>Spec: [#2080], [#7414] | ✔️ |
-| 1 | Overall theme support | Tab coloring, title bar coloring, pane border coloring, pane border width, definition of what makes a theme<br><br>Issue: [#3327]<br>Spec: [#5772] | 🦶 |
-| 1 | Open profile elevated | Configure profiles to always open elevated (if Terminal was run unelevated)<br><br>Issue: [#5000], [#632]<br>Spec: [#8455] | 📝 |
-| 1 | Open tab in existing window | Open new tabs in existing Terminal windows<br><br>Issue: [#5000], [#4472]<br>Spec: [#8135] | ✔️ |
-| 1 | Traditional opacity | Have a transparent background without the acrylic blur.<br><br>Issue: [#603] | ✔️ |
-| 2 | SnapOnOutput, scroll lock | Pause output or scrolling on click.<br><br>Issue: [#980]<br>Spec: [#2529]<br>Implementation: [#6062] | ✔️ |
-| 2 | Infinite scrollback | Have an infinite history for the text buffer.<br><br>Issue: [#1410] | 🦶 |
-| 2 | Pane management | All issues listed out in the original issue. Some features include pane resizing with mouse, pane zooming, and opening a pane by prompting which profile to use.<br><br>Issue: [#1000] | 📝 |
-| 2 | Theme marketplace | Marketplace for creation and distribution of themes.<br>Dependent on overall theming | 🦶 |
-| 2 | Jump list | Show profiles from task bar (on right click)/start menu.<br><br>Issue: [#576]<br>Implementation: [#7515] | ✔️ |
-| 2 | Open with multiple tabs | A setting that allows Windows Terminal to launch with a specific tab configuration (not using only command line arguments).<br><br>Issue: [#756] | ✔️ |
-| 3 | Open in Windows Terminal | Functionality to right click on a file or folder and select Open in Windows Terminal.<br><br>Issue: [#1060]<br>Implementation: [#6100] | ✔️ |
-| 3 | Session restoration | Launch Windows Terminal and the previous session is restored with the proper tab and pane configuration and starting directories.<br><br>Issues: [#961], [#960], [#766] | ✔️ |
-| 3 | Quake mode | Provide a quick launch terminal that appears and disappears when a hotkey is pressed.<br><br>Issue: [#653] | ✔️ |
-| 3 | Settings migration infrastructure | Migrate people's settings without breaking them. Hand-in-hand with settings UI. | 🦶 |
-| 3 | Pointer bindings | Provide settings that can be bound to the mouse.<br><br>Issue: [#1553] | 🦶 |
-
-* 📝: The feature is currently in progress
-* ✔️: The feature is complete and shipped in a Preview build
-* 🦶: The feature is at risk of being punted to a future release cycle (beyond 2.0)
+| Priority\* | Scenario | Description/Notes |
+| ---------- | -------- | ----------------- |
+| 0 | Settings UI | A user interface that connects to settings.json. This provides a way for people to edit their settings without having to edit a JSON file.<br><br>Issue: [#1564]<br>Specs: [#6720], [#6904]<br>Implementation: [#7283], [#7370], [#8048] |
+| 0 | Command palette | A popup menu to list possible actions and commands.<br><br>Issues: [#5400], [#2046]<br>Spec: [#2193]<br>Implementation: [#6635] |
+| 1 | Tab tear-off | The ability to tear a tab out of the current window and spawn a new window or attach it to a separate window.<br><br>Issue: [#1256], [#5000]<br>Spec: [#2080], [#7240] |
+| 1 | Clickable links | Hyperlinking any links that appear in the text buffer. When clicking on the link, the link will open in your default browser.<br><br>Issue: [#574]<br>Implementation: [#7251] |
+| 1 | Default terminal | If a command-line application is spawned, it should open in Windows Terminal (if installed) or your preferred terminal<br><br>Issue: [#492]<br>Spec: [#2080], [#7414] |
+| 1 | Overall theme support | Tab coloring, title bar coloring, pane border coloring, pane border width, definition of what makes a theme<br><br>Issue: [#3327]<br>Spec: [#5772] |
+| 1 | Open profile elevated | Configure profiles to always open elevated (if Terminal was run unelevated)<br><br>Issue: [#5000], [#632]<br>Spec: [#8455] |
+| 1 | Open tab in existing window | Open new tabs in existing Terminal windows<br><br>Issue: [#5000], [#4472]<br>Spec: [#8135] |
+| 1 | Traditional opacity | Have a transparent background without the acrylic blur.<br><br>Issue: [#603] <br>**Current State**: Blocked on WinUI 3.0 |
+| 2 | SnapOnOutput, scroll lock | Pause output or scrolling on click.<br><br>Issue: [#980]<br>Spec: [#2529]<br>Implementation: [#6062] |
+| 2 | Infinite scrollback | Have an infinite history for the text buffer.<br><br>Issue: [#1410] |
+| 2 | Pane management | All issues listed out in the original issue. Some features include pane resizing with mouse, pane zooming, and opening a pane by prompting which profile to use.<br><br>Issue: [#1000] |
+| 2 | Theme marketplace | Marketplace for creation and distribution of themes.<br>Dependent on overall theming |
+| 2 | Jump list | Show profiles from task bar (on right click)/start menu.<br><br>Issue: [#576]<br>Implementation: [#7515] |
+| 2 | Open with multiple tabs | A setting that allows Windows Terminal to launch with a specific tab configuration (not using only command line arguments).<br><br>Issue: [#756] |
+| 3 | Open in Windows Terminal | Functionality to right click on a file or folder and select Open in Windows Terminal.<br><br>Issue: [#1060]<br>Implementation: [#6100] |
+| 3 | Session restoration | Launch Windows Terminal and the previous session is restored with the proper tab and pane configuration and starting directories.<br><br>Issues: [#961], [#960], [#766] |
+| 3 | Quake mode | Provide a quick launch terminal that appears and disappears when a hotkey is pressed.<br><br>Issue: [#653] |
+| 3 | Settings migration infrastructure | Migrate people's settings without breaking them. Hand-in-hand with settings UI. |
+| 3 | Pointer bindings | Provide settings that can be bound to the mouse.<br><br>Issue: [#1553] |

 Feature Notes:

@@ -97,8 +91,6 @@ Feature Notes:
 [1.9]: https://github.com/microsoft/terminal/milestone/34
 [1.10]: https://github.com/microsoft/terminal/milestone/35
 [1.11]: https://github.com/microsoft/terminal/milestone/36
-[1.12]: https://github.com/microsoft/terminal/milestone/38
-[1.13]: https://github.com/microsoft/terminal/milestone/39
 [2.0]: https://github.com/microsoft/terminal/milestone/22
 [#1564]: https://github.com/microsoft/terminal/issues/1564
 [#6720]: https://github.com/microsoft/terminal/pull/6720
@@ -141,5 +133,3 @@ Feature Notes:
 [#632]: https://github.com/microsoft/terminal/issues/632
 [#4472]: https://github.com/microsoft/terminal/issues/4472
 [#8048]: https://github.com/microsoft/terminal/pull/8048
-
-[Terminal 2022 Roadmap]: https://github.com/microsoft/terminal/tree/main/doc/roadmap-2022.md
--- a/samples/ConPTY/EchoCon/EchoCon.sln
+++ b/samples/ConPTY/EchoCon/EchoCon.sln
@@ -1,4 +1,4 @@
-
+
 Microsoft Visual Studio Solution File, Format Version 12.00
 # Visual Studio 15
 VisualStudioVersion = 15.0.27703.2026
--- a/samples/ConPTY/EchoCon/EchoCon/EchoCon.vcxproj
+++ b/samples/ConPTY/EchoCon/EchoCon/EchoCon.vcxproj
@@ -23,7 +23,7 @@
    <ProjectGuid>{96274800-9574-423E-892A-909FBE2AC8BE}</ProjectGuid>
    <Keyword>Win32Proj</Keyword>
    <RootNamespace>EchoCon</RootNamespace>
-    <WindowsTargetPlatformVersion>10.0.22000.0</WindowsTargetPlatformVersion>
+    <WindowsTargetPlatformVersion>10.0.19041.0</WindowsTargetPlatformVersion>
    <WindowsTargetPlatformMinVersion>10.0.17763.0</WindowsTargetPlatformMinVersion>
  </PropertyGroup>
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
@@ -163,4 +163,4 @@
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
  <ImportGroup Label="ExtensionTargets">
  </ImportGroup>
-</Project>
+</Project>
--- a/samples/ConPTY/EchoCon/EchoCon/EchoCon.vcxproj.filters
+++ b/samples/ConPTY/EchoCon/EchoCon/EchoCon.vcxproj.filters
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="utf-8"?>
+<?xml version="1.0" encoding="utf-8"?>
 <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <Filter Include="Source Files">
--- a/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/GUIConsole.ConPTY.csproj
+++ b/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/GUIConsole.ConPTY.csproj
@@ -1,4 +1,4 @@
-<Project Sdk="Microsoft.NET.Sdk">
+<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
--- a/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Native/ConsoleApi.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Native/ConsoleApi.cs
@@ -1,4 +1,4 @@
-using System.Runtime.InteropServices;
+using System.Runtime.InteropServices;

 namespace GUIConsole.ConPTY.Native
 {
--- a/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Native/ProcessApi.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Native/ProcessApi.cs
@@ -1,4 +1,4 @@
-using System;
+using System;
 using System.Runtime.InteropServices;

 namespace GUIConsole.ConPTY.Native
--- a/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Native/PseudoConsoleApi.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Native/PseudoConsoleApi.cs
@@ -1,4 +1,4 @@
-using Microsoft.Win32.SafeHandles;
+using Microsoft.Win32.SafeHandles;
 using System;
 using System.Runtime.InteropServices;

--- a/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Processes/Process.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Processes/Process.cs
@@ -1,4 +1,4 @@
-using System;
+using System;
 using System.Runtime.InteropServices;
 using static GUIConsole.ConPTY.Native.ProcessApi;

--- a/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Processes/ProcessFactory.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Processes/ProcessFactory.cs
@@ -1,4 +1,4 @@
-using System;
+using System;
 using System.ComponentModel;
 using System.Runtime.InteropServices;
 using static GUIConsole.ConPTY.Native.ProcessApi;
--- a/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/PseudoConsole.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/PseudoConsole.cs
@@ -1,4 +1,4 @@
-using Microsoft.Win32.SafeHandles;
+using Microsoft.Win32.SafeHandles;
 using System;
 using System.ComponentModel;
 using static GUIConsole.ConPTY.Native.PseudoConsoleApi;
--- a/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/PseudoConsolePipe.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/PseudoConsolePipe.cs
@@ -1,4 +1,4 @@
-using Microsoft.Win32.SafeHandles;
+using Microsoft.Win32.SafeHandles;
 using System;
 using System.ComponentModel;
 using System.Runtime.InteropServices;
--- a/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Terminal.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.ConPTY/Terminal.cs
@@ -1,4 +1,4 @@
-using GUIConsole.ConPTY.Processes;
+using GUIConsole.ConPTY.Processes;
 using Microsoft.Win32.SafeHandles;
 using System;
 using System.IO;
--- a/samples/ConPTY/GUIConsole/GUIConsole.WPF/App.xaml.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.WPF/App.xaml.cs
@@ -1,4 +1,4 @@
-using System.Windows;
+using System.Windows;

 namespace GUIConsole.Wpf
 {
--- a/samples/ConPTY/GUIConsole/GUIConsole.WPF/GUIConsole.WPF.csproj
+++ b/samples/ConPTY/GUIConsole/GUIConsole.WPF/GUIConsole.WPF.csproj
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="utf-8"?>
+<?xml version="1.0" encoding="utf-8"?>
 <Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
  <PropertyGroup>
--- a/samples/ConPTY/GUIConsole/GUIConsole.WPF/MainWindow.xaml.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.WPF/MainWindow.xaml.cs
@@ -1,4 +1,4 @@
-using GUIConsole.ConPTY;
+using GUIConsole.ConPTY;
 using System;
 using System.IO;
 using System.Linq;
--- a/samples/ConPTY/GUIConsole/GUIConsole.WPF/Properties/AssemblyInfo.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.WPF/Properties/AssemblyInfo.cs
@@ -1,4 +1,4 @@
-using System.Reflection;
+using System.Reflection;
 using System.Resources;
 using System.Runtime.CompilerServices;
 using System.Runtime.InteropServices;
--- a/samples/ConPTY/GUIConsole/GUIConsole.WPF/Properties/Resources.Designer.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.WPF/Properties/Resources.Designer.cs
@@ -1,4 +1,4 @@
-//------------------------------------------------------------------------------
+//------------------------------------------------------------------------------
 // <auto-generated>
 //     This code was generated by a tool.
 //     Runtime Version:4.0.30319.42000
--- a/samples/ConPTY/GUIConsole/GUIConsole.WPF/Properties/Resources.resx
+++ b/samples/ConPTY/GUIConsole/GUIConsole.WPF/Properties/Resources.resx
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="utf-8"?>
+<?xml version="1.0" encoding="utf-8"?>
 <root>
  <!-- 
    Microsoft ResX Schema 
--- a/samples/ConPTY/GUIConsole/GUIConsole.WPF/Properties/Settings.Designer.cs
+++ b/samples/ConPTY/GUIConsole/GUIConsole.WPF/Properties/Settings.Designer.cs
@@ -1,4 +1,4 @@
-//------------------------------------------------------------------------------
+//------------------------------------------------------------------------------
 // <auto-generated>
 //     This code was generated by a tool.
 //     Runtime Version:4.0.30319.42000
--- a/samples/ConPTY/GUIConsole/GUIConsole.WPF/Properties/Settings.settings
+++ b/samples/ConPTY/GUIConsole/GUIConsole.WPF/Properties/Settings.settings
@@ -1,4 +1,4 @@
-<?xml version='1.0' encoding='utf-8'?>
+<?xml version='1.0' encoding='utf-8'?>
 <SettingsFile xmlns="uri:settings" CurrentProfile="(Default)">
  <Profiles>
    <Profile Name="(Default)" />
--- a/samples/ConPTY/GUIConsole/GUIConsole.sln
+++ b/samples/ConPTY/GUIConsole/GUIConsole.sln
@@ -1,4 +1,4 @@
-
+
 Microsoft Visual Studio Solution File, Format Version 12.00
 # Visual Studio 15
 VisualStudioVersion = 15.0.26124.0
--- a/samples/ConPTY/MiniTerm/MiniTerm.sln
+++ b/samples/ConPTY/MiniTerm/MiniTerm.sln
@@ -1,4 +1,4 @@
-
+
 Microsoft Visual Studio Solution File, Format Version 12.00
 # Visual Studio 15
 VisualStudioVersion = 15.0.27703.2035
--- a/Show More
+++ b/Show More