Commit Graph

19 Commits

Author SHA1 Message Date
Dustin L. Howett 06526cac0c
Remove our dependency on any CRT--AppX or forwarders (#15097)
The upgrade to Microsoft.UI.Xaml 2.8 was the last piece we needed to
break our dependency on the App CRT *and* any CRT whatsoever.
2023-04-04 16:11:12 -05:00
Dustin L. Howett 2cd280eeef
Move to CppWinRT 2.0.230207.1 (#14869)
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.
2023-02-17 16:19:47 -08:00
Dustin L. Howett 4903cfd484
AzureConnection: remove our dependency on cpprestsdk (#14776)
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.
2023-02-07 15:13:10 -06:00
musvaage d3264964a9
Fix some additional typos (#14671)
Fix spelling errors in code comments and markdown
Closes #14670
2023-01-16 16:17:54 +00:00
Rose 3517a6a3f1
Update scratch projects to XAML 2.7.3 (#14159)
This will let those projects build. I forgot to include them last time for some reason.

See PR #14123
2022-10-07 22:21:15 +00:00
Rose 11ad04754d
Update to XAML 2.7.3 (#14123)
And the prerelease version of it
2022-10-07 00:13:57 +00:00
Mike Griese 7e47f6aab9
Wire up passing LNK/EXE data from OpenCon to ITerminalHandoff (#13570)
This PR by itself doesn't _really_ change much. Technically, now the Terminal will respect the Title of a `.lnk` when started for defterm, but we don't do anything else yet. Primarily, the goal of this PR is to just wire up startup info in OpenConsole to the connected Terminal. 
* This required a bit of changes in `srvinit.cpp:ConsoleEstablishHandoff` to replicate other bits of startup, where we crack open the connect message to get the relevant bits of info.
* We pack that all into a `TERMINAL_STARTUP_INFO`, which we pass along to the registered terminal application.
* `ConptyConnection` accepts the handoff, and gathers that information out of the `TERMINAL_STARTUP_INFO`
* Some other updates to the scratch sln were made to make it build again (related, but unimportant).
* This is a precursor to:
  * #13111
  * #12154
* Closes #9458
* Tested manually
* I work here
2022-08-26 06:16:29 -05:00
Leonard Hecker b0396f1741
Make ToolsVersion more consistent in our project files (#13535)
While working on another PR related to this I noticed that my VS
generates `.vcxproj` files that are a bit different to the ones we have.
This commit is a quick search & replace of all our project files to make
(primarily) their `ToolsVersion` more in line with what VS does itself:
No `ToolsVersion` for `.vcxproj`, `ToolsVersion="15.0"`
for `.csproj` and `ToolsVersion="4.0"` for `.filters` files.
2022-07-26 22:31:42 +00:00
Dustin L. Howett cdffc99f76
Upgrade WinUI2 to 2.7.1 (#12847)
This fixes a number of issues including a NavigationView crash.
2022-04-06 22:23:04 +00:00
Dustin L. Howett 53a454fbd3
build: ship a Win11 build of Terminal that's <=half the size (#12560)
Four (4) squashed changes, with messages preserved.

## release: move symbol publication into its own phase

Right now, symbol publication happens every time we produce a final
bundle. In the future, we may be producing multiple bundles from the
same pipeline run, and we need to make sure we only do *one* symbol
publication to MSDL.

When we do that, it will be advantageous for us to have just one phase
that source-indexes and publishes all of the symbols.

## Remove Terminal's built-in copy of the VC Runtime

This removes the trick we pulled in #5661 and saves us ~550kb per arch.

Some of our dependencies still depend on the "app" versions of the
runtime libraries, so we are going to continue shipping the forwarders
in our package. Build rules have been updated to remove the non-Desktop
VCLibs dependency to slim down our package graph.

This is not a problem on Windows 11 -- it looks like it's shipped inbox.

**BREAKING CHANGE**: When launched unpackaged, Terminal now requires the
vcruntime redist to be installed.

## Prepare for toggling XAML between 2.7.0 and -prerelease on Win11

common.openconsole.props is a pretty good place to stash the XAML
version since it is included in every project (including the WAP
project (unlike the C++ build props!)).

I've gone ahead and added a "double dependency" on multiple XAML
versions. We'll toggle them with a build flag.

## Run the release pipeline twice, for Win10 and Win11, at the same time

This required some changes in how we download artifacts to make sure
that we could control which version of Windows we were processing in any
individual step.

We're also going to patch the package manifest on the Windows 11 version
so the store targets it more specifically.

On top of the prior three steps, this lets us ship a Windows 11
package that costs only ~15MB on disk. The Windows 10 version, for
comparison, is about 40.
2022-02-24 18:09:28 -06:00
Leonard Hecker ddae2a1d49
Remove UTF-8 BOM from all files (#11821)
As VS 2022 doesn't seem to store files with UTF-8 BOM as often anymore, we've
been getting more and more pull requests which seemingly randomly change files.
This cleans the situation up by removing the BOM from all files that have one.
Additionally, `Host.Tests.Feature.rc` was converted from UTF-16 to UTF-8.
2021-11-29 12:54:35 -06:00
Mike Griese 442432ea15
Fixes the wapproj fast-up-to-date check (#11806)
I'm working on making the FastUpToDate check in Vs work for the Terminal project. This is one of a few PRs in this area.

FastUpToDate lets vs check quickly determine that it doesn't need to do anything for a given project. 

However, a few of our projects don't produce all the right artifacts, or check too many things, and this eventually causes the `wapproj` to rebuild, EVERY TIME YOU F5 in VS. 

This third PR deals with the Actual fast up to date check for the CascadiaPackage.wapproj. When #11804, #11805 and this PR are all merged, you should be able to just F5 the Terminal in VS, and then change NOTHING, and F5 it again, without doing a build at all. 




The wapproj `GetResolvedWinMD` target tries to get a winmd from every cppwinrt
executable we put in the package. But we DON'T produce a winmd. This makes the
FastUpToDate check fail every time, and leads to the whole wapproj build
running even if you're just f5'ing the package. EVEN AFTER A SUCCESSFUL BUILD.

Setting GenerateWindowsMetadata=false is enough to tell the build system that
we don't produce one, and get it off our backs.

### teams chat where we figured this out

[3:38 PM] Dustin Howett
however, that's not the only thing that "GetTargetPath" checks.

[3:38 PM] Dustin Howett
oh yeah more info: wapproj calls GetTargetPath on all projects it references

[3:38 PM] Dustin Howett
when it calls GTP on WindowsTerminal.vcxproj it is getting back a winmd (!)


[3:39 PM] Dustin Howett
here's the magic

[3:39 PM] Dustin Howett
![image](https://user-images.githubusercontent.com/18356694/142945542-74734836-20d8-4f50-bf3a-be4e1170ae13.png)


[3:39 PM] Dustin Howett
it checks if any Link items specify GenerateWindowsMetadata

![image](https://user-images.githubusercontent.com/18356694/142945593-fd232243-0175-4653-8c34-cdc364a16031.png)
2021-11-23 11:22:56 +00:00
Mike Griese cfe14e8711
Update to MUX 2.7 (#11240)
* this is the same thing as #10996, but with the fix that caused us to #11031  
* This includes https://github.com/microsoft/microsoft-ui-xaml/pull/3769, so we had to make some adjustments to how we handle tab colors. It works the same as before.
* Should enable #11231 to be started
* [x] Closes #10508
* [x] Closes #7133
* [x] Closes #8948
* [ ] I need to finish letting my 19H1 VM boot to make sure unpackaged still works
2021-09-20 22:08:55 +00:00
Dustin L. Howett 3d7480e9b7
Upgrade to C++/WinRT 2.0.210825.3 (#11188)
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.
2021-09-10 21:33:13 +00:00
Dustin L. Howett f3cc4c0328
Revert "Upgrade to Microsoft.UI.Xaml 2.6.2 (or equivalent) (#10996)" (#11031)
The upgrade to 2.6 revealed #11003 and Microsoft/microsoft-ui-xaml#5435, and is impeding
progress on PGO.

This reverts commit cfdf03c24b.
Reverts microsoft/terminal#10996
2021-08-24 17:46:12 -05:00
Dustin L. Howett cfdf03c24b
Upgrade to Microsoft.UI.Xaml 2.6.2 (or equivalent) (#10996)
This commit moves us from MUX 2.5 to MUX 2.6. I have temporarily
disabled the new control styles in `TerminalApp\App.xaml` by setting
`ControlsResourcesVersion` to `Version1`. There is no significant expected
visual impact.

Closes #10508
2021-08-20 20:41:03 +00:00
Dustin L. Howett e37fd5e546
Update Xaml Toolkit App Host to 6.1.3 (#10640)
This is required for some inbox compliance tasks regarding symbol availability.
2021-07-12 22:58:02 +00:00
Alexander Sklar 8c00dd7d55
Update WindowExe.manifest (#10499)
Closes #10480
2021-06-23 17:59:07 +00:00
Mike Griese fe283fc28b Add a Scratch.sln for prototyping (#10067)
#### ⚠️ This targets #10051

## Summary of the Pull Request

This PR creates a `Samples` solution which can be used for quickly testing our particular WinUI + Xaml Islands + wapproj setup, with a `TermControl`. This lets us quickly prototype and minimally repro xaml islands bugs, but also lets us iterate quickly on changes in the process model. I'll be using this in the future to prove that the out-of-proc control works (for tear-out), without having to tear up the entire `TerminalApp` all at once.

While I'll be leaning on this extensively for tear-out prototyping, I've also found myself wanting this kind of sample sln many times in the past. We run into bugs all the time where we're not sure if they're XAML Islands bugs or Terminal bugs. However, standing up a scratch sln with MUX hooked up, and a `XamlApplication` from the toolkit, and XAML Islands is time consuming. This sample sln should let us validate if bugs are XI bugs or Terminal bugs much easier.

## References
* Tear-out: #1256
* Megathread: #5000
* Project: https://github.com/microsoft/terminal/projects/5

## PR Checklist
* [x] Closes one bullet point of https://github.com/microsoft/terminal/projects/5#card-50760312
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated

## Detailed Description of the Pull Request / Additional comments

This is _largely_ a copy-pasta of our existing projects, in massively simplified form. I'm gonna wontfix most comments on the code that was copy-pasta'd. If it's bad here, it's probably also bad in the real version in `OpenConsole.sln`.

* I made an entirely new `.sln` for this, so that these samples wouldn't need to build in CI. They're not critical code, they're literally just for prototyping.
* `TerminalAppLib` & `TerminalApp` became `SampleAppLib` and `SampleApp`. This is just a simple application hosting a single `TermControl`. It references the winmds and dlls from the main `OpenConsole.sln`, but in a way that would be more like a project consuming a nuget feed of the control, rather than a `ProjectReference`.
  - It still does all the `App.xaml` and `Toolkit.XamlApplication` stuff that TerminalApp does, so that it can load MUX resources, and do MUX-y things.
* `WindowsTerminal` became `WindowExe`. I tore out all of the `NonClientIslandWindow` stuff - this is just a window with a xaml island.
* `CascadiaPackage` became `Package`. It does the vclibs hack again for the `TerminalConnection` dlls (because this package can't actually determine that `TerminalConnection.dll` requires `cprest*.dll`), as well as for `windowsterminal.exe` (which we'll need in the future for out-of-proc controls). I got rid of all the Dev/Preview/Release asset machinations as well.

Wherever possible, I changed filenames slightly so that they won't get accitdentally opened when someone tries to open a file by name in their editor (**cough** sublime's <kbd>ctrl+p</kbd> menu **cough**).

## Validation Steps Performed

The sample app launches, and displays a TermControl. What else do you want? <sup>(_rhetorical, not a prompt for a wishlist_)</sup>

(cherry picked from commit 30d6cf4839fca8ac8203f6c2489b02a4088b851e)
2021-06-10 12:56:47 -05:00