I've also taken the opportunity to kill the xxxFullPDB trick. The
intermediate PDB is allowed to remain "vc141.pdb" or whatever it wants
to be. PDBs are now simply named after their projects, as was always
tradition.
I was looking at conhost/OpenConsole and noticed it was being pretty
inefficient with allocations due to some usages of std::deque and
std::vector that didn't need to be done quite that way.
So this uses std::vector for the TextBuffer's storage of ROW objects,
which allows one allocation to contiguously reserve space for all the
ROWs - on Desktop this is 9001 ROW objects which means it saves 9000
allocations that the std::deque would have done. Plus it has the
benefit of increasing locality of the ROW objects since deque is going
to chase pointers more often with its data structure.
Then, within each ROW there are CharRow and ATTR_ROW objects that use
std::vector today. This changes them to use Boost's small_vector, which
is a variation of vector that allows for the so-called "small string
optimization." Since we know the typical size of these vectors, we can
pre-reserve the right number of elements directly in the
CharRow/ATTR_ROW instances, avoiding any heap allocations at all for
constructing these objects.
There are a ton of variations on this "small_vector" concept out there
in the world - this one in Boost, LLVM has one called SmallVector,
Electronic Arts' STL has a small_vector, Facebook's folly library has
one...there are a silly number of these out there. But Boost seems like
it's by far the easiest to consume in terms of integration into this
repo, the CI/CD pipeline, licensing, and stuff like that, so I went with
the boost version.
In terms of numbers, I measured the startup path of OpenConsole.exe on
my dev box for Release x64 configuration. My box is an i7-6700k @ 4
Ghz, with 32 GB RAM, not that I think machine config matters much here:
| | Allocation count | Allocated bytes | CPU usage (ms) |
| ------ | ------------------- | ------------------ | -------------- |
| Before | 29,461 | 4,984,640 | 103 |
| After | 2,459 (-91%) | 4,853,931 (-2.6%) | 96 (-7%) |
Along the way, I also fixed a dynamic initializer I happened to spot in
the registry code, and updated some docs.
## Validation Steps Performed
- Ran "runut", "runft" and "runuia" locally and confirmed results are
the same as the main branch
- Profiled the before/after numbers in the Visual Studio profiler, for
the numbers shown in the table
Co-authored-by: Austin Lamb <austinl@microsoft.com>
Turns out there's an actual way to specify C++17 for MSBuild purposes
besides just passing the compile flag.
## References
* Future C++20 support (modules)
## PR Checklist
* [x] Closes random fact found while exploring VS16.8 preview C++20
modules.
* [x] I work here.
* [x] It still builds.
## Detailed Description of the Pull Request / Additional comments
* We've been setting C++17 with just the flag passed to the compiler
`cl.exe`. But it turns out that this particular `LanguageStandard`
option will need to be set appropriately one day for us to use C++20
modules (as evidenced by the latest VS16.8 preview that I tried out to
explore modules.) The `AdditionalOption` alone isn't enough to ensure
that modules can be "seen" by other projects after production, but
`LanguageStandard` is (and will set the compiler option as appropriate
as well as whatever internal goo that MSBuild needs to hook up other
stuff.)
## Validation Steps Performed
* Built with it changed.
This pull request is the initial implementation of hyperlink auto
detection
Overall design:
- Upon startup, TerminalCore gives the TextBuffer some patterns it
should know about
- Whenever something in the viewport changes (i.e. text
output/scrolling), TerminalControl tells TerminalCore (through a
throttled function for performance) to retrieve the visible pattern
locations from the TextBuffer
- When the renderer encounters a region that is associated with a
pattern, it paints that region differently
References #5001Closes#574
This commit fixes our longstanding build artifact output issues and
finally unifies all C++ project output into bin/ and obj/.
In light of that, I've removed NoOutputRedirection.
I've also updated WTU and U8U16Test to use our common build props and
fixed any warnings/compilation errors that popped out.
I validated this change by running repeated incremental builds after
changing individual .cpp files in many of our C++/WinRT projects.
This change is necessary as the dep/ folder is not synced into the
Windows source tree.
I've also added a build rule producing a lib for {fmt}.
This will be required for our next OS ingestion.
This commit adds a specific error message to the build that tells people
to restore git submodules if they forgot to read the README.
#5416 was the straw that broke the camel's back.
We received a request from our localization team to switch from
printf-style format strings (%s, %u) to format strings with positional
argument support. I've been hoping for a long time to take a dependency
on C++20's std::format, but we're just not somewhere we can do that.
Enter fmt. fmt is _exactly_ the library we need.
Minor comparison:
std::wstring_view world = /* ... */;
auto str{ wil::str_printf<std::wstring>(L"hello %.*s",
gsl::narrow_cast<size_t>(world.size()),
world.data()) };
---
auto str{ fmt::format(L"hello {0}", world) };
If you really want to use the print specifiers:
auto str{ fmt::printf(L"hello %s", world) };
It's got optional compile-time checking for format strings and is
MIT-licensed. Eventually, we should be able to replace fmt:: with std::
and end up pretty much where we left off.
What more could you ask for?
This commit replaces `std::vector<bool>` with `dynamic_bitset<>` by
@pinam45 (https://github.com/pinam45/dynamic_bitset) and with
`libpopcnt` for high-performance bit counting by @kimwalisch
(https://github.com/kimwalisch/libpopcnt).
* [x] In support of performance, incremental rendering, and Terminal
"not speed enough" as well as my sanity relative to
`std::vector<bool>`
* [x] Tests updated and passed.
* [x] `LICENSE`, `NOTICE`, and provenance files updated.
* [x] I'm a core contributor. I discussed it with @DHowett-MSFT and
cleared the licensing checks before pulling this in.
## Details `std::vector<bool>` provided by the Microsoft VC Runtime is
incapable of a great many things. Many of the methods you come to expect
off of `std::vector<T>` that are dutifully presented through the `bool`
variant will spontaneously fail at some future date because it decides
you allocated, resized, or manipulated the `vector<bool>` specialization
in an unsupported manner. Half of the methods will straight up not work
for filling/resizing in bulk. And you will tear your hair out as it will
somehow magically forget the assignment of half the bits you gave it
part way through an iteration then assert out and die.
As such, to preserve my sanity, I searched for an alternative. I came
across the self-contained header-only library `dynamic_bitset` by
@pinam45 which appears to do as much of `boost::dynamic_bitset` as I
wanted, but without including 400kg of boost libraries. It also has a
nifty optional dependency on `libpopcnt` by @kimwalisch that will use
processor-specific extensions for rapidly counting bits. @DHowett-MSFT
and I briefly discussed how nice `popcnt` would have been on
`std::vector<bool>` last week... and now we can have it. (To be fair, I
don't believe I'm using it yet... but we'll be able to easily dial in
`til::bitmap` soon and not worry about a performance hit if we do have
to walk bits and count them thanks to `libpopcnt`.)
This PR specifically focuses on swapping the dependencies out and
ingesting the new libraries. We'll further tune `til::bitmap` in future
pulls as necessary.
## Validation
* [x] Ran the automated tests for bitmap.
* [x] Ran the terminal manually and it looks fine still.
## Summary of the Pull Request
<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [x] Closes#4013
* [x] I work here.
* [x] Existing tests should be OK. Real changes, just adding a lib to use.
* [x] Couldn't find any existing docs about intsafe.
* [x] Am core contributor.
## Detailed Description of the Pull Request / Additional comments
* [x] Can we remove min/max completely or rename it in the two projects where it had to be reintroduced? This is now moved into #4152
* [x] How many usages of the old safe math are there? **79**
* [x] If not a ton, can we migrate them here or in a follow on PR? This is now moved into #4153
Files with old safe math:
- TerminalControl: TSFInputControl.cpp
- TerminalCore: TerminalDispatch.cpp
- TerminalCore: TerminalSelection.cpp
- Host: directio.cpp
- RendererGdi: invalidate.cpp
- RendererGdi: math.cpp
- RendererGdi: paint.cpp
- RendererVt: paint.cpp
- TerminalAdapter: adaptDispatch.cpp
- Types: viewport.cpp
- Types: WindowUiaProviderBase.cpp
## Validation Steps Performed
## 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
## 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.
This commit deletes ConhostConnection and replaces it with
ConptyConnection. The ConptyConnection uses CreatePseudoConsole and
depends on winconpty to override the one from kernel32.
* winconpty must be packageable, so I've added GetPackagingOutputs.
* To validate this, I added conpty.dll to the MSIX regression script.
* I moved the code from conpty-universal that deals with environment
strings into the types library.
This puts us in a way better place to implement #2563, as we can now
separately detect a failure to launch a pseudoconsole, a failure to
CreateProcess, and an unexpected termination of the launched process.
Fixes#1131.
This commit cleans up and deduplicates all of the common build
preamble/postamble across exe, dll, lib and c++/winrt projects.
The following specific changes have been made:
* All projects now define their ConfigurationType
* All projects now set all their properties *before* including a common
build file (or any other build files)
* cppwinrt.pre and cppwinrt.post now delegate most of their
configuration to common.pre and common.post
* (becuase of the above,) all build options are conserved between
console and c++/winrt components, including specific warnings and
preprocessor definitions.
* More properties that are configurable per-project are now
conditioned so the common props don't override them.
* The exe, dll, exe.or.dll, and lib postincludes have been merged into
pre or post and switched based on condition as required
* Shared items (-shared, -common) are now explicitly vcxitems instead of
vcxproj files.
* The link line is now manipulated after Microsoft.Cpp sets it, so the
libraries we specify "win". All console things link first against
onecore_apiset.lib.
* Fix all compilation errors caused by build unification
* Move CascadiaPackage's resources into a separate item file
Fixes#922.