2019-05-03 00:29:04 +02:00
|
|
|
/*++
|
|
|
|
|
Copyright (c) Microsoft Corporation
|
|
|
|
|
Licensed under the MIT license.
|
|
|
|
|
|
|
|
|
|
Module Name:
|
|
|
|
|
- globals.h
|
|
|
|
|
|
|
|
|
|
Abstract:
|
|
|
|
|
- This module contains the global variables used by the console server DLL.
|
|
|
|
|
|
|
|
|
|
Author:
|
|
|
|
|
- Jerry Shea (jerrysh) 21-Sep-1993
|
|
|
|
|
|
|
|
|
|
Revision History:
|
|
|
|
|
- Modified to reduce globals over Console V2 project (MiNiksa/PaulCam, 2014)
|
|
|
|
|
--*/
|
|
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
|
|
#include "selection.hpp"
|
|
|
|
|
#include "server.h"
|
|
|
|
|
#include "ConsoleArguments.hpp"
|
|
|
|
|
#include "ApiRoutines.h"
|
|
|
|
|
|
2020-11-25 22:02:10 +01:00
|
|
|
#include "../renderer/inc/IRenderData.hpp"
|
|
|
|
|
#include "../renderer/inc/IRenderEngine.hpp"
|
|
|
|
|
#include "../renderer/inc/IRenderer.hpp"
|
|
|
|
|
#include "../renderer/inc/IFontDefaultList.hpp"
|
2019-05-03 00:29:04 +02:00
|
|
|
|
2020-11-25 22:02:10 +01:00
|
|
|
#include "../server/DeviceComm.h"
|
Convert DeviceComm into an interface and add handle exchange (#8367)
This commit replaces DeviceComm with the interface IDeviceComm and the
concrete implementation type ConDrvDeviceComm. This work is done in
preparation for different device backends.
In addition to separating out ConDrv-specific behavior, I've introduced
a "handle exchange" interface.
HANDLE EXCHANGE
---------------
There are points where we give ConDrv opaque handle identifiers to our
input buffer, output buffer and process data. The exact content of the
opaque identifier is meaningless to ConDrv: the driver's only
interaction with these identifiers is to hold onto them and send back
whichever are pertinent for each API call.
Because of that, we used the raw register-width pointer value of the
input buffer, output buffer or process data _as_ the opaque handle
value.
This works very well for ConDrv <-> conhost using the ConDrvDeviceComm.
It works less well for something like the "logging" DeviceComm that will
log packets to a file: those packets *cannot* contain pointer values (!)
To address this, and to afford flexibility to DeviceComm implementers,
I've introduced a two-member complement of handle management functions:
* `ULONG_PTR PutHandle(void*)` registers an object with the DeviceComm
and returns an opaque identifier.
* `void* GetHandle(ULONG_PTR)` takes an opaque identifier and returns
the original object.
ConDrvDeviceComm implements PutHandle and GetHandle by casting the
object pointer to the "opaque handle value", which maintains wire format
compatibility[1] with revisions of conhost prior to this change.
Simpler DeviceComm implementations that require handle tracking but
cannot bear raw pointers can implement these functions by returning an
autoincrementing ID (or similar) and registering the raw object pointer
in a mapping.
I've audited all existing handle exchanges with the driver and updated
them to use Put/GetHandle.
(I intended to add DestroyHandle, but we are not equipped for handle
removal at the moment. ConsoleHandleData/ConsoleProcessHandle are
destroyed during wait routine completion, on client disconnect, etc.
This does mean that an id<->pointer mapping will grow without bound, but
at a cost of ~8 bytes per entry and a short-lived console session I am
not too concerned about the cost.)
[1] Wire format compatibility is not required, and later we may want to
switch ConDrvDeviceComm to `EncodePointer` and `DecodePointer` just to
insulate us against a spurious ConDrv packet allowing for an arbitrary
4/8-byte read and subsequent liftoff into space.
2020-12-16 00:07:43 +01:00
|
|
|
#include "../server/ConDrvDeviceComm.h"
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
|
#include <TraceLoggingProvider.h>
|
|
|
|
|
#include <winmeta.h>
|
|
|
|
|
TRACELOGGING_DECLARE_PROVIDER(g_hConhostV2EventTraceProvider);
|
|
|
|
|
|
|
|
|
|
class Globals
|
|
|
|
|
{
|
|
|
|
|
public:
|
|
|
|
|
UINT uiOEMCP = GetOEMCP();
|
|
|
|
|
UINT uiWindowsCP = GetACP();
|
|
|
|
|
HINSTANCE hInstance;
|
|
|
|
|
UINT uiDialogBoxCount;
|
|
|
|
|
|
|
|
|
|
ConsoleArguments launchArgs;
|
|
|
|
|
|
|
|
|
|
CONSOLE_INFORMATION& getConsoleInformation();
|
|
|
|
|
|
Convert DeviceComm into an interface and add handle exchange (#8367)
This commit replaces DeviceComm with the interface IDeviceComm and the
concrete implementation type ConDrvDeviceComm. This work is done in
preparation for different device backends.
In addition to separating out ConDrv-specific behavior, I've introduced
a "handle exchange" interface.
HANDLE EXCHANGE
---------------
There are points where we give ConDrv opaque handle identifiers to our
input buffer, output buffer and process data. The exact content of the
opaque identifier is meaningless to ConDrv: the driver's only
interaction with these identifiers is to hold onto them and send back
whichever are pertinent for each API call.
Because of that, we used the raw register-width pointer value of the
input buffer, output buffer or process data _as_ the opaque handle
value.
This works very well for ConDrv <-> conhost using the ConDrvDeviceComm.
It works less well for something like the "logging" DeviceComm that will
log packets to a file: those packets *cannot* contain pointer values (!)
To address this, and to afford flexibility to DeviceComm implementers,
I've introduced a two-member complement of handle management functions:
* `ULONG_PTR PutHandle(void*)` registers an object with the DeviceComm
and returns an opaque identifier.
* `void* GetHandle(ULONG_PTR)` takes an opaque identifier and returns
the original object.
ConDrvDeviceComm implements PutHandle and GetHandle by casting the
object pointer to the "opaque handle value", which maintains wire format
compatibility[1] with revisions of conhost prior to this change.
Simpler DeviceComm implementations that require handle tracking but
cannot bear raw pointers can implement these functions by returning an
autoincrementing ID (or similar) and registering the raw object pointer
in a mapping.
I've audited all existing handle exchanges with the driver and updated
them to use Put/GetHandle.
(I intended to add DestroyHandle, but we are not equipped for handle
removal at the moment. ConsoleHandleData/ConsoleProcessHandle are
destroyed during wait routine completion, on client disconnect, etc.
This does mean that an id<->pointer mapping will grow without bound, but
at a cost of ~8 bytes per entry and a short-lived console session I am
not too concerned about the cost.)
[1] Wire format compatibility is not required, and later we may want to
switch ConDrvDeviceComm to `EncodePointer` and `DecodePointer` just to
insulate us against a spurious ConDrv packet allowing for an arbitrary
4/8-byte read and subsequent liftoff into space.
2020-12-16 00:07:43 +01:00
|
|
|
IDeviceComm* pDeviceComm;
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
|
wil::unique_event_nothrow hInputEvent;
|
|
|
|
|
|
|
|
|
|
SHORT sVerticalScrollSize;
|
|
|
|
|
SHORT sHorizontalScrollSize;
|
|
|
|
|
|
|
|
|
|
int dpi = USER_DEFAULT_SCREEN_DPI;
|
|
|
|
|
ULONG cursorPixelWidth = 1;
|
|
|
|
|
|
|
|
|
|
NTSTATUS ntstatusConsoleInputInitStatus;
|
2019-11-08 22:44:52 +01:00
|
|
|
wil::unique_event_nothrow hConsoleInputInitEvent;
|
2019-05-03 00:29:04 +02:00
|
|
|
DWORD dwInputThreadId;
|
|
|
|
|
|
|
|
|
|
std::vector<wchar_t> WordDelimiters;
|
|
|
|
|
|
2019-05-30 20:14:21 +02:00
|
|
|
Microsoft::Console::Render::IRenderer* pRender;
|
2019-05-03 00:29:04 +02:00
|
|
|
|
2019-05-30 20:14:21 +02:00
|
|
|
Microsoft::Console::Render::IFontDefaultList* pFontDefaultList;
|
2019-05-03 00:29:04 +02:00
|
|
|
|
|
|
|
|
bool IsHeadless() const;
|
|
|
|
|
|
|
|
|
|
ApiRoutines api;
|
|
|
|
|
|
2021-02-11 22:07:50 +01:00
|
|
|
bool handoffTarget = false;
|
|
|
|
|
|
|
|
|
|
std::optional<CLSID> handoffConsoleClsid;
|
2021-03-26 23:09:49 +01:00
|
|
|
std::optional<CLSID> handoffTerminalClsid;
|
2021-02-11 22:07:50 +01:00
|
|
|
|
2020-01-29 17:33:06 +01:00
|
|
|
#ifdef UNIT_TESTING
|
Implement a pair of shims for `cls`, `Clear-Host` in conpty mode (#5627)
## Summary of the Pull Request
This PR implements a pair of shims for `cmd` and `powershell`, so that their `cls` and `Clear-Host` functions will clear the entire terminal buffer (like they do in conhost), instead of just the viewport. With the conpty viewport and buffer being the same size, there's effectively no way to know if an application is calling these API's in this way with the intention of clearing the buffer or the viewport. We absolutely have to guess.
Each of these shims checks to see if the way that the API is being called exactly matches the way `cmd` or `powershell` would call these APIs. If it does, we manually write a `^[[3J` to the connected terminal, to get he Terminal to clear it's own scrollback.
~~_⚠️ If another application were trying to clear the **viewport** with an exactly similar API call, this would also cause the terminal scrollback to get cleared ⚠️_~~
* [x] Should these shims be restricted to when the process that's calling them is actually `cmd.exe` or `powershell.exe`? Can I even do this? I think we've done such a good job of isolating the client process information from the rest of the host code that I can't figure out how to do this.
- YES, this can be done, and I did it.
* [ ] **TODO**: _While I'm here_, should I have `DoSrvPrivateEraseAll` (the implementation for `^[[2J`, in `getset.cpp`) also manually trigger a EraseAll in the terminal in conpty mode?
## PR Checklist
* [x] Closes #3126
* [x] Actually closes #1305 too, which is really the same thing, but probably deserves a callout
* [x] I work here
* [x] Tests added/passed
* [n/a] Requires documentation to be updated
## Validation Steps Performed
* ran tests
* checked `cls` in the Terminal
* checked `Clear-Host` in the Terminal
* Checked running `powershell clear-host` from `cmd.exe`
2020-04-30 23:53:31 +02:00
|
|
|
void EnableConptyModeForTests(std::unique_ptr<Microsoft::Console::Render::VtEngine> vtRenderEngine);
|
2020-01-29 17:33:06 +01:00
|
|
|
#endif
|
|
|
|
|
|
2019-05-03 00:29:04 +02:00
|
|
|
private:
|
|
|
|
|
CONSOLE_INFORMATION ciConsoleInformation;
|
|
|
|
|
};
|
