Remove VtApiRoutines #16954
Remove VtApiRoutines #16954
Conversation
lhecker
added
the
Area-CodeHealth
| catch (const wil::ResultException& e) | ||
| { | ||
| hr = e.GetStatusCode(); | ||
| } |
There was a problem hiding this comment.
this seems quite different from what we have today - does it deserve its own PR?
There was a problem hiding this comment.
Ironically it's what prompted me to make this change before I drifted off. I'd be happy to split this into its own PR. It doesn't change the behavior of this function (there shouldn't have been exceptions so far) nor should there be a performance difference (the catch clauses should be essentially cost free). I'm not sure whether a separate PR is better.
| // This is plenty of space to hold the formatted string | ||
| wchar_t cmd[MAX_PATH]{}; | ||
| const BOOL bInheritCursor = (dwFlags & PSEUDOCONSOLE_INHERIT_CURSOR) == PSEUDOCONSOLE_INHERIT_CURSOR; | ||
| const BOOL bResizeQuirk = (dwFlags & PSEUDOCONSOLE_RESIZE_QUIRK) == PSEUDOCONSOLE_RESIZE_QUIRK; | ||
| swprintf_s(cmd, | ||
| MAX_PATH, | ||
| pwszFormat, | ||
| L"\"%s\" --headless %s%s--width %hd --height %hd --signal 0x%tx --server 0x%tx", |
There was a problem hiding this comment.
i see you changed additional format parameters here. can you quickly dip into what tx is versus x? we've had it the one way for like five years ;P
There was a problem hiding this comment.
x is an unsigned int sized parameter and so it's wrong to pass a void* sized type. The only reason it works is because on x86 the stack word size is 8 bytes and so the alignment of those vararg parameters matches the pointer size. I'm sure it's the same on ARM. Additionally, handle values aren't usually very large.
C99 introduced 3 new prefixes:
z:size_tj:intmax_tt:ptrdiff_t
In this case passing t is the right choice. z would also be okay, but only because current architectures have ptrdiff == size.
microsoft-github-policy-service
bot
added
Needs-Author-Feedback
This removes
VtApiRoutinesand the VT passthrough mode.Why? While VT passthrough mode has a clear advantage (doesn't corrupt
VT sequences) it fails to address other pain points (performance,
out-of-sync issues after resize, etc.). Alternative options are
available which have less restrictions.
Why now? It's spring! Spring cleanup!