## Summary of the Pull Request
Improves Quick Fix's suggestions to use WinGet API and actually query
winget for packages based on the missing command.
To interact with the WinGet API, we need the
`Microsoft.WindowsPackageManager.ComInterop` NuGet package.
`Microsoft.WindowsPackageManager.ComInterop.Additional.targets` is used
to copy over the winmd into CascadiaPackage. The build variable
`TerminalWinGetInterop` is used to import the package properly.
`WindowsPackageManagerFactory` is used as a centralized way to generate
the winget objects. Long-term, we may need to do manual activation for
elevated sessions, which this class can easily be extended to support.
In the meantime, we'll just use the normal `winrt::create_instance` on
all sessions.
In `TerminalPage`, we conduct the search asynchronously when a missing
command was found. Search results are limited to 20 packages. We try to
retrieve packages with the following filters set, then fallback into the
next step:
1. `PackageMatchField::Command`,
`PackageFieldMatchOption::StartsWithCaseInsensitive`
2. `PackageMatchField::Name`,
`PackageFieldMatchOption::ContainsCaseInsensitive`
3. `PackageMatchField::Moniker`,
`PackageFieldMatchOption::ContainsCaseInsensitive`
This aligns with the Microsoft.WinGet.CommandNotFound PowerShell module
([link to relevant
code](9bc83617b9/src/WinGetCommandNotFoundFeedbackPredictor.cs (L165-L202))).
Closes#17378Closes#17631
Support for elevated sessions tracked in #17677
## References
-
https://github.com/microsoft/winget-cli/blob/master/src/Microsoft.Management.Deployment/PackageManager.idl:
winget object documentation
## Validation Steps Performed
- [X] unelevated sessions --> winget query performed and presented
- [X] elevated sessions --> nothing happens (got rid of `winget install
{}` suggestion)
The answerback feature allows for the user to define a message that the
terminal will transmit to the host whenever an `ENQ` (enquiry) control
character is received.
## Detailed Description of the Pull Request / Additional comments
In Windows Terminal, the message can be configured at the profile level
of the settings file, as a string property named `AnswerbackMessage`.
In ConHost, the message can be configured in the registry, again as a
string value with the name `AnswerbackMessage`.
## Validation Steps Performed
I've confirmed that the control is working as intended in both Windows
Terminal and ConHost using Vttest.
Closes#11946
This pull request removes the following vendored open source, in favor
of getting it from vcpkg:
- CLI11 2.4
- jsoncpp 1.9
- fmt 7.1.3
- gsl 3.1 (not vendored, but submoduled--arguably worse!)
Now that Visual Studio 2022 includes a built-in workload for vcpkg, the
onboarding process is much smoother. Terminal should only require the
vcpkg workload.
I've added some build rules that detect vcpkg via VS and via the user's
environment before falling back to a location in the source tree. The CI
pipeline will fall back to installing and bootstrapping vcpkg in
dep/vcpkg if necessary.
Some OSS has not been (and will not be) migrated:
- wyhash: ours is included directly in til/hash
- pcg_random: we have a stripped down copy compared to vcpkg
- stb_rect: vcpkg only ships *all of STB*; ours is a stripped down copy
- chromium numerics: vcpkg does not ship Chromium, especially not this
tiny fraction of Chromium
- dynamic_bitset and libpopcnt: removing in #17510
- interval_tree: no vcpkg equivalent
To support the needs of the inbox Windows build, I've split up our vcpkg
manifest into dependencies for all projects and dependencies just for
Terminal. To support this, we now offer a `terminal` feature. The vcpkg
rules in `common.build.pre.props` are set up to turn it on, whereas the
build rules we eventually write for the OS will not be.
Most of the work is concentrated in `common.build.pre.props`.
## Summary of the Pull Request
update to the latest cli11 version
## References and Relevant Issues
none
## Detailed Description of the Pull Request / Additional comments
none
## Validation Steps Performed
## PR Checklist
- [ ] Closes #xxx
- [ ] Tests added/passed
- [ ] Documentation updated
- If checked, please file a pull request on [our docs
repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
- [ ] Schema updated (if necessary)
---------
Co-authored-by: Leonard Hecker <lhecker@microsoft.com>
This includes a fix for the hang on shutdown due to the folder change
reader.
WIL now validates format strings in `LOG...` macros (yay!) and so we
needed to fix some of our `LOG` macros.
Closes#16456
The DWMWA for this has been documented for quite a while now!
I've also updated to a version of TerminalThemeHelpers that removes all the Dark Theme exports.
This fixes the BreadcrumbBar issue that would crash into the debugger
anytime you open the SUI on a second thread.
See #14957.
Maybe also tracked in #15144 - let's have @j4james test when this
merges.
Updates the Terminal to Microsoft.UI.Xaml v2.8.
* MUX 2.8 adds a dependency on WebView2, so we need to include parts of it too.
* See https://github.com/microsoft/microsoft-ui-xaml/pull/7574 for why
we're adding the `.props`
* The TabView thing:
> tl;dr: In >=MUX 2.7, we were updating our tab colors by doing a
"Visual State Dance", as I called it. We'd manually change the
`TabViewItem`'s VisualState to one that it wasn't in, then change it
back to the one it should be in. This seemingly re-applied the new
values of the brushes. However in 2.8, this seemingly didn't work
anymore!
>
> So instead, we do a "Theme Dance", like so:
> ```c++
> const auto& reqTheme = TabViewItem().RequestedTheme();
> TabViewItem().RequestedTheme(ElementTheme::Light);
> TabViewItem().RequestedTheme(ElementTheme::Dark);
> TabViewItem().RequestedTheme(reqTheme);
> ```
> This causes the `ThemeResource`s to be re-evaluated to the new values.
> We never got to the root cause of why this seems different in 2.8. It
literally makes no sense.
Closes#13495
Co-authored-by: Dustin L. Howett <duhowett@microsoft.com>
We ship a separate package to Windows 10, which contains a copy of XAML
embedded in it, because of a bug in activating classes from framework
packages while we're elevated.
We did this to avoid wasting disk space on Windows 11 installs (which is
critical given that we're preinstalled in the Windows image.)
The fix for this issue was released in a servicing update in April 2022.
Thanks to KB5011831, we no longer need this workaround!
And finally, this means that we no longer need to depend on a copy of
"pre-release" XAML. We only did that because it would copy all of its
assets into our package.
Introduced in #12560Closes#14106
Closes (discussion) #14981
Reverts #14660
Interesting things we could do after this:
- remove all `InitializeComponent` calls - they do it automatically
- have some Clang support (!)
- use `std::optional`<->`IReference` automatic binding
- use `std::format` support (!) for json/uri/hostname/http stuff/all
`IStringable`s
- potentially move to `/await:strict` for C++20 coroutines
I've also fixed up a couple ambiguities introduced by this change.
This pull request removes, in full, our dependency on cpprestsdk. This
allows us to shed 500KiB-1.2MiB from our package off the top and enables
the following future investments:
- Removal of the App CRT forwarders to save an additional ~500KiB
- Switching over to the HybridCRT and removing our dependency on _any
CRT_.
cpprest was built on my dev box two or so years ago, and is in _utter_
violation of our compliance guidelines on SBOM et al.
In addition, this change allows us to use the proxy server configured
in Windows Settings.
I did this in four steps (represented roughly by the individual commits):
1. Switch from cpprest's http_client/json to Windows.Web.Http and
Windows.Data.Json
2. Switch from websocketpp to winhttp.dll's WebSocket implementation¹
3. Remove all remaining utility classes
4. Purge all dependencies from all projects and scripts on cpprest.
I also took this opportunity to add a feature flag that allows Dev
builds to run AzureConnection in-process.
¹ Windows.Networking.Sockets' API is so unergonomic that it was simply
infeasible (and also _horrible_) to use it.
## Validation Steps
I've run the Azure Connection quite a bit inproc.
Closes#4575.
Might be related to #5977, #11714, and with the user agent thing maybe #14403.
We originally needed this library (or a separate DLL in our own project)
to handle hooking up the XAML resource loader to the providers that our
application needed. It was introduced in its nascent form in 2019, in a
PR titled "Make XAML files work."
It appears we no longer need it, and the provider hookup is being
handled by our `AppT2` base class override. I've tested this in Windows
10 Vb running unpackaged, and it seems to work totally fine. Crazy.
Removing this dependency saves us a couple hundred kilobytes on disk and
removes one consumer of the App CRT from our package.
When Leonard updated CLI11 in #12658, he imported a version that no
longer requires RTTI. Since CLI11 was the only reason we had enabled
RTTI in any of our projects, we're finally able to turn it off.
| | TerminalApp.dll | MSIX Package |
| ------ | ---------------:| ------------:|
| Before | 3180KiB | 6545KiB |
| After | 1970KiB | 6426KiB |
| Delta | **-1210KiB** | **-119KiB** |
This pull request adds the JSON schema for `cgmanifest.json`.
## FAQ
### Why?
A JSON schema helps you to ensure that your `cgmanifest.json` file is valid.
JSON schema validation is a build-in feature in most modern IDEs like Visual Studio and Visual Studio Code.
Most modern IDEs also provide code-completion for JSON schemas.
### How can I validate my `cgmanifest.json` file?
Most modern IDEs like Visual Studio and Visual Studio Code have a built-in feature to validate JSON files.
You can also use [this small script](https://github.com/JamieMagee/verify-cgmanifest) to validate your `cgmanifest.json` file.
### Why does it suggest camel case for the properties?
Component Detection is able to read camel case and pascal case properties.
However, the JSON schema doesn't have a case-insensitive mode.
We therefore suggest camel case as it's the most common format for JSON.
### Why is the diff so large?
To deserialize the `cgmanifest.json` file, we use [`JSON.parse()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse).
However, to serialize the JSON again we use [`prettier`](https://prettier.io/).
We found that, in general, it gave smaller diffs than the default [`JSON.stringify()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify) function.
Does two things:
* the first two commits: shakes up the way we reference MUX in our projects so we can actually just
```xml
<PropertyGroup Label="NuGet Dependencies">
<TerminalMUX>true</TerminalMUX>
</PropertyGroup>
```
Like every other dependency we have
* the last commit: update to MUX.2.7.3
This is the 1.14 PR, which should be appropriately cherry-picked through to `release-1.15` and `main`
(cherry picked from commit a277b56f6a)
`InteractivityOneCore` and `RendererWddmCon` were the last two remaining
projects which are relevant for our internal console builds, but couldn't be
easily compiled publicly by users on GitHub. This commit adds all definitions
required to compile the two projects into dysfunctional libraries at least.
(Since the added definitions are deliberately incorrect.)
Additionally this commit fixes the AuditMode build for the two projects.
## Validation Steps Performed
The two new projects compile fine.
On certain builds of Windows, when Terminal is set as the default it
will accumulate an unbounded amount of queued animations while the
screen is off and it is servicing window management for console
applications.
This results in Terminal hanging when left overnight, as it has millions
of animations to process.
The new call into TerminalThemeHelpers will tell our compositor to
automatically complete animations that are scheduled while the screen is
off.
Fixes MSFT-38506980
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
This builds on top of #12707. As I understand it the primary motivation for using a git submodule instead of NuGet is just that it is too annoying to have to manage dozens of packages.config files and their corresponding import statements. Now that there is a single global nuget definition that is a nonissue and we can switch over.
This also updates to the latest version of WIL.
Now that the latest version of WIL is available it uses it to replace `winrt::resume_foreground` with `wil::resume_foreground`. See [492c01bb53) for a detailed explanation of the problems with `winrt::resume_foreground` and how WIL addresses them.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes#12776, Closes#12777
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx
<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Ran `git clean -fdx` to wipe my clone to be completely clean. Opened the solution in Visual Studio 2022 and build it. Used `razzle.cmd`, `b`, and `runut.cmd` to run the tests.
These changes are purely a refactoring of the build files. There should
be no difference to the compiled result or runtime behavior.
Currently there are packages.config files in lots of directories, with
those same projects referencing props/targets from packages/ with a
version string in the path. This is frustrating because version changes
or new dependencies require updating lots and lots of build files
identically. There is also the possibility of error where locations are
missed.
With these changes there is a single canonical nuget configuration that
takes effect for all of OpenConsole.sln. Updating version numbers
should be limited to a single set of global files.
The changes were done incrementally but the result is basically that
dep\nuget\packages.config serves as the global NuGet dependency list. A
pair of common build files (common.nugetversions.props and
common.nugetversions.targets) were added to contain the various imports
and error checks. There is also a special build target to ensure that
the restore happens before builds even though a given directory doesn't
have a packages.config for Visual Studio to observe.
These new *.nugetversions.* files are imported in pretty much every
vcxproj/csproj in the solution in the appropriate place to satisfy the
need for packages. There are opt-in configuration values (e.g.
`TerminalCppWinrt=true`) that must be set to opt into a given
dependency. Adding a new dependency is just a matter of adding a new
opt-in value. The ordering of include does matter, which was a
difficult challenge to realize and address.
There was also a preexisting issue in 3 test projects where
cppwinrt.props was included but not cppwinrt.targets. By consolidating
things globally that "error" was fixed, but broke the build in a way
that was very confusing. Those projects don't need the cppwinrt targets
so they were opted out of the cppwinrt build files entirely to fix the
breaks and get back to previous behavior.
There are two notable exceptions to this canonical versioning. The
first is that there are dueling XAML 2.7 dependencies. I avoided that
by leaving those as per-project package.config entries. The second is
that any projects outside of the .sln (such as the Island samples) were
not touched.
## Validation Steps Performed
The primary validation is that the solution builds without errors. That
is what I'm seeing (x64|Debug). I also ran `git clean -fdx` from the
root of the repo to wipe it to clean and then opened the solution and
was able to build successfully. The project F5 deploys and looks fine
to me with just a cursory glance. The tests also largely pass (7418
pass, 188 fail, 14 other) which is as good or better than the baseline I
established from a clean clone.
Closes#12708
This commit enables `/std:c++20` for local development under VS17.
Our CIs will continue to use VS16 and C++17 for now in order to reduce
the likelihood of regressions during the current development cycle.
It's expected that we'll migrate to VS17 soon, as this
is what conhost is already being built with anyways.
## PR Checklist
* [x] Closes#12510
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Everything compiles under `/std:c++20` ✅
This commit removes our local copy of clang-format 8 and replaces it
with a newly-built nuget package containing clang-format 10.
This resolves the inconsistency between our version of clang-format and
the one shipped in Visual Studio.
A couple minor format changes were either required or erroneously forced
upon us--chief among them is a redistribution of `*`s around SAL
annotations in inline class members of COM classes. Don't ask why; I
couldn't figure it out.
We had some aspirational goals for our formatting, which were left in
but commented out. Enabling them changes our format a little more than
I'm comfortable with, so I uncommented them and locked them to the
format style we've been using for the past year. We may not love it, but
our aspirations may not matter here any longer. Consistent formatting is
better than perfect formatting.
GSL 3, the next major version of GSL after the one we're using, replaced
their local implementation of `span` with one that more closely mimics
C++20's span. Unfortunately, that is a breaking change for all of GSL's
consumers.
This commit updates our use of span to comply with the new changes in
GSL 3.
Chief among those breaking changes is:
* `span::at` no longer exists; I replaced many instances of `span::at`
with `gsl::at(x)`
* `span::size_type` has finally given up on `ptrdiff_t` and become
`size_t` like all other containers
While I was here, I also made the following mechanical replacements:
* In some of our "early standardized" code, we used std::optional's
`has_value` and `value` back-to-back. Each `value` incurs an
additional presence test.
* Change: `x.value().member` -> `x->member` (`optional::operator->`
skips the presence test)
* Change: `x.value()` -> `*x` (as above)
* GSL 3 uses `size_t` for `size_type`.
* Change: `gsl::narrow<size_t>(x.size())` -> `x.size()`
* Change: `gsl::narrow<ptrdiff_t>(nonSpan.size())` -> `nonSpan.size()`
during span construction
I also replaced two instances of `x[x.size() - 1]` with `x.back()` and
one instance of a manual array walk (for comparison) with a direct
comparison.
NOTE: Span comparison and `make_span` are not part of the C++20 span
library.
Fixes#6251
## Summary of the Pull Request
When resizing the window title, a GDI object would be leaked. This has to do with our island message handler using `wil` to track these objects and `wil` having a bug.
## References
microsoft/wil#100
## PR Checklist
* [x] Closes#5949
* [x] I work here.
* [x] Tested manually
* [x] Doc not required.
* [x] Am core contributor.
## Validation Steps Performed
* [x] Added the GDI Objects column to Task Manager, set the Terminal to use the `titleWidth` size tabs, then changed the title a bunch with PowerShell. Confirmed repro before (increasing GDI count). Confirmed it's gone after (no change to object count).
This change is necessary as the dep/ folder is not synced into the
Windows source tree.
I've also added a build rule producing a lib for {fmt}.
This will be required for our next OS ingestion.
We received a request from our localization team to switch from
printf-style format strings (%s, %u) to format strings with positional
argument support. I've been hoping for a long time to take a dependency
on C++20's std::format, but we're just not somewhere we can do that.
Enter fmt. fmt is _exactly_ the library we need.
Minor comparison:
std::wstring_view world = /* ... */;
auto str{ wil::str_printf<std::wstring>(L"hello %.*s",
gsl::narrow_cast<size_t>(world.size()),
world.data()) };
---
auto str{ fmt::format(L"hello {0}", world) };
If you really want to use the print specifiers:
auto str{ fmt::printf(L"hello %s", world) };
It's got optional compile-time checking for format strings and is
MIT-licensed. Eventually, we should be able to replace fmt:: with std::
and end up pretty much where we left off.
What more could you ask for?
This commit replaces `std::vector<bool>` with `dynamic_bitset<>` by
@pinam45 (https://github.com/pinam45/dynamic_bitset) and with
`libpopcnt` for high-performance bit counting by @kimwalisch
(https://github.com/kimwalisch/libpopcnt).
* [x] In support of performance, incremental rendering, and Terminal
"not speed enough" as well as my sanity relative to
`std::vector<bool>`
* [x] Tests updated and passed.
* [x] `LICENSE`, `NOTICE`, and provenance files updated.
* [x] I'm a core contributor. I discussed it with @DHowett-MSFT and
cleared the licensing checks before pulling this in.
## Details `std::vector<bool>` provided by the Microsoft VC Runtime is
incapable of a great many things. Many of the methods you come to expect
off of `std::vector<T>` that are dutifully presented through the `bool`
variant will spontaneously fail at some future date because it decides
you allocated, resized, or manipulated the `vector<bool>` specialization
in an unsupported manner. Half of the methods will straight up not work
for filling/resizing in bulk. And you will tear your hair out as it will
somehow magically forget the assignment of half the bits you gave it
part way through an iteration then assert out and die.
As such, to preserve my sanity, I searched for an alternative. I came
across the self-contained header-only library `dynamic_bitset` by
@pinam45 which appears to do as much of `boost::dynamic_bitset` as I
wanted, but without including 400kg of boost libraries. It also has a
nifty optional dependency on `libpopcnt` by @kimwalisch that will use
processor-specific extensions for rapidly counting bits. @DHowett-MSFT
and I briefly discussed how nice `popcnt` would have been on
`std::vector<bool>` last week... and now we can have it. (To be fair, I
don't believe I'm using it yet... but we'll be able to easily dial in
`til::bitmap` soon and not worry about a performance hit if we do have
to walk bits and count them thanks to `libpopcnt`.)
This PR specifically focuses on swapping the dependencies out and
ingesting the new libraries. We'll further tune `til::bitmap` in future
pulls as necessary.
## Validation
* [x] Ran the automated tests for bitmap.
* [x] Ran the terminal manually and it looks fine still.
This commit upgrades C++/WinRT to 2.0.200316.3 and fixes a couple of the
transitive dependency issues we had in the process.
Because the latest version has better dependency resolution, we're able
to properly depend on Microsoft.UI.Xaml and the Toolkit in TerminalApp
and TerminalAppLib so we no longer need to manually include .dll and
.pri files.
Because of nebulous _other_ changes in dependency resolution,
WindowsTerminalUniversal isn't picking up transitive .winmd dependencies
from TerminalApp, and needs to include them as ProjectReferences
directly. This was already happening transitively, so now it's explicit.
I've also taken the time to upgrade GSL to v2.1.0, the last release
before they removed span::at and blew up our world.
## Summary of the Pull Request
Adds support for commandline arguments to the Windows Terminal, in accordance with the spec in #3495
## References
* Original issue: #607
* Original spec: #3495
## PR Checklist
* [x] Closes#607
* [x] I work here
* [x] Tests added/passed
* [ ] We should probably add some docs on these commands
* [x] The spec (#3495) needs to be merged first!
## Detailed Description of the Pull Request / Additional comments
🛑 **STOP** 🛑 - have you read #3495 yet? If you haven't, go do that now.
This PR adds support for three initial sub-commands to the `wt.exe` application:
* `new-tab`: Used to create a new tab.
* `split-pane`: Used to create a new split.
* `focus-tab`: Moves focus to another tab.
These commands are largely POC to prove that the commandlines work. They're not totally finished, but they work well enough. Follow up work items will be filed to track adding support for additional parameters and subcommands
Important scenarios added:
* `wt -d .`: Open a new wt instance in the current working directory #878
* `wt -p <profile name>`: Create a wt instance running the given profile, to unblock #576, #1357, #2339
* `wt ; new-tab ; split-pane -V`: Launch the terminal with multiple tabs, splits, to unblock #756
## Validation Steps Performed
* Ran tests
* Played with it a bunch
## Summary of the Pull Request
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#4013
* [x] I work here.
* [x] Existing tests should be OK. Real changes, just adding a lib to use.
* [x] Couldn't find any existing docs about intsafe.
* [x] Am core contributor.
## Detailed Description of the Pull Request / Additional comments
* [x] Can we remove min/max completely or rename it in the two projects where it had to be reintroduced? This is now moved into #4152
* [x] How many usages of the old safe math are there? **79**
* [x] If not a ton, can we migrate them here or in a follow on PR? This is now moved into #4153
Files with old safe math:
- TerminalControl: TSFInputControl.cpp
- TerminalCore: TerminalDispatch.cpp
- TerminalCore: TerminalSelection.cpp
- Host: directio.cpp
- RendererGdi: invalidate.cpp
- RendererGdi: math.cpp
- RendererGdi: paint.cpp
- RendererVt: paint.cpp
- TerminalAdapter: adaptDispatch.cpp
- Types: viewport.cpp
- Types: WindowUiaProviderBase.cpp
## Validation Steps Performed
Switch to using jsoncpp as our json library. This lets us pretty-print the json file by default, and lets users place comments in the json file.
We will now only re-write the file when the actual logical structure of the json object changes, not only when the serialization changes.
Unfortunately, this will remove any existing ordering of profiles, and make the order random. We don't terribly care though, because when #754 lands, this will be less painful.
It also introduces a top-level globals object to hold all the global properties, including keybindings. Existing profiles should gracefully upgrade.
Carlos Zamora
Dustin L. Howett
James Holderness
David Federman
David Federman
Jvr
Mike Griese
Rose
Jamie Magee
dependabot[bot]
Leonard Hecker
David Machaj
Mingjie Shao
Michael Niksa
Dustin L. Howett
adiviness