Upgrades our SDK from 19041 (Windows 10 20H1) to 22000 (Windows 11 RTM).
The newer SDK is more compatible with /Zc:preprocessor
and will allow us to use newer Windows 11 APIs directly.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Compiles ✔️
* Runs ✔️
## Summary of the Pull Request
Remove those imports as they are unnecessary, _template.py_ contains these too but I guess it's fine since it's a template after all
## Summary of the Pull Request
Upgrade the Windows SDK to 19041 by setting `WindowsTargetPlatformMinVersion` to 17763 and `WindowsTargetPlatformVersion` to 19041.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
General usage of the Windows Terminal application appears fine.
This PR adds a sample monarch/peasant application. This is a type of
application where a single "Monarch" can coordinate the actions of multiple
other "Peasant" processes, as described by the specs in #7240 and #8135.
This project is intended to be a standalone sample of how the architecture would
work, without involving the entirety of the Windows Terminal build. Eventually,
this architecture will be incorporated into `wt.exe` itself, to enable scenarios
like:
* Run `wt` in the current window (#4472)
* Single Instance Mode (#2227)
For an example of this sample running, see the below GIF:
This sample operates largely by printing to the console, to help the reader
understand how it's working through its logic.
I'm doing this mostly so we can have a _committed_ sample of this type of application, kinda like how VtPipeTerm is a sample ConPTY application. It's a lot easier to understand (& build on) when there aren't any window shenanigans, settings loading, Island instantiation, or anything else that the whole of `WindowsTerminal.exe` needs
* [x] I work here
* [x] This is sample code, so I'm not shipping tests for it.
* [x] Go see the doc over in #8135
Many include statements use forward slashes, while others use backwards
slashes. This is inconsistent formatting. For this reason, I changed the
backward slashes to forward slashes since that is the standard.
[Git2Git] Git Train: Merge of building/rs_onecore_dep_uxp/201117-2002 into official/rs_onecore_dep_uxp Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_onecore_dep_uxp 526043ab6050397506b3cdb77e6a43b5ca9a2e9a
Related work items: MSFT-29990377
This commit fixes our longstanding build artifact output issues and
finally unifies all C++ project output into bin/ and obj/.
In light of that, I've removed NoOutputRedirection.
I've also updated WTU and U8U16Test to use our common build props and
fixed any warnings/compilation errors that popped out.
I validated this change by running repeated incremental builds after
changing individual .cpp files in many of our C++/WinRT projects.
This PR updates the rendering of the _underlined_ graphic rendition
attribute, using the style specified in the active font, instead of just
reusing the grid line at the bottom of the character cell.
* Support for drawing the correct underline effect in the grid line
renderer was added in #7107.
There was already an `ExtendedAttributes` flag defined for the
underlined state, but I needed to update the `SetUnderlined` and
`IsUnderlined` methods in the `TextAttribute` class to use that flag
now in place of the legacy `LVB_UNDERSCORE` attribute. This enables
underlines set via a VT sequence to be tracked separately from
`LVB_UNDERSCORE` grid lines set via the console API.
I then needed to update the `Renderer::s_GetGridlines` method to
activate the `GridLines::Underline` style when the `Underlined`
attribute was set. The `GridLines::Bottom` style is still triggered by
the `LVB_UNDERSCORE` attribute to produce the bottom grid line effect.
Validation
----------
Because this is a change from the existing behaviour, certain unit tests
that were expecting the `LVB_UNDERSCORE` to be toggled by `SGR 4` and
`SGR 24` have now had to be updated to check the `Underlined` flag
instead.
There were also some UI Automation tests that were checking for `SGR 4`
mapping to `LVB_UNDERSCORE` attribute, which I've now substituted with a
test of the `SGR 53` overline attribute mapping to
`LVB_GRID_HORIZONTAL`. These tests only work with legacy attributes, so
they can't access the extended underline state, and I thought a
replacement test that covered similar ground would be better than
dropping the tests altogether.
As far as the visual rendering is concerned, I've manually confirmed
that the VT underline sequences now draw the underline in the correct
position and style, while grid lines output via the console API are
still displayed in their original form.
Closes#2915
This PR fixes the scheme resolution bug outlined in #5326
The approach is as follows:
* In [SchemeManager.cs], find the first scheme parser that actually
successfully parses the scheme, as opposed to the existing code, which
finds the first scheme parser which _says it can parse the scheme_, as
that logic spuriously returns `true` currently.
* In [XmlSchemeParser.cs] and [JsonParser.cs], ensure that the contents
of the file are read and the contents passed to XmlDocument.LoadXXX,
as this fails with an UriException on WSL otherwise.
* Remove `CanParse` as it is superfluous. The check for a valid scheme
parser should not just check an extension but also if the file exists
- this is best done by the `ParseScheme` function as it already
returns null on failure.
* Add `FileExtension` to the interface because we need it lifted now.
Closes#5326
<!-- 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
Many places in this codebase has an equality comparison to the boolean FALSE. This adds unneeded complexity as C and C++ has a NOT operand for use of these in if statements. This makes the code more readable in those areas.
<!-- 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
* [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [X] Tests added/passed
* [ ] Requires documentation to be 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
One boolean being compared to FALSE was only used once, with the boolean name being "b", so it is better off not existing at all.
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Unit Testing passed, compiler refactoring
## Summary of the Pull Request
Adds implicit stdexcept header include to u8u16test tool.
## PR Checklist
* [x] Closes regression introduced when moving from VS 16.5 to VS 16.6 (which the CI did of its own accord)
* [x] I work here.
* [x] Built it.
* [x] No doc.
* [x] Am core contributor.
## Detailed Description of the Pull Request / Additional comments
In VS 16.5, the <stdexcept> header was pulled in by `<string>` or `<string_view>` or `<array>` or `<algorithm>` implicitly. In VS 16.6, that's gone. No one wrote it in the header because it was just automatically there in the past. Now I wrote it in the header.
## Validation Steps Performed
* [x] Built it on my machine after upgrading to VS `16.6.0`.
* [x] Built it in CI.
Followup to ea61aa3b.
The default foreground in the iTerm2 defaults for the Tango Dark color
scheme is too bright, use the value for ANSI 7 (white) instead.
References #5305
Sorry, I should have really done this in the original PR.
Signed-off-by: Rafael Kitover <rkitover@gmail.com>
Literally just <kbd>ctrl+f</kbd> find-and-replace all the old `profiles.json` that are sitting around in the repo with `settings.json`. I didn't touch the specs, since it seemed better to leave them in the state that they were originally authored in.
* [x] closes#5522
* [x] I work here.
* [x] This is docs.
* Cleaning up the whitelist a bit.
* The magic to exclude repeated characters worked 👍
* Every successful run on master now logs its suggested cleanup, e.g. for 5740e197c2 has https://github.com/microsoft/terminal/runs/596271627#step:4:37
* ⚠️ This check-spelling 0.0.15a+ tolerates Windows line endings in the `whitelist.txt` file (another project I touched had some `.gitconfig` magic which required supporting them).
This means that if someone edits the file w/ something that likes Windows line endings, the file will successfully convert (instead of it being ignored and check-spelling complaining about everything). Most likely anyone else who then edits the file will use something that will maintain the line endings.
The Tango color scheme is part of the Tango Desktop Project, which was
released to the public domain in 2009.
More information is available at http://tango-project.org/.
This commit adds the "Tango Dark" and "Tango Light" color scheme
presets.
Closes#5281
Signed-off-by: Rafael Kitover <rkitover@gmail.com>
This PR updates our internal tool `conechokey` to use `ReadConsoleInputW` by default. It also adds a flag `-a` to force it to use `ReadConsoleInputA`.
I discovered this while digging around for #1503, but figured I'd get this checked in now while I'm still investigating.
Since this is just a helper tool, I spent as little effort writing this change - yea the whole tool could benefit from cleaner code but _ain't nobody got time for that_.
<!-- 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
Every single time a PR is run, there are a bunch of warnings about whitespace in the .cs files, so I ran the code format on those files, without changing their contents, so it won't be flagged anymore.
<!-- 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
* [X] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [X] Tests added/passed
<!-- 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 the code-format utility on the .cs files
This commit introduces a github action to check our spelling and fixes
the following misspelled words so that we come up green.
It also renames TfEditSes to TfEditSession, because Ses is not a word.
currently, excerpt, fallthrough, identified, occurred, propagate,
provided, rendered, resetting, separate, succeeded, successfully,
terminal, transferred, adheres, breaks, combining, preceded,
architecture, populated, previous, setter, visible, window, within,
appxmanifest, hyphen, control, offset, powerpoint, suppress, parsing,
prioritized, aforementioned, check in, build, filling, indices, layout,
mapping, trying, scroll, terabyte, vetoes, viewport, whose
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.
<!-- 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
Translate automatically generated message text from German into English.
<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? -->
## References
#4799
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Requires documentation to be 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
@miniksa mentioned in https://github.com/microsoft/terminal/pull/4799#discussion_r389166916
> Actually..... we would consider that block to be wrong. It should have had the English error text there. [...] It's just our practice to have everything be in English as that's our company's working language. [...]
The translation is based on the message text found in the official docs: https://docs.microsoft.com/en-us/nuget/Consume-Packages/Package-restore-troubleshooting
<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed
Generated by https://github.com/jsoref/spelling `f`; to maintain your repo, please consider `fchurn`
I generally try to ignore upstream bits. I've accidentally included some items from the `deps/` directory. I expect someone will give me a list of items to drop, I'm happy to drop whole files/directories, or to split the PR into multiple items (E.g. comments/locals/public).
Closes#4294
First, my changes to `build.bat`:
1. `Build.bat` now looks for Visual Studio 2019 too.
2. `Build.bat` now ensures that the linker places ColorTool.exe into
`\debug` or `\release` folders, not `\debug\net471` or
`\release\net471`.
3. `Build.bat` is now smarter in its search. It determines the operating
system's CPU architecture before deciding whether to search in "Program
Files (x86)" or "Program Files".
Second, my changes to the help text displayed to the user:
1. The help text now makes it clear that some switches cannot be used
with certain others.
2. Some typos are fixed. e.g. "ct" to "ColorTool" (it took me two hours
to figure this one out!) and "schemename" to "scheme name".
I've made a minor change to the order of `switch (arg)` in Program.cs
too, to ensure that the terminating switches are analyzed first. This
way, there will be fewer surprises if the user supplies malformed input.
But feel free to reject this one.
# Unresolved issues
`Build.bat` is inherently faulty. On a pristine computer, a user cannot
just install the latest version of Microsoft Build Tool and run
`build.bat` to build ColorTool. The reason is the absence of certain
NuGet packages. Either NuGet or Visual Studio must download the
dependencies first.
# Validation Steps Performed
Since the changes to the code are minor, I don't know what test I can
possibly devise, other than compiling it and seeing that it works.
This commit cleans up and deduplicates all of the common build
preamble/postamble across exe, dll, lib and c++/winrt projects.
The following specific changes have been made:
* All projects now define their ConfigurationType
* All projects now set all their properties *before* including a common
build file (or any other build files)
* cppwinrt.pre and cppwinrt.post now delegate most of their
configuration to common.pre and common.post
* (becuase of the above,) all build options are conserved between
console and c++/winrt components, including specific warnings and
preprocessor definitions.
* More properties that are configurable per-project are now
conditioned so the common props don't override them.
* The exe, dll, exe.or.dll, and lib postincludes have been merged into
pre or post and switched based on condition as required
* Shared items (-shared, -common) are now explicitly vcxitems instead of
vcxproj files.
* The link line is now manipulated after Microsoft.Cpp sets it, so the
libraries we specify "win". All console things link first against
onecore_apiset.lib.
* Fix all compilation errors caused by build unification
* Move CascadiaPackage's resources into a separate item file
Fixes#922.
[Git2Git] Git Train: Merge of building/rs_onecore_dep_uxp/191011-1234 into official/rs_onecore_dep_uxp Retrieved from https://microsoft.visualstudio.com os OS official/rs_onecore_dep_uxp b80345479891d1e7a9f7e38b6b5f40083c6a564a
sources changes from 21H1
Merged PR 3896217: [Git2Git] Changes from vb_release_dep_dev1
server init changes from 20H1 (onecore headless mode)
Since ColorTool shares the same Release page as Windows Terminal, it is more difficult to navigate to it. So whenever ColorTool is updated with a new release, we will update the link to the latest release. The link I changed to is the latest available from April 2019.
* Add a new console target that writes the color scheme to stdout in JSON format for copying into a Windows Terminal profiles.json file.
* Update src/tools/ColorTool/ColorTool/ConsoleTargets/TerminalSchemeConsoleTarget.cs
Co-Authored-By: Michael Niksa <miniksa@microsoft.com>
* Create a base class for scheme parsers for common code and helpers. Fix string formatting according to review comments.
* Cascadia/TerminalConnection: Close the output thread on exit.
It seems that TerminateThread() is available in the code...
* VtPipeTerm: Don't crash when closing the app.
- Gracefully handle ReadFile returning false (usually because of ERROR_BROKEN_PIPE on exit).
- Minor whitespace formatting.
* Cascadia/TerminalConnection: Finish to implement the ConhostConnection::Close() 'TODO' block.
Almost all functions in the Windows API that open or create objects and return HANDLEs to them return null on failure; only a few (mostly to do with the file system) return INVALID_HANDLE_VALUE on failure. This PR scrubs the repo of a few, but not necessarily all, cases where INVALID_HANDLE_VALUE was mistakenly used or tested against instead of null. In particular, it fixes 2 cases reported in issue #427 where the return value of CreateThread() was compared against INVALID_HANDLE_VALUE against null, causing the error handling code to run at the wrong time.
There are a lot of other uses of INVALID_HANDLE_VALUE I found that looked questionable, but which I left alone. Most of these were used to initialize HANDLE-typed variables and as a sentinel to see if those variables remained unset to a "real" value.
Fixes#427
