diff --git a/doc/specs/#13000 - In-process ConPTY.md b/doc/specs/#13000 - In-process ConPTY.md
index 763b836432e..9c618465ead 100644
--- a/doc/specs/#13000 - In-process ConPTY.md
+++ b/doc/specs/#13000 - In-process ConPTY.md
@@ -12,16 +12,16 @@ issue id: 13000
**Why?**
* Out-of-process leads to out-of-sync issues.
* Not all Console APIs have a VT equivalent.
-* Time consuming maintenance work due to poor encapsulation inside conhost.
+* Time-consuming maintenance work due to poor encapsulation inside conhost.
**How?**
1. Remove `VtEngine` and translate Console API calls directly to VT.
-2. Move all Console API related code from the `Host` to the `Server` project.
+2. Move all code related to the Console API from the `Host` to the `Server` project.
Narrow the `IApiRoutines` interface down to its essentials.
Replace relevant singletons with instances.
3. Make `Server` a standalone library with `IApiRoutines` as its primary callback interface.
Integrate the library in Windows Terminal.
-4. (Long term goal:) Ship the `Server` library as part of Windows. Build conhost itself on top of it.
+4. (Long-term goal:) Ship the `Server` library as part of Windows. Build conhost itself on top of it.
## Why?
@@ -138,25 +138,25 @@ flowchart LR
end
```
-To extend on the [tl;dr](#tldr):
-* ConPTY runs outside the hosting terminal which leads to an unsolvable issue: The buffer contents between ConPTY and the terminal can go out of sync.
+To expand on the [tl;dr](#tldr):
+* ConPTY runs outside the hosting terminal, which leads to an unsolvable issue: The buffer contents between ConPTY and the terminal can go out of sync.
* The terminal and ConPTY may implement escape sequences differently.
* ...may implement text processing differently.
* ...may implement text reflow (resize) differently.
- * Resizing the terminal and ConPTY is asynchronous and there may be concurrent text output.
+ * Resizing the terminal and ConPTY is asynchronous, and there may be concurrent text output.
* ...and it may uncover text from the scrollback, which ConPTY doesn't know about.
* Some Console API methods cannot be represented via escape sequences and so ConPTY cannot produce them either.
The most basic example of this is the lack of LVB gridlines.
-* The above suggested new architecture represents a significant simplification with no loss in features.
-* ConPTY has fulfilled our needs a thousand times over, but as it's layered on top of conhost it has resulted in software decay.
- The layer boundary has blurred over the years resulting in debugging and maintenance difficulties.
+* The architecture suggested above represents a significant simplification with no loss in features.
+* ConPTY has fulfilled our needs a thousand times over, but as it's layered on top of conhost, it has resulted in software decay.
+ The layer boundary has blurred over the years, resulting in debugging and maintenance difficulties.
Lastly, its performance is insufficient and has been subject to much debate.
It's on us now to pay our debt and clean up the architecture so that ConPTY, conhost, and Windows Terminal can be built on top of it.
Considerations:
* A named `MUTEX` can theoretically solve parts of the out-of-sync issue, because it could be used to synchronize buffer reflow.
However, this requires the lock to be acquired on every API call, on top of the regular console lock, which raises ABBA deadlock concerns.
- Making this setup not just hopefully but also provably robust, is likely to be very difficult.
+ Making this setup not just hopefully but also provably robust is likely to be very difficult.
It also doesn't solve any of the other listed problems.
## Goal 1: Remove VtEngine
@@ -237,17 +237,17 @@ The idea is that we can translate Console API calls directly to VT at least as w
For instance, a call to `SetConsoleCursorPosition` clearly translates directly to a `CUP` escape sequence.
Effectively, instead of translating output asynchronously in the renderer thread, we'll do it synchronously right during the Console API call.
-Apart from the Console APIs, the "cooked read" implementation, which handles our builtin "readline"-like text editor, will need to receive some larger changes as well.
-Its popups use `ReadConsoleOutput` and `WriteConsoleOutput` to backup and restore the affected rectangle.
-It also directly interfaces with the backing text buffer and its translation to VT relies on the existence of VtEngine.
+Apart from the Console APIs, the "cooked read" implementation, which handles our built-in "readline"-like text editor, will need to receive some larger changes as well.
+Its popups use `ReadConsoleOutput` and `WriteConsoleOutput` to back up and restore the affected rectangle.
+It also directly interfaces with the backing text buffer, and its translation to VT relies on the existence of VtEngine.
This results in all of the same issues that were previously outlined.
In order to solve this, the popups need to be rewritten to use escape sequences so that they can be directly passed to the hosting terminal.
They should also always be below the current prompt line so that we don't need to perform a potentially lossy backup/restore operation.
-The `--vtmode xterm-ascii` switch exists for the telnet client as it only supports ASCII as per RFC854 section "THE NVT PRINTER AND KEYBOARD".
-However, telnet is the only user of this flag and it's trivial to do there (for instance by stripping high codepoints in `WriteOutputToClient` in `telnet/console.cpp`), so there's no reason for us to keep this logic in the new code.
+The `--vtmode xterm-ascii` switch exists for the telnet client, as it only supports ASCII as per RFC854 section "THE NVT PRINTER AND KEYBOARD".
+However, telnet is the only user of this flag, and it's trivial to do there (for instance by stripping high codepoints in `WriteOutputToClient` in `telnet/console.cpp`), so there's no reason for us to keep this logic in the new code.
-This change will result in a significant reduction in complexity of our architecture.
+This change will result in a significant reduction in the complexity of our architecture.
VT input from the shell or other clients will be given 1:1 to the hosting terminal, which will resolve our ordering and buffering issues.
## Goal 2: Move Console API implementations to Server
@@ -326,7 +326,7 @@ flowchart TD
### Discussion
-The basic idea is that instead of having 3 arrows going in and out of the Server component, we got exactly 1.
+The basic idea is that instead of having 3 arrows going in and out of the Server component, we have exactly 1.
This makes the console server and its VT translation a reusable component, which we need so that we can solve the out-of-sync issues by integrating it into Windows Terminal.
To make the Server API convenient to use, the interface needs to be narrowed down to as few methods as possible. This interface is currently called `IApiRoutines`.
@@ -335,14 +335,14 @@ To make the Server API convenient to use, the interface needs to be narrowed dow
Design goals:
* Low overhead
The API should never be the reason why the terminal is slow.
- Among others, the design includes both UTF8 and UTF16 functions, as both encodings are common on Windows and the server component should not make assumptions which one the terminal prefers.
+ Among others, the design includes both UTF8 and UTF16 functions, as both encodings are common on Windows, and the server component should not make assumptions about which one the terminal prefers.
* Easy to use
The Console API is unfortunately quite powerful.
In order to make implementing the callback interface still reasonably easy, the API should have as few methods as are needed.
If a complex Console API call can be expressed as a series of simpler ones, and if no other performance expectations exist, it should be expressed via the simpler ones.
* Works even if only partially implemented
- Example: `CreateConsoleScreenBuffer` is seldomly used, but its existence adds significant complexity to the callback API design and potential implementations.
- A terminal should either be able to return `E_NOTIMPL` and we provide a fallback, or we provide guidance for how reasonable fallbacks can be implemented (e.g. by using the xterm alt buffer in this example).
+ Example: `CreateConsoleScreenBuffer` is seldom used, but its existence adds significant complexity to the callback API design and potential implementations.
+ Either a terminal should be able to return `E_NOTIMPL`, in which case we provide a fallback, or we provide guidance for how reasonable fallbacks can be implemented (e.g. by using the xterm alt buffer in this example).
> [!IMPORTANT]
> The following API design is a rough draft just to convey the general idea.
@@ -368,7 +368,7 @@ Design goals:
// ╰ └──────────────────┘
//
// The good news is that nothing prevents you from giving the Console Buffer the exact
-// same size as the VT Viewport and for modern terminals doing so is recommended.
+// same size as the VT Viewport, and doing so is recommended for modern terminals.
// That way, coordinates are viewport-relative and content below/above the viewport is never addressed:
//
// ┌──────────────────┐ ╮
@@ -382,7 +382,7 @@ Design goals:
// ╰ └──────────────────┘ ╯
//
// Coordinates are 0-indexed. Note that while INT32 coordinates are used by this API, coordinates below
-// 0 and above 65535 are generally invalid as the Console ABI currently uses unsigned 16-Bit integers.
+// 0 and above 65535 are generally invalid as the Console ABI currently uses unsigned 16-bit integers.
struct CONSRV_POINT_I32 {
INT32 x;
@@ -397,7 +397,7 @@ struct CONSRV_POINT_F32 {
// These flags are also defined via Windows.h.
#if 0
// These flags are equivalent to the classic 4-bit indexed colors in VT via SGR.
-// However, the position of the blue and red bits are swapped.
+// However, the positions of the blue and red bits are swapped.
#define FOREGROUND_BLUE 0x0001 // Text color contains blue.
#define FOREGROUND_GREEN 0x0002 // Text color contains green.
#define FOREGROUND_RED 0x0004 // Text color contains red.
@@ -415,20 +415,20 @@ struct CONSRV_POINT_F32 {
#define COMMON_LVB_REVERSE_VIDEO 0x4000 // Reverse foreground and background attribute.
// NOTE: These flags have no equivalent in VT. COMMON_LVB_UNDERSCORE in particular is not the same as a
-// "CSI 4 m" underline in VT, despite the name. They're used to give a cell border (= grid) lines.
+// "CSI 4 m" underline in VT, despite the name. They're used to draw lines on a cell's border (i.e. a grid).
#define COMMON_LVB_GRID_HORIZONTAL 0x0400 // Top horizontal.
#define COMMON_LVB_GRID_LVERTICAL 0x0800 // Left vertical.
#define COMMON_LVB_GRID_RVERTICAL 0x1000 // Right vertical.
#define COMMON_LVB_UNDERSCORE 0x8000 // Underscore.
#endif
-// This struct is binary compatible to the CHAR_INFO struct from the Windows API and functionally equivalent.
+// This struct is binary compatible with the CHAR_INFO struct from the Windows API and functionally equivalent.
//
// The following rules MUST be followed:
// * Each instance represents 1 column in the terminal.
// * Any cells that aren't representable with a single UCS-2 character, or are wider than 2 columns,
-// must be replaced with U+FFFD. Grapheme clusters, surrogate pairs, and similar, are not allowed.
-// Keep in mind that U+FFFD is a narrow character. It does not get the wide wide-glyph treatment below.
+// must be replaced with U+FFFD. Grapheme clusters, surrogate pairs, and similar are not allowed.
+// Keep in mind that U+FFFD is a narrow character. It does not get the wide-glyph treatment below.
// * Colors that cannot be represented via the `attributes` flags can be replaced with an approximation.
// Alternatively, `FOREGROUND_BLUE | FOREGROUND_GREEN | FOREGROUND_RED` can be used (no `BACKGROUND` bit set).
// * If a wide glyph (2 columns wide) is encountered, the following applies:
@@ -459,11 +459,11 @@ struct CONSRV_UTF16_STRING {
DWORD length;
};
-// NOTE: At the time of writing the required fields are not fully known.
-// NOTE: boolean is 8 Bits large.
+// NOTE: At the time of writing, the required fields are not fully known.
+// NOTE: boolean is 8 bits large.
struct CONSRV_INFO {
// NOTE: msys2 relies on the HWND value to uniquely identify terminal sessions.
- // If we were to hand out the multiplexed terminal window HWND to msys2, it will break. Either we need to
+ // If we were to hand out the multiplexed terminal window HWND to msys2, it would break. Either we need to
// create fake windows inside conhost (very bad & buggy) or break msys2 intentionally (also very bad).
HWND window;
CONSRV_UTF16_STRING originalWindowTitle;
@@ -489,10 +489,10 @@ struct CONSRV_INFO {
// Any item that has changed relative to the current CONSRV_INFO will be set to a non-null pointer.
// In other words, members that are null represent those that remain unchanged.
//
-// If the request cannot be supported return E_INVALIDARG. For instance, you may choose to
+// If the request cannot be supported, return E_INVALIDARG. For instance, you may choose to
// do so if you receive a `bufferSizeInCells` change while the xterm alt buffer is active.
//
-// NOTE: At the time of writing the required fields are not fully known.
+// NOTE: At the time of writing, the required fields are not fully known.
struct CONSRV_INFO_CHANGE {
CONSRV_POINT_I32* bufferSizeInCells;
CONSRV_POINT_I32* cursorPositionInCells;
@@ -510,11 +510,11 @@ struct CONSRV_INFO_CHANGE {
};
interface IConsoleServer : IUnknown {
- // TODO: This interface is incomplete. Among others, a way to launch new application into the server is missing.
+ // TODO: This interface is incomplete. Among others, a way to launch new applications into the server is missing.
// ConPTY manages stdin as a ring buffer for you. When the terminal has focus, you simply need to write your input.
// Keyboard input MUST be written via `WriteInputRecords`. The other 2 functions DO NOT parse any VT sequences.
- // They're instead meant either for VT responses (DECRPM, etc.) and for dumping plain text (clipboard, etc.).
+ // They're instead meant either for VT responses (DECRPM, etc.) or for dumping plain text (clipboard, etc.).
void WriteInputRecords([in] DWORD count, [in, length_is(count)] const INPUT_RECORD* records);
void WriteInputUTF8([in] CONSRV_UTF8_STRING text);
void WriteInputUTF16([in] CONSRV_UTF16_STRING text);
@@ -523,22 +523,22 @@ interface IConsoleServer : IUnknown {
// First of all: You don't need to implement all functions and all structs perfectly for ConPTY to work decently well.
// For instance, if you don't implement `CONSRV_INFO::cursorHeight` properly, barely anything will happen.
interface IConsoleServerCallback : IUnknown {
- // The console server is single-threaded and no two calls will be made simultaneously. These two functions
+ // The console server is single-threaded, and no two calls will be made simultaneously. These two functions
// simply allow you to synchronize the calls down below if your application is multi-threaded.
//
// Lock() will always be called before any of the functions below are called.
// Lock() and Unlock() do not need to support recursive locking.
// Any other calls between Lock() and Unlock() should be treated as an atomic operation.
//
- // It is recommended to use a fair lock instead of OS primitives like SRWLOCK. These callback functions may be
+ // It is recommended to use a fair lock instead of OS primitives like SRWLOCK. These callback functions may be called
// much more often than your text renderer, etc., runs. An unfair lock will result in thread starvation.
HRESULT Lock();
HRESULT Unlock();
// If called, you're requested to create a new console alt buffer. The Console API supports having
- // multiple concurrent such buffers. They're not the same as the xterm alt buffer, however (CSI ? 1049 h):
- // They can be resized to be larger than the current viewport and switching between such buffers DOES NOT
- // clear them nor does it reset any other per-buffer state.
+ // multiple such buffers concurrently. They're not the same as the xterm alt buffer, however (CSI ? 1049 h):
+ // They can be resized to be larger than the current viewport, and switching between such buffers DOES NOT
+ // clear them, nor does it reset any other per-buffer state.
//
// If you have trouble adding support for multiple console alt buffers, consider using the xterm alt buffer
// (CSI ? 1049 h) for the first buffer that gets created, and return E_OUTOFMEMORY for any further buffers.
@@ -549,13 +549,13 @@ interface IConsoleServerCallback : IUnknown {
HRESULT ReleaseBuffer([in] void* buffer);
// This switches between different console alt buffers. Switching to a buffer should change the content that's
- // being shown, similar to the xterm alt buffer, however unlike it doing so DOES NOT reset any per-buffer state.
+ // being shown, similar to the xterm alt buffer; however, unlike it, doing so DOES NOT reset any per-buffer state.
// All it does is to basically swap out the underlying, active text buffer of the terminal.
//
- // If `buffer` is NULL it's a request to switch back to the main buffer.
+ // If `buffer` is NULL, it's a request to switch back to the main buffer.
//
- // `temporary` is a hint. If it's `true` it indicates that the previous buffer will soon be activated again.
- // In other words, on Unlock() the buffer was active during Lock() will be active again.
+ // `temporary` is a hint. If it's `true`, it indicates that the previous buffer will soon be activated again.
+ // In other words, on Unlock(), the buffer that was active during Lock() will be active again.
// It's recommended that temporary switches are lightweight as they may occur relatively often.
HRESULT ActivateBuffer([in] void* buffer, [in] boolean temporary);
@@ -574,8 +574,8 @@ interface IConsoleServerCallback : IUnknown {
// It's recommended that this function is lightweight as it may be called relatively often.
const CONSRV_INFO* GetInfo();
- // When this method is called you're asked to apply any non-null member of the given CONSRV_INFO_CHANGE struct
- // to the active buffer. For instance a non-null `.cursorPosition` is identical to calling `SetCursorPosition`,
+ // When this method is called, you're asked to apply any non-null member of the given CONSRV_INFO_CHANGE struct
+ // to the active buffer. For instance, a non-null `.cursorPosition` is identical to calling `SetCursorPosition`,
// a non-null `.bufferSize` is a request to resize the terminal, and so on.
HRESULT SetInfo([in] const CONSRV_INFO_CHANGE* info);
@@ -585,7 +585,7 @@ interface IConsoleServerCallback : IUnknown {
// printf("\x1b[%d;%dC", pos.y + 1, pos.x + 1);
HRESULT SetCursorPosition([in] CONSRV_POINT_I32 pos);
- // The Console API supports 4 gridline attributes which cannot be translated to VT.
+ // The Console API supports 4 gridline attributes, which cannot be translated to VT.
// This function is necessary to represent those. If you don't plan to support the gridlines,
// you can translate the attributes to VT with the following code or some equivalent:
// static const uint8_t lut[] = { 30, 34, 32, 36, 31, 35, 33, 37, 90, 94, 92, 96, 91, 95, 93, 97 };
@@ -601,11 +601,11 @@ interface IConsoleServerCallback : IUnknown {
// printf("\x1b[7m");
HRESULT SetCurrentAttributes([in] UINT16 attributes);
- // Starting from column `pos.x` in row `pos.y`, this reads `count`-many characters and attributes.
+ // Starting from column `pos.x` in row `pos.y`, this reads `count` characters and attributes.
// `pos` and `count` will be clamped such that reads never extend outside of the `CONSRV_INFO::bufferSize`.
//
// However, it may still read cells that have never been written to (for instance below the current viewport!).
- // Such reads should not fail. Simply fill the `infos` array with whitespaces and a default attribute of your chosing,
+ // Such reads should not fail. Simply fill the `infos` array with whitespace and a default attribute of your choosing,
// but `FOREGROUND_BLUE | FOREGROUND_GREEN | FOREGROUND_RED` is recommended (no other bits set).
//
// NOTE that this API should ignore any line renditions (DECDWL, DECDHL), margins (DECSLRM, ...), etc.
@@ -613,33 +613,33 @@ interface IConsoleServerCallback : IUnknown {
// as described in the previous paragraph.
HRESULT ReadBuffer([in] CONSRV_POINT_I32 pos, [in] INT32 count, [out, length_is(count)] CONSRV_CHAR_INFO* infos);
- // These two functions are used to layout text for the internal "GNU Readline"-like implementation.
+ // These two functions are used to lay out text for the internal "GNU Readline"-like implementation.
// `text` is the string to operate on. As with any other method, input validation should be performed.
- // It's preferred to pretend as if invalid codepoints (in particular invalid surrogate pairs)
+ // It's preferred to pretend that invalid codepoints (in particular invalid surrogate pairs)
// are U+FFFD, because this provides the user with some level of text editing capability.
- // The alternative is to have none at all when facing invalid strings which is strictly worse.
- // `maxClusters` is the maximum amount of "cursor movements" these functions should apply
+ // The alternative is to have none at all when facing invalid strings, which is strictly worse.
+ // `maxClusters` is the maximum number of "cursor movements" these functions should apply
// (like when pressing the left/right arrow buttons).
- // `maxColumns` is the maximum amount of columns the functions may iterate over. When the text is "a猫" and
+ // `maxColumns` is the maximum number of columns the functions may iterate over. When the text is "a猫" and
// `maxColumns` is 2, then the result should be "a", because "猫" doesn't fit anymore.
// `position` on input contains the current position of the cursor inside `text`, counted in characters from the
// start of the `text`. On output it's supposed to contain the new cursor position.
// `position` may be out of bounds and you should clamp it to a valid range first.
// `columns` on output should contain the number of columns that have been iterated over.
//
- // The idea is that a `maxClusters = 1` and `maxColumns = inf` can be used to implement left/right cursor movement,
- // while `maxClusters = inf` and `maxColumns = window width` can be used to layout text within the window.
+ // The idea is that `maxClusters = 1` and `maxColumns = inf` can be used to implement left/right cursor movement,
+ // while `maxClusters = inf` and `maxColumns = window width` can be used to lay out text within the window.
//
- // You don't need to handle escape characters. These functions will never be called with any present.
- // For robustness against bugs it's however recommended to handle them anyway, in whatever way you wish.
+ // You don't need to handle escape characters. These functions will never be called with any escape characters present.
+ // For robustness against bugs, however, it's recommended to handle them anyway, in whatever way you wish.
// If you have no preference, it's recommended to treat them as zero-width characters.
HRESULT MeasureTextForward([in] CONSRV_UTF16_STRING text, [in] DWORD maxClusters, [in] DWORD maxColumns, [in, out] DWORD* position, [out] DWORD* columns);
HRESULT MeasureTextBackward([in] CONSRV_UTF16_STRING text, [in] DWORD maxClusters, [in] DWORD maxColumns, [in, out] DWORD* position, [out] DWORD* columns);
- // UTF8 and UTF16 are both widely used text encodings on Windows and it's recommended that both
+ // UTF8 and UTF16 are both widely used text encodings on Windows, and it's recommended that both
// functions are reasonably fast. ConPTY will translate all non-Unicode text to UTF16 for you.
// You must validate incoming text. It's recommended to replace invalid codepoints with U+FFFD.
- // You don't need to check for broken up codepoints at the start/end of the text, as ConPTY will handle that for you.
+ // You don't need to check for broken-up codepoints at the start/end of the text, as ConPTY will handle that for you.
HRESULT WriteUTF8([in] boolean raw, [in] CONSRV_UTF8_STRING text);
HRESULT WriteUTF16([in] boolean raw, [in] CONSRV_UTF16_STRING text);
};
@@ -647,7 +647,7 @@ interface IConsoleServerCallback : IUnknown {
The list shows how each Console API function is implemented in terms of the above interface.
* Aliases
-
Fully implemented inside the server component without API.
+
Fully implemented inside the server component without an API.
* `AddConsoleAlias`
* `GetConsoleAlias`
* `GetConsoleAliases`
@@ -655,7 +655,7 @@ The list shows how each Console API function is implemented in terms of the abov
* `GetConsoleAliasExes`
* `GetConsoleAliasExesLength`
* History
-
Fully implemented inside the server component without API.
+
Fully implemented inside the server component without an API.
* `ExpungeConsoleCommandHistory`
* `GetConsoleCommandHistory`
* `GetConsoleCommandHistoryLength`
@@ -663,7 +663,7 @@ The list shows how each Console API function is implemented in terms of the abov
* `SetConsoleHistoryInfo`
* `SetConsoleNumberOfCommands`
* stdin
-
Fully implemented inside the server component without API.
+
Fully implemented inside the server component without an API.
* `FlushConsoleInputBuffer`
* `GetConsoleInput`
* `GetConsoleInputCodePage`
@@ -679,9 +679,9 @@ The list shows how each Console API function is implemented in terms of the abov
* `SetConsoleDisplayMode`
* Buffer management
* `GetConsoleScreenBufferInfoEx`:
- Gets information from server's internal `SCREEN_INFORMATION` class (which represents the `HANDLE`).
+ Gets information from the server's internal `SCREEN_INFORMATION` class (which represents the `HANDLE`).
* `SetConsoleScreenBufferInfoEx`:
- Sets information on server's internal `SCREEN_INFORMATION` class.
+ Sets information on the server's internal `SCREEN_INFORMATION` class.
* `CreateConsoleScreenBuffer`:
`CreateBuffer`
* `SetConsoleActiveScreenBuffer`:
@@ -715,7 +715,7 @@ The list shows how each Console API function is implemented in terms of the abov
`GetInfo`; The window frame size can be inferred from the difference between the `GetWindowRect(hwnd)` and the `viewSizeInCells * cellSizeInDIP`.
The max. cell count can then be calculated by getting the `MonitorFromWindow(hwnd)` size, subtracting the frame size and calculating the cell count.
* `GetNumberOfConsoleMouseButtons`:
- Implemented inside the server component via `GetSystemMetrics(SM_CMOUSEBUTTONS)`
+ Implemented inside the server component via `GetSystemMetrics(SM_CMOUSEBUTTONS)`.
* `SetConsoleTitle`:
`SetInfo`
* `SetConsoleWindowInfo`:
@@ -726,13 +726,13 @@ The list shows how each Console API function is implemented in terms of the abov
For each line, get the existing contents with `ReadBuffer`, `SetCursorPosition` to the start, concatenate the cells and write them with `WriteUTF16`.
* `FillConsoleOutputCharacter`:
For each line, get the existing contents with `ReadBuffer`, `SetCursorPosition` to the start, concatenate the cells and write them with `WriteUTF16`.
- At the start of each line and every time the attributes change use `SetCurrentAttributes` to set them up.
+ At the start of each line and every time the attributes change, use `SetCurrentAttributes` to set them up.
* `GetConsoleOutputCodePage`:
Implemented inside the server component.
* `GetConsoleOutputMode`:
Implemented inside the server component.
* `ScrollConsoleScreenBuffer`:
- **TODO**: It may be necessary to add a `ScrollBuffer` API to make vertical scrolling across the entire buffer width faster. This fast pass currently exists as well.
+ **TODO**: It may be necessary to add a `ScrollBuffer` API to make vertical scrolling across the entire buffer width faster. This fast path currently exists as well.
Otherwise, this will be translated to: Read all lines in the source rectangle with `ReadBuffer`.
Then refer to the `WriteConsoleOutput` implementation for writing it to the target.
* `SetConsoleOutputCodePage`:
@@ -745,7 +745,7 @@ The list shows how each Console API function is implemented in terms of the abov
`WriteUTF8` if `CP_UTF8` is active and otherwise `WriteUTF16`.
* `WriteConsoleOutput`:
For each line, `SetCursorPosition` to the start, concatenate the cells and write them with `WriteUTF16`.
- At the start of each line and every time the attributes change use `SetCurrentAttributes` to set them up.
+ At the start of each line and every time the attributes change, use `SetCurrentAttributes` to set them up.
* `WriteConsoleOutputAttribute`:
Same as `FillConsoleOutputAttribute`, but with varying attributes.
* `WriteConsoleOutputCharacter`:
@@ -836,5 +836,5 @@ At this point we should also see if we can find early adopters of the API in oth
The console server on Windows has been an internal ABI for the longest time.
As we have started shipping ConPTY bundled with conhost/OpenConsole to other projects, the internal ABI has become a public one.
-While we have no intention of ever breaking forward compatability of the console server with future Windows versions, it would be reassuring if the ABI long-term became internal once more.
-This will allow us complete freedom over its design, even in the decades to come, and allow us to fully shim any 3rd party applications on Windows if a ABI change were to ever happen.
+While we have no intention of ever breaking forward compatibility of the console server with future Windows versions, it would be reassuring if the ABI became internal once more in the long term.
+This will allow us complete freedom over its design, even in the decades to come, and allow us to fully shim any third-party applications on Windows if an ABI change were to ever happen.