maxmustermann
/
terminal
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
terminal/OpenConsole.sln

3489 lines
274 KiB
Plaintext
Raw Permalink Normal View History

Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00

Microsoft Visual Studio Solution File, Format Version 12.00
Apply a GDI region to the top level Island window to allow dragging with a single Island (#929) * Use a region to cut off the dragable region * Use proper measurements for the draggable area * Working better, paint works most of the time * Fix a bug where paint is incomplete when double clicking the dragbar * Remove old fork on XamlApplication * Upgrade to XamlApp preview6.2 * Add Microsoft.VCRTForwarders to make it easy to dogfood Co-Authored-By: Michael Niksa <miniksa@microsoft.com> Co-Authored-By: Mike Griese <migrie@microsoft.com>
2019-06-25 22:06:11 +02:00
# Visual Studio Version 16
VisualStudioVersion = 16.0.29001.49
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
MinimumVisualStudioVersion = 10.0.40219.1
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Terminal", "Terminal", "{59840756-302F-44DF-AA47-441A9D673202}"
EndProject
Project("{C7167F0D-BC9F-4E6E-AFE1-012C56B48DB5}") = "CascadiaPackage", "src\cascadia\CascadiaPackage\CascadiaPackage.wapproj", "{CA5CAD1A-224A-4171-B13A-F16E576FDD12}"
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
ProjectSection(ProjectDependencies) = postProject
{F2ED628A-DB22-446F-A081-4CC845B51A2B} = {F2ED628A-DB22-446F-A081-4CC845B51A2B}
EndProjectSection
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
EndProject
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.EXE", "src\host\exe\Host.EXE.vcxproj", "{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}"
ProjectSection(ProjectDependencies) = postProject
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF} = {71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714} = {0CF235BD-2DA0-407E-90EE-C467E8BBC714}
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239} = {5D23E8E1-3C64-4CC1-A8F7-6861677F7239}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "PropertiesLibrary", "src\propslib\propslib.vcxproj", "{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "_Dependencies", "_Dependencies", "{81C352DB-1818-45B7-A284-18E259F1CC87}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "wil", "wil", "{4C8E6BB0-4713-4ADB-BD04-81628ECEAF20}"
ProjectSection(SolutionItems) = preProject
dep\wil\include\wil\common.h = dep\wil\include\wil\common.h
dep\wil\include\wil\filesystem.h = dep\wil\include\wil\filesystem.h
dep\wil\include\wil\functional.h = dep\wil\include\wil\functional.h
dep\wil\include\wil\registry.h = dep\wil\include\wil\registry.h
dep\wil\include\wil\resource.h = dep\wil\include\wil\resource.h
dep\wil\include\wil\result.h = dep\wil\include\wil\result.h
dep\wil\include\wil\resultmacros.h = dep\wil\include\wil\resultmacros.h
dep\wil\include\wil\stl.h = dep\wil\include\wil\stl.h
dep\wil\include\wil\win32helpers.h = dep\wil\include\wil\win32helpers.h
dep\wil\include\wil\wistd_functional.h = dep\wil\include\wil\wistd_functional.h
dep\wil\include\wil\wistd_memory.h = dep\wil\include\wil\wistd_memory.h
dep\wil\include\wil\wistd_type_traits.h = dep\wil\include\wil\wistd_type_traits.h
EndProjectSection
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Console", "Console", "{D57841D1-8294-4F2B-BB8B-D2A35738DECD}"
ProjectSection(SolutionItems) = preProject
dep\Console\winconp.h = dep\Console\winconp.h
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TextServicesFramework", "src\tsf\tsf.vcxproj", "{2FD12FBB-1DDB-46D8-B818-1023C624CACA}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalParser", "src\terminal\parser\lib\parser.vcxproj", "{3AE13314-1939-4DFA-9C14-38CA0834050C}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalAdapter", "src\terminal\adapter\lib\adapter.vcxproj", "{DCF55140-EF6A-4736-A403-957E4F7430BB}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalInput", "src\terminal\input\lib\terminalinput.vcxproj", "{1CF55140-EF6A-4736-A403-957E4F7430BB}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererBase", "src\renderer\base\lib\base.vcxproj", "{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererGdi", "src\renderer\gdi\lib\gdi.vcxproj", "{1C959542-BAC2-4E55-9A6D-13251914CBB9}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host", "src\host\lib\hostlib.vcxproj", "{06EC74CB-9A12-429C-B551-8562EC954746}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF} = {71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714} = {0CF235BD-2DA0-407E-90EE-C467E8BBC714}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.unittest", "src\host\ut_lib\host.unittest.vcxproj", "{06EC74CB-9A12-429C-B551-8562EC954747}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
Make sure we terminate the expected title string (#10711) When you use the size parameter to WideCharToMultiByte, it only null-terminates the output string if the input string was null-terminated within the specified range. Burned in for 1k runs- BEFORE Summary: Total=1000, Passed=997, Failed=3 AFTER Summary: Total=1000, Passed=1000, Failed=0 Fixes MSFT-34656993
2021-07-20 16:04:53 +02:00
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF} = {71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.Tests.Unit", "src\host\ut_host\Host.UnitTests.vcxproj", "{531C23E7-4B76-4C08-8AAD-04164CB628C9}"
ProjectSection(ProjectDependencies) = postProject
{0CF235BD-2DA0-407E-90EE-C467E8BBC714} = {0CF235BD-2DA0-407E-90EE-C467E8BBC714}
{06EC74CB-9A12-429C-B551-8562EC954747} = {06EC74CB-9A12-429C-B551-8562EC954747}
EndProjectSection
EndProject
Turn on Text Buffer unit tests in Azure DevOps CI build (#1057) * rename TextBuffer.UnitTests.dll -> TextBuffer.Unit.Tests.dll * renamed the project file as well
2019-05-30 04:51:17 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TextBuffer.Unit.Tests", "src\buffer\out\ut_textbuffer\TextBuffer.Unit.Tests.vcxproj", "{531C23E7-4B76-4C08-8BBD-04164CB628C9}"
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
ProjectSection(ProjectDependencies) = postProject
{0CF235BD-2DA0-407E-90EE-C467E8BBC714} = {0CF235BD-2DA0-407E-90EE-C467E8BBC714}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.Tests.Feature", "src\host\ft_host\Host.FeatureTests.vcxproj", "{8CDB8850-7484-4EC7-B45B-181F85B2EE54}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
{FC802440-AD6A-4919-8F2C-7701F2B38D79} = {FC802440-AD6A-4919-8F2C-7701F2B38D79}
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A} = {58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B} = {9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalParser.UnitTests", "src\terminal\parser\ut_parser\Parser.UnitTests.vcxproj", "{12144E07-FE63-4D33-9231-748B8D8C3792}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalAdapter.UnitTests", "src\terminal\adapter\ut_adapter\Adapter.UnitTests.vcxproj", "{6AF01638-84CF-4B65-9870-484DFFCAC772}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalParser.Fuzzer", "src\terminal\parser\ft_fuzzer\VTCommandFuzzer.vcxproj", "{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalParser.FuzzWrapper", "src\terminal\parser\ft_fuzzwrapper\FuzzWrapper.vcxproj", "{F210A4AE-E02A-4BFC-80BB-F50A672FE763}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Propsheet.DLL", "src\propsheet\propsheet.vcxproj", "{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "_Build Common", "_Build Common", "{04170EEF-983A-4195-BFEF-2321E5E38A1E}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Server", "src\server\lib\server.vcxproj", "{18D09A24-8240-42D6-8CB6-236EEE820262}"
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
ProjectSection(ProjectDependencies) = postProject
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF} = {71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}
EndProjectSection
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Host.Tests.UIA", "src\host\ft_uia\Host.Tests.UIA.csproj", "{C17E1BF3-9D34-4779-9458-A8EF98CC5662}"
ProjectSection(ProjectDependencies) = postProject
{099193A0-1E43-4BBC-BA7F-7B351E1342DF} = {099193A0-1E43-4BBC-BA7F-7B351E1342DF}
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB} = {C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B} = {9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}
EndProjectSection
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "VTApp", "src\tools\vtapp\VTApp.csproj", "{099193A0-1E43-4BBC-BA7F-7B351E1342DF}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "_Tools", "_Tools", "{A10C4720-DCA4-4640-9749-67F4314F527C}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Nihilist", "src\tools\nihilist\Nihilist.vcxproj", "{FC802440-AD6A-4919-8F2C-7701F2B38D79}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "FontList", "src\tools\fontlist\FontList.vcxproj", "{919544AC-D39B-463F-8414-3C3C67CF727C}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Scratch", "src\tools\scratch\Scratch.vcxproj", "{ED82003F-FC5D-4E94-8B36-F480018ED064}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InteractivityWin32", "src\interactivity\win32\lib\win32.LIB.vcxproj", "{06EC74CB-9A12-429C-B551-8532EC964726}"
ProjectSection(ProjectDependencies) = postProject
{1C959542-BAC2-4E55-9A6D-13251914CBB9} = {1C959542-BAC2-4E55-9A6D-13251914CBB9}
{990F2657-8580-4828-943F-5DD657D11842} = {990F2657-8580-4828-943F-5DD657D11842}
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F} = {AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "buffersize", "src\tools\buffersize\buffersize.vcxproj", "{ED82003F-FC5D-4E94-8B47-F480018ED064}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InteractivityBase", "src\interactivity\base\lib\InteractivityBase.vcxproj", "{06EC74CB-9A12-429C-B551-8562EC964846}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Interactivity.Win32.Tests.Unit", "src\interactivity\win32\ut_interactivity_win32\Interactivity.Win32.UnitTests.vcxproj", "{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}"
ProjectSection(ProjectDependencies) = postProject
{990F2657-8580-4828-943F-5DD657D11842} = {990F2657-8580-4828-943F-5DD657D11842}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "CloseTest", "src\tools\closetest\CloseTest.vcxproj", "{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererVt", "src\renderer\vt\lib\vt.vcxproj", "{990F2657-8580-4828-943F-5DD657D11842}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "VtPipeTerm", "src\tools\vtpipeterm\VtPipeTerm.vcxproj", "{814DBDDE-894E-4327-A6E1-740504850098}"
The InputStateMachine should dispatch Intermediate characters (#1267) The OutputStateMachine needs to collect "Intermediate" characters to be able to call [`Designate G0 Character Set`](https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Controls-beginning-with-ESC) (as well as other sequences we don't yet support). However, the InputStateMachine used by conpty to process input should _not_ collect these characters. The input engine uses `\x1b` as an indicator that a key was pressed with `Alt`. For keys like `/`, we want to dispatch the key immediately, instead of collecting it and leaving us in the Escape state.
2019-06-14 21:48:12 +02:00
ProjectSection(ProjectDependencies) = postProject
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B} = {9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}
EndProjectSection
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ConEchoKey", "src\tools\echokey\ConEchoKey.vcxproj", "{814CBEEE-894E-4327-A6E1-740504850098}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Types", "src\types\lib\types.vcxproj", "{18D09A24-8240-42D6-8CB6-236EEE820263}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererVt.unittest", "src\renderer\vt\ut_lib\vt.unittest.vcxproj", "{990F2657-8580-4828-943F-5DD657D11843}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "BufferOut", "src\buffer\out\lib\bufferout.vcxproj", "{0CF235BD-2DA0-407E-90EE-C467E8BBC714}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererDx", "src\renderer\dx\lib\dx.vcxproj", "{48D21369-3D7B-4431-9967-24E81292CF62}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalConnection", "src\cascadia\TerminalConnection\TerminalConnection.vcxproj", "{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}"
Make TerminalConnection depend on OpenConsoleProxy (#9649) Building code merged with `main` this morning, and I hit a error where the `TerminalConnection` project needed `ITerminalHandoff` something or other, but that hadn't been built yet. I suspect that's because the `OpenConsoleProxy` project needs to be built first, but it isn't set as a dependency. I suspect once that project is built once, this isn't ever an issue, but I hadn't done that yet. This fixed the build for me locally. * [x] fixes local dev builds * [x] also updates the name of the TerminalControl project in the .sln, because apparently VS didn't like that.
2021-03-29 18:57:18 +02:00
ProjectSection(ProjectDependencies) = postProject
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF} = {71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}
EndProjectSection
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalCore", "src\cascadia\TerminalCore\lib\TerminalCore-lib.vcxproj", "{CA5CAD1A-ABCD-429C-B551-8562EC954746}"
EndProject
Make TerminalConnection depend on OpenConsoleProxy (#9649) Building code merged with `main` this morning, and I hit a error where the `TerminalConnection` project needed `ITerminalHandoff` something or other, but that hadn't been built yet. I suspect that's because the `OpenConsoleProxy` project needs to be built first, but it isn't set as a dependency. I suspect once that project is built once, this isn't ever an issue, but I hadn't done that yet. This fixed the build for me locally. * [x] fixes local dev builds * [x] also updates the name of the TerminalControl project in the .sln, because apparently VS didn't like that.
2021-03-29 18:57:18 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.Terminal.Control.Lib", "src\cascadia\TerminalControl\TerminalControlLib.vcxproj", "{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}"
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B} = {CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}
{CA5CAD1A-ABCD-429C-B551-8562EC954746} = {CA5CAD1A-ABCD-429C-B551-8562EC954746}
{1CF55140-EF6A-4736-A403-957E4F7430BB} = {1CF55140-EF6A-4736-A403-957E4F7430BB}
Split `TermControl` into a Core, Interactivity, and Control layer (#9820) ## Summary of the Pull Request Brace yourselves, it's finally here. This PR does the dirty work of splitting the monolithic `TermControl` into three components. These components are: * `ControlCore`: This encapsulates the `Terminal` instance, the `DxEngine` and `Renderer`, and the `Connection`. This is intended to everything that someone might need to stand up a terminal instance in a control, but without any regard for how the UX works. * `ControlInteractivity`: This is a wrapper for the `ControlCore`, which holds the logic for things like double-click, right click copy/paste, selection, etc. This is intended to be a UI framework-independent abstraction. The methods this layer exposes can be called the same from both the WinUI TermControl and the WPF control. * `TermControl`: This is the UWP control. It's got a Core and Interactivity inside it, which it uses for the actual logic of the terminal itself. TermControl's main responsibility is now By splitting into smaller pieces, it will enable us to * write unit tests for the `Core` and `Interactivity` bits, which we desparately need * Combine `ControlCore` and `ControlInteractivity` in an out-of-proc core process in the future, to enable tab tearout. However, we're not doing that work quite yet. There's still lots of work to be done to enable that, thought this is likely the biggest portion. Ideally, this would just be methods moved wholesale from one file to another. Unfortunately, there are a bunch of cases where that didn't work as well as expected. Especially when trying to better enforce the boundary between the classes. We've got a couple tests here that I've added. These are partially examples, and partially things I ran into while implementing this. A bunch of things from #7001 can go in now that we have this. This PR is gonna be a huge pain to review - 38 files with 3,730 additions and 1,661 deletions is nothing to scoff at. It will also conflict 100% with anything that's targeting `TermControl`. I'm hoping we can review this over the course of the next week and just be done with it, and leave plenty of runway for 1.9 bugs in post. ## References * In pursuit of #1256 * Proc Model: #5000 * https://github.com/microsoft/terminal/projects/5 ## PR Checklist * [x] Closes #6842 * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760249 * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760258 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments * I don't love the names `ControlCore` and `ControlInteractivity`. Open to other names. * I added a `ICoreState` interface for "properties that come from the `ControlCore`, but consumers of the `TermControl` need to know". In the future, these will all need to be handled specially, because they might involve an RPC call to retrieve the info from the core (or cache it) in the window process. * I've added more `EventArgs` to make more events proper `TypedEvent`s. * I've changed how the TerminalApp layer requests updated TaskbarProgress state. It doesn't need to pump TermControl to raise a new event anymore. * ~~Something that snuck into this branch in the very long history is the switch to `DCompositionCreateSurfaceHandle` for the `DxEngine`. @miniksa wrote this originally in 30b8335, I'm just finally committing it here. We'll need that in the future for the out-of-proc stuff.~~ * I reverted this in c113b65d9. We can revert _that_ commit when we want to come back to it. * I've changed the acrylic handler a decent amount. But added tests! * All the `ThrottledFunc` things are left in `TermControl`. Some might be able to move down into core/interactivity, but once we figure out how to use a different kind of Dispatcher (because a UI thread won't necessarily exist for those components). * I've undoubtably messed up the merging of the locking around the appearance config stuff recently ## Validation Steps Performed I've got a rolling list in https://github.com/microsoft/terminal/issues/6842#issuecomment-810990460 that I'm updating as I go.
2021-04-27 17:50:45 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62} = {48D21369-3D7B-4431-9967-24E81292CF62}
Hey look the TermControl needs to depend on the UIA renderer (#3983) We unintentionally broke the build in #2930. If you're building the entire solution, then you won't have any problems, because the `UiaRenderer` project will get built before the `TerminalControl`. However, if you're like me and you only really build the solution one project at a time, you'll find that building `TerminalControl` won't build `UiaRenderer` automagically. This fixes that. s/o to @Rrogntudju for catching this
2019-12-17 19:16:26 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63} = {48D21369-3D7B-4431-9967-24E81292CF63}
Split `TermControl` into a Core, Interactivity, and Control layer (#9820) ## Summary of the Pull Request Brace yourselves, it's finally here. This PR does the dirty work of splitting the monolithic `TermControl` into three components. These components are: * `ControlCore`: This encapsulates the `Terminal` instance, the `DxEngine` and `Renderer`, and the `Connection`. This is intended to everything that someone might need to stand up a terminal instance in a control, but without any regard for how the UX works. * `ControlInteractivity`: This is a wrapper for the `ControlCore`, which holds the logic for things like double-click, right click copy/paste, selection, etc. This is intended to be a UI framework-independent abstraction. The methods this layer exposes can be called the same from both the WinUI TermControl and the WPF control. * `TermControl`: This is the UWP control. It's got a Core and Interactivity inside it, which it uses for the actual logic of the terminal itself. TermControl's main responsibility is now By splitting into smaller pieces, it will enable us to * write unit tests for the `Core` and `Interactivity` bits, which we desparately need * Combine `ControlCore` and `ControlInteractivity` in an out-of-proc core process in the future, to enable tab tearout. However, we're not doing that work quite yet. There's still lots of work to be done to enable that, thought this is likely the biggest portion. Ideally, this would just be methods moved wholesale from one file to another. Unfortunately, there are a bunch of cases where that didn't work as well as expected. Especially when trying to better enforce the boundary between the classes. We've got a couple tests here that I've added. These are partially examples, and partially things I ran into while implementing this. A bunch of things from #7001 can go in now that we have this. This PR is gonna be a huge pain to review - 38 files with 3,730 additions and 1,661 deletions is nothing to scoff at. It will also conflict 100% with anything that's targeting `TermControl`. I'm hoping we can review this over the course of the next week and just be done with it, and leave plenty of runway for 1.9 bugs in post. ## References * In pursuit of #1256 * Proc Model: #5000 * https://github.com/microsoft/terminal/projects/5 ## PR Checklist * [x] Closes #6842 * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760249 * [x] Closes https://github.com/microsoft/terminal/projects/5#card-50760258 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments * I don't love the names `ControlCore` and `ControlInteractivity`. Open to other names. * I added a `ICoreState` interface for "properties that come from the `ControlCore`, but consumers of the `TermControl` need to know". In the future, these will all need to be handled specially, because they might involve an RPC call to retrieve the info from the core (or cache it) in the window process. * I've added more `EventArgs` to make more events proper `TypedEvent`s. * I've changed how the TerminalApp layer requests updated TaskbarProgress state. It doesn't need to pump TermControl to raise a new event anymore. * ~~Something that snuck into this branch in the very long history is the switch to `DCompositionCreateSurfaceHandle` for the `DxEngine`. @miniksa wrote this originally in 30b8335, I'm just finally committing it here. We'll need that in the future for the out-of-proc stuff.~~ * I reverted this in c113b65d9. We can revert _that_ commit when we want to come back to it. * I've changed the acrylic handler a decent amount. But added tests! * All the `ThrottledFunc` things are left in `TermControl`. Some might be able to move down into core/interactivity, but once we figure out how to use a different kind of Dispatcher (because a UI thread won't necessarily exist for those components). * I've undoubtably messed up the merging of the locking around the appearance config stuff recently ## Validation Steps Performed I've got a rolling list in https://github.com/microsoft/terminal/issues/6842#issuecomment-810990460 that I'm updating as I go.
2021-04-27 17:50:45 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F} = {AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndProjectSection
EndProject
Make TerminalConnection depend on OpenConsoleProxy (#9649) Building code merged with `main` this morning, and I hit a error where the `TerminalConnection` project needed `ITerminalHandoff` something or other, but that hadn't been built yet. I suspect that's because the `OpenConsoleProxy` project needs to be built first, but it isn't set as a dependency. I suspect once that project is built once, this isn't ever an issue, but I hadn't done that yet. This fixed the build for me locally. * [x] fixes local dev builds * [x] also updates the name of the TerminalControl project in the .sln, because apparently VS didn't like that.
2021-03-29 18:57:18 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.Terminal.Control", "src\cascadia\TerminalControl\dll\TerminalControl.vcxproj", "{CA5CAD1A-F542-4635-A069-7CAEFB930070}"
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}
EndProjectSection
EndProject
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WindowsTerminal", "src\cascadia\WindowsTerminal\WindowsTerminal.vcxproj", "{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}"
ProjectSection(ProjectDependencies) = postProject
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
{CA5CAD1A-F542-4635-A069-7CAEFB930070} = {CA5CAD1A-F542-4635-A069-7CAEFB930070}
Make TerminalConnection depend on OpenConsoleProxy (#9649) Building code merged with `main` this morning, and I hit a error where the `TerminalConnection` project needed `ITerminalHandoff` something or other, but that hadn't been built yet. I suspect that's because the `OpenConsoleProxy` project needs to be built first, but it isn't set as a dependency. I suspect once that project is built once, this isn't ever an issue, but I hadn't done that yet. This fixed the build for me locally. * [x] fixes local dev builds * [x] also updates the name of the TerminalControl project in the .sln, because apparently VS didn't like that.
2021-03-29 18:57:18 +02:00
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32} = {CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12} = {CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}
{CA5CAD1A-ABCD-429C-B551-8562EC954746} = {CA5CAD1A-ABCD-429C-B551-8562EC954746}
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE} = {27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B} = {9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}
EndProjectSection
EndProject
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalApp", "src\cascadia\TerminalApp\dll\TerminalApp.vcxproj", "{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}"
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
ProjectSection(ProjectDependencies) = postProject
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {CA5CAD1A-9A12-429C-B551-8562EC954746}
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-082C-4476-9F33-94B339494076} = {CA5CAD1A-082C-4476-9F33-94B339494076}
Make TerminalConnection depend on OpenConsoleProxy (#9649) Building code merged with `main` this morning, and I hit a error where the `TerminalConnection` project needed `ITerminalHandoff` something or other, but that hadn't been built yet. I suspect that's because the `OpenConsoleProxy` project needs to be built first, but it isn't set as a dependency. I suspect once that project is built once, this isn't ever an issue, but I hadn't done that yet. This fixed the build for me locally. * [x] fixes local dev builds * [x] also updates the name of the TerminalControl project in the .sln, because apparently VS didn't like that.
2021-03-29 18:57:18 +02:00
{CA5CAD1A-F542-4635-A069-7CAEFB930070} = {CA5CAD1A-F542-4635-A069-7CAEFB930070}
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32} = {CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B} = {CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}
EndProjectSection
EndProject
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WindowsTerminalShellExt", "src\cascadia\ShellExtension\WindowsTerminalShellExt.vcxproj", "{F2ED628A-DB22-446F-A081-4CC845B51A2B}"
EndProject
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "UnitTests_TerminalCore", "src\cascadia\UnitTests_TerminalCore\UnitTests.vcxproj", "{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}"
Fix the `UnitTests_TerminalCore`'s dependency on `RendererGdi` (#4319) ## Summary of the Pull Request In #4213 I added a dependency to the `UnitTests_TerminalCore` project on basically all of conhost. This _worked on my machine_, but it's consistently not working on other machines. This should fix those issues. ## References ## PR Checklist * [x] Closes #4285 * [x] I work here * [n/a] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed Made a fresh clone and built it.
2020-01-22 22:30:53 +01:00
ProjectSection(ProjectDependencies) = postProject
{06EC74CB-9A12-429C-B551-8562EC954747} = {06EC74CB-9A12-429C-B551-8562EC954747}
EndProjectSection
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Internal", "src\internal\internal.vcxproj", "{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "gsl", "gsl", "{16376381-CE22-42BE-B667-C6B35007008D}"
ProjectSection(SolutionItems) = preProject
dep\gsl\include\gsl\gsl = dep\gsl\include\gsl\gsl
dep\gsl\include\gsl\gsl_algorithm = dep\gsl\include\gsl\gsl_algorithm
dep\gsl\include\gsl\gsl_assert = dep\gsl\include\gsl\gsl_assert
dep\gsl\include\gsl\gsl_byte = dep\gsl\include\gsl\gsl_byte
dep\gsl\include\gsl\gsl_util = dep\gsl\include\gsl\gsl_util
dep\gsl\include\gsl\multi_span = dep\gsl\include\gsl\multi_span
dep\gsl\include\gsl\pointers = dep\gsl\include\gsl\pointers
dep\gsl\include\gsl\span = dep\gsl\include\gsl\span
dep\gsl\include\gsl\string_span = dep\gsl\include\gsl\string_span
EndProjectSection
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Virtual Terminal", "Virtual Terminal", "{F1995847-4AE5-479A-BBAF-382E51A63532}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Rendering", "Rendering", "{05500DEF-2294-41E3-AF9A-24E580B82836}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Conhost", "Conhost", "{E8F24881-5E37-4362-B191-A3BA0ED7F4EB}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Buffer", "Buffer", "{1E4A062E-293B-4817-B20D-BF16B979E350}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Shared", "Shared", "{89CDCC5C-9F53-4054-97A4-639D99F169CD}"
EndProject
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Types.Unit.Tests", "src\types\ut_types\Types.Unit.Tests.vcxproj", "{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}"
EndProject
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "PublicTerminalCore", "src\cascadia\PublicTerminalCore\PublicTerminalCore.vcxproj", "{84848BFA-931D-42CE-9ADF-01EE54DE7890}"
EndProject
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WpfTerminalControl", "src\cascadia\WpfTerminalControl\WpfTerminalControl.csproj", "{376FE273-6B84-4EB5-8B30-8DE9D21B022C}"
EndProject
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "UnitTests_TerminalApp", "src\cascadia\ut_app\TerminalApp.UnitTests.vcxproj", "{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {CA5CAD1A-9A12-429C-B551-8562EC954746}
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
EndProjectSection
EndProject
Fix intellisense errors by moving TerminalApp projects around (#6897) The easiest fix was actually just moving all the source files from `TerminalApp` to `TerminalApp/lib`, where the appropriate `pch.h` actually resides. Closes #6866
2020-08-21 00:44:37 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalAppLib", "src\cascadia\TerminalApp\TerminalAppLib.vcxproj", "{CA5CAD1A-9A12-429C-B551-8562EC954746}"
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
ProjectSection(ProjectDependencies) = postProject
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-082C-4476-9F33-94B339494076} = {CA5CAD1A-082C-4476-9F33-94B339494076}
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
{CA5CAD1A-F542-4635-A069-7CAEFB930070} = {CA5CAD1A-F542-4635-A069-7CAEFB930070}
Make TerminalConnection depend on OpenConsoleProxy (#9649) Building code merged with `main` this morning, and I hit a error where the `TerminalConnection` project needed `ITerminalHandoff` something or other, but that hadn't been built yet. I suspect that's because the `OpenConsoleProxy` project needs to be built first, but it isn't set as a dependency. I suspect once that project is built once, this isn't ever an issue, but I hadn't done that yet. This fixed the build for me locally. * [x] fixes local dev builds * [x] also updates the name of the TerminalControl project in the .sln, because apparently VS didn't like that.
2021-03-29 18:57:18 +02:00
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32} = {CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
EndProjectSection
EndProject
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "LocalTests_TerminalApp", "src\cascadia\LocalTests_TerminalApp\TerminalApp.LocalTests.vcxproj", "{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {CA5CAD1A-9A12-429C-B551-8562EC954746}
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-082C-4476-9F33-94B339494076} = {CA5CAD1A-082C-4476-9F33-94B339494076}
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12} = {CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
EndProjectSection
EndProject
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererUia", "src\renderer\uia\lib\uia.vcxproj", "{48D21369-3D7B-4431-9967-24E81292CF63}"
EndProject
Introduce a WinRT utils library and "checked resources" (#3350) 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] ```
2019-11-01 23:47:05 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WinRTUtils", "src\cascadia\WinRTUtils\WinRTUtils.vcxproj", "{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}"
EndProject
Introduce a Universal package for Windows Terminal (#3236) 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.
2019-11-26 01:30:45 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "WindowsTerminalUniversal", "src\cascadia\WindowsTerminalUniversal\WindowsTerminalUniversal.vcxproj", "{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}"
EndProject
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "winconpty.LIB", "src\winconpty\lib\winconptylib.vcxproj", "{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "winconpty.DLL", "src\winconpty\dll\winconptydll.vcxproj", "{A22EC5F6-7851-4B88-AC52-47249D437A52}"
EndProject
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TestHostApp", "src\cascadia\LocalTests_TerminalApp\TestHostApp\TestHostApp.vcxproj", "{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506} = {CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-082C-4476-9F33-94B339494076} = {CA5CAD1A-082C-4476-9F33-94B339494076}
{CA5CAD1A-9B68-456A-B13E-C8218070DC42} = {CA5CAD1A-9B68-456A-B13E-C8218070DC42}
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
EndProjectSection
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Tests", "Tests", "{BDB237B6-1D1D-400F-84CC-40A58FA59C8E}"
EndProject
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "til.unit.tests", "src\til\ut_til\til.unit.tests.vcxproj", "{767268EE-174A-46FE-96F0-EEE698A1BBC9}"
EndProject
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "U8U16Test", "src\tools\U8U16Test\U8U16Test.vcxproj", "{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}"
EndProject
Move tests to invoke `te.exe` directly instead of using VSTest runner (#4490) Moves the tests from using the `vstest.console.exe` route to just using `te.exe`. PROs: - `te.exe` is significantly faster for running tests because the TAEF/VSTest adapter isn't great. - Running through `te.exe` is closer to what our developers are doing on their dev boxes - `te.exe` is how they run in the Windows gates. - `te.exe` doesn't seem to have the sporadic `0x6` error code thrown during the tests where somehow the console handles get lost - `te.exe` doesn't seem to repro the other intermittent issues that we have been having that are inscrutable. - Fewer processes in the tree (te is running anyway under `vstest.console.exe`, just indirected a lot - The log outputs scroll live with all our logging messages instead of suppressing everything until there's a failure - The log output is actually in the order things are happening versus vstest. CONs: - No more code coverage. - No more test records in the ADO build/test panel. - Tests really won't work inside Visual Studio at all. - The log files are really big now - Testing is not a test task anymore, just another script. Refuting each CON: - We didn't read the code coverage numbers - We didn't look at the ADO test panel results or build-over-build velocities - Tests didn't really work inside Visual Studio anyway unless you did the right incantations under the full moon. - We could tone down the logging if we wanted at either the te.exe execution time (with a switch) or by declaring properties in the tests/classes/modules that are very verbose to not log unless it fails. - I don't think anyone cares how they get run as long as they do.
2020-02-10 20:14:06 +01:00
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Common Props", "Common Props", "{53DD5520-E64C-4C06-B472-7CE62CA539C9}"
ProjectSection(SolutionItems) = preProject
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
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
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
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "YAML", "YAML", "{6B5A44ED-918D-4747-BFB1-2472A1FCA173}"
ProjectSection(SolutionItems) = preProject
build\pipelines\templates\build-console-audit-job.yml = build\pipelines\templates\build-console-audit-job.yml
build\pipelines\templates\build-console-ci.yml = build\pipelines\templates\build-console-ci.yml
build\pipelines\templates\build-console-int.yml = build\pipelines\templates\build-console-int.yml
build\pipelines\templates\build-console-steps.yml = build\pipelines\templates\build-console-steps.yml
build\pipelines\templates\check-formatting.yml = build\pipelines\templates\check-formatting.yml
build\pipelines\ci.yml = build\pipelines\ci.yml
build\pipelines\templates\release-sign-and-bundle.yml = build\pipelines\templates\release-sign-and-bundle.yml
build\pipelines\release.yml = build\pipelines\release.yml
EndProjectSection
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Scripts", "Scripts", "{D3EF7B96-CD5E-47C9-B9A9-136259563033}"
ProjectSection(SolutionItems) = preProject
build\scripts\Create-AppxBundle.ps1 = build\scripts\Create-AppxBundle.ps1
build\scripts\Index-Pdbs.ps1 = build\scripts\Index-Pdbs.ps1
build\scripts\Invoke-FormattingCheck.ps1 = build\scripts\Invoke-FormattingCheck.ps1
build\scripts\Run-Tests.ps1 = build\scripts\Run-Tests.ps1
build\scripts\Test-WindowsTerminalPackage.ps1 = build\scripts\Test-WindowsTerminalPackage.ps1
EndProjectSection
EndProject
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Dx.Unit.Tests", "src\renderer\dx\ut_dx\Dx.Unit.Tests.vcxproj", "{95B136F9-B238-490C-A7C5-5843C1FECAC4}"
EndProject
Migrate the ConPTY functional tests out of Windows (#4648) ## Summary of the Pull Request This will allow us to run the ConPTY tests in CI. ## PR Checklist * [x] Closes MSFT:24265197 * [X] I've discussed this with core contributors already. ## Validation Steps Performed I've run the tests. Please note: this code is unchanged (apart from `wil::ScopeExit` -> `wil::scope_exit`) from Windows. Now is not the time to comment on their perfectness.
2020-02-19 22:27:17 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "winconpty.Tests.Feature", "src\winconpty\ft_pty\winconpty.FeatureTests.vcxproj", "{024052DE-83FB-4653-AEA4-90790D29D5BD}"
EndProject
Shim the AzureConn through a conhost to stop VT bleeding (#4652) This commit introduces a small console-subsystem application whose sole job is to consume TerminalConnection.dll and hook it up to something other than Terminal. It is 99% of the way to a generic solution. I've introduced a stopgap in TerminalPage that makes sure we launch TerminalAzBridge using ConptyConnection instead of AzureConnection. As a bonus, this commit includes a class whose sole job it is to make reading VT input off a console handle not terrible. It returns you a string and dispatches window size change callbacks. Fixes #2267. Fixes #4589. Related to #2266 (since pwsh needs better VT).
2020-02-21 01:21:05 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "TerminalAzBridge", "src\cascadia\TerminalAzBridge\TerminalAzBridge.vcxproj", "{067F0A06-FCB7-472C-96E9-B03B54E8E18D}"
EndProject
Import fmtlib/fmt@6.2.0, a C++20-style format library (#5336) 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?
2020-04-14 22:04:23 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "fmt", "src\dep\fmt\fmt.vcxproj", "{6BAE5851-50D5-4934-8D5E-30361A8A40F3}"
EndProject
wpf: target netcoreapp3.1, clean up test project path (#8491) There were some minor annoyances with the WPF projects. 1. WpfTerminalTestNetCore was in an unnecessary same-named subdirectory 2. The build started throwing deprecation warnings because `netcoreapp3.0` is not LTS and is going away.
2020-12-04 19:17:25 +01:00
Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "WpfTerminalTestNetCore", "src\cascadia\WpfTerminalTestNetCore\WpfTerminalTestNetCore.csproj", "{1588FD7C-241E-4E7D-9113-43735F3E6BAD}"
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
ProjectSection(ProjectDependencies) = postProject
{A22EC5F6-7851-4B88-AC52-47249D437A52} = {A22EC5F6-7851-4B88-AC52-47249D437A52}
{84848BFA-931D-42CE-9ADF-01EE54DE7890} = {84848BFA-931D-42CE-9ADF-01EE54DE7890}
EndProjectSection
EndProject
Build and ship an actual binary named wt that just launches WT (#6860) Due to a shell limitation, Ctrl+Shift+Enter will not launch Windows Terminal as Administrator. This is caused by the app execution alias and the actual targeted executable not having the same name. In addition, PowerShell has an issue detecting app execution aliases as GUI/TUI applications. When you run wt from PowerShell, the shell will wait for WT to exit before returning to the prompt. Having a shim that immediately re-executes WindowsTerminal and then returns handily knocks this issue out (as the process that PS was waiting for exits immediately.) This could cause a regression for anybody who tries to capture the PID of wt.exe. Our process tree is not an API, and we have offered no consistency guarantee on it. VALIDATION ---------- Tested manual launch in a number of different scenarios: * [x] start menu "wtd" * [x] start menu tile * [x] powertoys run * [x] powertoys run ctrl+shift (admin) * [x] powershell inbox, "core" * [x] cmd * [x] run dialog * [x] run dialog ctrl+shift (admin) * [x] run from a lnk with window mode=maximized Fixes #4645 (PowerShell waits for wt) Fixes #6625 (Can't launch as admin using C-S-enter)
2020-07-11 00:41:37 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "wt", "src\cascadia\wt\wt.vcxproj", "{506FD703-BAA7-4F6E-9361-64F550EC8FCA}"
EndProject
Introduce the Terminal Settings Editor (#8048) This commit introduces the terminal settings editor (to wit: the Settings UI) as a standalone project. This project, and this commit, is the result of two and a half months of work. TSE started as a hackathon project in the Microsoft 2020 Hackathon, and from there it's grown to be a bona-fide graphical settings editor. There is a lot of xaml data binding in here, a number of views and a number of view models, and a bunch of paradigms that we've been reviewing and testing out and designing and refining. Specified in #6720, #8269 Follow-up work in #6800 Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com> Co-authored-by: Alberto Medina Gutierrez <almedina@microsoft.com> Co-authored-by: John Grandle <jograndl@microsoft.com> Co-authored-by: xerootg <xerootg@users.noreply.github.com> Co-authored-by: Scott <sarmiger1@gmail.com> Co-authored-by: Vineeth Thomas Alex <vineeththomasalex@gmail.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Dustin L. Howett <duhowett@microsoft.com> Signed-off-by: Dustin L. Howett <duhowett@microsoft.com>
2020-12-11 22:34:21 +01:00
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}
EndProjectSection
EndProject
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.Terminal.Settings.Model.Lib", "src\cascadia\TerminalSettingsModel\Microsoft.Terminal.Settings.ModelLib.vcxproj", "{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}"
ProjectSection(ProjectDependencies) = postProject
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
{CA5CAD1A-F542-4635-A069-7CAEFB930070} = {CA5CAD1A-F542-4635-A069-7CAEFB930070}
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.Terminal.Settings.Model", "src\cascadia\TerminalSettingsModel\dll\Microsoft.Terminal.Settings.Model.vcxproj", "{CA5CAD1A-082C-4476-9F33-94B339494076}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "LocalTests_SettingsModel", "src\cascadia\LocalTests_SettingsModel\SettingsModel.LocalTests.vcxproj", "{CA5CAD1A-9B68-456A-B13E-C8218070DC42}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-082C-4476-9F33-94B339494076} = {CA5CAD1A-082C-4476-9F33-94B339494076}
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
{CA5CAD1A-F542-4635-A069-7CAEFB930070} = {CA5CAD1A-F542-4635-A069-7CAEFB930070}
Make TerminalConnection depend on OpenConsoleProxy (#9649) Building code merged with `main` this morning, and I hit a error where the `TerminalConnection` project needed `ITerminalHandoff` something or other, but that hadn't been built yet. I suspect that's because the `OpenConsoleProxy` project needs to be built first, but it isn't set as a dependency. I suspect once that project is built once, this isn't ever an issue, but I hadn't done that yet. This fixed the build for me locally. * [x] fixes local dev builds * [x] also updates the name of the TerminalControl project in the .sln, because apparently VS didn't like that.
2021-03-29 18:57:18 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B} = {CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907} = {CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}
EndProjectSection
EndProject
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "MonarchPeasantSample", "src\tools\MonarchPeasantSample\MonarchPeasantSample.vcxproj", "{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}"
ProjectSection(ProjectDependencies) = postProject
{18D09A24-8240-42D6-8CB6-236EEE820263} = {18D09A24-8240-42D6-8CB6-236EEE820263}
EndProjectSection
EndProject
Project("{C7167F0D-BC9F-4E6E-AFE1-012C56B48DB5}") = "MonarchPeasantPackage", "src\tools\MonarchPeasantPackage\MonarchPeasantPackage.wapproj", "{F75E29D0-D288-478B-8D83-2C190F321A3F}"
EndProject
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.Terminal.Remoting.Lib", "src\cascadia\Remoting\Microsoft.Terminal.RemotingLib.vcxproj", "{43CE4CE5-0010-4B99-9569-672670D26E26}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Microsoft.Terminal.Remoting", "src\cascadia\Remoting\dll\Microsoft.Terminal.Remoting.vcxproj", "{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}"
ProjectSection(ProjectDependencies) = postProject
{43CE4CE5-0010-4B99-9569-672670D26E26} = {43CE4CE5-0010-4B99-9569-672670D26E26}
EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "UnitTests_Remoting", "src\cascadia\UnitTests_Remoting\Remoting.UnitTests.vcxproj", "{68A10CD3-AA64-465B-AF5F-ED4E9700543C}"
ProjectSection(ProjectDependencies) = postProject
{43CE4CE5-0010-4B99-9569-672670D26E26} = {43CE4CE5-0010-4B99-9569-672670D26E26}
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE} = {27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}
EndProjectSection
EndProject
Add support for running a commandline in another WT window (#8898) ## Summary of the Pull Request **If you're reading this PR and haven't signed off on #8135, go there first.** ![window-management-000](https://user-images.githubusercontent.com/18356694/103932910-25199380-50e8-11eb-97e3-594a31da62d2.gif) This provides the basic parts of the implementation of #4472. Namely: * We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window. * If `window-id` is `0`, run the given commands in _the current window_. * If `window-id` is a negative number, run the commands in a _new_ Terminal window. * If `window-id` is the ID of an existing window, then run the commandline in that window. * If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window. * If `window-id` is omitted, then create a new window. ## References * Spec: #8135 * Megathread: #5000 * Project: projects/5 ## PR Checklist * [x] Closes #4472 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **sure does** ## Detailed Description of the Pull Request / Additional comments Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change There are limitations, and there are plenty of things to work on in the future: * [ ] We don't support names for windows yet * [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that. * [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from. * [ ] Basically anything else that's listed in projects/5. I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in. ## Validation Steps Performed I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain. # TODOs * [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬 - [x] `Monarch.cpp` - [x] `Peasant.cpp` - [x] `WindowManager.cpp` - [x] `AppHost.cpp` * [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully. - Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID. - Could we gracefully recover from such a state? maybe, probably not though. - Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant? - After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
2021-02-10 12:28:09 +01:00
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "wpf", "wpf", "{4DAF0299-495E-4CD1-A982-9BAC16A45932}"
EndProject
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "OpenConsoleProxy", "src\host\proxy\Host.Proxy.vcxproj", "{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}"
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Window", "Window", "{2D17E75D-2DDC-42C4-AD70-704D95A937AE}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Settings", "Settings", "{77875138-BB08-49F9-8BB1-409C2150E0E1}"
EndProject
Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Control", "Control", "{9921CA0A-320C-4460-8623-3A3196E7F4CB}"
Merged PR 5677497: [Git2Git] Merged PR 5655213: Allow conhost to handoff to registered default app handler Contains: - Delegation Configurator that can lookup/edit/save configuration information to registry - Conhost can lookup the CLSID of a registered default - Conhost has the ability to handoff a starting visible-window interactive session to the registered default - Velocity key since this is a big deal and we want to be careful - IDL for the interface Related work items: MSFT-16458099 Retrieved from https://microsoft.visualstudio.com os.2020 OS official/rs_wdx_dxp_windev 0ca55027d8180fbbaa145f2fe7a15005856c0f7c
2021-02-11 22:07:50 +01:00
EndProject
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Host.FuzzWrapper", "src\host\ft_fuzzer\Host.FuzzWrapper.vcxproj", "{05D9052F-D78F-478F-968A-2DE38A6DB996}"
EndProject
Create a control unittesting project (#9677) Does what it says on the can. This is a follow up to #9472. Now that we have a control .lib, we can add tests for it. Unfortunately, the `TermControl` itself is a horrible mess. So this new unittest lib is empty for now. I'm working on actual tests as a part of #6842, but this PR is here to keep the diffs smaller. Also, apparently `server.vcxproj` had the wrong GUID in it. * [x] I work here * [x] Adds tests
2021-04-05 18:07:55 +02:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "UnitTests_Control", "src\cascadia\UnitTests_Control\Control.UnitTests.vcxproj", "{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}"
ProjectSection(ProjectDependencies) = postProject
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}
EndProjectSection
EndProject
Implement PGO in pipelines for AMD64 architecture; supply training test scenarios (#10071) Implement PGO in pipelines for AMD64 architecture; supply training test scenarios ## References - #3075 - Relevant to speed interests there and other linked issues. ## PR Checklist * [x] Closes #6963 * [x] I work here. * [x] New UIA Tests added and passed. Manual build runs also tested. ## Detailed Description of the Pull Request / Additional comments - Creates a new pipeline run for creating instrumented binaries for Profile Guided Optimization (PGO). - Creates a new suite of UIA tests on the full Windows Terminal app to run PGO training scenarios on instrumented binaries (and incidentally can be used to write other UIA tests later for the full Terminal app.) - Creates a new NuGet artifact to store trained PGO databases (PGD files) at `Microsoft.Internal.Windows.Terminal.PGODatabase` - Creates a new NuGet artifact to supply large-scale test content for automated tests at `Microsoft.Internal.Windows.Terminal.TestContent` - Adjusts the release pipeline to run binaries in PGO optimized mode where content from PGO databases is leveraged at link time to optimize the final release build The following binaries are trained: - OpenConsole.exe - WindowsTerminal.exe - TerminalApp.dll - TerminalConnection.dll - Microsoft.Terminal.Control.dll - Microsoft.Terminal.Remoting.dll - Microsoft.Terminal.Settings.Editor.dll - Microsoft.Terminal.Settings.Model.dll In the future, adding `<PgoTarget>true</PgoTarget>` to a new `vcxproj` file will automatically enroll the DLL/EXE for PGO instrumentation and optimization going forward. Two training test scenarios are implemented: - Smoke test the Terminal by just opening it and typing a bit of text then exiting. (Should help focus on the standard launch path.) - Optimize bulk text output by launching terminal, outputting `big.txt`, then exiting. Additional scenarios can be contributed to the `WindowsTerminal_UIATests` project with the `[TestProperty("IsPGO", "true")]` annotation to add them to the suite of scenarios for PGO. **NOTE:** There are currently no weights applied to the various test scenarios. We will revisit that in the future when/if necessary. ## Validation Steps Performed - [x] - Training run completed at https://dev.azure.com/ms/terminal/_build?definitionId=492&_a=summary - [x] - Optimization run completed locally (by forcing `PGOBuildMode` to `Optimize` on my local machine, manually retrieving the databases with NuGet, and building). - [x] - Validated locally that x86 and ARM64 do not get trained and automatically skip optimization as databases are not present for them. - [x] - Smoke tested optimized binary versus latest releases. `big.txt` output through CMD is ~11-12seconds prior to PGO and just over 8 seconds with PGO.
2021-05-13 23:12:30 +02:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "WindowsTerminal.UIA.Tests", "src\cascadia\WindowsTerminal_UIATests\WindowsTerminal.UIA.Tests.csproj", "{F19DACD5-0C6E-40DC-B6E4-767A3200542C}"
EndProject
Introduce a api-ms-win-core-synch-l1-2-0 shim for Windows 7 (#10559) The code in this file was adapted from the STL on the 2021-07-05. It backports the following Windows 8 functions to Windows 7: * WaitOnAddress * WakeByAddressSingle * WakeByAddressAll These functions are used within `til`. This commit will allow `til` to be used in the conhost source code. Validation * [x] correct .dll loads on Windows 7 * [x] correct .dll loads on Windows 10 * [x] link line for PublicTerminalCore prefers this fake apiset over kernel32
2021-07-07 18:48:28 +02:00
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
Introduce AtlasEngine - A new text rendering prototype (#11623) This commit introduces "AtlasEngine", a new text renderer based on DxEngine. But unlike it, DirectWrite and Direct2D are only used to rasterize glyphs. Blending and placing these glyphs into the target view is being done using Direct3D and a simple HLSL shader. Since this new renderer more aggressively assumes that the text is monospace, it simplifies the implementation: The viewport is divided into cells, and its data is stored as a simple matrix. Modifications to this matrix involve only simple pointer arithmetic and is easy to understand. But just like with DxEngine however, DirectWrite related code remains extremely complex and hard to understand. Supported features: * Basic text rendering with grayscale AA * Foreground and background colors * Emojis, including zero width joiners * Underline, dotted underline, strikethrough * Custom font axes and features * Selections * All cursor styles * Full alpha support for all colors * _Should_ work with Windows 7 Unsupported features: * A more conservative GPU memory usage The backing texture atlas for glyphs is grow-only and will not shrink. After 256MB of memory is used up (~20k glyphs) text output will be broken until the renderer is restarted. * ClearType * Remaining gridlines (left, right, top, bottom, double underline) * Hyperlinks don't get full underlines if hovered in WT * Softfonts * Non-default line renditions Performance: * Runs at up to native display refresh rate Unfortunately the frame rate often drops below refresh rate, due us fighting over the buffer lock with other parts of the application. * CPU consumption is up to halved compared to DxEngine AtlasEngine is still highly unoptimized. Glyph hashing consumes up to a third of the current CPU time. * No regressions in WT performance VT parsing and related buffer management takes up most of the CPU time (~85%), due to which the AtlasEngine can't show any further improvements. * ~2x improvement in raw text throughput in OpenConsole compared to DxEngine running at 144 FPS * ≥10x improvement in colored VT output in WT/OpenConsole compared to DxEngine running at 144 FPS
2021-11-13 01:10:06 +01:00
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "RendererAtlas", "src\renderer\atlas\atlas.vcxproj", "{8222900C-8B6C-452A-91AC-BE95DB04B95F}"
EndProject
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
AuditMode|Any CPU = AuditMode|Any CPU
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
AuditMode|ARM = AuditMode|ARM
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
AuditMode|ARM64 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
AuditMode|DotNet_x64Test = AuditMode|DotNet_x64Test
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
AuditMode|DotNet_x86Test = AuditMode|DotNet_x86Test
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
AuditMode|x64 = AuditMode|x64
AuditMode|x86 = AuditMode|x86
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
Debug|Any CPU = Debug|Any CPU
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
Debug|ARM = Debug|ARM
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Debug|ARM64 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
Debug|DotNet_x64Test = Debug|DotNet_x64Test
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
Debug|DotNet_x86Test = Debug|DotNet_x86Test
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Debug|x64 = Debug|x64
Debug|x86 = Debug|x86
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
Fuzzing|Any CPU = Fuzzing|Any CPU
Fuzzing|ARM = Fuzzing|ARM
Fuzzing|ARM64 = Fuzzing|ARM64
Fuzzing|DotNet_x64Test = Fuzzing|DotNet_x64Test
Fuzzing|DotNet_x86Test = Fuzzing|DotNet_x86Test
Fuzzing|x64 = Fuzzing|x64
Fuzzing|x86 = Fuzzing|x86
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
Release|Any CPU = Release|Any CPU
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
Release|ARM = Release|ARM
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Release|ARM64 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
Release|DotNet_x64Test = Release|DotNet_x64Test
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
Release|DotNet_x86Test = Release|DotNet_x86Test
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
Release|x64 = Release|x64
Release|x86 = Release|x86
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|Any CPU.ActiveCfg = Debug|x86
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|ARM.ActiveCfg = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|ARM.Build.0 = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|ARM.Deploy.0 = Debug|x64
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|x86
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|x86
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.AuditMode|x86.ActiveCfg = Release|x86
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|Any CPU.ActiveCfg = Debug|x86
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM.ActiveCfg = Debug|x86
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|ARM64.Deploy.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|DotNet_x64Test.ActiveCfg = Debug|x86
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|DotNet_x86Test.ActiveCfg = Debug|x86
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x64.Deploy.0 = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.ActiveCfg = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.Build.0 = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Debug|x86.Deploy.0 = Debug|x86
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Fuzzing|Any CPU.ActiveCfg = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Fuzzing|ARM.ActiveCfg = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Fuzzing|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Fuzzing|DotNet_x64Test.ActiveCfg = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Fuzzing|DotNet_x86Test.ActiveCfg = Debug|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Fuzzing|x64.ActiveCfg = Debug|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Fuzzing|x86.ActiveCfg = Debug|x86
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|Any CPU.ActiveCfg = Release|x86
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM.ActiveCfg = Release|x86
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|ARM64.Deploy.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|DotNet_x64Test.ActiveCfg = Release|x86
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|DotNet_x86Test.ActiveCfg = Release|x86
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x64.Deploy.0 = Release|x64
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.ActiveCfg = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.Build.0 = Release|x86
{CA5CAD1A-224A-4171-B13A-F16E576FDD12}.Release|x86.Deploy.0 = Release|x86
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x64.ActiveCfg = Release|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|x64.ActiveCfg = Debug|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|x64.Build.0 = Debug|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|x86.ActiveCfg = Debug|Win32
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|ARM64.ActiveCfg = Release|ARM64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|x64.ActiveCfg = Release|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|x64.Build.0 = Release|x64
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.ActiveCfg = Release|Win32
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|x64.ActiveCfg = Release|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|ARM64.ActiveCfg = Debug|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|x64.ActiveCfg = Debug|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|x64.Build.0 = Debug|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|x86.ActiveCfg = Debug|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Fuzzing|x64.Build.0 = Fuzzing|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|ARM64.ActiveCfg = Release|ARM64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|x64.ActiveCfg = Release|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|x64.Build.0 = Release|x64
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|x86.ActiveCfg = Release|Win32
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|x64.ActiveCfg = Release|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|ARM64.ActiveCfg = Debug|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|x64.ActiveCfg = Debug|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|x64.Build.0 = Debug|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|x86.ActiveCfg = Debug|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Fuzzing|x64.Build.0 = Fuzzing|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|ARM64.ActiveCfg = Release|ARM64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|x64.ActiveCfg = Release|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|x64.Build.0 = Release|x64
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|x86.ActiveCfg = Release|Win32
{2FD12FBB-1DDB-46D8-B818-1023C624CACA}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Apply audit mode to TerminalInput/Adapter/Parser libraries (#4005) <!-- 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 - Enables auditing of Virtual Terminal libraries (input, adapter, parser) <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor * [x] Closes #3957 <!-- 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 This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 15:25:21 +01:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|x64.ActiveCfg = AuditMode|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|x64.Build.0 = AuditMode|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|ARM64.ActiveCfg = Debug|ARM64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|DotNet_x64Test.Build.0 = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|DotNet_x86Test.Build.0 = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|x64.ActiveCfg = Debug|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|x64.Build.0 = Debug|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|x86.ActiveCfg = Debug|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Fuzzing|x64.Build.0 = Fuzzing|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|ARM64.ActiveCfg = Release|ARM64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|DotNet_x64Test.Build.0 = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|DotNet_x86Test.Build.0 = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|x64.ActiveCfg = Release|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|x64.Build.0 = Release|x64
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|x86.ActiveCfg = Release|Win32
{3AE13314-1939-4DFA-9C14-38CA0834050C}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Apply audit mode to TerminalInput/Adapter/Parser libraries (#4005) <!-- 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 - Enables auditing of Virtual Terminal libraries (input, adapter, parser) <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor * [x] Closes #3957 <!-- 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 This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 15:25:21 +01:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.ActiveCfg = AuditMode|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.Build.0 = AuditMode|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.ActiveCfg = Debug|ARM64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x64.ActiveCfg = Debug|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x64.Build.0 = Debug|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x86.ActiveCfg = Debug|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|x64.Build.0 = Fuzzing|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|ARM64.ActiveCfg = Release|ARM64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|x64.ActiveCfg = Release|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|x64.Build.0 = Release|x64
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.ActiveCfg = Release|Win32
{DCF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Apply audit mode to TerminalInput/Adapter/Parser libraries (#4005) <!-- 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 - Enables auditing of Virtual Terminal libraries (input, adapter, parser) <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor * [x] Closes #3957 <!-- 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 This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 15:25:21 +01:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.ActiveCfg = AuditMode|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x64.Build.0 = AuditMode|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.ActiveCfg = Debug|ARM64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|DotNet_x64Test.Build.0 = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|DotNet_x86Test.Build.0 = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x64.ActiveCfg = Debug|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x64.Build.0 = Debug|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x86.ActiveCfg = Debug|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|x64.Build.0 = Fuzzing|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|ARM64.ActiveCfg = Release|ARM64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|DotNet_x64Test.Build.0 = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|DotNet_x86Test.Build.0 = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|x64.ActiveCfg = Release|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|x64.Build.0 = Release|x64
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.ActiveCfg = Release|Win32
{1CF55140-EF6A-4736-A403-957E4F7430BB}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|x64.ActiveCfg = Release|x64
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|x64.Build.0 = Release|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|ARM64.ActiveCfg = Debug|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|DotNet_x64Test.Build.0 = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|DotNet_x86Test.Build.0 = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|x64.ActiveCfg = Debug|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|x64.Build.0 = Debug|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|x86.ActiveCfg = Debug|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Fuzzing|x64.Build.0 = Fuzzing|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|ARM64.ActiveCfg = Release|ARM64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|DotNet_x64Test.Build.0 = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|DotNet_x86Test.Build.0 = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|x64.ActiveCfg = Release|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|x64.Build.0 = Release|x64
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|x86.ActiveCfg = Release|Win32
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|x64.ActiveCfg = Release|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|x64.ActiveCfg = Debug|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|x64.Build.0 = Debug|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|x86.ActiveCfg = Debug|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Fuzzing|x64.Build.0 = Fuzzing|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|ARM64.ActiveCfg = Release|ARM64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|x64.ActiveCfg = Release|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|x64.Build.0 = Release|x64
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|x86.ActiveCfg = Release|Win32
{1C959542-BAC2-4E55-9A6D-13251914CBB9}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|x64.ActiveCfg = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|x64.Build.0 = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|x86.ActiveCfg = Debug|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.Fuzzing|x64.Build.0 = Fuzzing|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954746}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|x64.ActiveCfg = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|x64.Build.0 = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|x86.ActiveCfg = Debug|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC954747}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|x64.ActiveCfg = Release|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|x64.ActiveCfg = Debug|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|x64.Build.0 = Debug|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|x86.ActiveCfg = Debug|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|ARM64.ActiveCfg = Release|ARM64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|x64.ActiveCfg = Release|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|x64.Build.0 = Release|x64
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|x86.ActiveCfg = Release|Win32
{531C23E7-4B76-4C08-8AAD-04164CB628C9}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|x64.ActiveCfg = Release|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|x64.ActiveCfg = Debug|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|x64.Build.0 = Debug|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|x86.ActiveCfg = Debug|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|ARM64.ActiveCfg = Release|ARM64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|x64.ActiveCfg = Release|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|x64.Build.0 = Release|x64
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|x86.ActiveCfg = Release|Win32
{531C23E7-4B76-4C08-8BBD-04164CB628C9}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|x64.ActiveCfg = Release|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|ARM64.ActiveCfg = Debug|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|x64.ActiveCfg = Debug|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|x64.Build.0 = Debug|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Debug|x86.ActiveCfg = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|ARM64.ActiveCfg = Release|ARM64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|x64.ActiveCfg = Release|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|x64.Build.0 = Release|x64
{8CDB8850-7484-4EC7-B45B-181F85B2EE54}.Release|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|x64.ActiveCfg = Release|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|ARM64.ActiveCfg = Debug|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|x64.ActiveCfg = Debug|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|x64.Build.0 = Debug|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|x86.ActiveCfg = Debug|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|ARM64.ActiveCfg = Release|ARM64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|x64.ActiveCfg = Release|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|x64.Build.0 = Release|x64
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|x86.ActiveCfg = Release|Win32
{12144E07-FE63-4D33-9231-748B8D8C3792}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|x64.ActiveCfg = Release|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|ARM64.ActiveCfg = Debug|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|x64.ActiveCfg = Debug|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|x64.Build.0 = Debug|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|x86.ActiveCfg = Debug|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|ARM64.ActiveCfg = Release|ARM64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|x64.ActiveCfg = Release|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|x64.Build.0 = Release|x64
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|x86.ActiveCfg = Release|Win32
{6AF01638-84CF-4B65-9870-484DFFCAC772}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|x64.ActiveCfg = Release|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|ARM64.ActiveCfg = Debug|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|x64.ActiveCfg = Debug|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|x64.Build.0 = Debug|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|x86.ActiveCfg = Debug|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|ARM64.ActiveCfg = Release|ARM64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|x64.ActiveCfg = Release|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|x64.Build.0 = Release|x64
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|x86.ActiveCfg = Release|Win32
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|x64.ActiveCfg = Release|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|ARM64.ActiveCfg = Debug|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|x64.ActiveCfg = Debug|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|x64.Build.0 = Debug|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|x86.ActiveCfg = Debug|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|ARM64.ActiveCfg = Release|ARM64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|x64.ActiveCfg = Release|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|x64.Build.0 = Release|x64
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|x86.ActiveCfg = Release|Win32
{F210A4AE-E02A-4BFC-80BB-F50A672FE763}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|x64.ActiveCfg = Release|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|ARM64.ActiveCfg = Debug|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|x64.ActiveCfg = Debug|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|x64.Build.0 = Debug|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|x86.ActiveCfg = Debug|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Fuzzing|x64.Build.0 = Fuzzing|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|ARM64.ActiveCfg = Release|ARM64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|x64.ActiveCfg = Release|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|x64.Build.0 = Release|x64
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|x86.ActiveCfg = Release|Win32
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|x64.ActiveCfg = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|ARM64.ActiveCfg = Debug|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|x64.ActiveCfg = Debug|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|x64.Build.0 = Debug|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|x86.ActiveCfg = Debug|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Fuzzing|x64.Build.0 = Fuzzing|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|ARM64.ActiveCfg = Release|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|x64.ActiveCfg = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|x64.Build.0 = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|x86.ActiveCfg = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820262}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|Any CPU.ActiveCfg = Debug|ARM64
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|ARM.ActiveCfg = Release|ARM64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|ARM.Build.0 = Release|ARM64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|ARM64.ActiveCfg = Debug|Win32
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|ARM64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|ARM64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|x64.ActiveCfg = Release|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|ARM64.ActiveCfg = Debug|Win32
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|x64.ActiveCfg = Debug|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|x64.Build.0 = Debug|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|x86.ActiveCfg = Debug|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Fuzzing|Any CPU.ActiveCfg = Debug|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Fuzzing|ARM.ActiveCfg = Debug|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Fuzzing|ARM64.ActiveCfg = Release|ARM64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Fuzzing|DotNet_x64Test.ActiveCfg = Debug|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Fuzzing|DotNet_x86Test.ActiveCfg = Debug|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Fuzzing|x64.ActiveCfg = Debug|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Fuzzing|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|x64.ActiveCfg = Release|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|x64.Build.0 = Release|x64
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|x86.ActiveCfg = Release|Win32
{C17E1BF3-9D34-4779-9458-A8EF98CC5662}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|Any CPU.ActiveCfg = Debug|ARM64
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|ARM.ActiveCfg = Release|ARM64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|ARM.Build.0 = Release|ARM64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|ARM64.ActiveCfg = Debug|Win32
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|ARM64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|ARM64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|x64.ActiveCfg = Release|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|ARM64.ActiveCfg = Debug|Win32
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x64.ActiveCfg = Debug|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x64.Build.0 = Debug|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x86.ActiveCfg = Debug|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{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 = 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 = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|x64.ActiveCfg = Release|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|x64.Build.0 = Release|x64
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|x86.ActiveCfg = Release|Win32
{099193A0-1E43-4BBC-BA7F-7B351E1342DF}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|x64.ActiveCfg = Release|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|ARM64.ActiveCfg = Debug|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|x64.ActiveCfg = Debug|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|x64.Build.0 = Debug|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|x86.ActiveCfg = Debug|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|ARM64.ActiveCfg = Release|ARM64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|x64.ActiveCfg = Release|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|x64.Build.0 = Release|x64
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|x86.ActiveCfg = Release|Win32
{FC802440-AD6A-4919-8F2C-7701F2B38D79}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|x64.ActiveCfg = Release|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|ARM64.ActiveCfg = Debug|ARM64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|x64.ActiveCfg = Debug|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|x64.Build.0 = Debug|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|x86.ActiveCfg = Debug|Win32
{919544AC-D39B-463F-8414-3C3C67CF727C}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{919544AC-D39B-463F-8414-3C3C67CF727C}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{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
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|ARM64.ActiveCfg = Release|ARM64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|x64.ActiveCfg = Release|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|x64.Build.0 = Release|x64
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|x86.ActiveCfg = Release|Win32
{919544AC-D39B-463F-8414-3C3C67CF727C}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|x64.ActiveCfg = Release|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|ARM64.ActiveCfg = Debug|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|x64.ActiveCfg = Debug|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|x64.Build.0 = Debug|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|x86.ActiveCfg = Debug|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|ARM64.ActiveCfg = Release|ARM64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|x64.ActiveCfg = Release|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|x64.Build.0 = Release|x64
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|x86.ActiveCfg = Release|Win32
{ED82003F-FC5D-4E94-8B36-F480018ED064}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|x64.ActiveCfg = Debug|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|x64.Build.0 = Debug|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|x86.ActiveCfg = Debug|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.Fuzzing|x64.Build.0 = Fuzzing|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8532EC964726}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|x64.ActiveCfg = Release|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|ARM64.ActiveCfg = Debug|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|x64.ActiveCfg = Debug|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|x64.Build.0 = Debug|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|x86.ActiveCfg = Debug|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Fuzzing|x64.Build.0 = Fuzzing|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|ARM64.ActiveCfg = Release|ARM64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|x64.ActiveCfg = Release|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|x64.Build.0 = Release|x64
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|x86.ActiveCfg = Release|Win32
{ED82003F-FC5D-4E94-8B47-F480018ED064}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|ARM64.ActiveCfg = Debug|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|x64.ActiveCfg = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|x64.Build.0 = Debug|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|x86.ActiveCfg = Debug|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.Fuzzing|x64.Build.0 = Fuzzing|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|ARM64.ActiveCfg = Release|ARM64
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|x64.ActiveCfg = Release|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|x64.Build.0 = Release|x64
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|x86.ActiveCfg = Release|Win32
{06EC74CB-9A12-429C-B551-8562EC964846}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|x64.ActiveCfg = Release|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|ARM64.ActiveCfg = Debug|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|x64.ActiveCfg = Debug|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|x64.Build.0 = Debug|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|x86.ActiveCfg = Debug|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|ARM64.ActiveCfg = Release|ARM64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|x64.ActiveCfg = Release|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|x64.Build.0 = Release|x64
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|x86.ActiveCfg = Release|Win32
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|x64.ActiveCfg = Release|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|ARM64.ActiveCfg = Debug|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|x64.ActiveCfg = Debug|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|x64.Build.0 = Debug|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|x86.ActiveCfg = Debug|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|ARM64.ActiveCfg = Release|ARM64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|x64.ActiveCfg = Release|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|x64.Build.0 = Release|x64
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|x86.ActiveCfg = Release|Win32
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|x64.ActiveCfg = Release|x64
{990F2657-8580-4828-943F-5DD657D11842}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{990F2657-8580-4828-943F-5DD657D11842}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Debug|ARM64.ActiveCfg = Debug|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Debug|x64.ActiveCfg = Debug|x64
{990F2657-8580-4828-943F-5DD657D11842}.Debug|x64.Build.0 = Debug|x64
{990F2657-8580-4828-943F-5DD657D11842}.Debug|x86.ActiveCfg = Debug|Win32
{990F2657-8580-4828-943F-5DD657D11842}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{990F2657-8580-4828-943F-5DD657D11842}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{990F2657-8580-4828-943F-5DD657D11842}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{990F2657-8580-4828-943F-5DD657D11842}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{990F2657-8580-4828-943F-5DD657D11842}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{990F2657-8580-4828-943F-5DD657D11842}.Fuzzing|x64.Build.0 = Fuzzing|x64
{990F2657-8580-4828-943F-5DD657D11842}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{990F2657-8580-4828-943F-5DD657D11842}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Release|ARM64.ActiveCfg = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11842}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11842}.Release|x64.ActiveCfg = Release|x64
{990F2657-8580-4828-943F-5DD657D11842}.Release|x64.Build.0 = Release|x64
{990F2657-8580-4828-943F-5DD657D11842}.Release|x86.ActiveCfg = Release|Win32
{990F2657-8580-4828-943F-5DD657D11842}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|x64.ActiveCfg = Release|x64
{814DBDDE-894E-4327-A6E1-740504850098}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|ARM64.ActiveCfg = Debug|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|x64.ActiveCfg = Debug|x64
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|x64.Build.0 = Debug|x64
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|x86.ActiveCfg = Debug|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{814DBDDE-894E-4327-A6E1-740504850098}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{814DBDDE-894E-4327-A6E1-740504850098}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Release|ARM64.ActiveCfg = Release|ARM64
{814DBDDE-894E-4327-A6E1-740504850098}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814DBDDE-894E-4327-A6E1-740504850098}.Release|x64.ActiveCfg = Release|x64
{814DBDDE-894E-4327-A6E1-740504850098}.Release|x64.Build.0 = Release|x64
{814DBDDE-894E-4327-A6E1-740504850098}.Release|x86.ActiveCfg = Release|Win32
{814DBDDE-894E-4327-A6E1-740504850098}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|x64.ActiveCfg = Release|x64
{814CBEEE-894E-4327-A6E1-740504850098}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|ARM64.ActiveCfg = Debug|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|x64.ActiveCfg = Debug|x64
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|x64.Build.0 = Debug|x64
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|x86.ActiveCfg = Debug|Win32
{814CBEEE-894E-4327-A6E1-740504850098}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{814CBEEE-894E-4327-A6E1-740504850098}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{814CBEEE-894E-4327-A6E1-740504850098}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{814CBEEE-894E-4327-A6E1-740504850098}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{814CBEEE-894E-4327-A6E1-740504850098}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{814CBEEE-894E-4327-A6E1-740504850098}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{814CBEEE-894E-4327-A6E1-740504850098}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Release|ARM64.ActiveCfg = Release|ARM64
{814CBEEE-894E-4327-A6E1-740504850098}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{814CBEEE-894E-4327-A6E1-740504850098}.Release|x64.ActiveCfg = Release|x64
{814CBEEE-894E-4327-A6E1-740504850098}.Release|x64.Build.0 = Release|x64
{814CBEEE-894E-4327-A6E1-740504850098}.Release|x86.ActiveCfg = Release|Win32
{814CBEEE-894E-4327-A6E1-740504850098}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x64.ActiveCfg = AuditMode|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x64.Build.0 = AuditMode|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.AuditMode|x86.Build.0 = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|ARM64.ActiveCfg = Debug|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|DotNet_x64Test.Build.0 = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|DotNet_x86Test.Build.0 = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x64.ActiveCfg = Debug|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x64.Build.0 = Debug|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x86.ActiveCfg = Debug|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|x64.Build.0 = Fuzzing|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|ARM64.ActiveCfg = Release|ARM64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|DotNet_x64Test.Build.0 = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|DotNet_x86Test.Build.0 = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x64.ActiveCfg = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x64.Build.0 = Release|x64
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x86.ActiveCfg = Release|Win32
{18D09A24-8240-42D6-8CB6-236EEE820263}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|x64.ActiveCfg = Release|x64
{990F2657-8580-4828-943F-5DD657D11843}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{990F2657-8580-4828-943F-5DD657D11843}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Debug|ARM64.ActiveCfg = Debug|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Debug|x64.ActiveCfg = Debug|x64
{990F2657-8580-4828-943F-5DD657D11843}.Debug|x64.Build.0 = Debug|x64
{990F2657-8580-4828-943F-5DD657D11843}.Debug|x86.ActiveCfg = Debug|Win32
{990F2657-8580-4828-943F-5DD657D11843}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{990F2657-8580-4828-943F-5DD657D11843}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{990F2657-8580-4828-943F-5DD657D11843}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{990F2657-8580-4828-943F-5DD657D11843}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{990F2657-8580-4828-943F-5DD657D11843}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{990F2657-8580-4828-943F-5DD657D11843}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{990F2657-8580-4828-943F-5DD657D11843}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Release|ARM64.ActiveCfg = Release|ARM64
{990F2657-8580-4828-943F-5DD657D11843}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{990F2657-8580-4828-943F-5DD657D11843}.Release|x64.ActiveCfg = Release|x64
{990F2657-8580-4828-943F-5DD657D11843}.Release|x64.Build.0 = Release|x64
{990F2657-8580-4828-943F-5DD657D11843}.Release|x86.ActiveCfg = Release|Win32
{990F2657-8580-4828-943F-5DD657D11843}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|x64.ActiveCfg = AuditMode|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|x64.Build.0 = AuditMode|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.AuditMode|x86.Build.0 = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|ARM64.ActiveCfg = Debug|ARM64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|DotNet_x64Test.Build.0 = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|DotNet_x86Test.Build.0 = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|x64.ActiveCfg = Debug|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|x64.Build.0 = Debug|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|x86.ActiveCfg = Debug|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Fuzzing|x64.Build.0 = Fuzzing|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|ARM64.ActiveCfg = Release|ARM64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|DotNet_x64Test.Build.0 = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|DotNet_x86Test.Build.0 = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|x64.ActiveCfg = Release|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|x64.Build.0 = Release|x64
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|x86.ActiveCfg = Release|Win32
{0CF235BD-2DA0-407E-90EE-C467E8BBC714}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|x64.ActiveCfg = AuditMode|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|x64.Build.0 = AuditMode|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.AuditMode|x86.Build.0 = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|ARM64.ActiveCfg = Debug|ARM64
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|DotNet_x64Test.Build.0 = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|DotNet_x86Test.Build.0 = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|x64.ActiveCfg = Debug|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|x64.Build.0 = Debug|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|x86.ActiveCfg = Debug|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{48D21369-3D7B-4431-9967-24E81292CF62}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Fuzzing|x64.Build.0 = Fuzzing|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|ARM64.ActiveCfg = Release|ARM64
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|DotNet_x64Test.Build.0 = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|DotNet_x86Test.Build.0 = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|x64.ActiveCfg = Release|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|x64.Build.0 = Release|x64
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|x86.ActiveCfg = Release|Win32
{48D21369-3D7B-4431-9967-24E81292CF62}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|Win32
Apply audit mode to TerminalConnection/Core/Settings and WinCon… (#4016) ## Summary of the Pull Request - Enables auditing of some Terminal libraries (Connection, Core, Settings) - Also audit WinConPTY.LIB since Connection depends on it ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor ## Detailed Description of the Pull Request / Additional comments This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 19:44:27 +01:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|x64.Build.0 = AuditMode|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Apply audit mode to TerminalConnection/Core/Settings and WinCon… (#4016) ## Summary of the Pull Request - Enables auditing of some Terminal libraries (Connection, Core, Settings) - Also audit WinConPTY.LIB since Connection depends on it ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor ## Detailed Description of the Pull Request / Additional comments This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 19:44:27 +01:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|x64.Build.0 = AuditMode|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|DotNet_x64Test.Build.0 = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|DotNet_x86Test.Build.0 = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|DotNet_x64Test.Build.0 = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|DotNet_x86Test.Build.0 = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-ABCD-429C-B551-8562EC954746}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED}.Release|x86.Build.0 = Release|Win32
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.AuditMode|x86.ActiveCfg = Release|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Debug|Any CPU.ActiveCfg = Debug|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Debug|ARM.ActiveCfg = Debug|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Release|Any CPU.ActiveCfg = Release|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Release|ARM.ActiveCfg = Release|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-F542-4635-A069-7CAEFB930070}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|Any CPU.ActiveCfg = Debug|x64
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|x64
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12}.Release|x86.Build.0 = Release|Win32
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.AuditMode|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.AuditMode|x64.ActiveCfg = Release|x64
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.AuditMode|x64.Build.0 = Release|x64
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.AuditMode|x86.ActiveCfg = Release|Win32
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Debug|ARM.ActiveCfg = Debug|Win32
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Debug|x64.ActiveCfg = Debug|x64
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Debug|x64.Build.0 = Debug|x64
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Debug|x86.ActiveCfg = Debug|Win32
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Release|ARM.ActiveCfg = Release|Win32
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Release|ARM64.ActiveCfg = Release|ARM64
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Add a context menu entry to "Open Windows Terminal here" (#6100) ## Summary of the Pull Request ![image](https://user-images.githubusercontent.com/18356694/82586680-94447680-9b5d-11ea-9cf1-a85d2b32db10.png) I went with the simple option - just open the Terminal with the default profile in the selected directory. I'd love to add another entry for "Open Terminal here with Profile...", but that's going to be follow-up work, once we sort out pulling the Terminal Settings into their own dll. ## References * I'm going to need to file a bunch of follow-ups on this one. - We should add another entry to let the user select which profile - We should add the icon - I've got to do it in `dllname.dll,1` format, which is annoying. - These strings should be localized. - Should this only appear on <kbd>Shift</kbd>+right click? Probably! However, I don't know how to do that. * [A Win7 Explorer Command Sample](https://github.com/microsoft/Windows-classic-samples/tree/master/Samples/Win7Samples/winui/shell/appshellintegration/ExplorerCommandVerb) which hasn't aged well * [cppwinrt tutorial](https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/author-coclasses) on using COM in cppwinrt * [This is PowerToys' manifest](https://github.com/microsoft/PowerToys/blob/d2a60c7287eb5667b5282a519c92b759664c9e30/installer/MSIX/appxmanifest.xml#L53-L65) and then [their implementation](https://github.com/microsoft/PowerToys/blob/d16ebba9e0f06e7a0d41d981aeb1fd0a78192dc0/src/modules/powerrename/dll/PowerRenameExt.cpp) which were both helpful * [This ](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#instructions) was the sample I followed for how to actually set up the manifest, with the added magic that [`desktop5` lets you specify "Directory"](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-desktop5-itemtype) ## PR Checklist * [x] Closes #1060 * [x] I work here * [ ] Tests added/passed * [n/a] Requires documentation to be updated ## Detailed Description of the Pull Request / Additional comments This adds a COM class that implements `IExplorerCommand`, which is what lets us populate the context menu entry. We expose that type through a new DLL that is simply responsible for the shell extension, so that explorer doesn't need to load the entire Terminal just to populate that entry. The COM class is tied to the application through some new entries in the manifest. The Clsid values are IMPORTANT - they must match the UUID of the implementation type. However, the `Verb` in the manifest didn't seem important.
2020-05-28 17:42:13 +02:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Release|x64.ActiveCfg = Release|x64
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Release|x64.Build.0 = Release|x64
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Release|x86.ActiveCfg = Release|Win32
{F2ED628A-DB22-446F-A081-4CC845B51A2B}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|x64.ActiveCfg = AuditMode|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.AuditMode|x86.ActiveCfg = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|x64.ActiveCfg = Debug|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|x64.Build.0 = Debug|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|x86.ActiveCfg = Debug|Win32
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|ARM64.ActiveCfg = Release|ARM64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|x64.ActiveCfg = Release|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|x64.Build.0 = Release|x64
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|x86.ActiveCfg = Release|Win32
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|x64.ActiveCfg = AuditMode|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|x64.Build.0 = AuditMode|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.AuditMode|x86.Build.0 = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|ARM.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|ARM64.ActiveCfg = Debug|ARM64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|x64.ActiveCfg = Debug|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|x64.Build.0 = Debug|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|x86.ActiveCfg = Debug|Win32
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Fuzzing|x64.Build.0 = Fuzzing|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|ARM.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|ARM64.ActiveCfg = Release|ARM64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|x64.ActiveCfg = Release|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|x64.Build.0 = Release|x64
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|x86.ActiveCfg = Release|Win32
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|x64.ActiveCfg = AuditMode|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.AuditMode|x86.ActiveCfg = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|ARM.ActiveCfg = Debug|Win32
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|ARM64.ActiveCfg = Debug|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|x64.ActiveCfg = Debug|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|x64.Build.0 = Debug|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|x86.ActiveCfg = Debug|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|ARM.ActiveCfg = Release|Win32
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|ARM64.ActiveCfg = Release|ARM64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|x64.ActiveCfg = Release|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|x64.Build.0 = Release|x64
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|x86.ActiveCfg = Release|Win32
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|x64.ActiveCfg = AuditMode|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|x64.Build.0 = AuditMode|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.AuditMode|x86.Build.0 = AuditMode|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|ARM.ActiveCfg = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|ARM64.ActiveCfg = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|DotNet_x64Test.Build.0 = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|DotNet_x86Test.Build.0 = Debug|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|x64.ActiveCfg = Debug|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|x64.Build.0 = Debug|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|x86.ActiveCfg = Debug|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|ARM.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|DotNet_x64Test.Build.0 = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|DotNet_x86Test.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|x64.ActiveCfg = Release|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|x64.Build.0 = Release|x64
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|x86.ActiveCfg = Release|Win32
{84848BFA-931D-42CE-9ADF-01EE54DE7890}.Release|x86.Build.0 = Release|Win32
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|Any CPU.ActiveCfg = Release|Any CPU
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|ARM.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|ARM.Build.0 = Debug|Any CPU
Fix our parallel (and repeating) builds (#3412) The WAP packaging project in VS <= 16.3.7 produces a couple global properties as part of its normal operation that cause MSBuild to flag our projects as out-of-date and requiring a rebuild. By forcing those properties to match the WAP values, we can get consistent builds. One of those properties, however, is "GenerateAppxPackageOnBuild", and WAP sets it to *false*. When we set that, of course, we don't get an MSIX out of our build pipeline. Therefore, we have to break our build into two phases -- build, then package. This required us to change our approach to PCH deletion. A project without a PCH is *also* considered out-of-date. Now, we keep all PCH files but truncate them to 0 bytes. TerminalApp, however, is re-linked during packaging because the Xaml compiler emits a new generated C++ file on every build. We have to keep those PCHs around. * Remove WpfTerminalControl AnyCPU from Arch-specific builds This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level. This also cleans up some new projects that were added and build for "Any CPU".
2019-11-01 22:38:13 +01:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|ARM64.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|ARM64.Build.0 = Debug|Any CPU
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|DotNet_x64Test.ActiveCfg = Release|Any CPU
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|DotNet_x86Test.ActiveCfg = Release|Any CPU
Fix our parallel (and repeating) builds (#3412) The WAP packaging project in VS <= 16.3.7 produces a couple global properties as part of its normal operation that cause MSBuild to flag our projects as out-of-date and requiring a rebuild. By forcing those properties to match the WAP values, we can get consistent builds. One of those properties, however, is "GenerateAppxPackageOnBuild", and WAP sets it to *false*. When we set that, of course, we don't get an MSIX out of our build pipeline. Therefore, we have to break our build into two phases -- build, then package. This required us to change our approach to PCH deletion. A project without a PCH is *also* considered out-of-date. Now, we keep all PCH files but truncate them to 0 bytes. TerminalApp, however, is re-linked during packaging because the Xaml compiler emits a new generated C++ file on every build. We have to keep those PCHs around. * Remove WpfTerminalControl AnyCPU from Arch-specific builds This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level. This also cleans up some new projects that were added and build for "Any CPU".
2019-11-01 22:38:13 +01:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|x64.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|x64.Build.0 = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|x86.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.AuditMode|x86.Build.0 = Debug|Any CPU
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|Any CPU.Build.0 = Debug|Any CPU
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|ARM.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|ARM.Build.0 = Debug|Any CPU
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|ARM64.ActiveCfg = Debug|Any CPU
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|DotNet_x64Test.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|DotNet_x64Test.Build.0 = Debug|Any CPU
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|DotNet_x86Test.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|DotNet_x86Test.Build.0 = Debug|Any CPU
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|x64.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Debug|x86.ActiveCfg = Debug|Any CPU
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Fuzzing|Any CPU.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Fuzzing|ARM.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Fuzzing|ARM64.ActiveCfg = Fuzzing|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Fuzzing|DotNet_x86Test.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Fuzzing|x64.ActiveCfg = Debug|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Fuzzing|x86.ActiveCfg = Fuzzing|Any CPU
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|Any CPU.ActiveCfg = Release|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|Any CPU.Build.0 = Release|Any CPU
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|ARM.ActiveCfg = Release|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|ARM.Build.0 = Release|Any CPU
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|ARM64.ActiveCfg = Release|Any CPU
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|DotNet_x64Test.ActiveCfg = Release|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|DotNet_x64Test.Build.0 = Release|Any CPU
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|DotNet_x86Test.ActiveCfg = Release|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|DotNet_x86Test.Build.0 = Release|Any CPU
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|x64.ActiveCfg = Release|Any CPU
{376FE273-6B84-4EB5-8B30-8DE9D21B022C}.Release|x86.ActiveCfg = Release|Any CPU
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.AuditMode|x86.ActiveCfg = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|ARM.ActiveCfg = Debug|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|ARM.ActiveCfg = Release|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.AuditMode|x86.ActiveCfg = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|ARM.ActiveCfg = Debug|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|ARM.ActiveCfg = Release|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-9A12-429C-B551-8562EC954746}.Release|x86.Build.0 = Release|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.AuditMode|x86.ActiveCfg = AuditMode|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|ARM.ActiveCfg = Debug|Win32
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
add wpf control (#2004) This adds the WPF control to our project, courtesy of the Visual Studio team. It re-hosts the Terminal Control components inside a reusable WPF adapter so it can be composed onto C# type surfaces like Visual Studio requires.
2019-10-11 23:02:09 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|ARM.ActiveCfg = Release|Win32
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Add a Local Test binary, to enable local TerminalApp testing (#2294) In #1164 we learned that our CI doesn't support WinRT testing. This made us all sad. Since that merged, we haven't really added any TerminalApp tests, because it's a little too hard. You'd have to uncomment the entire file, and if the list of types changed you'd have to manually update the sxs manifest and appxmanifest. Since that was all insane, I created a new Terminal App unittesting project without those problems. 1. The project is not named *Unit*Test*, so the CI won't run it, but it will run locally. 2. The project will auto-generate its SxS manifest, using the work from #1987. 3. We'll use the SxS manifest from step 2 to generate an AppxManifest for running packaged tests. * This is the start of me trying to enable local unittesting again * We've got a new unittests project that isn't named *unit*test* * We're manually generating the SxS manifest for it. B/C we need to use it at runtime, we need to manually combine it into one manifest file * the runas:UAP thing still doesn't work. We'll investigate. * This shockingly works but I'm still stuck with: ``` Summary of Errors Outside of Tests: Error: TAEF: [HRESULT: 0x80270254] Failed to create the test host process for out of process test execution. (The IApplicationActivationManager::ActivateApplication call failed while using a default host. TAEF's ETW logs which are gathered with the /enableEtwLogging switch should contain events from relevant providers that may help to diagnose the failure.) ``` * Cleaning this all up for review. Frankly just pushing to see if it'll work in CI * Couple things I noticed in the diff from master * Apply @dhowett-msft's suggestions from code review
2019-08-13 15:23:28 +02:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506}.Release|x86.Build.0 = Release|Win32
Fix our parallel (and repeating) builds (#3412) The WAP packaging project in VS <= 16.3.7 produces a couple global properties as part of its normal operation that cause MSBuild to flag our projects as out-of-date and requiring a rebuild. By forcing those properties to match the WAP values, we can get consistent builds. One of those properties, however, is "GenerateAppxPackageOnBuild", and WAP sets it to *false*. When we set that, of course, we don't get an MSIX out of our build pipeline. Therefore, we have to break our build into two phases -- build, then package. This required us to change our approach to PCH deletion. A project without a PCH is *also* considered out-of-date. Now, we keep all PCH files but truncate them to 0 bytes. TerminalApp, however, is re-linked during packaging because the Xaml compiler emits a new generated C++ file on every build. We have to keep those PCHs around. * Remove WpfTerminalControl AnyCPU from Arch-specific builds This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level. This also cleans up some new projects that were added and build for "Any CPU".
2019-11-01 22:38:13 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|x64.ActiveCfg = AuditMode|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|x64.Build.0 = AuditMode|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{48D21369-3D7B-4431-9967-24E81292CF63}.AuditMode|x86.Build.0 = AuditMode|Win32
Fix our parallel (and repeating) builds (#3412) The WAP packaging project in VS <= 16.3.7 produces a couple global properties as part of its normal operation that cause MSBuild to flag our projects as out-of-date and requiring a rebuild. By forcing those properties to match the WAP values, we can get consistent builds. One of those properties, however, is "GenerateAppxPackageOnBuild", and WAP sets it to *false*. When we set that, of course, we don't get an MSIX out of our build pipeline. Therefore, we have to break our build into two phases -- build, then package. This required us to change our approach to PCH deletion. A project without a PCH is *also* considered out-of-date. Now, we keep all PCH files but truncate them to 0 bytes. TerminalApp, however, is re-linked during packaging because the Xaml compiler emits a new generated C++ file on every build. We have to keep those PCHs around. * Remove WpfTerminalControl AnyCPU from Arch-specific builds This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level. This also cleans up some new projects that were added and build for "Any CPU".
2019-11-01 22:38:13 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|ARM.ActiveCfg = Debug|Win32
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|ARM64.ActiveCfg = Debug|ARM64
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|x64.ActiveCfg = Debug|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|x64.Build.0 = Debug|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|x86.ActiveCfg = Debug|Win32
{48D21369-3D7B-4431-9967-24E81292CF63}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{48D21369-3D7B-4431-9967-24E81292CF63}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{48D21369-3D7B-4431-9967-24E81292CF63}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{48D21369-3D7B-4431-9967-24E81292CF63}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{48D21369-3D7B-4431-9967-24E81292CF63}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{48D21369-3D7B-4431-9967-24E81292CF63}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Fix our parallel (and repeating) builds (#3412) The WAP packaging project in VS <= 16.3.7 produces a couple global properties as part of its normal operation that cause MSBuild to flag our projects as out-of-date and requiring a rebuild. By forcing those properties to match the WAP values, we can get consistent builds. One of those properties, however, is "GenerateAppxPackageOnBuild", and WAP sets it to *false*. When we set that, of course, we don't get an MSIX out of our build pipeline. Therefore, we have to break our build into two phases -- build, then package. This required us to change our approach to PCH deletion. A project without a PCH is *also* considered out-of-date. Now, we keep all PCH files but truncate them to 0 bytes. TerminalApp, however, is re-linked during packaging because the Xaml compiler emits a new generated C++ file on every build. We have to keep those PCHs around. * Remove WpfTerminalControl AnyCPU from Arch-specific builds This removes another source of build nondeterminism: that WpfTerminalControl was propagating TargetFramework into architecture-specific C++ builds. Its "Any CPU" platform has been removed from architecture builds at the solution level. This also cleans up some new projects that were added and build for "Any CPU".
2019-11-01 22:38:13 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|ARM.ActiveCfg = Release|Win32
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|ARM64.ActiveCfg = Release|ARM64
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|x64.ActiveCfg = Release|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|x64.Build.0 = Release|x64
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|x86.ActiveCfg = Release|Win32
{48D21369-3D7B-4431-9967-24E81292CF63}.Release|x86.Build.0 = Release|Win32
Introduce a WinRT utils library and "checked resources" (#3350) 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] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|Any CPU.ActiveCfg = Release|x64
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Introduce a WinRT utils library and "checked resources" (#3350) 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] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|ARM64.ActiveCfg = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|DotNet_x64Test.ActiveCfg = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|DotNet_x86Test.ActiveCfg = Release|x64
Enable Audit Mode for WinRTUtils (#3923) ## Summary of the Pull Request Turns on Audit for WinRTUtils, fixes audit failures. ## PR Checklist * [x] I work here * [x] Still builds * [x] Am core contributor. ## Validation Steps Performed Built it.
2019-12-12 14:28:32 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|x64.Build.0 = AuditMode|x64
Introduce a WinRT utils library and "checked resources" (#3350) 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] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.AuditMode|x86.ActiveCfg = Release|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|ARM.ActiveCfg = Debug|Win32
Introduce a WinRT utils library and "checked resources" (#3350) 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] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Introduce a WinRT utils library and "checked resources" (#3350) 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] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Introduce a WinRT utils library and "checked resources" (#3350) 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] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|ARM.ActiveCfg = Release|Win32
Introduce a WinRT utils library and "checked resources" (#3350) 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] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Introduce a WinRT utils library and "checked resources" (#3350) 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] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE}.Release|x86.Build.0 = Release|Win32
Introduce a Universal package for Windows Terminal (#3236) 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.
2019-11-26 01:30:45 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|Any CPU.ActiveCfg = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|Any CPU.Build.0 = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|Any CPU.Deploy.0 = Release|x64
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Introduce a Universal package for Windows Terminal (#3236) 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.
2019-11-26 01:30:45 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|ARM64.ActiveCfg = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|ARM64.Build.0 = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|ARM64.Deploy.0 = Release|x64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|DotNet_x64Test.ActiveCfg = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|DotNet_x86Test.ActiveCfg = Release|x64
Introduce a Universal package for Windows Terminal (#3236) 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.
2019-11-26 01:30:45 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x64.ActiveCfg = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x86.ActiveCfg = Release|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x86.Build.0 = Release|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.AuditMode|x86.Deploy.0 = Release|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|ARM.ActiveCfg = Debug|Win32
Introduce a Universal package for Windows Terminal (#3236) 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.
2019-11-26 01:30:45 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|ARM64.ActiveCfg = Debug|Win32
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Introduce a Universal package for Windows Terminal (#3236) 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.
2019-11-26 01:30:45 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x64.ActiveCfg = Debug|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x64.Build.0 = Debug|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x64.Deploy.0 = Debug|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x86.ActiveCfg = Debug|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x86.Build.0 = Debug|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Debug|x86.Deploy.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Introduce a Universal package for Windows Terminal (#3236) 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.
2019-11-26 01:30:45 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|ARM.ActiveCfg = Release|Win32
Enable signing and ARM64 for Universal Terminal (#3716)
2019-11-26 23:25:54 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|ARM64.ActiveCfg = Release|ARM64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|ARM64.Build.0 = Release|ARM64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|ARM64.Deploy.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Introduce a Universal package for Windows Terminal (#3236) 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.
2019-11-26 01:30:45 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x64.ActiveCfg = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x64.Build.0 = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x64.Deploy.0 = Release|x64
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x86.ActiveCfg = Release|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x86.Build.0 = Release|Win32
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1}.Release|x86.Deploy.0 = Release|Win32
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Apply audit mode to TerminalConnection/Core/Settings and WinCon… (#4016) ## Summary of the Pull Request - Enables auditing of some Terminal libraries (Connection, Core, Settings) - Also audit WinConPTY.LIB since Connection depends on it ## PR Checklist * [x] Rolls audit out to more things * [x] I work here * [x] Tests should still pass * [x] Am core contributor ## Detailed Description of the Pull Request / Additional comments This is turning on the auditing of these projects (as enabled by the heavier lifting in the other refactor) and then cleaning up the remaining warnings. ## Validation Steps Performed - [x] Built it - [x] Ran the tests
2020-01-03 19:44:27 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|x64.ActiveCfg = AuditMode|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|x64.Build.0 = AuditMode|x64
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.AuditMode|x86.Build.0 = AuditMode|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|ARM.ActiveCfg = Debug|Win32
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|ARM64.ActiveCfg = Debug|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|DotNet_x86Test.ActiveCfg = Debug|x64
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x64.ActiveCfg = Debug|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x64.Build.0 = Debug|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x86.ActiveCfg = Debug|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|ARM.ActiveCfg = Release|Win32
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|ARM64.ActiveCfg = Release|ARM64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|DotNet_x64Test.ActiveCfg = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|DotNet_x86Test.ActiveCfg = Release|x64
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x64.ActiveCfg = Release|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x64.Build.0 = Release|x64
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x86.ActiveCfg = Release|Win32
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A}.Release|x86.Build.0 = Release|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|x64.ActiveCfg = Release|x64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.AuditMode|x86.Build.0 = AuditMode|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|ARM.ActiveCfg = Debug|Win32
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|ARM64.ActiveCfg = Debug|ARM64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|DotNet_x86Test.ActiveCfg = Debug|x64
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|x64.ActiveCfg = Debug|x64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|x64.Build.0 = Debug|x64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|x86.ActiveCfg = Debug|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|ARM.ActiveCfg = Release|Win32
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|ARM64.ActiveCfg = Release|ARM64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|DotNet_x64Test.ActiveCfg = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|DotNet_x86Test.ActiveCfg = Release|x64
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|x64.ActiveCfg = Release|x64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|x64.Build.0 = Release|x64
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|x86.ActiveCfg = Release|Win32
{A22EC5F6-7851-4B88-AC52-47249D437A52}.Release|x86.Build.0 = Release|Win32
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.AuditMode|Any CPU.ActiveCfg = AuditMode|x64
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|x64
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.AuditMode|x64.ActiveCfg = AuditMode|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|ARM.ActiveCfg = Debug|Win32
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|ARM64.ActiveCfg = Debug|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|ARM64.Build.0 = Debug|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|ARM64.Deploy.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x64.ActiveCfg = Debug|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x64.Build.0 = Debug|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x64.Deploy.0 = Debug|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x86.ActiveCfg = Debug|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x86.Build.0 = Debug|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Debug|x86.Deploy.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|ARM.ActiveCfg = Release|Win32
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|ARM64.ActiveCfg = Release|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|ARM64.Build.0 = Release|ARM64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|ARM64.Deploy.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x64.ActiveCfg = Release|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x64.Build.0 = Release|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x64.Deploy.0 = Release|x64
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x86.ActiveCfg = Release|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x86.Build.0 = Release|Win32
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8}.Release|x86.Deploy.0 = Release|Win32
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|x64.ActiveCfg = Release|x64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.AuditMode|x86.Build.0 = AuditMode|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|ARM.ActiveCfg = Debug|Win32
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|ARM64.ActiveCfg = Debug|ARM64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|x64.ActiveCfg = Debug|x64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|x64.Build.0 = Debug|x64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|x86.ActiveCfg = Debug|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|ARM.ActiveCfg = Release|Win32
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|ARM64.ActiveCfg = Release|ARM64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|x64.ActiveCfg = Release|x64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|x64.Build.0 = Release|x64
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|x86.ActiveCfg = Release|Win32
{767268EE-174A-46FE-96F0-EEE698A1BBC9}.Release|x86.Build.0 = Release|Win32
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|Any CPU.ActiveCfg = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|Any CPU.Build.0 = Release|x64
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|ARM64.ActiveCfg = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|ARM64.Build.0 = Release|x64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|DotNet_x64Test.ActiveCfg = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|DotNet_x86Test.ActiveCfg = Release|x64
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|x64.ActiveCfg = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|x64.Build.0 = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|x86.ActiveCfg = Release|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.AuditMode|x86.Build.0 = Release|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|ARM.ActiveCfg = Debug|Win32
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|ARM64.ActiveCfg = Debug|Win32
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|x64.ActiveCfg = Debug|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|x64.Build.0 = Debug|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|x86.ActiveCfg = Debug|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|ARM.ActiveCfg = Release|Win32
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|ARM64.ActiveCfg = Release|Win32
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|x64.ActiveCfg = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|x64.Build.0 = Release|x64
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|x86.ActiveCfg = Release|Win32
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1}.Release|x86.Build.0 = Release|Win32
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|x64.ActiveCfg = Release|x64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.AuditMode|x86.Build.0 = AuditMode|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|ARM.ActiveCfg = Debug|Win32
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|ARM64.ActiveCfg = Debug|ARM64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|x64.ActiveCfg = Debug|x64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|x64.Build.0 = Debug|x64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|x86.ActiveCfg = Debug|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|ARM.ActiveCfg = Release|Win32
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|ARM64.ActiveCfg = Release|ARM64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|x64.ActiveCfg = Release|x64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|x64.Build.0 = Release|x64
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|x86.ActiveCfg = Release|Win32
{95B136F9-B238-490C-A7C5-5843C1FECAC4}.Release|x86.Build.0 = Release|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|x64.ActiveCfg = Release|x64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.AuditMode|x86.Build.0 = AuditMode|Win32
Migrate the ConPTY functional tests out of Windows (#4648) ## Summary of the Pull Request This will allow us to run the ConPTY tests in CI. ## PR Checklist * [x] Closes MSFT:24265197 * [X] I've discussed this with core contributors already. ## Validation Steps Performed I've run the tests. Please note: this code is unchanged (apart from `wil::ScopeExit` -> `wil::scope_exit`) from Windows. Now is not the time to comment on their perfectness.
2020-02-19 22:27:17 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|ARM.ActiveCfg = Debug|Win32
Migrate the ConPTY functional tests out of Windows (#4648) ## Summary of the Pull Request This will allow us to run the ConPTY tests in CI. ## PR Checklist * [x] Closes MSFT:24265197 * [X] I've discussed this with core contributors already. ## Validation Steps Performed I've run the tests. Please note: this code is unchanged (apart from `wil::ScopeExit` -> `wil::scope_exit`) from Windows. Now is not the time to comment on their perfectness.
2020-02-19 22:27:17 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|ARM64.ActiveCfg = Debug|ARM64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Migrate the ConPTY functional tests out of Windows (#4648) ## Summary of the Pull Request This will allow us to run the ConPTY tests in CI. ## PR Checklist * [x] Closes MSFT:24265197 * [X] I've discussed this with core contributors already. ## Validation Steps Performed I've run the tests. Please note: this code is unchanged (apart from `wil::ScopeExit` -> `wil::scope_exit`) from Windows. Now is not the time to comment on their perfectness.
2020-02-19 22:27:17 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|x64.ActiveCfg = Debug|x64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|x64.Build.0 = Debug|x64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|x86.ActiveCfg = Debug|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Migrate the ConPTY functional tests out of Windows (#4648) ## Summary of the Pull Request This will allow us to run the ConPTY tests in CI. ## PR Checklist * [x] Closes MSFT:24265197 * [X] I've discussed this with core contributors already. ## Validation Steps Performed I've run the tests. Please note: this code is unchanged (apart from `wil::ScopeExit` -> `wil::scope_exit`) from Windows. Now is not the time to comment on their perfectness.
2020-02-19 22:27:17 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|ARM.ActiveCfg = Release|Win32
Migrate the ConPTY functional tests out of Windows (#4648) ## Summary of the Pull Request This will allow us to run the ConPTY tests in CI. ## PR Checklist * [x] Closes MSFT:24265197 * [X] I've discussed this with core contributors already. ## Validation Steps Performed I've run the tests. Please note: this code is unchanged (apart from `wil::ScopeExit` -> `wil::scope_exit`) from Windows. Now is not the time to comment on their perfectness.
2020-02-19 22:27:17 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|ARM64.ActiveCfg = Release|ARM64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Migrate the ConPTY functional tests out of Windows (#4648) ## Summary of the Pull Request This will allow us to run the ConPTY tests in CI. ## PR Checklist * [x] Closes MSFT:24265197 * [X] I've discussed this with core contributors already. ## Validation Steps Performed I've run the tests. Please note: this code is unchanged (apart from `wil::ScopeExit` -> `wil::scope_exit`) from Windows. Now is not the time to comment on their perfectness.
2020-02-19 22:27:17 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|x64.ActiveCfg = Release|x64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|x64.Build.0 = Release|x64
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|x86.ActiveCfg = Release|Win32
{024052DE-83FB-4653-AEA4-90790D29D5BD}.Release|x86.Build.0 = Release|Win32
Clip text to within the row we expect (#4671) ## Summary of the Pull Request Adjusts `DrawGlyphRun` method inside DirectX renderer to restrict text to be clipped within the boundaries of the row. ## PR Checklist * [x] Closes #1703 * [x] I work here. * [x] No tests. * [x] No docs. * [x] I am core contributor. ## Detailed Description of the Pull Request / Additional comments For whatever reason, some of these shade glyphs near U+2591 tend to extend way above the height of where we expect they should. This didn't look like a problem in conhost because it clipped every draw inside the bounds. This therefore applies the same clip logic as people don't really expect text to pour out of the box. It could, theoretically, get us into trouble later should someone attempt zalgo text. But doing zalgo text is more of a silliness that varies in behavior across rendering platforms anyway. ## Validation Steps Performed - Ran the old conhost GDI renderer and observed - Ran the new Terminal DX renderer and observed - Made the code change - Observed that the height and approximate display characteristics of the U+2591 shade and neighboring characters now matches with the conhost GDI style to stay within its lane.
2020-02-21 01:57:14 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Clip text to within the row we expect (#4671) ## Summary of the Pull Request Adjusts `DrawGlyphRun` method inside DirectX renderer to restrict text to be clipped within the boundaries of the row. ## PR Checklist * [x] Closes #1703 * [x] I work here. * [x] No tests. * [x] No docs. * [x] I am core contributor. ## Detailed Description of the Pull Request / Additional comments For whatever reason, some of these shade glyphs near U+2591 tend to extend way above the height of where we expect they should. This didn't look like a problem in conhost because it clipped every draw inside the bounds. This therefore applies the same clip logic as people don't really expect text to pour out of the box. It could, theoretically, get us into trouble later should someone attempt zalgo text. But doing zalgo text is more of a silliness that varies in behavior across rendering platforms anyway. ## Validation Steps Performed - Ran the old conhost GDI renderer and observed - Ran the new Terminal DX renderer and observed - Made the code change - Observed that the height and approximate display characteristics of the U+2591 shade and neighboring characters now matches with the conhost GDI style to stay within its lane.
2020-02-21 01:57:14 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Clip text to within the row we expect (#4671) ## Summary of the Pull Request Adjusts `DrawGlyphRun` method inside DirectX renderer to restrict text to be clipped within the boundaries of the row. ## PR Checklist * [x] Closes #1703 * [x] I work here. * [x] No tests. * [x] No docs. * [x] I am core contributor. ## Detailed Description of the Pull Request / Additional comments For whatever reason, some of these shade glyphs near U+2591 tend to extend way above the height of where we expect they should. This didn't look like a problem in conhost because it clipped every draw inside the bounds. This therefore applies the same clip logic as people don't really expect text to pour out of the box. It could, theoretically, get us into trouble later should someone attempt zalgo text. But doing zalgo text is more of a silliness that varies in behavior across rendering platforms anyway. ## Validation Steps Performed - Ran the old conhost GDI renderer and observed - Ran the new Terminal DX renderer and observed - Made the code change - Observed that the height and approximate display characteristics of the U+2591 shade and neighboring characters now matches with the conhost GDI style to stay within its lane.
2020-02-21 01:57:14 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.AuditMode|x64.ActiveCfg = Release|x64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.AuditMode|x86.Build.0 = AuditMode|Win32
Shim the AzureConn through a conhost to stop VT bleeding (#4652) This commit introduces a small console-subsystem application whose sole job is to consume TerminalConnection.dll and hook it up to something other than Terminal. It is 99% of the way to a generic solution. I've introduced a stopgap in TerminalPage that makes sure we launch TerminalAzBridge using ConptyConnection instead of AzureConnection. As a bonus, this commit includes a class whose sole job it is to make reading VT input off a console handle not terrible. It returns you a string and dispatches window size change callbacks. Fixes #2267. Fixes #4589. Related to #2266 (since pwsh needs better VT).
2020-02-21 01:21:05 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|ARM.ActiveCfg = Debug|Win32
Shim the AzureConn through a conhost to stop VT bleeding (#4652) This commit introduces a small console-subsystem application whose sole job is to consume TerminalConnection.dll and hook it up to something other than Terminal. It is 99% of the way to a generic solution. I've introduced a stopgap in TerminalPage that makes sure we launch TerminalAzBridge using ConptyConnection instead of AzureConnection. As a bonus, this commit includes a class whose sole job it is to make reading VT input off a console handle not terrible. It returns you a string and dispatches window size change callbacks. Fixes #2267. Fixes #4589. Related to #2266 (since pwsh needs better VT).
2020-02-21 01:21:05 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|ARM64.ActiveCfg = Debug|ARM64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
Shim the AzureConn through a conhost to stop VT bleeding (#4652) This commit introduces a small console-subsystem application whose sole job is to consume TerminalConnection.dll and hook it up to something other than Terminal. It is 99% of the way to a generic solution. I've introduced a stopgap in TerminalPage that makes sure we launch TerminalAzBridge using ConptyConnection instead of AzureConnection. As a bonus, this commit includes a class whose sole job it is to make reading VT input off a console handle not terrible. It returns you a string and dispatches window size change callbacks. Fixes #2267. Fixes #4589. Related to #2266 (since pwsh needs better VT).
2020-02-21 01:21:05 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|x64.ActiveCfg = Debug|x64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|x64.Build.0 = Debug|x64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|x86.ActiveCfg = Debug|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Shim the AzureConn through a conhost to stop VT bleeding (#4652) This commit introduces a small console-subsystem application whose sole job is to consume TerminalConnection.dll and hook it up to something other than Terminal. It is 99% of the way to a generic solution. I've introduced a stopgap in TerminalPage that makes sure we launch TerminalAzBridge using ConptyConnection instead of AzureConnection. As a bonus, this commit includes a class whose sole job it is to make reading VT input off a console handle not terrible. It returns you a string and dispatches window size change callbacks. Fixes #2267. Fixes #4589. Related to #2266 (since pwsh needs better VT).
2020-02-21 01:21:05 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|ARM.ActiveCfg = Release|Win32
Shim the AzureConn through a conhost to stop VT bleeding (#4652) This commit introduces a small console-subsystem application whose sole job is to consume TerminalConnection.dll and hook it up to something other than Terminal. It is 99% of the way to a generic solution. I've introduced a stopgap in TerminalPage that makes sure we launch TerminalAzBridge using ConptyConnection instead of AzureConnection. As a bonus, this commit includes a class whose sole job it is to make reading VT input off a console handle not terrible. It returns you a string and dispatches window size change callbacks. Fixes #2267. Fixes #4589. Related to #2266 (since pwsh needs better VT).
2020-02-21 01:21:05 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|ARM64.ActiveCfg = Release|ARM64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
Shim the AzureConn through a conhost to stop VT bleeding (#4652) This commit introduces a small console-subsystem application whose sole job is to consume TerminalConnection.dll and hook it up to something other than Terminal. It is 99% of the way to a generic solution. I've introduced a stopgap in TerminalPage that makes sure we launch TerminalAzBridge using ConptyConnection instead of AzureConnection. As a bonus, this commit includes a class whose sole job it is to make reading VT input off a console handle not terrible. It returns you a string and dispatches window size change callbacks. Fixes #2267. Fixes #4589. Related to #2266 (since pwsh needs better VT).
2020-02-21 01:21:05 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|x64.ActiveCfg = Release|x64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|x64.Build.0 = Release|x64
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|x86.ActiveCfg = Release|Win32
{067F0A06-FCB7-472C-96E9-B03B54E8E18D}.Release|x86.Build.0 = Release|Win32
Import fmtlib/fmt@6.2.0, a C++20-style format library (#5336) 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?
2020-04-14 22:04:23 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Import fmtlib/fmt@6.2.0, a C++20-style format library (#5336) 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?
2020-04-14 22:04:23 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
Import fmtlib/fmt@6.2.0, a C++20-style format library (#5336) 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?
2020-04-14 22:04:23 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x64.ActiveCfg = AuditMode|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x64.Build.0 = AuditMode|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.AuditMode|x86.Build.0 = AuditMode|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|ARM.ActiveCfg = Debug|Win32
Import fmtlib/fmt@6.2.0, a C++20-style format library (#5336) 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?
2020-04-14 22:04:23 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|ARM64.ActiveCfg = Debug|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|ARM64.Build.0 = Debug|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|DotNet_x64Test.Build.0 = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|DotNet_x86Test.Build.0 = Debug|Win32
Import fmtlib/fmt@6.2.0, a C++20-style format library (#5336) 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?
2020-04-14 22:04:23 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x64.ActiveCfg = Debug|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x64.Build.0 = Debug|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x86.ActiveCfg = Debug|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|x64.Build.0 = Fuzzing|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Import fmtlib/fmt@6.2.0, a C++20-style format library (#5336) 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?
2020-04-14 22:04:23 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|ARM.ActiveCfg = Release|Win32
Import fmtlib/fmt@6.2.0, a C++20-style format library (#5336) 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?
2020-04-14 22:04:23 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|ARM64.ActiveCfg = Release|ARM64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|ARM64.Build.0 = Release|ARM64
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|DotNet_x64Test.Build.0 = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|DotNet_x86Test.Build.0 = Release|Win32
Import fmtlib/fmt@6.2.0, a C++20-style format library (#5336) 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?
2020-04-14 22:04:23 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x64.ActiveCfg = Release|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x64.Build.0 = Release|x64
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x86.ActiveCfg = Release|Win32
{6BAE5851-50D5-4934-8D5E-30361A8A40F3}.Release|x86.Build.0 = Release|Win32
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.AuditMode|Any CPU.ActiveCfg = Debug|Any CPU
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.AuditMode|ARM.ActiveCfg = Release|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.AuditMode|ARM.Build.0 = Release|Any CPU
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.AuditMode|ARM64.ActiveCfg = Debug|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|Any CPU
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|Any CPU
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.AuditMode|x64.ActiveCfg = Debug|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.AuditMode|x86.ActiveCfg = Debug|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Debug|ARM.ActiveCfg = Debug|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Debug|ARM.Build.0 = Debug|Any CPU
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Debug|ARM64.ActiveCfg = Debug|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Debug|DotNet_x64Test.Build.0 = Debug|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Debug|DotNet_x86Test.ActiveCfg = Debug|x86
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Debug|DotNet_x86Test.Build.0 = Debug|x86
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Debug|x64.ActiveCfg = Debug|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Debug|x86.ActiveCfg = Debug|Any CPU
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Fuzzing|Any CPU.ActiveCfg = Debug|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Fuzzing|ARM.ActiveCfg = Debug|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Fuzzing|ARM64.ActiveCfg = Fuzzing|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Fuzzing|DotNet_x86Test.ActiveCfg = Debug|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Fuzzing|x64.ActiveCfg = Debug|x64
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Fuzzing|x86.ActiveCfg = Fuzzing|x86
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|Any CPU.ActiveCfg = Release|Any CPU
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|ARM.ActiveCfg = Release|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|ARM.Build.0 = Release|Any CPU
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|ARM64.ActiveCfg = Release|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|DotNet_x64Test.Build.0 = Release|x64
WpfTest: Add an x86/Win32 build, make DPI aware (#6455) This matches more closely how Visual Studio uses the WPF control. It comes in the form of _another platform_ (sorry), `DotNet_x86Test`.
2020-06-10 23:08:16 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|DotNet_x86Test.ActiveCfg = Release|x86
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|DotNet_x86Test.Build.0 = Release|x86
wpf: add a .NET Core WPF Test project for the WPF Control (#6441) This commit introduces a new project that lets you F5 a working instance of the Wpf Terminal Control. To make the experience as seamless as possible, I've introduced another solution platform called "DotNet_x64Test". It is set to build the WPF projects for "Any CPU" and every project that PublicTerminalCore requires (including itself) for "x64". This is the only way to ensure that when you press F5, all of the native and managed dependencies get updated. It's all quite cool when it works.
2020-06-09 22:41:42 +02:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|x64.ActiveCfg = Release|Any CPU
{1588FD7C-241E-4E7D-9113-43735F3E6BAD}.Release|x86.ActiveCfg = Release|Any CPU
Build and ship an actual binary named wt that just launches WT (#6860) Due to a shell limitation, Ctrl+Shift+Enter will not launch Windows Terminal as Administrator. This is caused by the app execution alias and the actual targeted executable not having the same name. In addition, PowerShell has an issue detecting app execution aliases as GUI/TUI applications. When you run wt from PowerShell, the shell will wait for WT to exit before returning to the prompt. Having a shim that immediately re-executes WindowsTerminal and then returns handily knocks this issue out (as the process that PS was waiting for exits immediately.) This could cause a regression for anybody who tries to capture the PID of wt.exe. Our process tree is not an API, and we have offered no consistency guarantee on it. VALIDATION ---------- Tested manual launch in a number of different scenarios: * [x] start menu "wtd" * [x] start menu tile * [x] powertoys run * [x] powertoys run ctrl+shift (admin) * [x] powershell inbox, "core" * [x] cmd * [x] run dialog * [x] run dialog ctrl+shift (admin) * [x] run from a lnk with window mode=maximized Fixes #4645 (PowerShell waits for wt) Fixes #6625 (Can't launch as admin using C-S-enter)
2020-07-11 00:41:37 +02:00
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Build and ship an actual binary named wt that just launches WT (#6860) Due to a shell limitation, Ctrl+Shift+Enter will not launch Windows Terminal as Administrator. This is caused by the app execution alias and the actual targeted executable not having the same name. In addition, PowerShell has an issue detecting app execution aliases as GUI/TUI applications. When you run wt from PowerShell, the shell will wait for WT to exit before returning to the prompt. Having a shim that immediately re-executes WindowsTerminal and then returns handily knocks this issue out (as the process that PS was waiting for exits immediately.) This could cause a regression for anybody who tries to capture the PID of wt.exe. Our process tree is not an API, and we have offered no consistency guarantee on it. VALIDATION ---------- Tested manual launch in a number of different scenarios: * [x] start menu "wtd" * [x] start menu tile * [x] powertoys run * [x] powertoys run ctrl+shift (admin) * [x] powershell inbox, "core" * [x] cmd * [x] run dialog * [x] run dialog ctrl+shift (admin) * [x] run from a lnk with window mode=maximized Fixes #4645 (PowerShell waits for wt) Fixes #6625 (Can't launch as admin using C-S-enter)
2020-07-11 00:41:37 +02:00
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x64.ActiveCfg = AuditMode|x64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x64.Build.0 = AuditMode|x64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.AuditMode|x86.Build.0 = AuditMode|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|ARM.ActiveCfg = Debug|Win32
Build and ship an actual binary named wt that just launches WT (#6860) Due to a shell limitation, Ctrl+Shift+Enter will not launch Windows Terminal as Administrator. This is caused by the app execution alias and the actual targeted executable not having the same name. In addition, PowerShell has an issue detecting app execution aliases as GUI/TUI applications. When you run wt from PowerShell, the shell will wait for WT to exit before returning to the prompt. Having a shim that immediately re-executes WindowsTerminal and then returns handily knocks this issue out (as the process that PS was waiting for exits immediately.) This could cause a regression for anybody who tries to capture the PID of wt.exe. Our process tree is not an API, and we have offered no consistency guarantee on it. VALIDATION ---------- Tested manual launch in a number of different scenarios: * [x] start menu "wtd" * [x] start menu tile * [x] powertoys run * [x] powertoys run ctrl+shift (admin) * [x] powershell inbox, "core" * [x] cmd * [x] run dialog * [x] run dialog ctrl+shift (admin) * [x] run from a lnk with window mode=maximized Fixes #4645 (PowerShell waits for wt) Fixes #6625 (Can't launch as admin using C-S-enter)
2020-07-11 00:41:37 +02:00
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|ARM64.ActiveCfg = Debug|ARM64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|ARM64.Build.0 = Debug|ARM64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x64.ActiveCfg = Debug|x64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x64.Build.0 = Debug|x64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x86.ActiveCfg = Debug|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Build and ship an actual binary named wt that just launches WT (#6860) Due to a shell limitation, Ctrl+Shift+Enter will not launch Windows Terminal as Administrator. This is caused by the app execution alias and the actual targeted executable not having the same name. In addition, PowerShell has an issue detecting app execution aliases as GUI/TUI applications. When you run wt from PowerShell, the shell will wait for WT to exit before returning to the prompt. Having a shim that immediately re-executes WindowsTerminal and then returns handily knocks this issue out (as the process that PS was waiting for exits immediately.) This could cause a regression for anybody who tries to capture the PID of wt.exe. Our process tree is not an API, and we have offered no consistency guarantee on it. VALIDATION ---------- Tested manual launch in a number of different scenarios: * [x] start menu "wtd" * [x] start menu tile * [x] powertoys run * [x] powertoys run ctrl+shift (admin) * [x] powershell inbox, "core" * [x] cmd * [x] run dialog * [x] run dialog ctrl+shift (admin) * [x] run from a lnk with window mode=maximized Fixes #4645 (PowerShell waits for wt) Fixes #6625 (Can't launch as admin using C-S-enter)
2020-07-11 00:41:37 +02:00
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|ARM.ActiveCfg = Release|Win32
Build and ship an actual binary named wt that just launches WT (#6860) Due to a shell limitation, Ctrl+Shift+Enter will not launch Windows Terminal as Administrator. This is caused by the app execution alias and the actual targeted executable not having the same name. In addition, PowerShell has an issue detecting app execution aliases as GUI/TUI applications. When you run wt from PowerShell, the shell will wait for WT to exit before returning to the prompt. Having a shim that immediately re-executes WindowsTerminal and then returns handily knocks this issue out (as the process that PS was waiting for exits immediately.) This could cause a regression for anybody who tries to capture the PID of wt.exe. Our process tree is not an API, and we have offered no consistency guarantee on it. VALIDATION ---------- Tested manual launch in a number of different scenarios: * [x] start menu "wtd" * [x] start menu tile * [x] powertoys run * [x] powertoys run ctrl+shift (admin) * [x] powershell inbox, "core" * [x] cmd * [x] run dialog * [x] run dialog ctrl+shift (admin) * [x] run from a lnk with window mode=maximized Fixes #4645 (PowerShell waits for wt) Fixes #6625 (Can't launch as admin using C-S-enter)
2020-07-11 00:41:37 +02:00
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|ARM64.ActiveCfg = Release|ARM64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|ARM64.Build.0 = Release|ARM64
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{506FD703-BAA7-4F6E-9361-64F550EC8FCA}.Release|x64.ActiveCfg = Release|x64
{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
Introduce the Terminal Settings Editor (#8048) This commit introduces the terminal settings editor (to wit: the Settings UI) as a standalone project. This project, and this commit, is the result of two and a half months of work. TSE started as a hackathon project in the Microsoft 2020 Hackathon, and from there it's grown to be a bona-fide graphical settings editor. There is a lot of xaml data binding in here, a number of views and a number of view models, and a bunch of paradigms that we've been reviewing and testing out and designing and refining. Specified in #6720, #8269 Follow-up work in #6800 Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com> Co-authored-by: Alberto Medina Gutierrez <almedina@microsoft.com> Co-authored-by: John Grandle <jograndl@microsoft.com> Co-authored-by: xerootg <xerootg@users.noreply.github.com> Co-authored-by: Scott <sarmiger1@gmail.com> Co-authored-by: Vineeth Thomas Alex <vineeththomasalex@gmail.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Dustin L. Howett <duhowett@microsoft.com> Signed-off-by: Dustin L. Howett <duhowett@microsoft.com>
2020-12-11 22:34:21 +01:00
{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
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Introduce the Terminal Settings Editor (#8048) This commit introduces the terminal settings editor (to wit: the Settings UI) as a standalone project. This project, and this commit, is the result of two and a half months of work. TSE started as a hackathon project in the Microsoft 2020 Hackathon, and from there it's grown to be a bona-fide graphical settings editor. There is a lot of xaml data binding in here, a number of views and a number of view models, and a bunch of paradigms that we've been reviewing and testing out and designing and refining. Specified in #6720, #8269 Follow-up work in #6800 Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com> Co-authored-by: Alberto Medina Gutierrez <almedina@microsoft.com> Co-authored-by: John Grandle <jograndl@microsoft.com> Co-authored-by: xerootg <xerootg@users.noreply.github.com> Co-authored-by: Scott <sarmiger1@gmail.com> Co-authored-by: Vineeth Thomas Alex <vineeththomasalex@gmail.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Dustin L. Howett <duhowett@microsoft.com> Signed-off-by: Dustin L. Howett <duhowett@microsoft.com>
2020-12-11 22:34:21 +01:00
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|ARM64.ActiveCfg = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|ARM64.Build.0 = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|ARM64.Deploy.0 = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|DotNet_x64Test.ActiveCfg = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|DotNet_x64Test.Build.0 = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|DotNet_x64Test.Deploy.0 = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|DotNet_x86Test.ActiveCfg = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|DotNet_x86Test.Build.0 = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|DotNet_x86Test.Deploy.0 = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|x64.Deploy.0 = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|x86.ActiveCfg = Release|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|x86.Build.0 = Release|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.AuditMode|x86.Deploy.0 = Release|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|ARM.ActiveCfg = Debug|Win32
Introduce the Terminal Settings Editor (#8048) This commit introduces the terminal settings editor (to wit: the Settings UI) as a standalone project. This project, and this commit, is the result of two and a half months of work. TSE started as a hackathon project in the Microsoft 2020 Hackathon, and from there it's grown to be a bona-fide graphical settings editor. There is a lot of xaml data binding in here, a number of views and a number of view models, and a bunch of paradigms that we've been reviewing and testing out and designing and refining. Specified in #6720, #8269 Follow-up work in #6800 Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com> Co-authored-by: Alberto Medina Gutierrez <almedina@microsoft.com> Co-authored-by: John Grandle <jograndl@microsoft.com> Co-authored-by: xerootg <xerootg@users.noreply.github.com> Co-authored-by: Scott <sarmiger1@gmail.com> Co-authored-by: Vineeth Thomas Alex <vineeththomasalex@gmail.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Dustin L. Howett <duhowett@microsoft.com> Signed-off-by: Dustin L. Howett <duhowett@microsoft.com>
2020-12-11 22:34:21 +01:00
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|x64.Deploy.0 = Debug|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|x86.Build.0 = Debug|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Debug|x86.Deploy.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Introduce the Terminal Settings Editor (#8048) This commit introduces the terminal settings editor (to wit: the Settings UI) as a standalone project. This project, and this commit, is the result of two and a half months of work. TSE started as a hackathon project in the Microsoft 2020 Hackathon, and from there it's grown to be a bona-fide graphical settings editor. There is a lot of xaml data binding in here, a number of views and a number of view models, and a bunch of paradigms that we've been reviewing and testing out and designing and refining. Specified in #6720, #8269 Follow-up work in #6800 Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com> Co-authored-by: Alberto Medina Gutierrez <almedina@microsoft.com> Co-authored-by: John Grandle <jograndl@microsoft.com> Co-authored-by: xerootg <xerootg@users.noreply.github.com> Co-authored-by: Scott <sarmiger1@gmail.com> Co-authored-by: Vineeth Thomas Alex <vineeththomasalex@gmail.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Dustin L. Howett <duhowett@microsoft.com> Signed-off-by: Dustin L. Howett <duhowett@microsoft.com>
2020-12-11 22:34:21 +01:00
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|ARM.ActiveCfg = Release|Win32
Introduce the Terminal Settings Editor (#8048) This commit introduces the terminal settings editor (to wit: the Settings UI) as a standalone project. This project, and this commit, is the result of two and a half months of work. TSE started as a hackathon project in the Microsoft 2020 Hackathon, and from there it's grown to be a bona-fide graphical settings editor. There is a lot of xaml data binding in here, a number of views and a number of view models, and a bunch of paradigms that we've been reviewing and testing out and designing and refining. Specified in #6720, #8269 Follow-up work in #6800 Closes #1564 Closes #8048 (PR) Co-authored-by: Carlos Zamora <carlos.zamora@microsoft.com> Co-authored-by: Kayla Cinnamon <cinnamon@microsoft.com> Co-authored-by: Alberto Medina Gutierrez <almedina@microsoft.com> Co-authored-by: John Grandle <jograndl@microsoft.com> Co-authored-by: xerootg <xerootg@users.noreply.github.com> Co-authored-by: Scott <sarmiger1@gmail.com> Co-authored-by: Vineeth Thomas Alex <vineeththomasalex@gmail.com> Co-authored-by: Leon Liang <lelian@microsoft.com> Co-authored-by: Dustin L. Howett <duhowett@microsoft.com> Signed-off-by: Dustin L. Howett <duhowett@microsoft.com>
2020-12-11 22:34:21 +01:00
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|x64.Deploy.0 = Release|x64
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-0B5E-45C3-96A8-BB496BFE4E32}.Release|x86.Deploy.0 = Release|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.AuditMode|x86.Build.0 = AuditMode|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|ARM.ActiveCfg = Debug|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|ARM.ActiveCfg = Release|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-D7EC-4107-B7C6-79CB77AE2907}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-082C-4476-9F33-94B339494076}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-082C-4476-9F33-94B339494076}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{CA5CAD1A-082C-4476-9F33-94B339494076}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{CA5CAD1A-082C-4476-9F33-94B339494076}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.AuditMode|x64.ActiveCfg = Release|x64
{CA5CAD1A-082C-4476-9F33-94B339494076}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.AuditMode|x86.Build.0 = AuditMode|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-082C-4476-9F33-94B339494076}.Debug|ARM.ActiveCfg = Debug|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-082C-4476-9F33-94B339494076}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-082C-4476-9F33-94B339494076}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-082C-4476-9F33-94B339494076}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-082C-4476-9F33-94B339494076}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-082C-4476-9F33-94B339494076}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-082C-4476-9F33-94B339494076}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-082C-4476-9F33-94B339494076}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-082C-4476-9F33-94B339494076}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-082C-4476-9F33-94B339494076}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-082C-4476-9F33-94B339494076}.Release|ARM.ActiveCfg = Release|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-082C-4476-9F33-94B339494076}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-082C-4476-9F33-94B339494076}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-082C-4476-9F33-94B339494076}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-082C-4476-9F33-94B339494076}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-082C-4476-9F33-94B339494076}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-082C-4476-9F33-94B339494076}.Release|x86.Build.0 = Release|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.AuditMode|x64.ActiveCfg = AuditMode|x64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.AuditMode|x86.Build.0 = AuditMode|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Debug|ARM.ActiveCfg = Debug|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Debug|ARM64.ActiveCfg = Debug|ARM64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Debug|ARM64.Build.0 = Debug|ARM64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Debug|x64.ActiveCfg = Debug|x64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Debug|x64.Build.0 = Debug|x64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Debug|x86.ActiveCfg = Debug|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Release|ARM.ActiveCfg = Release|Win32
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Release|ARM64.ActiveCfg = Release|ARM64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Release|ARM64.Build.0 = Release|ARM64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Release|x64.ActiveCfg = Release|x64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Release|x64.Build.0 = Release|x64
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Release|x86.ActiveCfg = Release|Win32
{CA5CAD1A-9B68-456A-B13E-C8218070DC42}.Release|x86.Build.0 = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.AuditMode|ARM64.ActiveCfg = Release|ARM64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.AuditMode|x64.ActiveCfg = Release|x64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.AuditMode|x86.ActiveCfg = Release|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Debug|Any CPU.ActiveCfg = Debug|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Debug|ARM.ActiveCfg = Debug|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Debug|ARM64.ActiveCfg = Debug|ARM64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Debug|ARM64.Build.0 = Debug|ARM64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Debug|x64.ActiveCfg = Debug|x64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Debug|x64.Build.0 = Debug|x64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Debug|x86.ActiveCfg = Debug|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Release|Any CPU.ActiveCfg = Release|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Release|ARM.ActiveCfg = Release|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Release|ARM64.ActiveCfg = Release|ARM64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Release|ARM64.Build.0 = Release|ARM64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Release|x64.ActiveCfg = Release|x64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Release|x64.Build.0 = Release|x64
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Release|x86.ActiveCfg = Release|Win32
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D}.Release|x86.Build.0 = Release|Win32
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|Any CPU.ActiveCfg = Release|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|ARM.ActiveCfg = Debug|ARM
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|ARM.Build.0 = Debug|ARM
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|ARM.Deploy.0 = Debug|ARM
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|ARM64.ActiveCfg = Debug|ARM64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|ARM64.Build.0 = Debug|ARM64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|ARM64.Deploy.0 = Debug|ARM64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|DotNet_x64Test.ActiveCfg = Release|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|DotNet_x86Test.ActiveCfg = Release|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|x64.ActiveCfg = Debug|x64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|x64.Build.0 = Debug|x64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|x64.Deploy.0 = Debug|x64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|x86.ActiveCfg = Debug|x86
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|x86.Build.0 = Debug|x86
{F75E29D0-D288-478B-8D83-2C190F321A3F}.AuditMode|x86.Deploy.0 = Debug|x86
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|ARM.ActiveCfg = Debug|ARM
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|ARM.Build.0 = Debug|ARM
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|ARM.Deploy.0 = Debug|ARM
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|ARM64.ActiveCfg = Debug|ARM64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|ARM64.Build.0 = Debug|ARM64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|ARM64.Deploy.0 = Debug|ARM64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|DotNet_x64Test.ActiveCfg = Debug|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|DotNet_x86Test.ActiveCfg = Debug|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|x64.ActiveCfg = Debug|x64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|x64.Build.0 = Debug|x64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|x64.Deploy.0 = Debug|x64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|x86.ActiveCfg = Debug|x86
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|x86.Build.0 = Debug|x86
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Debug|x86.Deploy.0 = Debug|x86
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Fuzzing|Any CPU.ActiveCfg = Release|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Fuzzing|ARM.ActiveCfg = Fuzzing|ARM
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Fuzzing|DotNet_x86Test.ActiveCfg = Release|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Fuzzing|x64.ActiveCfg = Release|x64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Fuzzing|x86.ActiveCfg = Release|x86
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|Any CPU.ActiveCfg = Release|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|ARM.ActiveCfg = Release|ARM
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|ARM.Build.0 = Release|ARM
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|ARM.Deploy.0 = Release|ARM
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|ARM64.ActiveCfg = Release|ARM64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|ARM64.Build.0 = Release|ARM64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|ARM64.Deploy.0 = Release|ARM64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|DotNet_x64Test.ActiveCfg = Release|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|DotNet_x86Test.ActiveCfg = Release|Any CPU
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|x64.ActiveCfg = Release|x64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|x64.Build.0 = Release|x64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|x64.Deploy.0 = Release|x64
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|x86.ActiveCfg = Release|x86
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|x86.Build.0 = Release|x86
{F75E29D0-D288-478B-8D83-2C190F321A3F}.Release|x86.Deploy.0 = Release|x86
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{43CE4CE5-0010-4B99-9569-672670D26E26}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{43CE4CE5-0010-4B99-9569-672670D26E26}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{43CE4CE5-0010-4B99-9569-672670D26E26}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{43CE4CE5-0010-4B99-9569-672670D26E26}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{43CE4CE5-0010-4B99-9569-672670D26E26}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.AuditMode|x64.ActiveCfg = Release|x64
Add support for running a commandline in another WT window (#8898) ## Summary of the Pull Request **If you're reading this PR and haven't signed off on #8135, go there first.** ![window-management-000](https://user-images.githubusercontent.com/18356694/103932910-25199380-50e8-11eb-97e3-594a31da62d2.gif) This provides the basic parts of the implementation of #4472. Namely: * We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window. * If `window-id` is `0`, run the given commands in _the current window_. * If `window-id` is a negative number, run the commands in a _new_ Terminal window. * If `window-id` is the ID of an existing window, then run the commandline in that window. * If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window. * If `window-id` is omitted, then create a new window. ## References * Spec: #8135 * Megathread: #5000 * Project: projects/5 ## PR Checklist * [x] Closes #4472 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **sure does** ## Detailed Description of the Pull Request / Additional comments Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change There are limitations, and there are plenty of things to work on in the future: * [ ] We don't support names for windows yet * [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that. * [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from. * [ ] Basically anything else that's listed in projects/5. I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in. ## Validation Steps Performed I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain. # TODOs * [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬 - [x] `Monarch.cpp` - [x] `Peasant.cpp` - [x] `WindowManager.cpp` - [x] `AppHost.cpp` * [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully. - Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID. - Could we gracefully recover from such a state? maybe, probably not though. - Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant? - After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
2021-02-10 12:28:09 +01:00
{43CE4CE5-0010-4B99-9569-672670D26E26}.AuditMode|x64.Build.0 = Release|x64
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{43CE4CE5-0010-4B99-9569-672670D26E26}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.AuditMode|x86.Build.0 = AuditMode|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{43CE4CE5-0010-4B99-9569-672670D26E26}.Debug|ARM.ActiveCfg = Debug|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{43CE4CE5-0010-4B99-9569-672670D26E26}.Debug|ARM64.ActiveCfg = Debug|ARM64
{43CE4CE5-0010-4B99-9569-672670D26E26}.Debug|ARM64.Build.0 = Debug|ARM64
{43CE4CE5-0010-4B99-9569-672670D26E26}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.Debug|x64.ActiveCfg = Debug|x64
{43CE4CE5-0010-4B99-9569-672670D26E26}.Debug|x64.Build.0 = Debug|x64
{43CE4CE5-0010-4B99-9569-672670D26E26}.Debug|x86.ActiveCfg = Debug|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{43CE4CE5-0010-4B99-9569-672670D26E26}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{43CE4CE5-0010-4B99-9569-672670D26E26}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{43CE4CE5-0010-4B99-9569-672670D26E26}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{43CE4CE5-0010-4B99-9569-672670D26E26}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{43CE4CE5-0010-4B99-9569-672670D26E26}.Release|ARM.ActiveCfg = Release|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{43CE4CE5-0010-4B99-9569-672670D26E26}.Release|ARM64.ActiveCfg = Release|ARM64
{43CE4CE5-0010-4B99-9569-672670D26E26}.Release|ARM64.Build.0 = Release|ARM64
{43CE4CE5-0010-4B99-9569-672670D26E26}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.Release|x64.ActiveCfg = Release|x64
{43CE4CE5-0010-4B99-9569-672670D26E26}.Release|x64.Build.0 = Release|x64
{43CE4CE5-0010-4B99-9569-672670D26E26}.Release|x86.ActiveCfg = Release|Win32
{43CE4CE5-0010-4B99-9569-672670D26E26}.Release|x86.Build.0 = Release|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.AuditMode|x64.ActiveCfg = Release|x64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.AuditMode|x86.Build.0 = AuditMode|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Debug|ARM.ActiveCfg = Debug|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Debug|ARM64.ActiveCfg = Debug|ARM64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Debug|ARM64.Build.0 = Debug|ARM64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Debug|x64.ActiveCfg = Debug|x64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Debug|x64.Build.0 = Debug|x64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Debug|x86.ActiveCfg = Debug|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Release|ARM.ActiveCfg = Release|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Release|ARM64.ActiveCfg = Release|ARM64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Release|ARM64.Build.0 = Release|ARM64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Release|x64.ActiveCfg = Release|x64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Release|x64.Build.0 = Release|x64
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Release|x86.ActiveCfg = Release|Win32
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE}.Release|x86.Build.0 = Release|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.AuditMode|x64.ActiveCfg = AuditMode|x64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.AuditMode|x86.Build.0 = AuditMode|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Debug|Any CPU.ActiveCfg = Debug|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Debug|ARM.ActiveCfg = Debug|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Debug|ARM64.ActiveCfg = Debug|ARM64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Debug|ARM64.Build.0 = Debug|ARM64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Debug|x64.ActiveCfg = Debug|x64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Debug|x64.Build.0 = Debug|x64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Debug|x86.ActiveCfg = Debug|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Release|Any CPU.ActiveCfg = Release|Win32
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Release|ARM.ActiveCfg = Release|Win32
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Release|ARM64.ActiveCfg = Release|ARM64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Release|ARM64.Build.0 = Release|ARM64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Release|x64.ActiveCfg = Release|x64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Release|x64.Build.0 = Release|x64
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Release|x86.ActiveCfg = Release|Win32
{68A10CD3-AA64-465B-AF5F-ED4E9700543C}.Release|x86.Build.0 = Release|Win32
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.AuditMode|x64.ActiveCfg = AuditMode|x64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.AuditMode|x64.Build.0 = AuditMode|x64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.AuditMode|x86.Build.0 = AuditMode|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Debug|Any CPU.ActiveCfg = Debug|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Debug|ARM.ActiveCfg = Debug|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Debug|ARM64.ActiveCfg = Debug|ARM64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Debug|ARM64.Build.0 = Debug|ARM64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Debug|x64.ActiveCfg = Debug|x64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Debug|x64.Build.0 = Debug|x64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Debug|x86.ActiveCfg = Debug|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Debug|x86.Build.0 = Debug|Win32
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Fuzzing|x64.Build.0 = Fuzzing|x64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Release|Any CPU.ActiveCfg = Release|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Release|ARM.ActiveCfg = Release|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Release|ARM64.ActiveCfg = Release|ARM64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Release|ARM64.Build.0 = Release|ARM64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Release|x64.ActiveCfg = Release|x64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Release|x64.Build.0 = Release|x64
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Release|x86.ActiveCfg = Release|Win32
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF}.Release|x86.Build.0 = Release|Win32
Create a control unittesting project (#9677) Does what it says on the can. This is a follow up to #9472. Now that we have a control .lib, we can add tests for it. Unfortunately, the `TermControl` itself is a horrible mess. So this new unittest lib is empty for now. I'm working on actual tests as a part of #6842, but this PR is here to keep the diffs smaller. Also, apparently `server.vcxproj` had the wrong GUID in it. * [x] I work here * [x] Adds tests
2021-04-05 18:07:55 +02:00
{05D9052F-D78F-478F-968A-2DE38A6DB996}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{05D9052F-D78F-478F-968A-2DE38A6DB996}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.AuditMode|x64.ActiveCfg = AuditMode|x64
{05D9052F-D78F-478F-968A-2DE38A6DB996}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Debug|Any CPU.ActiveCfg = Debug|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Debug|ARM.ActiveCfg = Debug|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Debug|ARM64.ActiveCfg = Debug|ARM64
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Debug|x64.ActiveCfg = Debug|x64
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Debug|x86.ActiveCfg = Debug|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Fuzzing|DotNet_x64Test.ActiveCfg = Fuzzing|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Fuzzing|DotNet_x86Test.ActiveCfg = Fuzzing|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Fuzzing|x64.ActiveCfg = Fuzzing|x64
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Fuzzing|x64.Build.0 = Fuzzing|x64
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Fuzzing|x86.ActiveCfg = Fuzzing|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Release|Any CPU.ActiveCfg = Release|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Release|ARM.ActiveCfg = Release|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Release|ARM64.ActiveCfg = Release|ARM64
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Release|x64.ActiveCfg = Release|x64
{05D9052F-D78F-478F-968A-2DE38A6DB996}.Release|x86.ActiveCfg = Release|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.AuditMode|x64.ActiveCfg = Release|x64
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.AuditMode|x86.Build.0 = AuditMode|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Debug|Any CPU.ActiveCfg = Debug|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Debug|ARM.ActiveCfg = Debug|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Debug|ARM64.ActiveCfg = Debug|ARM64
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Debug|ARM64.Build.0 = Debug|ARM64
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Debug|DotNet_x64Test.ActiveCfg = Debug|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Debug|x64.ActiveCfg = Debug|x64
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Debug|x64.Build.0 = Debug|x64
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Debug|x86.ActiveCfg = Debug|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Debug|x86.Build.0 = Debug|Win32
{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
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|ARM64.Build.0 = Release|ARM64
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|DotNet_x64Test.ActiveCfg = Release|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|x64.ActiveCfg = Release|x64
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|x64.Build.0 = Release|x64
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|x86.ActiveCfg = Release|Win32
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B}.Release|x86.Build.0 = Release|Win32
Implement PGO in pipelines for AMD64 architecture; supply training test scenarios (#10071) Implement PGO in pipelines for AMD64 architecture; supply training test scenarios ## References - #3075 - Relevant to speed interests there and other linked issues. ## PR Checklist * [x] Closes #6963 * [x] I work here. * [x] New UIA Tests added and passed. Manual build runs also tested. ## Detailed Description of the Pull Request / Additional comments - Creates a new pipeline run for creating instrumented binaries for Profile Guided Optimization (PGO). - Creates a new suite of UIA tests on the full Windows Terminal app to run PGO training scenarios on instrumented binaries (and incidentally can be used to write other UIA tests later for the full Terminal app.) - Creates a new NuGet artifact to store trained PGO databases (PGD files) at `Microsoft.Internal.Windows.Terminal.PGODatabase` - Creates a new NuGet artifact to supply large-scale test content for automated tests at `Microsoft.Internal.Windows.Terminal.TestContent` - Adjusts the release pipeline to run binaries in PGO optimized mode where content from PGO databases is leveraged at link time to optimize the final release build The following binaries are trained: - OpenConsole.exe - WindowsTerminal.exe - TerminalApp.dll - TerminalConnection.dll - Microsoft.Terminal.Control.dll - Microsoft.Terminal.Remoting.dll - Microsoft.Terminal.Settings.Editor.dll - Microsoft.Terminal.Settings.Model.dll In the future, adding `<PgoTarget>true</PgoTarget>` to a new `vcxproj` file will automatically enroll the DLL/EXE for PGO instrumentation and optimization going forward. Two training test scenarios are implemented: - Smoke test the Terminal by just opening it and typing a bit of text then exiting. (Should help focus on the standard launch path.) - Optimize bulk text output by launching terminal, outputting `big.txt`, then exiting. Additional scenarios can be contributed to the `WindowsTerminal_UIATests` project with the `[TestProperty("IsPGO", "true")]` annotation to add them to the suite of scenarios for PGO. **NOTE:** There are currently no weights applied to the various test scenarios. We will revisit that in the future when/if necessary. ## Validation Steps Performed - [x] - Training run completed at https://dev.azure.com/ms/terminal/_build?definitionId=492&_a=summary - [x] - Optimization run completed locally (by forcing `PGOBuildMode` to `Optimize` on my local machine, manually retrieving the databases with NuGet, and building). - [x] - Validated locally that x86 and ARM64 do not get trained and automatically skip optimization as databases are not present for them. - [x] - Smoke tested optimized binary versus latest releases. `big.txt` output through CMD is ~11-12seconds prior to PGO and just over 8 seconds with PGO.
2021-05-13 23:12:30 +02:00
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|Any CPU.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|ARM.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|ARM64.ActiveCfg = Debug|ARM64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|DotNet_x64Test.ActiveCfg = Debug|x64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|DotNet_x86Test.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|x64.ActiveCfg = Debug|x64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.AuditMode|x86.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|Any CPU.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|ARM.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|ARM64.ActiveCfg = Debug|ARM64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|ARM64.Build.0 = Debug|ARM64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|x64.ActiveCfg = Debug|x64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|x64.Build.0 = Debug|x64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|x86.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Debug|x86.Build.0 = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|Any CPU.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|ARM.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|ARM64.ActiveCfg = Debug|ARM64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|DotNet_x64Test.ActiveCfg = Debug|x64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|DotNet_x86Test.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|x64.ActiveCfg = Debug|x64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Fuzzing|x86.ActiveCfg = Debug|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|Any CPU.ActiveCfg = Release|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|ARM.ActiveCfg = Release|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|ARM64.ActiveCfg = Release|ARM64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|ARM64.Build.0 = Release|ARM64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|x64.ActiveCfg = Release|x64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|x64.Build.0 = Release|x64
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|x86.ActiveCfg = Release|Win32
{F19DACD5-0C6E-40DC-B6E4-767A3200542C}.Release|x86.Build.0 = Release|Win32
Introduce a api-ms-win-core-synch-l1-2-0 shim for Windows 7 (#10559) The code in this file was adapted from the STL on the 2021-07-05. It backports the following Windows 8 functions to Windows 7: * WaitOnAddress * WakeByAddressSingle * WakeByAddressAll These functions are used within `til`. This commit will allow `til` to be used in the conhost source code. Validation * [x] correct .dll loads on Windows 7 * [x] correct .dll loads on Windows 10 * [x] link line for PublicTerminalCore prefers this fake apiset over kernel32
2021-07-07 18:48:28 +02:00
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|Any CPU.ActiveCfg = AuditMode|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|ARM.ActiveCfg = AuditMode|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|ARM64.ActiveCfg = AuditMode|ARM64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|ARM64.Build.0 = AuditMode|ARM64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|DotNet_x64Test.ActiveCfg = AuditMode|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|DotNet_x86Test.ActiveCfg = AuditMode|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|x64.ActiveCfg = AuditMode|x64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|x64.Build.0 = AuditMode|x64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|x86.ActiveCfg = AuditMode|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.AuditMode|x86.Build.0 = AuditMode|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|Any CPU.ActiveCfg = Debug|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|ARM.ActiveCfg = Debug|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|ARM64.ActiveCfg = Debug|ARM64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|ARM64.Build.0 = Debug|ARM64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|DotNet_x64Test.ActiveCfg = Debug|x64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|DotNet_x64Test.Build.0 = Debug|x64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|DotNet_x86Test.ActiveCfg = Debug|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|DotNet_x86Test.Build.0 = Debug|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|x64.ActiveCfg = Debug|x64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|x64.Build.0 = Debug|x64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|x86.ActiveCfg = Debug|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Debug|x86.Build.0 = Debug|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|Any CPU.ActiveCfg = Fuzzing|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|ARM.ActiveCfg = Fuzzing|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|ARM64.ActiveCfg = Fuzzing|ARM64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Fuzzing|ARM64.Build.0 = Fuzzing|ARM64
{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
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|ARM.ActiveCfg = Release|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|ARM64.ActiveCfg = Release|ARM64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|ARM64.Build.0 = Release|ARM64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|DotNet_x64Test.ActiveCfg = Release|x64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|DotNet_x64Test.Build.0 = Release|x64
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|DotNet_x86Test.ActiveCfg = Release|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|DotNet_x86Test.Build.0 = Release|Win32
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5}.Release|x64.ActiveCfg = Release|x64
{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
Introduce AtlasEngine - A new text rendering prototype (#11623) This commit introduces "AtlasEngine", a new text renderer based on DxEngine. But unlike it, DirectWrite and Direct2D are only used to rasterize glyphs. Blending and placing these glyphs into the target view is being done using Direct3D and a simple HLSL shader. Since this new renderer more aggressively assumes that the text is monospace, it simplifies the implementation: The viewport is divided into cells, and its data is stored as a simple matrix. Modifications to this matrix involve only simple pointer arithmetic and is easy to understand. But just like with DxEngine however, DirectWrite related code remains extremely complex and hard to understand. Supported features: * Basic text rendering with grayscale AA * Foreground and background colors * Emojis, including zero width joiners * Underline, dotted underline, strikethrough * Custom font axes and features * Selections * All cursor styles * Full alpha support for all colors * _Should_ work with Windows 7 Unsupported features: * A more conservative GPU memory usage The backing texture atlas for glyphs is grow-only and will not shrink. After 256MB of memory is used up (~20k glyphs) text output will be broken until the renderer is restarted. * ClearType * Remaining gridlines (left, right, top, bottom, double underline) * Hyperlinks don't get full underlines if hovered in WT * Softfonts * Non-default line renditions Performance: * Runs at up to native display refresh rate Unfortunately the frame rate often drops below refresh rate, due us fighting over the buffer lock with other parts of the application. * CPU consumption is up to halved compared to DxEngine AtlasEngine is still highly unoptimized. Glyph hashing consumes up to a third of the current CPU time. * No regressions in WT performance VT parsing and related buffer management takes up most of the CPU time (~85%), due to which the AtlasEngine can't show any further improvements. * ~2x improvement in raw text throughput in OpenConsole compared to DxEngine running at 144 FPS * ≥10x improvement in colored VT output in WT/OpenConsole compared to DxEngine running at 144 FPS
2021-11-13 01:10:06 +01:00
{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
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndGlobalSection
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
EndGlobalSection
GlobalSection(NestedProjects) = preSolution
Set the default startup project (#1314) Visual Studio defaults the startup project to the first project listed in the solution. Set the default to CascadiaPackage, which launches the packaged terminal. This required moving both its solution folder and the project itself to the top of the solution. The other moves in the file is "VS" fixing the ordering based on the move. This prevents the solution from being automatically changed by VS when other folks open it.
2019-06-24 18:47:00 +02:00
{CA5CAD1A-224A-4171-B13A-F16E576FDD12} = {59840756-302F-44DF-AA47-441A9D673202}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{9CBD7DFA-1754-4A9D-93D7-857A9D17CB1B} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{345FD5A4-B32B-4F29-BD1C-B033BD2C35CC} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{4C8E6BB0-4713-4ADB-BD04-81628ECEAF20} = {81C352DB-1818-45B7-A284-18E259F1CC87}
{D57841D1-8294-4F2B-BB8B-D2A35738DECD} = {81C352DB-1818-45B7-A284-18E259F1CC87}
{2FD12FBB-1DDB-46D8-B818-1023C624CACA} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{3AE13314-1939-4DFA-9C14-38CA0834050C} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{DCF55140-EF6A-4736-A403-957E4F7430BB} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{1CF55140-EF6A-4736-A403-957E4F7430BB} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{AF0A096A-8B3A-4949-81EF-7DF8F0FEE91F} = {05500DEF-2294-41E3-AF9A-24E580B82836}
{1C959542-BAC2-4E55-9A6D-13251914CBB9} = {05500DEF-2294-41E3-AF9A-24E580B82836}
{06EC74CB-9A12-429C-B551-8562EC954746} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{06EC74CB-9A12-429C-B551-8562EC954747} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{531C23E7-4B76-4C08-8AAD-04164CB628C9} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{531C23E7-4B76-4C08-8BBD-04164CB628C9} = {1E4A062E-293B-4817-B20D-BF16B979E350}
{8CDB8850-7484-4EC7-B45B-181F85B2EE54} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{12144E07-FE63-4D33-9231-748B8D8C3792} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{6AF01638-84CF-4B65-9870-484DFFCAC772} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{96927B31-D6E8-4ABD-B03E-A5088A30BEBE} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{F210A4AE-E02A-4BFC-80BB-F50A672FE763} = {F1995847-4AE5-479A-BBAF-382E51A63532}
{5D23E8E1-3C64-4CC1-A8F7-6861677F7239} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{18D09A24-8240-42D6-8CB6-236EEE820262} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{C17E1BF3-9D34-4779-9458-A8EF98CC5662} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{099193A0-1E43-4BBC-BA7F-7B351E1342DF} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{FC802440-AD6A-4919-8F2C-7701F2B38D79} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{919544AC-D39B-463F-8414-3C3C67CF727C} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{ED82003F-FC5D-4E94-8B36-F480018ED064} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{06EC74CB-9A12-429C-B551-8532EC964726} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{ED82003F-FC5D-4E94-8B47-F480018ED064} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{06EC74CB-9A12-429C-B551-8562EC964846} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{D3B92829-26CB-411A-BDA2-7F5DA3D25DD4} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{C7A6A5D9-60BE-4AEB-A5F6-AFE352F86CBB} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{990F2657-8580-4828-943F-5DD657D11842} = {05500DEF-2294-41E3-AF9A-24E580B82836}
{814DBDDE-894E-4327-A6E1-740504850098} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{814CBEEE-894E-4327-A6E1-740504850098} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{18D09A24-8240-42D6-8CB6-236EEE820263} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
{990F2657-8580-4828-943F-5DD657D11843} = {05500DEF-2294-41E3-AF9A-24E580B82836}
{0CF235BD-2DA0-407E-90EE-C467E8BBC714} = {1E4A062E-293B-4817-B20D-BF16B979E350}
{48D21369-3D7B-4431-9967-24E81292CF62} = {05500DEF-2294-41E3-AF9A-24E580B82836}
{CA5CAD1A-C46D-4588-B1C0-40F31AE9100B} = {59840756-302F-44DF-AA47-441A9D673202}
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
{CA5CAD1A-ABCD-429C-B551-8562EC954746} = {9921CA0A-320C-4460-8623-3A3196E7F4CB}
{CA5CAD1A-44BD-4AC7-AC72-6CA5B3AB89ED} = {9921CA0A-320C-4460-8623-3A3196E7F4CB}
{CA5CAD1A-F542-4635-A069-7CAEFB930070} = {9921CA0A-320C-4460-8623-3A3196E7F4CB}
{CA5CAD1A-1754-4A9D-93D7-857A9D17CB1B} = {2D17E75D-2DDC-42C4-AD70-704D95A937AE}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{CA5CAD1A-44BD-4AC7-AC72-F16E576FDD12} = {59840756-302F-44DF-AA47-441A9D673202}
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
{F2ED628A-DB22-446F-A081-4CC845B51A2B} = {2D17E75D-2DDC-42C4-AD70-704D95A937AE}
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{2C2BEEF4-9333-4D05-B12A-1905CBF112F9} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
{EF3E32A7-5FF6-42B4-B6E2-96CD7D033F00} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{16376381-CE22-42BE-B667-C6B35007008D} = {81C352DB-1818-45B7-A284-18E259F1CC87}
{F1995847-4AE5-479A-BBAF-382E51A63532} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
{05500DEF-2294-41E3-AF9A-24E580B82836} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
{1E4A062E-293B-4817-B20D-BF16B979E350} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
Switch to v5 UUIDs as profile GUIDs for the default profiles (#913) This commit switches the GUIDs for default profiles from being randomly generated to being version 5 UUIDs. More info in #870. ## PR Checklist * [x] Closes #870 * [x] CLA signed * [x] Tests added/passed * [x] Requires documentation to be updated (#883) * [x] I've discussed this with core contributors already. ## Detailed Description of the Pull Request / Additional comments This commit has a number of changes that seem ancillary, but they're general goodness. Let me explain: * I've added a whole new Types test library with only two tests in * Since UUIDv5 generation requires SHA1, we needed to take a dependency on bcrypt * I honestly don't think we should have to link bcrypt in conhost, but LTO should take care of that * I considered adding a new Terminal-specific Utils/Types library, but that seemed like a waste * The best way to link bcrypt turned out to be in line with a discussion @miniksa and I had, where we decided we both love APISets and think that the console should link against them exclusively... so I've added `onecore_apiset.lib` to the front of the link line, where it will deflect the linker away from most of the other libs automagically. ``` StartGroup: UuidTests::TestV5UuidU8String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU8String [Passed] StartGroup: UuidTests::TestV5UuidU16String Verify: AreEqual(uuidExpected, uuidActual) EndGroup: UuidTests::TestV5UuidU16String [Passed] ```
2019-05-21 22:29:16 +02:00
{34DE34D3-1CD6-4EE3-8BD9-A26B5B27EC73} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
Add support for running a commandline in another WT window (#8898) ## Summary of the Pull Request **If you're reading this PR and haven't signed off on #8135, go there first.** ![window-management-000](https://user-images.githubusercontent.com/18356694/103932910-25199380-50e8-11eb-97e3-594a31da62d2.gif) This provides the basic parts of the implementation of #4472. Namely: * We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window. * If `window-id` is `0`, run the given commands in _the current window_. * If `window-id` is a negative number, run the commands in a _new_ Terminal window. * If `window-id` is the ID of an existing window, then run the commandline in that window. * If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window. * If `window-id` is omitted, then create a new window. ## References * Spec: #8135 * Megathread: #5000 * Project: projects/5 ## PR Checklist * [x] Closes #4472 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **sure does** ## Detailed Description of the Pull Request / Additional comments Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change There are limitations, and there are plenty of things to work on in the future: * [ ] We don't support names for windows yet * [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that. * [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from. * [ ] Basically anything else that's listed in projects/5. I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in. ## Validation Steps Performed I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain. # TODOs * [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬 - [x] `Monarch.cpp` - [x] `Peasant.cpp` - [x] `WindowManager.cpp` - [x] `AppHost.cpp` * [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully. - Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID. - Could we gracefully recover from such a state? maybe, probably not though. - Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant? - After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
2021-02-10 12:28:09 +01:00
{84848BFA-931D-42CE-9ADF-01EE54DE7890} = {4DAF0299-495E-4CD1-A982-9BAC16A45932}
{376FE273-6B84-4EB5-8B30-8DE9D21B022C} = {4DAF0299-495E-4CD1-A982-9BAC16A45932}
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{CA5CAD1A-9333-4D05-B12A-1905CBF112F9} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
Refactor TerminalApp and Add Tests for Xaml Content (#1164) * 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 b72bd9eb73cca9c3a9887e4d7a67ec2696dc6dba. * 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
2019-07-15 21:27:56 +02:00
{CA5CAD1A-9A12-429C-B551-8562EC954746} = {59840756-302F-44DF-AA47-441A9D673202}
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{CA5CAD1A-B11C-4DDB-A4FE-C3AFAE9B5506} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
Introduce UiaRenderer project (#2930) As a part of setting up UIA Events, we need to be able to identify WHEN to notify the client. We'll be adopting the RendererEngine model that the VTRenderer and DxRenderer follow to identify when something on the screen is changing and what to alert the automation clients about. This PR just introduces the UiaRenderer. There's a lot of E_NOTIMPLs and S_FALSEs and a few comments throughout as to my thoughts. This'll make diffing future PRs easier and can make this process more iterative. The code does run with the PR so I plan on merging this into master as normal.
2019-10-28 17:42:54 +01:00
{48D21369-3D7B-4431-9967-24E81292CF63} = {05500DEF-2294-41E3-AF9A-24E580B82836}
Introduce a WinRT utils library and "checked resources" (#3350) 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] ```
2019-11-01 23:47:05 +01:00
{CA5CAD1A-039A-4929-BA2A-8BEB2E4106FE} = {59840756-302F-44DF-AA47-441A9D673202}
Introduce a Universal package for Windows Terminal (#3236) 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.
2019-11-26 01:30:45 +01:00
{B0AC39D6-7B40-49A9-8202-58549BAE1FB1} = {59840756-302F-44DF-AA47-441A9D673202}
Make ConPTY build as both LIB and DLL. (#3565) * Make ConPTY build as both LIB and DLL. * Update TerminalConnection reference to LIB version (because Terminal builds both UWP and Centennial, requiring different CRTs each). * DLL is now available (and against desktop CRT) to be PInvokable from C# for WPF terminal. Note, DLL MUST BUILD PRECOMP to get the magic pragma linking information to the Desktop CRT. * don't audit PTY lib. I can't do safe things because the safe things we use don't fit back inside kernelbase.dll. Closes #3563.
2019-11-14 20:22:00 +01:00
{58A03BB2-DF5A-4B66-91A0-7EF3BA01269A} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
{A22EC5F6-7851-4B88-AC52-47249D437A52} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
Fix unittesting our `.xaml` classes (#4105) ## Summary of the Pull Request New year, new unittests. This PR introduces a new project, `TestHostApp`. This project is largely taken from the TAEF samples, and allows us to easily construct a helper executable and `resources.pri` for running TerminalApp unittests. ## References ## PR Checklist * [x] Closes #3986 * [x] I work here * [x] is Tests * [n/a] Requires documentation to be updated * [x] **Waiting for an updated version of TAEF to be available** ## Detailed Description of the Pull Request / Additional comments Unittesting for the TerminalApp project has been a horrifying process to try getting everything pieced together just right. Dependencies need to get added to manifests, binplaced correctly, and XAML resources need to get compiled together as well. In addition, using a MUX `Application` (as opposed to the Windows.UI.Xaml `Application`) has led to additional problems. This was always a horrifying house of cards for us. Turns out, the reason this was so horrible is that the test infrastructure for doing what we're doing _literally didn't exist_ when I started doing all that work last year. So, with help from the TAEF team, I was able to get rid of our entire house of cards, and use a much simpler project to build and run the tests. Unfortunately, the latest TAEF release has a minor bug in it's build rules, and only publishes the x86 version of a dll we need from them. But, the rest of this PR works for x86, and I'll bump this when that updated version is available. We should be able to review this even in the state it's in. ## Validation Steps Performed ran the tests yo
2020-01-10 19:55:31 +01:00
{A021EDFF-45C8-4DC2-BEF7-36E1B3B8CFE8} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
{BDB237B6-1D1D-400F-84CC-40A58FA59C8E} = {59840756-302F-44DF-AA47-441A9D673202}
Introduce til::some (#4123) ## Summary of the Pull Request Introduces a type that is basically an array (stack allocated, fixed size) that reports size based on how many elements are actually filled (from the front), iterates only the filled ones, and has some basic vector push/pop semantics. ## PR Checklist * [x] I work here * [x] I work here * [x] I work here * [ ] I'd love to roll this out to SomeViewports.... maybe in this commit or a follow on one. * [ ] We need a TIL tests library and I should test this there. ## Detailed Description of the Pull Request / Additional comments The original gist of this was used for `SomeViewports` which was a struct to hold between 0 and 4 viewports, based on how many were left after subtraction (since rectangle subtraction functions in Windows code simply fail for resultants that yield >=2 rectangle regions.) I figured now that we're TIL-ifying useful common utility things that this would be best suited to a template because I'm certain there are other circumstances where we would like to iterate a partially filled array and want it to not auto-resize-up like a vector would. ## Validation Steps Performed * [ ] TIL tests added
2020-01-09 18:07:52 +01:00
{767268EE-174A-46FE-96F0-EEE698A1BBC9} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
Implement til::u8u16 and til::u16u8 conversion functions (#4093) This commit also switches ConptyConnection to consume til::u8u16 and removes the UTF8OutPipeReader. Closes #4092.
2020-01-30 01:55:48 +01:00
{A602A555-BAAC-46E1-A91D-3DAB0475C5A1} = {A10C4720-DCA4-4640-9749-67F4314F527C}
Move tests to invoke `te.exe` directly instead of using VSTest runner (#4490) Moves the tests from using the `vstest.console.exe` route to just using `te.exe`. PROs: - `te.exe` is significantly faster for running tests because the TAEF/VSTest adapter isn't great. - Running through `te.exe` is closer to what our developers are doing on their dev boxes - `te.exe` is how they run in the Windows gates. - `te.exe` doesn't seem to have the sporadic `0x6` error code thrown during the tests where somehow the console handles get lost - `te.exe` doesn't seem to repro the other intermittent issues that we have been having that are inscrutable. - Fewer processes in the tree (te is running anyway under `vstest.console.exe`, just indirected a lot - The log outputs scroll live with all our logging messages instead of suppressing everything until there's a failure - The log output is actually in the order things are happening versus vstest. CONs: - No more code coverage. - No more test records in the ADO build/test panel. - Tests really won't work inside Visual Studio at all. - The log files are really big now - Testing is not a test task anymore, just another script. Refuting each CON: - We didn't read the code coverage numbers - We didn't look at the ADO test panel results or build-over-build velocities - Tests didn't really work inside Visual Studio anyway unless you did the right incantations under the full moon. - We could tone down the logging if we wanted at either the te.exe execution time (with a switch) or by declaring properties in the tests/classes/modules that are very verbose to not log unless it fails. - I don't think anyone cares how they get run as long as they do.
2020-02-10 20:14:06 +01:00
{53DD5520-E64C-4C06-B472-7CE62CA539C9} = {04170EEF-983A-4195-BFEF-2321E5E38A1E}
{6B5A44ED-918D-4747-BFB1-2472A1FCA173} = {04170EEF-983A-4195-BFEF-2321E5E38A1E}
{D3EF7B96-CD5E-47C9-B9A9-136259563033} = {04170EEF-983A-4195-BFEF-2321E5E38A1E}
Restrict DX run height adjustment to only relevant glyph AND Correct PTY rendering on trailing half of fullwidth glyphs (#4668) ## Summary of the Pull Request - Height adjustment of a glyph is now restricted to itself in the DX renderer instead of applying to the entire run - ConPTY compensates for drawing the right half of a fullwidth character. The entire render base has this behavior restored now as well. ## PR Checklist * [x] Closes #2191 * [x] I work here * [x] Tests added/passed * [x] No doc * [x] Am core contributor. ## Detailed Description of the Pull Request / Additional comments Two issues: 1. On the DirectX renderer side, when confronted with shrinking a glyph, the correction code would apply the shrunken size to the entire run, not just the potentially individual glyph that needed to be reduced in size. Unfortunately while adjusting the horizontal X width can be done for each glyph in a run, the vertical Y height has to be adjusted for an entire run. So the solution here was to split the individual glyph needing shrinking out of the run into its own run so it can be shrunk. 2. On the ConPTY side, there was a long standing TODO that was never completed to deal with a request to draw only the right half of a two-column character. This meant that when encountering a request for the right half only, we would transmit the entire full character to be drawn, left and right halves, struck over the right half position. Now we correct the cursor back a position (if space) and draw it out so the right half is struck over where we believe the right half should be (and the left half is updated as well as a consequence, which should be OK.) The reason this happens right now is because despite VIM only updating two cells in the buffer, the differential drawing calculation in the ConPTY is very simplistic and intersects only rectangles. This means from the top left most character drawn down to the row/col cursor count indicator in vim's modeline are redrawn with each character typed. This catches the line below the edited line in the typing and refreshes it. But incorrectly. We need to address making ConPTY smarter about what it draws incrementally as it's clearly way too chatty. But I plan to do that with some of the structures I will be creating to solve #778. ## Validation Steps Performed - Ran the scenario listed in #2191 in vim in the Terminal - Added unit tests similar to examples given around glyph/text mapping in runs from Microsoft community page
2020-02-21 01:24:12 +01:00
{95B136F9-B238-490C-A7C5-5843C1FECAC4} = {05500DEF-2294-41E3-AF9A-24E580B82836}
Migrate the ConPTY functional tests out of Windows (#4648) ## Summary of the Pull Request This will allow us to run the ConPTY tests in CI. ## PR Checklist * [x] Closes MSFT:24265197 * [X] I've discussed this with core contributors already. ## Validation Steps Performed I've run the tests. Please note: this code is unchanged (apart from `wil::ScopeExit` -> `wil::scope_exit`) from Windows. Now is not the time to comment on their perfectness.
2020-02-19 22:27:17 +01:00
{024052DE-83FB-4653-AEA4-90790D29D5BD} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
Shim the AzureConn through a conhost to stop VT bleeding (#4652) This commit introduces a small console-subsystem application whose sole job is to consume TerminalConnection.dll and hook it up to something other than Terminal. It is 99% of the way to a generic solution. I've introduced a stopgap in TerminalPage that makes sure we launch TerminalAzBridge using ConptyConnection instead of AzureConnection. As a bonus, this commit includes a class whose sole job it is to make reading VT input off a console handle not terrible. It returns you a string and dispatches window size change callbacks. Fixes #2267. Fixes #4589. Related to #2266 (since pwsh needs better VT).
2020-02-21 01:21:05 +01:00
{067F0A06-FCB7-472C-96E9-B03B54E8E18D} = {59840756-302F-44DF-AA47-441A9D673202}
Import fmtlib/fmt@6.2.0, a C++20-style format library (#5336) 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?
2020-04-14 22:04:23 +02:00
{6BAE5851-50D5-4934-8D5E-30361A8A40F3} = {81C352DB-1818-45B7-A284-18E259F1CC87}
Add support for running a commandline in another WT window (#8898) ## Summary of the Pull Request **If you're reading this PR and haven't signed off on #8135, go there first.** ![window-management-000](https://user-images.githubusercontent.com/18356694/103932910-25199380-50e8-11eb-97e3-594a31da62d2.gif) This provides the basic parts of the implementation of #4472. Namely: * We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window. * If `window-id` is `0`, run the given commands in _the current window_. * If `window-id` is a negative number, run the commands in a _new_ Terminal window. * If `window-id` is the ID of an existing window, then run the commandline in that window. * If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window. * If `window-id` is omitted, then create a new window. ## References * Spec: #8135 * Megathread: #5000 * Project: projects/5 ## PR Checklist * [x] Closes #4472 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **sure does** ## Detailed Description of the Pull Request / Additional comments Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change There are limitations, and there are plenty of things to work on in the future: * [ ] We don't support names for windows yet * [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that. * [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from. * [ ] Basically anything else that's listed in projects/5. I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in. ## Validation Steps Performed I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain. # TODOs * [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬 - [x] `Monarch.cpp` - [x] `Peasant.cpp` - [x] `WindowManager.cpp` - [x] `AppHost.cpp` * [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully. - Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID. - Could we gracefully recover from such a state? maybe, probably not though. - Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant? - After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
2021-02-10 12:28:09 +01:00
{1588FD7C-241E-4E7D-9113-43735F3E6BAD} = {4DAF0299-495E-4CD1-A982-9BAC16A45932}
Build and ship an actual binary named wt that just launches WT (#6860) Due to a shell limitation, Ctrl+Shift+Enter will not launch Windows Terminal as Administrator. This is caused by the app execution alias and the actual targeted executable not having the same name. In addition, PowerShell has an issue detecting app execution aliases as GUI/TUI applications. When you run wt from PowerShell, the shell will wait for WT to exit before returning to the prompt. Having a shim that immediately re-executes WindowsTerminal and then returns handily knocks this issue out (as the process that PS was waiting for exits immediately.) This could cause a regression for anybody who tries to capture the PID of wt.exe. Our process tree is not an API, and we have offered no consistency guarantee on it. VALIDATION ---------- Tested manual launch in a number of different scenarios: * [x] start menu "wtd" * [x] start menu tile * [x] powertoys run * [x] powertoys run ctrl+shift (admin) * [x] powershell inbox, "core" * [x] cmd * [x] run dialog * [x] run dialog ctrl+shift (admin) * [x] run from a lnk with window mode=maximized Fixes #4645 (PowerShell waits for wt) Fixes #6625 (Can't launch as admin using C-S-enter)
2020-07-11 00:41:37 +02:00
{506FD703-BAA7-4F6E-9361-64F550EC8FCA} = {59840756-302F-44DF-AA47-441A9D673202}
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
{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}
Introduce TerminalSettingsModel project (#7667) Introduces a new TerminalSettingsModel (TSM) project. This project is responsible for (de)serializing and exposing Windows Terminal's settings as WinRT objects. ## References #885: TSM epic #1564: Settings UI is dependent on this for data binding and settings access #6904: TSM Spec In the process of ripping out TSM from TerminalApp, a few other changes were made to make this possible: 1. AppLogic's `ApplicationDisplayName` and `ApplicationVersion` was moved to `CascadiaSettings` - These are defined as static functions. They also no longer check if `AppLogic::Current()` is nullptr. 2. `enum LaunchMode` was moved from TerminalApp to TSM 3. `AzureConnectionType` and `TelnetConnectionType` were moved from the profile generators to their respective TerminalConnections 4. CascadiaSettings' `SettingsPath` and `DefaultSettingsPath` are exposed as `hstring` instead of `std::filesystem::path` 5. `Command::ExpandCommands()` was exposed via the IDL - This required some of the warnings to be saved to an `IVector` instead of `std::vector`, among some other small changes. 6. The localization resources had to be split into two halves. - Resource file linked in init.cpp. Verified at runtime thanks to the StaticResourceLoader. 7. Added constructors to some `ActionArgs` 8. Utils.h/cpp were moved to `cascadia/inc`. `JsonKey()` was moved to `JsonUtils`. Both TermApp and TSM need access to Utils.h/cpp. A large amount of work includes moving to the new namespace (`TerminalApp` --> `Microsoft::Terminal::Settings::Model`). Fixing the tests had its own complications. Testing required us to split up TSM into a DLL and LIB, similar to TermApp. Discussion on creating a non-local test variant can be found in #7743. Closes #885
2020-10-06 18:56:59 +02:00
{CA5CAD1A-9B68-456A-B13E-C8218070DC42} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
Add a Monarch/Peasant sample app (#8171) 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: ![monarch-peasant-sample-001](https://user-images.githubusercontent.com/18356694/98262202-f39b1500-1f4a-11eb-9220-4af4d922339f.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
2021-01-19 22:55:30 +01:00
{21B7EA5E-1EF8-49B6-AC07-11714AF0E37D} = {A10C4720-DCA4-4640-9749-67F4314F527C}
{F75E29D0-D288-478B-8D83-2C190F321A3F} = {A10C4720-DCA4-4640-9749-67F4314F527C}
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
{43CE4CE5-0010-4B99-9569-672670D26E26} = {2D17E75D-2DDC-42C4-AD70-704D95A937AE}
{27B5AAEB-A548-44CF-9777-F8BAA32AF7AE} = {2D17E75D-2DDC-42C4-AD70-704D95A937AE}
Add `Microsoft.Terminal.Remoting.dll` (#8607) Adds a `Microsoft.Terminal.Remoting.dll` to our solution. This DLL will be responsible for all the Monarch/Peasant work that's been described in #7240 & #8135. This PR does _not_ implement the Monarch/Peasant architecture in any significant way. The goal of this PR is to just to establish the project layout, and the most basic connections. This should make reviewing the actual meat of the implementation (in a later PR) easier. It will also give us the opportunity to include some of the basic weird things we're doing (with `CoRegisterClass`) in the Terminal _now_, and get them selfhosted, before building on them too much. This PR does have windows registering the `Monarch` class with COM. When windows are created, they'll as the Monarch if they should create a new window or not. In this PR, the Monarch will always reply "yes, please make a new window". Similar to other projects in our solution, we're adding 3 projects here: * `Microsoft.Terminal.Remoting.lib`: the actual implementation, as a static lib. * `Microsoft.Terminal.Remoting.dll`: The implementation linked as a DLL, for use in `WindowsTerminal.exe`. * `Remoting.UnitTests.dll`: A unit test dll that links with the static lib. There are plenty of TODOs scattered about the code. Clearly, most of this isn't implemented yet, but I do have more WIP branches. I'm using [`projects/5`](https://github.com/microsoft/terminal/projects/5) as my notation for TODOs that are too small for an issue, but are part of the whole Process Model 2.0 work. ## References * #5000 - this is the process model megathread * #7240 - The process model 2.0 spec. * #8135 - the window management spec. (please review me, I have 0/3 signoffs even after the discussion we had 😢) * #8171 - the Monarch/peasant sample. (please review me, I have 1/2) ## PR Checklist * [x] Closes nothing, this is just infrastructure * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated
2021-01-07 23:59:37 +01:00
{68A10CD3-AA64-465B-AF5F-ED4E9700543C} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
Add support for running a commandline in another WT window (#8898) ## Summary of the Pull Request **If you're reading this PR and haven't signed off on #8135, go there first.** ![window-management-000](https://user-images.githubusercontent.com/18356694/103932910-25199380-50e8-11eb-97e3-594a31da62d2.gif) This provides the basic parts of the implementation of #4472. Namely: * We add support for the `--window,-w <window-id>` argument to `wt.exe`, to allow a commandline to be given to another window. * If `window-id` is `0`, run the given commands in _the current window_. * If `window-id` is a negative number, run the commands in a _new_ Terminal window. * If `window-id` is the ID of an existing window, then run the commandline in that window. * If `window-id` is _not_ the ID of an existing window, create a new window. That window will be assigned the ID provided in the commandline. The provided subcommands will be run in that new window. * If `window-id` is omitted, then create a new window. ## References * Spec: #8135 * Megathread: #5000 * Project: projects/5 ## PR Checklist * [x] Closes #4472 * [x] I work here * [x] Tests added/passed * [ ] Requires documentation to be updated - **sure does** ## Detailed Description of the Pull Request / Additional comments Note that `wt -w 1 -d c:\foo cmd.exe` does work, by causing window 1 to change There are limitations, and there are plenty of things to work on in the future: * [ ] We don't support names for windows yet * [ ] We don't support window glomming by default, or a setting to configure what happens when `-w` is omitted. I thought it best to lay the groundwork first, then come back to that. * [ ] `-w 0` currently just uses the "last activated" window, not "the current". There's more follow-up work to try and smartly find the actual window we're being called from. * [ ] Basically anything else that's listed in projects/5. I'm cutting this PR where it currently is, because this is already a huge PR. I believe the remaining tasks will all be easier to land, once this is in. ## Validation Steps Performed I've been creating windows, and closing them, and running cmdlines for a while now. I'm gonna keep doing that while the PR is open, till no bugs remain. # TODOs * [x] There are a bunch of `GetID`, `GetPID` calls that aren't try/caught 😬 - [x] `Monarch.cpp` - [x] `Peasant.cpp` - [x] `WindowManager.cpp` - [x] `AppHost.cpp` * [x] If the monarch gets hung, then _you can't launch any Terminals_ 😨 We should handle this gracefully. - Proposed idea: give the Monarch some time to respond to a proposal for a commandline. If there's no response in that timeframe, this window is now a _hermit_, outside of society entirely. It can't be elected Monarch. It can't receive command lines. It has no ID. - Could we gracefully recover from such a state? maybe, probably not though. - Same deal if a peasant hangs, it could end up hanging the monarch, right? Like if you do `wt -w 2`, and `2` is hung, then does the monarch get hung waiting on the hung peasant? - After talking with @miniksa, **we're gonna punt this from the initial implementation**. If people legit hit this in the wild, we'll fix it then.
2021-02-10 12:28:09 +01:00
{4DAF0299-495E-4CD1-A982-9BAC16A45932} = {59840756-302F-44DF-AA47-441A9D673202}
Implement Default Terminal (#7489) - Implements the default application behavior and handoff mechanisms between console and terminal. The inbox portion is done already. This adds the ability for our OpenConsole.exe to accept the incoming server connection from the Windows OS, stand up a PTY session, start the Windows Terminal as a listener for an incoming connection, and then send it the incoming PTY connection for it to launch a tab. - The tab is launched with default settings at the moment. - You must configure the default application using the `conhost.exe` propsheet or with the registry keys. Finishing the setting inside Windows Terminal will be a todo after this is complete. The OS Settings panel work to surface this setting is a dependency delivered by another team and you will not see it here. ## Validation Steps Performed - [x] Manual adjust of registry keys to the delegation conhost/terminal behavior - [x] Adjustment of the delegation options with the propsheet - [x] Launching things from the run box manually and watching them show in Terminal - [x] Launching things from shortcuts and watching them show in the Terminal Documentation on how it works will be a TODO post completion in #9462 References #7414 - Default Terminal spec Closes #492
2021-03-26 23:09:49 +01:00
{71CC9D78-BA29-4D93-946F-BEF5D9A3A6EF} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
Rename `Microsoft.Terminal.TerminalControl` to `.Control`; Split into dll & lib (#9472) **BE NOT AFRAID**. I know that there's 107 files in this PR, but almost all of it is just find/replacing `TerminalControl` with `Control`. This is the start of the work to move TermControl into multiple pieces, for #5000. The PR starts this work by: * Splits `TerminalControl` into separate lib and dll projects. We'll want control tests in the future, and for that, we'll need a lib. * Moves `ICoreSettings` back into the `Microsoft.Terminal.Core` namespace. We'll have other types in there soon too. * I could not tell you why this works suddenly. New VS versions? New cppwinrt version? Maybe we're just better at dealing with mdmerge bugs these days. * RENAMES `Microsoft.Terminal.TerminalControl` to `Microsoft.Terminal.Control`. This touches pretty much every file in the sln. Sorry about that (not sorry). An upcoming PR will move much of the logic in TermControl into a new `ControlCore` class that we'll add in `Microsoft.Terminal.Core`. `ControlCore` will then be unittest-able in the `UnitTests_TerminalCore`, which will help prevent regressions like #9455 ## Detailed Description of the Pull Request / Additional comments You're really gonna want to clean the sln first, then merge this into your branch, then rebuild. It's very likely that old winmds will get left behind. If you see something like ``` Error MDM2007 Cannot create type Microsoft.Terminal.TerminalControl.KeyModifiers in read-only metadata file Microsoft.Terminal.TerminalControl. ``` then that's what happened to you.
2021-03-17 21:47:24 +01:00
{2D17E75D-2DDC-42C4-AD70-704D95A937AE} = {59840756-302F-44DF-AA47-441A9D673202}
{77875138-BB08-49F9-8BB1-409C2150E0E1} = {59840756-302F-44DF-AA47-441A9D673202}
{9921CA0A-320C-4460-8623-3A3196E7F4CB} = {59840756-302F-44DF-AA47-441A9D673202}
Add a Fuzzing configuration and a version of conhost that can be fuzzed (#9604) This commit introduces a new build configuration, "Fuzzing", which enables the new address sanitizer (shipped in VS 16.9) and code coverage over the entire solution. Only a small subset of projects (those comprising original conhost, right now) are selected to build in this configuration, and even then only in Fuzzing|x64. It also adds a fuzzing-adapted build of conhost, which makes no server connections and handles no client applications. To do this, I've replicated a bit of the console startup routine into fuzzmain.cpp and made up some fake data. This is the bare minimum required to boot up Win32 interactivity (or VT interactivity!) and pretend that a process has connected. If we don't pretend that a process has connected, "conhost" will exit immediately. If we don't forge the process list, conhost will exit. If we can't provide a server handle, we can't provide a "device comm". Minor changes were necessary to server/host such that they would accept a preexisting "device comm". We use this new behavior to provide a "null" one that only hangs up threads and otherwise responds to requests successfully. This fuzzing-adapted build links LLVM's libFuzzer, which is an excellent coverage-based fuzzer that will produce a corpus of inputs that exercise unique codepaths. Eventually, we can use this to generate known-"good" inputs for anything. I've gone ahead and added a fuzz function that yeets bytes directly into WriteCharsLegacy, which was the original reason I went down this path. The implementation of LLVMFuzzerTestOneInput should be replaced with whatever you want to fuzz.
2021-03-29 16:23:30 +02:00
{05D9052F-D78F-478F-968A-2DE38A6DB996} = {E8F24881-5E37-4362-B191-A3BA0ED7F4EB}
Create a control unittesting project (#9677) Does what it says on the can. This is a follow up to #9472. Now that we have a control .lib, we can add tests for it. Unfortunately, the `TermControl` itself is a horrible mess. So this new unittest lib is empty for now. I'm working on actual tests as a part of #6842, but this PR is here to keep the diffs smaller. Also, apparently `server.vcxproj` had the wrong GUID in it. * [x] I work here * [x] Adds tests
2021-04-05 18:07:55 +02:00
{C323DAEE-B307-4C7B-ACE5-7293CBEFCB5B} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
Implement PGO in pipelines for AMD64 architecture; supply training test scenarios (#10071) Implement PGO in pipelines for AMD64 architecture; supply training test scenarios ## References - #3075 - Relevant to speed interests there and other linked issues. ## PR Checklist * [x] Closes #6963 * [x] I work here. * [x] New UIA Tests added and passed. Manual build runs also tested. ## Detailed Description of the Pull Request / Additional comments - Creates a new pipeline run for creating instrumented binaries for Profile Guided Optimization (PGO). - Creates a new suite of UIA tests on the full Windows Terminal app to run PGO training scenarios on instrumented binaries (and incidentally can be used to write other UIA tests later for the full Terminal app.) - Creates a new NuGet artifact to store trained PGO databases (PGD files) at `Microsoft.Internal.Windows.Terminal.PGODatabase` - Creates a new NuGet artifact to supply large-scale test content for automated tests at `Microsoft.Internal.Windows.Terminal.TestContent` - Adjusts the release pipeline to run binaries in PGO optimized mode where content from PGO databases is leveraged at link time to optimize the final release build The following binaries are trained: - OpenConsole.exe - WindowsTerminal.exe - TerminalApp.dll - TerminalConnection.dll - Microsoft.Terminal.Control.dll - Microsoft.Terminal.Remoting.dll - Microsoft.Terminal.Settings.Editor.dll - Microsoft.Terminal.Settings.Model.dll In the future, adding `<PgoTarget>true</PgoTarget>` to a new `vcxproj` file will automatically enroll the DLL/EXE for PGO instrumentation and optimization going forward. Two training test scenarios are implemented: - Smoke test the Terminal by just opening it and typing a bit of text then exiting. (Should help focus on the standard launch path.) - Optimize bulk text output by launching terminal, outputting `big.txt`, then exiting. Additional scenarios can be contributed to the `WindowsTerminal_UIATests` project with the `[TestProperty("IsPGO", "true")]` annotation to add them to the suite of scenarios for PGO. **NOTE:** There are currently no weights applied to the various test scenarios. We will revisit that in the future when/if necessary. ## Validation Steps Performed - [x] - Training run completed at https://dev.azure.com/ms/terminal/_build?definitionId=492&_a=summary - [x] - Optimization run completed locally (by forcing `PGOBuildMode` to `Optimize` on my local machine, manually retrieving the databases with NuGet, and building). - [x] - Validated locally that x86 and ARM64 do not get trained and automatically skip optimization as databases are not present for them. - [x] - Smoke tested optimized binary versus latest releases. `big.txt` output through CMD is ~11-12seconds prior to PGO and just over 8 seconds with PGO.
2021-05-13 23:12:30 +02:00
{F19DACD5-0C6E-40DC-B6E4-767A3200542C} = {BDB237B6-1D1D-400F-84CC-40A58FA59C8E}
Introduce a api-ms-win-core-synch-l1-2-0 shim for Windows 7 (#10559) The code in this file was adapted from the STL on the 2021-07-05. It backports the following Windows 8 functions to Windows 7: * WaitOnAddress * WakeByAddressSingle * WakeByAddressAll These functions are used within `til`. This commit will allow `til` to be used in the conhost source code. Validation * [x] correct .dll loads on Windows 7 * [x] correct .dll loads on Windows 10 * [x] link line for PublicTerminalCore prefers this fake apiset over kernel32
2021-07-07 18:48:28 +02:00
{9CF74355-F018-4C19-81AD-9DC6B7F2C6F5} = {89CDCC5C-9F53-4054-97A4-639D99F169CD}
Introduce AtlasEngine - A new text rendering prototype (#11623) This commit introduces "AtlasEngine", a new text renderer based on DxEngine. But unlike it, DirectWrite and Direct2D are only used to rasterize glyphs. Blending and placing these glyphs into the target view is being done using Direct3D and a simple HLSL shader. Since this new renderer more aggressively assumes that the text is monospace, it simplifies the implementation: The viewport is divided into cells, and its data is stored as a simple matrix. Modifications to this matrix involve only simple pointer arithmetic and is easy to understand. But just like with DxEngine however, DirectWrite related code remains extremely complex and hard to understand. Supported features: * Basic text rendering with grayscale AA * Foreground and background colors * Emojis, including zero width joiners * Underline, dotted underline, strikethrough * Custom font axes and features * Selections * All cursor styles * Full alpha support for all colors * _Should_ work with Windows 7 Unsupported features: * A more conservative GPU memory usage The backing texture atlas for glyphs is grow-only and will not shrink. After 256MB of memory is used up (~20k glyphs) text output will be broken until the renderer is restarted. * ClearType * Remaining gridlines (left, right, top, bottom, double underline) * Hyperlinks don't get full underlines if hovered in WT * Softfonts * Non-default line renditions Performance: * Runs at up to native display refresh rate Unfortunately the frame rate often drops below refresh rate, due us fighting over the buffer lock with other parts of the application. * CPU consumption is up to halved compared to DxEngine AtlasEngine is still highly unoptimized. Glyph hashing consumes up to a third of the current CPU time. * No regressions in WT performance VT parsing and related buffer management takes up most of the CPU time (~85%), due to which the AtlasEngine can't show any further improvements. * ~2x improvement in raw text throughput in OpenConsole compared to DxEngine running at 144 FPS * ≥10x improvement in colored VT output in WT/OpenConsole compared to DxEngine running at 144 FPS
2021-11-13 01:10:06 +01:00
{8222900C-8B6C-452A-91AC-BE95DB04B95F} = {05500DEF-2294-41E3-AF9A-24E580B82836}
Initial release of the Windows Terminal source code This commit introduces all of the Windows Terminal and Console Host source, under the MIT license.
2019-05-03 00:29:04 +02:00
EndGlobalSection
GlobalSection(ExtensibilityGlobals) = postSolution
SolutionGuid = {3140B1B7-C8EE-43D1-A772-D82A7061A271}
EndGlobalSection
EndGlobal