After this commit OpenConsoleProxy will be built without a CRT.
This cuts down its binary size and DLL dependency bloat.
We hope that this fixes a COM server activation bug if the
user doesn't have a CRT installed globally on their system.
Fixes#11529
This pull request moves us to Microsoft.Windows.CppWinRT 2.0.210825.3.
Notable improvements from 2.0.210309.3:
* Restored Windows 7 functionality
* C++20 ranges support
* `capture` now works with a raw pointer
* `hstring::starts_with` and `hstring::ends_with` (C++20)
Unit/Functional Tests:
Summary: Total=7728, Passed=7571, Failed=10, Blocked=0, Not Run=0, Skipped=147
Local Tests:
Summary: Total=163, Passed=158, Failed=5, Blocked=0, Not Run=0, Skipped=0
The above failures are (1) in UIA tests for conhost/WT (which do not work here) or
(2) in already known-broken local tests.
This commit is a preparation for upcoming changes to KeyChordSerialization for #7539 and #10203.
In order to support variadic macros, /Zc:preprocessor was enabled, which required changing unrelated parts of the project.
## PR Checklist
* [x] I work here
* [x] Tests added/passed
## Validation Steps Performed
* Project still compiles ✔️
C++/WinRT has a way to ensure that we use `make<>` instead of allocating
WinRT objects on the stack, but until 10.0.19041 the XAML compiler
generated code that violated that rule.
Because of how make detection is implemented, it must create a derived
type (and so WinRT implementation types can't be `final`).
## 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.
C++/WinRT added a feature where it will detect a mismatch in some of its
build flags.
Because we build XAML projects and non-XAML projects, and try to link
them together in static libraries, we need those flags to always match.
C++/WinRT only respects this flag when `DEBUG` is set, so our CI missed
this.
With thanks to @carlos-zamora for letting me build/test/commit this on
his computer.
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.
## Summary of the Pull Request
Move `ICoreSettings` and `IControlSettings` from the TerminalSettings project to the TerminalCore and TerminalControl projects respectively. Also entirely removes the TerminalSettings project.
The purpose of these interfaces is unchanged. `ICoreSettings` is used to instantiate a terminal. `IControlSettings` (which requires an `ICoreSettings`) is used to instantiate a UWP terminal control.
## References
Closes#7140
Related Epic: #885
Related Spec: #6904
## PR Checklist
* [X] Closes#7140
* [X] CLA signed
* [X] Tests ~added~/passed (no additional tests necessary)
* [X] ~Documentation updated~
* [X] ~Schema updated~
## Detailed Description of the Pull Request / Additional comments
A lot of the work here was having to deal with winmd files across all of these projects. The TerminalCore project now outputs a Microsoft.Terminal.TerminalControl.winmd. Some magic happens in TerminalControl.vcxproj to get this to work properly.
## Validation Steps Performed
Deployed Windows Terminal and opened a few new tabs.
This fixes the build the rest of the way in VS 16.7. Something about the
way we were using the Store/Container flags caused some of our projects
to end up linking kernel32.lib only (MinimalCoreWin==KernelOnly).
The best way to solve it once and for all is to make sure MinimalCoreWin
is always set.
References 313568d0e5.
The main change in 16.7 is the separation of `AppContainerApplication`
into `WindowsStoreApp` and `WindowsAppContainer`. There's been a bit of
interest in splitting packaging away from containment, and this is the
first step in that direction.
We're a somewhat unique application, but as WinUI3 becomes more
prevalent we will become _less_ unique.
Some of these things, I've looked at and wondered how they ever worked.
## PR Checklist
* [x] Closes nothing
## Validation Steps Performed
Built locally and in CI. Tested the generated package with the package tester. Built on 16.6 and seen that it still seems to work.
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.
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
This PR creates a Universal entrypoint for the Windows Terminal solution
in search of our goals to run everywhere, on all Windows platforms.
The Universal entrypoint is relatively straightforward and mostly just
invokes the App without any of the other islands and win32 boilerplate
required for the centennial route. The Universal project is also its own
packaging project all in one and will emit a relevant APPX.
A few things were required to make this work correctly:
* Vcxitems reuse of resources (and link instructions on all of them
for proper pkg layout)
* Move all Terminal project CRT usages to the app ones (and ensure
forwarders are only Nugetted to the Centennial package to not pollute
the Universal one)
* Fix/delay dependencies in `TerminalApp` that are not available in
the core platform (or don't have an appropriate existing platform
forwarder... do a loader snaps check)
* vcpkg needs updating for the Azure connection parser
* font fallbacks because Consolas isn't necessarily there
* fallbacks because there are environments without a window handle
Some of those happened in other small PRs in the past week or two. They
were relevant to this.
Note, this isn't *useful* as such yet. You can run the Terminal in this
context and even get some of the shells to work. But they don't do a
whole lot yet. Scoping which shells appear in the profiles list and only
offering those that contextually make sense is future work.
* Break everything out of App except the base initialization for XAML. AppLogic is the new home.
* deduplicate logics by always using the app one (since it has to be there to support universal launch).
* apparently that was too many cross-boundary calls and we can cache it because winrt objects are magic.
* Put UWP project into solution.
* tabs in titlebar needs disabling from uwp context as the non-client is way different. This adds a method to signal that to logic and apply the setting override.
* Change to use App CRT in preparation for universal.
* Try to make project build again by setting winconpty to static lib so it'll use the CRT inside TerminalConnection (or its other consumers) instead of linking its own.
* Remove test for conpty dll, it's a lib now. Add additional commentary on how CRT linking works for future reference. I'm sure this will come up again.
* This fixes the build error.
* use the _apiset variant until proven otherwise to match the existing one.
* Merge branch 'master' into dev/miniksa/uwp3
* recorrect spacing in cppwinrt.build.pre.props
* Add multiple additional fonts to fallback to. Also, guard for invalid window handle on title update.
* Remove ARMs from solution.
* Share items resources between centennial and universal project.
* cleanup resources and split manifest for dev/release builds.
* Rev entire solution to latest Toolkit (6.0.0 stable release).
* shorten the items file using include patterns
* cleanup this filters file a bit.
* Fix C26445 by using string_view as value, not ref. Don't build Universal in Audit because we're not auditing app yet.
* some PR feedback. document losing the pointer. get rid of 16.3.9 workarounds. improve consistency of variable decl in applogic.h
* Make dev phone product ID not match prod phone ID. Fix universal package identity to match proposed license information.
* Change to use App CRT in preparation for universal.
* Try to make project build again by setting winconpty to static lib so it'll use the CRT inside TerminalConnection (or its other consumers) instead of linking its own.
* Remove test for conpty dll, it's a lib now. Add additional commentary on how CRT linking works for future reference. I'm sure this will come up again.
* use the _apiset variant until proven otherwise to match the existing one.
* Clarification in the comments for linking.
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.
This commit introduces a C++/WinRT utility library and moves
ScopedResourceLoader into it. I decided to get uppity and introduce
something I like to call "checked resources." The idea is that every
resource reference from a library is knowable at compile time, and we
should be able to statically ensure that all resources exist.
This is a system that lets us immediately failfast (on launch) when a
library makes a static reference to a resource that doesn't exist at
runtime.
It exposes two new (preprocessor) APIs:
* `RS_(wchar_t)`: loads a localizable string resource by name.
* `USES_RESOURCE(wchar_t)`: marks a resource key as used, but is intended
for loading images or passing static resource keys as parameters to
functions that will look them up later.
Resource checking relies on diligent use of `USES_RESOURCE()` and `RS_()`
(which uses `USES_RESOURCE`), but can make sure we don't ship something
that'll blow up at runtime.
It works like this:
**IN DEBUG MODE**
- All resource names referenced through `USES_RESOURCE()` are emitted
alongside their referencing filenames and line numbers into a static
section of the binary.
That section is named `.util$res$m`.
- We emit two sentinel values into two different sections, `.util$res$a`
and `.util$res$z`.
- The linker sorts all sections alphabetically before crushing them
together into the final binary.
- When we first construct a library's scoped resource loader, we
iterate over every resource reference between `$a` and `$z` and check
residency.
**IN RELEASE MODE**
- All checked resource code is compiled out.
Fixes#2146.
Macros are the only way to do something this cool, incidentally.
## Validation Steps Performed
Made references to a bunch of bad resources, tried to break it a lot.
It looks like this when it fails:
### App.cpp
```
36 static const std::array<std::wstring_view, 2> settingsLoadErrorsLabels {
37 USES_RESOURCE(L"NoProfilesText"),
38 USES_RESOURCE(L"AllProfilesHiddenText_HA_JUST_KIDDING")
39 };
```
```
WinRTUtils\LibraryResources.cpp(68)\TerminalApp.dll:
FailFast(1) tid(1034) 8000FFFF Catastrophic failure
Msg:[Resource AllProfilesHiddenText_HA_JUST_KIDDING not found in
scope TerminalApp/Resources (App.cpp:38)] [EnsureAllResourcesArePresent]
```
[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)
* Refactors TerminalApp into two projects:
- TerminalAppLib, which builds a .lib, and includes all the code
- TerminalApp, which builds a dll by linking the lib
* Adds a TerminalApp.Unit.Tests project
- Includes the ability to test cppwinrt types we've authored using a SxS manifest for unpackaged winrt activation
- includes the ability to test types with XAML content using an appxmanifest
* Adds a giant doc explaining how this was all done. Really, just go read that doc, it'll really help you understand what's going on in this PR.
-------------------------
These are some previous commit messages. They may be helpful to future readers.
* Start adding unittests for json parsing, end up creating a TerminalAppLib project to make a lib. See #1042
* VS automatically did this for me
* This is a dead end
I tried including the idl-y things into the lib, but that way leads insanity
If you want to make a StaticLibrary, then suddenly the winrt toolchain forgets
that ProjectReferences can have winmd's in them, so it won't be able to
compile any types from the referenced projects. If you instead try to manually
reference the types, you'll get duplicate types up the wazoo, which of course
is insane, since we're referencing them the _one_ time
* Yea just follow #1042 on github for status
So current state:
1. If you try to add a `Reference` to all of MUX.Markup, TerminalControl and
TerminalSettings, then mdmerge will complain about all the types from
TerminalSettings being defined twice. In this magic scenario, the
dependencies of TerminalControl are used directly for some reason:
```
12> Load input metadata file ...OpenConsole\x64\Debug\TerminalSettings\Microsoft.Terminal.Settings.winmd.
12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.Settings.winmd.
12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalConnection.winmd.
12> Load input metadata file ...OpenConsole\x64\Debug\TerminalControl\Microsoft.Terminal.TerminalControl.winmd.
12> Load input metadata file ...OpenConsole\x64\Debug\Microsoft.UI.Xaml.Markup\Microsoft.UI.Xaml.Markup.winmd.
```
2. If you don't add a `Reference` TerminalControl, then it'll complain about
being unable to find the type TitleChangedEventArgs, which is defined in
TerminalControl.
3. If you don't add a `Reference` TerminalSettings, then it'll complain about
being unable to find the type KeyChord and other types from
TerminalSettings. In this scenario, it doesn't recurse on the other
dependencies from TerminalControl for whatever reason.
4. If you instead try to add all 3 as a `ProjectReference`, then it'll
complain about being unable to find TitleChangedEventArgs, as in 2.
Presumably, it;ll have troubles with the other types too, as none of the 3
are actually included in the midlrt.rsp file.
5. If you add all 3 as a `ProjectReference`, then also add TerminalControl as
a `Reference`, you'll get a `MIDL2011: [msg] unresolved type declaration
Microsoft.UI.Xaml.Markup.XamlApplication`
6. If you add all 3 as a `ProjectReference`, then also add TerminalControl AND
MUX.Markup as a `Reference`, you'll get the same result as 3.
* what if we just don't idl
This seems to compile
* This compiles but I broke the MUX resources
look at the App.xaml change. in this changelist. That's what's broken right now. Lets fix that!
* lets do this
If I leave the MUX nuget out of the project, I'll get a compile error in
App.xaml:
```
...OpenConsole\src\cascadia\TerminalApp\App.xaml(21,40): XamlCompiler error WMC0001: Unknown type 'XamlControlsResources' in XML namespace 'using:Microsoft.UI.Xaml.Controls'
```
If I add it back to the project, it works
* Some cleanup from the previous commit
* This is busted again.
Doing a clean build didn't work.
A clean rebuild of the project, paired with some removal of dead code
revealed a problem with what I have so far.
TerminalAppLib depends on the generation of two headers,
`AppKeyBindings.g.h` and `App.g.h`, as those define some of bits of the
winrt types. They're needed to be able to compile the implementations.
Presumably that's not getting generated by the lib project, because the dll
project is the one to generate that file.
So we need to move the idl's to the lib project. This created maddness,
because of course the Duplicate Type thing. The solution to that is to
actually mark the winrt DLLs that we're chaining up through us as
```
<Private>false</Private>
<CopyLocalSatelliteAssemblies>false</CopyLocalSatelliteAssemblies>
```
This will prevent them from getting double-included.
This still doesn't work however, since
```
app.cpp(40): error C2039: 'XamlMetaDataProvider': is not a member of 'winrt::TerminalApp'
error C3861: 'XamlMetaDataProvider': identifier not found
```
So we need to figure that out. The dll project is still generating the right
header, so lets look there.
* Move the xaml stuff to the lib
This compiles, but when we launch, we fail to load the tabviewcontrol
resources again. So that's not what you want. Why is it not included?
* It works again!
* Use the pri, xbf files from TerminalAppLib, not TerminalApp
* Manually make TerminalApp include a reference to TerminalAppLib's
TerminalApp.winmd. This will force the build to copy TerminalApp.winmd to
TerminalApp/, which WindowsTerminal needs to be able to ProjectReference the
TerminalApp project (it's expecting it to have a winmd)
* Remove the module.g.cpp from TerminalApp, and move to TerminalAppLib. The
dll doesn't do any codegen anymore.
* Agressively clean up these files
* Clean up unnecessary includes in the dll pch.h
* This does NOT work.
The WindowsxamlManager call crashes. I'm thinking it has to do with activation
of winrt types from a dll.
Email out to @Austin-Lamb to see if he can assist
* This gets our cppwinrt types working, but xaml islands is still broken
* Split the tests apart, so they aren't insane
* These are the magic words to make xaml islands work
* All this witchcraft is necessary to make XAML+MUX work right
* Clean this up a bit and add comments
* Create an enormous doc explaining this madness
* Unsure how this got changed.
* Trying to get the CI build to work again.
This resolves the MUX issue. We need to manually include it, because their package's target doesn't mark it as CopyLocalSatelliteAssemblies=false, Private=false.
However, the TerminalApp project is still able to magically reason that the TerminalAppLib project should be included in the MdMerge step, because it think's it's a `GetCppWinRTStaticProjectReferences` reference.
* Update cppwinrt to the latest version - this fixes the MSBuild
* I still need to re-add the KeyModifiers checks from TermControl. I think
this update broke `operator&` for that enum.
* There needs to be some cleanup obviously
* The doc should be updated as well
* Clean up changes from cppwinrt update
* Try doing this, even though it seems wrong
* Lets try this (press x to doubt)
* Clean up vcxproj file, and remove appxmanifest change from previous commit
* Update to the latest TAEF release, maybe that'll work
* Let's try a prerelease version, shall we?
* Add notes about TAEF package, comment out tests
* Format the code
* Hopefully fix the arm64 and x86 builds
also a typo
* Fix PR nits
* Fix some bad merge conflicts
* Some cleanup from the merge
* Well I was close to getting the merge right
* I believe this will fix CI
* Apply suggestions from code review
Co-Authored-By: Carlos Zamora <carlos.zamora@microsoft.com>
* These definitely need to be fixed
* Try version detecting in the test
IDK if this will build, I'm letting the CI try while I clean rebuild locally
* Try blindly updating to the newest nuget version
* Revert "Try blindly updating to the newest nuget version"
This reverts commit b72bd9eb73.
* We're just going to see if these work in CI with this change
* Comment the tests back out. Windows Server 2019 is 10.0.17763.557
* Remove the nuget package
We don't need this package anymore now that we're hosting it
* Okay this _was_ important
