2012-10-23 22:31:36 +00:00
|
|
|
/*
|
2004-01-11 17:31:16 +00:00
|
|
|
* COPYRIGHT: See COPYING in the top level directory
|
2012-10-25 20:40:41 +00:00
|
|
|
* PROJECT: ReactOS Console Server DLL
|
2015-10-05 12:21:25 +00:00
|
|
|
* FILE: win32ss/user/winsrv/consrv/frontends/tui/tuiterm.c
|
2013-04-11 23:37:09 +00:00
|
|
|
* PURPOSE: TUI Terminal Front-End - Virtual Consoles...
|
2013-04-10 20:22:30 +00:00
|
|
|
* PROGRAMMERS: David Welch
|
2021-07-03 23:46:52 +00:00
|
|
|
* Gé van Geldorp
|
2013-04-10 20:22:30 +00:00
|
|
|
* Jeffrey Morlan
|
|
|
|
* Hermes Belusca-Maito (hermes.belusca@sfr.fr)
|
2004-01-11 17:31:16 +00:00
|
|
|
*/
|
|
|
|
|
2013-06-23 00:18:47 +00:00
|
|
|
#ifdef TUITERM_COMPILE
|
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
#include <consrv.h>
|
|
|
|
|
2014-08-31 14:04:03 +00:00
|
|
|
// #include "include/conio.h"
|
2013-04-13 21:09:49 +00:00
|
|
|
#include "include/console.h"
|
2013-04-11 23:37:09 +00:00
|
|
|
#include "include/settings.h"
|
|
|
|
#include "tuiterm.h"
|
2015-03-08 13:52:06 +00:00
|
|
|
|
|
|
|
#include <ndk/iofuncs.h>
|
|
|
|
#include <ndk/setypes.h>
|
2012-10-23 22:31:36 +00:00
|
|
|
#include <drivers/blue/ntddblue.h>
|
|
|
|
|
2004-01-11 17:31:16 +00:00
|
|
|
#define NDEBUG
|
|
|
|
#include <debug.h>
|
|
|
|
|
2013-01-04 00:41:10 +00:00
|
|
|
|
2021-07-03 23:46:52 +00:00
|
|
|
/* CAB FILE STRUCTURES ******************************************************/
|
|
|
|
|
|
|
|
typedef struct _CFHEADER
|
|
|
|
{
|
|
|
|
ULONG Signature; // File signature 'MSCF' (CAB_SIGNATURE)
|
|
|
|
ULONG Reserved1; // Reserved field
|
|
|
|
ULONG CabinetSize; // Cabinet file size
|
|
|
|
ULONG Reserved2; // Reserved field
|
|
|
|
ULONG FileTableOffset; // Offset of first CFFILE
|
|
|
|
ULONG Reserved3; // Reserved field
|
|
|
|
USHORT Version; // Cabinet version (CAB_VERSION)
|
|
|
|
USHORT FolderCount; // Number of folders
|
|
|
|
USHORT FileCount; // Number of files
|
|
|
|
USHORT Flags; // Cabinet flags (CAB_FLAG_*)
|
|
|
|
USHORT SetID; // Cabinet set id
|
|
|
|
USHORT CabinetNumber; // Zero-based cabinet number
|
|
|
|
} CFHEADER, *PCFHEADER;
|
|
|
|
|
|
|
|
typedef struct _CFFILE
|
|
|
|
{
|
|
|
|
ULONG FileSize; // Uncompressed file size in bytes
|
|
|
|
ULONG FileOffset; // Uncompressed offset of file in the folder
|
|
|
|
USHORT FileControlID; // File control ID (CAB_FILE_*)
|
|
|
|
USHORT FileDate; // File date stamp, as used by DOS
|
|
|
|
USHORT FileTime; // File time stamp, as used by DOS
|
|
|
|
USHORT Attributes; // File attributes (CAB_ATTRIB_*)
|
|
|
|
/* After this is the NULL terminated filename */
|
|
|
|
// CHAR FileName[ANYSIZE_ARRAY];
|
|
|
|
} CFFILE, *PCFFILE;
|
|
|
|
|
|
|
|
#define CAB_SIGNATURE 0x4643534D // "MSCF"
|
|
|
|
#define CAB_VERSION 0x0103
|
|
|
|
|
|
|
|
|
|
|
|
/* GLOBALS ******************************************************************/
|
2013-03-08 23:37:11 +00:00
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
#define ConsoleOutputUnicodeToAnsiChar(Console, dChar, sWChar) \
|
2020-02-08 23:24:21 +00:00
|
|
|
do { \
|
|
|
|
ASSERT((ULONG_PTR)(dChar) != (ULONG_PTR)(sWChar)); \
|
|
|
|
WideCharToMultiByte((Console)->OutputCodePage, 0, (sWChar), 1, (dChar), 1, NULL, NULL); \
|
|
|
|
} while (0)
|
2015-03-08 13:52:06 +00:00
|
|
|
|
2013-01-04 00:41:10 +00:00
|
|
|
/* TUI Console Window Class name */
|
|
|
|
#define TUI_CONSOLE_WINDOW_CLASS L"TuiConsoleWindowClass"
|
|
|
|
|
2013-03-08 23:37:11 +00:00
|
|
|
typedef struct _TUI_CONSOLE_DATA
|
|
|
|
{
|
|
|
|
CRITICAL_SECTION Lock;
|
2013-04-11 23:37:09 +00:00
|
|
|
LIST_ENTRY Entry; /* Entry in the list of virtual consoles */
|
2013-03-08 23:37:11 +00:00
|
|
|
// HANDLE hTuiInitEvent;
|
2015-03-08 13:52:06 +00:00
|
|
|
// HANDLE hTuiTermEvent;
|
2013-03-08 23:37:11 +00:00
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
HWND hWindow; /* Handle to the console's window (used for the window's procedure) */
|
2013-03-08 23:37:11 +00:00
|
|
|
|
2014-08-11 20:55:50 +00:00
|
|
|
PCONSRV_CONSOLE Console; /* Pointer to the owned console */
|
2015-03-08 13:52:06 +00:00
|
|
|
PCONSOLE_SCREEN_BUFFER ActiveBuffer; /* Pointer to the active screen buffer (then maybe the previous Console member is redundant?? Or not...) */
|
2013-04-11 23:37:09 +00:00
|
|
|
// TUI_CONSOLE_INFO TuiInfo; /* TUI terminal settings */
|
2013-03-08 23:37:11 +00:00
|
|
|
} TUI_CONSOLE_DATA, *PTUI_CONSOLE_DATA;
|
2013-01-04 00:41:10 +00:00
|
|
|
|
2014-08-04 21:09:46 +00:00
|
|
|
#define GetNextConsole(Console) \
|
|
|
|
CONTAINING_RECORD(Console->Entry.Flink, TUI_CONSOLE_DATA, Entry)
|
|
|
|
|
|
|
|
#define GetPrevConsole(Console) \
|
|
|
|
CONTAINING_RECORD(Console->Entry.Blink, TUI_CONSOLE_DATA, Entry)
|
|
|
|
|
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
/* List of the maintained virtual consoles and its lock */
|
|
|
|
static LIST_ENTRY VirtConsList;
|
|
|
|
static PTUI_CONSOLE_DATA ActiveConsole; /* The active console on screen */
|
|
|
|
static CRITICAL_SECTION ActiveVirtConsLock;
|
|
|
|
|
2004-01-11 17:31:16 +00:00
|
|
|
static COORD PhysicalConsoleSize;
|
|
|
|
static HANDLE ConsoleDeviceHandle;
|
|
|
|
|
2005-04-18 18:24:06 +00:00
|
|
|
static BOOL ConsInitialized = FALSE;
|
2004-01-11 17:31:16 +00:00
|
|
|
|
2013-01-13 19:50:52 +00:00
|
|
|
/******************************************************************************\
|
|
|
|
|** BlueScreen Driver management **|
|
|
|
|
\**/
|
|
|
|
/* Code taken and adapted from base/system/services/driver.c */
|
|
|
|
static DWORD
|
|
|
|
ScmLoadDriver(LPCWSTR lpServiceName)
|
|
|
|
{
|
2013-01-26 23:16:34 +00:00
|
|
|
NTSTATUS Status = STATUS_SUCCESS;
|
|
|
|
BOOLEAN WasPrivilegeEnabled = FALSE;
|
2013-01-13 19:50:52 +00:00
|
|
|
PWSTR pszDriverPath;
|
|
|
|
UNICODE_STRING DriverPath;
|
|
|
|
|
|
|
|
/* Build the driver path */
|
|
|
|
/* 52 = wcslen(L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\") */
|
2013-05-12 00:20:15 +00:00
|
|
|
pszDriverPath = ConsoleAllocHeap(HEAP_ZERO_MEMORY,
|
|
|
|
(52 + wcslen(lpServiceName) + 1) * sizeof(WCHAR));
|
2013-01-13 19:50:52 +00:00
|
|
|
if (pszDriverPath == NULL)
|
|
|
|
return ERROR_NOT_ENOUGH_MEMORY;
|
|
|
|
|
|
|
|
wcscpy(pszDriverPath,
|
|
|
|
L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\");
|
|
|
|
wcscat(pszDriverPath,
|
|
|
|
lpServiceName);
|
|
|
|
|
|
|
|
RtlInitUnicodeString(&DriverPath,
|
|
|
|
pszDriverPath);
|
|
|
|
|
|
|
|
DPRINT(" Path: %wZ\n", &DriverPath);
|
|
|
|
|
|
|
|
/* Acquire driver-loading privilege */
|
2013-01-26 23:16:34 +00:00
|
|
|
Status = RtlAdjustPrivilege(SE_LOAD_DRIVER_PRIVILEGE,
|
|
|
|
TRUE,
|
|
|
|
FALSE,
|
|
|
|
&WasPrivilegeEnabled);
|
|
|
|
if (!NT_SUCCESS(Status))
|
2013-01-13 19:50:52 +00:00
|
|
|
{
|
|
|
|
/* We encountered a failure, exit properly */
|
2013-01-26 23:16:34 +00:00
|
|
|
DPRINT1("CONSRV: Cannot acquire driver-loading privilege, Status = 0x%08lx\n", Status);
|
2013-01-13 19:50:52 +00:00
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
Status = NtLoadDriver(&DriverPath);
|
|
|
|
|
|
|
|
/* Release driver-loading privilege */
|
2013-01-26 23:16:34 +00:00
|
|
|
RtlAdjustPrivilege(SE_LOAD_DRIVER_PRIVILEGE,
|
|
|
|
WasPrivilegeEnabled,
|
|
|
|
FALSE,
|
|
|
|
&WasPrivilegeEnabled);
|
2013-01-13 19:50:52 +00:00
|
|
|
|
|
|
|
done:
|
2013-05-12 00:20:15 +00:00
|
|
|
ConsoleFreeHeap(pszDriverPath);
|
2013-01-26 23:16:34 +00:00
|
|
|
return RtlNtStatusToDosError(Status);
|
2013-01-13 19:50:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef BLUESCREEN_DRIVER_UNLOADING
|
|
|
|
static DWORD
|
|
|
|
ScmUnloadDriver(LPCWSTR lpServiceName)
|
|
|
|
{
|
2013-01-26 23:16:34 +00:00
|
|
|
NTSTATUS Status = STATUS_SUCCESS;
|
|
|
|
BOOLEAN WasPrivilegeEnabled = FALSE;
|
2013-01-13 19:50:52 +00:00
|
|
|
PWSTR pszDriverPath;
|
|
|
|
UNICODE_STRING DriverPath;
|
|
|
|
|
|
|
|
/* Build the driver path */
|
|
|
|
/* 52 = wcslen(L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\") */
|
2013-05-12 00:20:15 +00:00
|
|
|
pszDriverPath = ConsoleAllocHeap(HEAP_ZERO_MEMORY,
|
|
|
|
(52 + wcslen(lpServiceName) + 1) * sizeof(WCHAR));
|
2013-01-13 19:50:52 +00:00
|
|
|
if (pszDriverPath == NULL)
|
|
|
|
return ERROR_NOT_ENOUGH_MEMORY;
|
|
|
|
|
|
|
|
wcscpy(pszDriverPath,
|
|
|
|
L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\");
|
|
|
|
wcscat(pszDriverPath,
|
|
|
|
lpServiceName);
|
|
|
|
|
|
|
|
RtlInitUnicodeString(&DriverPath,
|
|
|
|
pszDriverPath);
|
|
|
|
|
2013-01-26 23:16:34 +00:00
|
|
|
DPRINT(" Path: %wZ\n", &DriverPath);
|
|
|
|
|
2013-01-13 19:50:52 +00:00
|
|
|
/* Acquire driver-unloading privilege */
|
2013-01-26 23:16:34 +00:00
|
|
|
Status = RtlAdjustPrivilege(SE_LOAD_DRIVER_PRIVILEGE,
|
|
|
|
TRUE,
|
|
|
|
FALSE,
|
|
|
|
&WasPrivilegeEnabled);
|
|
|
|
if (!NT_SUCCESS(Status))
|
2013-01-13 19:50:52 +00:00
|
|
|
{
|
|
|
|
/* We encountered a failure, exit properly */
|
2013-01-26 23:16:34 +00:00
|
|
|
DPRINT1("CONSRV: Cannot acquire driver-unloading privilege, Status = 0x%08lx\n", Status);
|
2013-01-13 19:50:52 +00:00
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
|
|
|
Status = NtUnloadDriver(&DriverPath);
|
|
|
|
|
|
|
|
/* Release driver-unloading privilege */
|
2013-01-26 23:16:34 +00:00
|
|
|
RtlAdjustPrivilege(SE_LOAD_DRIVER_PRIVILEGE,
|
|
|
|
WasPrivilegeEnabled,
|
|
|
|
FALSE,
|
|
|
|
&WasPrivilegeEnabled);
|
2013-01-13 19:50:52 +00:00
|
|
|
|
|
|
|
done:
|
2013-05-12 00:20:15 +00:00
|
|
|
ConsoleFreeHeap(pszDriverPath);
|
2013-01-26 23:16:34 +00:00
|
|
|
return RtlNtStatusToDosError(Status);
|
2013-01-13 19:50:52 +00:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
/**\
|
|
|
|
\******************************************************************************/
|
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
#if 0
|
2014-05-02 16:46:13 +00:00
|
|
|
static BOOL
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
TuiSwapConsole(INT Next)
|
|
|
|
{
|
2013-04-11 23:37:09 +00:00
|
|
|
static PTUI_CONSOLE_DATA SwapConsole = NULL; /* Console we are thinking about swapping with */
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
DWORD BytesReturned;
|
|
|
|
ANSI_STRING Title;
|
|
|
|
PVOID Buffer;
|
|
|
|
PCOORD pos;
|
|
|
|
|
|
|
|
if (0 != Next)
|
|
|
|
{
|
2013-04-11 23:37:09 +00:00
|
|
|
/*
|
|
|
|
* Alt-Tab, swap consoles.
|
|
|
|
* move SwapConsole to next console, and print its title.
|
|
|
|
*/
|
|
|
|
EnterCriticalSection(&ActiveVirtConsLock);
|
|
|
|
if (!SwapConsole) SwapConsole = ActiveConsole;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
SwapConsole = (0 < Next ? GetNextConsole(SwapConsole) : GetPrevConsole(SwapConsole));
|
|
|
|
Title.MaximumLength = RtlUnicodeStringToAnsiSize(&SwapConsole->Console->Title);
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Title.Length = 0;
|
2013-05-12 00:20:15 +00:00
|
|
|
Buffer = ConsoleAllocHeap(0, sizeof(COORD) + Title.MaximumLength);
|
2013-04-11 23:37:09 +00:00
|
|
|
pos = (PCOORD)Buffer;
|
|
|
|
Title.Buffer = (PVOID)((ULONG_PTR)Buffer + sizeof(COORD));
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
RtlUnicodeStringToAnsiString(&Title, &SwapConsole->Console->Title, FALSE);
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
pos->X = (PhysicalConsoleSize.X - Title.Length) / 2;
|
2013-04-11 23:37:09 +00:00
|
|
|
pos->Y = PhysicalConsoleSize.Y / 2;
|
|
|
|
/* Redraw the console to clear off old title */
|
|
|
|
ConioDrawConsole(ActiveConsole->Console);
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (!DeviceIoControl(ConsoleDeviceHandle, IOCTL_CONSOLE_WRITE_OUTPUT_CHARACTER,
|
|
|
|
NULL, 0, Buffer, sizeof(COORD) + Title.Length,
|
|
|
|
&BytesReturned, NULL))
|
|
|
|
{
|
|
|
|
DPRINT1( "Error writing to console\n" );
|
|
|
|
}
|
2013-05-12 00:20:15 +00:00
|
|
|
ConsoleFreeHeap(Buffer);
|
2013-04-11 23:37:09 +00:00
|
|
|
LeaveCriticalSection(&ActiveVirtConsLock);
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
else if (NULL != SwapConsole)
|
|
|
|
{
|
2013-04-11 23:37:09 +00:00
|
|
|
EnterCriticalSection(&ActiveVirtConsLock);
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
if (SwapConsole != ActiveConsole)
|
|
|
|
{
|
2013-04-11 23:37:09 +00:00
|
|
|
/* First remove swapconsole from the list */
|
|
|
|
SwapConsole->Entry.Blink->Flink = SwapConsole->Entry.Flink;
|
|
|
|
SwapConsole->Entry.Flink->Blink = SwapConsole->Entry.Blink;
|
|
|
|
/* Now insert before activeconsole */
|
|
|
|
SwapConsole->Entry.Flink = &ActiveConsole->Entry;
|
|
|
|
SwapConsole->Entry.Blink = ActiveConsole->Entry.Blink;
|
|
|
|
ActiveConsole->Entry.Blink->Flink = &SwapConsole->Entry;
|
|
|
|
ActiveConsole->Entry.Blink = &SwapConsole->Entry;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
}
|
|
|
|
ActiveConsole = SwapConsole;
|
|
|
|
SwapConsole = NULL;
|
2013-04-11 23:37:09 +00:00
|
|
|
ConioDrawConsole(ActiveConsole->Console);
|
|
|
|
LeaveCriticalSection(&ActiveVirtConsLock);
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
}
|
2015-03-08 13:52:06 +00:00
|
|
|
#endif
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
|
2014-05-02 16:46:13 +00:00
|
|
|
static VOID
|
2013-06-14 01:10:43 +00:00
|
|
|
TuiCopyRect(PCHAR Dest, PTEXTMODE_SCREEN_BUFFER Buff, SMALL_RECT* Region)
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
{
|
2013-04-11 23:37:09 +00:00
|
|
|
UINT SrcDelta, DestDelta;
|
|
|
|
LONG i;
|
2013-06-14 01:10:43 +00:00
|
|
|
PCHAR_INFO Src, SrcEnd;
|
2013-04-11 23:37:09 +00:00
|
|
|
|
|
|
|
Src = ConioCoordToPointer(Buff, Region->Left, Region->Top);
|
2013-06-14 01:10:43 +00:00
|
|
|
SrcDelta = Buff->ScreenBufferSize.X * sizeof(CHAR_INFO);
|
|
|
|
SrcEnd = Buff->Buffer + Buff->ScreenBufferSize.Y * Buff->ScreenBufferSize.X * sizeof(CHAR_INFO);
|
|
|
|
DestDelta = ConioRectWidth(Region) * 2 /* 2 == sizeof(CHAR) + sizeof(BYTE) */;
|
2013-04-11 23:37:09 +00:00
|
|
|
for (i = Region->Top; i <= Region->Bottom; i++)
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
{
|
2015-03-08 13:52:06 +00:00
|
|
|
ConsoleOutputUnicodeToAnsiChar(Buff->Header.Console, (PCHAR)Dest, &Src->Char.UnicodeChar);
|
2013-06-14 01:10:43 +00:00
|
|
|
*(PBYTE)(Dest + 1) = (BYTE)Src->Attributes;
|
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
Src += SrcDelta;
|
|
|
|
if (SrcEnd <= Src)
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
{
|
2013-06-14 01:10:43 +00:00
|
|
|
Src -= Buff->ScreenBufferSize.Y * Buff->ScreenBufferSize.X * sizeof(CHAR_INFO);
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
}
|
2013-04-11 23:37:09 +00:00
|
|
|
Dest += DestDelta;
|
|
|
|
}
|
|
|
|
}
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
static LRESULT CALLBACK
|
|
|
|
TuiConsoleWndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
|
|
|
|
{
|
2013-04-13 21:09:49 +00:00
|
|
|
/*
|
|
|
|
PTUI_CONSOLE_DATA TuiData = NULL;
|
2014-08-11 20:55:50 +00:00
|
|
|
PCONSRV_CONSOLE Console = NULL;
|
2013-04-13 21:09:49 +00:00
|
|
|
|
|
|
|
TuiData = TuiGetGuiData(hWnd);
|
|
|
|
if (TuiData == NULL) return 0;
|
|
|
|
*/
|
|
|
|
|
|
|
|
switch (msg)
|
2013-04-11 23:37:09 +00:00
|
|
|
{
|
2013-04-13 21:09:49 +00:00
|
|
|
case WM_CHAR:
|
|
|
|
case WM_SYSCHAR:
|
|
|
|
case WM_KEYDOWN:
|
|
|
|
case WM_SYSKEYDOWN:
|
|
|
|
case WM_KEYUP:
|
|
|
|
case WM_SYSKEYUP:
|
|
|
|
{
|
2014-05-20 19:56:47 +00:00
|
|
|
#if 0
|
|
|
|
if ((HIWORD(lParam) & KF_ALTDOWN) && wParam == VK_TAB)
|
|
|
|
{
|
|
|
|
// if ((HIWORD(lParam) & (KF_UP | KF_REPEAT)) != KF_REPEAT)
|
|
|
|
TuiSwapConsole(ShiftState & SHIFT_PRESSED ? -1 : 1);
|
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
else if (wParam == VK_MENU /* && !Down */)
|
|
|
|
{
|
|
|
|
TuiSwapConsole(0);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2014-12-14 18:05:50 +00:00
|
|
|
if (ConDrvValidateConsoleUnsafe((PCONSOLE)ActiveConsole->Console, CONSOLE_RUNNING, TRUE))
|
2013-04-13 21:09:49 +00:00
|
|
|
{
|
|
|
|
MSG Message;
|
|
|
|
Message.hwnd = hWnd;
|
|
|
|
Message.message = msg;
|
|
|
|
Message.wParam = wParam;
|
|
|
|
Message.lParam = lParam;
|
|
|
|
|
|
|
|
ConioProcessKey(ActiveConsole->Console, &Message);
|
|
|
|
LeaveCriticalSection(&ActiveConsole->Console->Lock);
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case WM_ACTIVATE:
|
2013-04-11 23:37:09 +00:00
|
|
|
{
|
2014-12-14 18:05:50 +00:00
|
|
|
if (ConDrvValidateConsoleUnsafe((PCONSOLE)ActiveConsole->Console, CONSOLE_RUNNING, TRUE))
|
2013-04-13 21:09:49 +00:00
|
|
|
{
|
|
|
|
if (LOWORD(wParam) != WA_INACTIVE)
|
|
|
|
{
|
|
|
|
SetFocus(hWnd);
|
|
|
|
ConioDrawConsole(ActiveConsole->Console);
|
|
|
|
}
|
|
|
|
LeaveCriticalSection(&ActiveConsole->Console->Lock);
|
|
|
|
}
|
|
|
|
break;
|
2013-04-11 23:37:09 +00:00
|
|
|
}
|
2013-04-13 21:09:49 +00:00
|
|
|
|
|
|
|
default:
|
|
|
|
break;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
}
|
2013-04-13 21:09:49 +00:00
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
return DefWindowProcW(hWnd, msg, wParam, lParam);
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static DWORD NTAPI
|
2014-12-14 21:51:32 +00:00
|
|
|
TuiConsoleThread(PVOID Param)
|
2013-04-11 23:37:09 +00:00
|
|
|
{
|
2014-12-14 21:51:32 +00:00
|
|
|
PTUI_CONSOLE_DATA TuiData = (PTUI_CONSOLE_DATA)Param;
|
2014-08-11 20:55:50 +00:00
|
|
|
PCONSRV_CONSOLE Console = TuiData->Console;
|
2013-04-11 23:37:09 +00:00
|
|
|
HWND NewWindow;
|
|
|
|
MSG msg;
|
|
|
|
|
|
|
|
NewWindow = CreateWindowW(TUI_CONSOLE_WINDOW_CLASS,
|
|
|
|
Console->Title.Buffer,
|
|
|
|
0,
|
|
|
|
-32000, -32000, 0, 0,
|
|
|
|
NULL, NULL,
|
|
|
|
ConSrvDllInstance,
|
|
|
|
(PVOID)Console);
|
|
|
|
if (NULL == NewWindow)
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
{
|
2013-04-11 23:37:09 +00:00
|
|
|
DPRINT1("CONSRV: Unable to create console window\n");
|
|
|
|
return 1;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
}
|
2013-04-11 23:37:09 +00:00
|
|
|
TuiData->hWindow = NewWindow;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
SetForegroundWindow(TuiData->hWindow);
|
|
|
|
NtUserConsoleControl(ConsoleAcquireDisplayOwnership, NULL, 0);
|
|
|
|
|
|
|
|
while (GetMessageW(&msg, NULL, 0, 0))
|
|
|
|
{
|
|
|
|
TranslateMessage(&msg);
|
|
|
|
DispatchMessageW(&msg);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
}
|
|
|
|
|
2021-07-03 23:46:52 +00:00
|
|
|
static BOOLEAN
|
|
|
|
TuiSetConsoleOutputCP(
|
|
|
|
IN HANDLE hNtConddHandle,
|
|
|
|
IN UINT CodePage)
|
|
|
|
{
|
|
|
|
static UINT LastLoadedCodepage = 0;
|
|
|
|
UNICODE_STRING FontFile = RTL_CONSTANT_STRING(L"\\SystemRoot\\vgafonts.cab");
|
|
|
|
CHAR FontName[20];
|
|
|
|
|
|
|
|
NTSTATUS Status;
|
|
|
|
HANDLE FileHandle;
|
|
|
|
OBJECT_ATTRIBUTES ObjectAttributes;
|
|
|
|
IO_STATUS_BLOCK IoStatusBlock;
|
|
|
|
// ULONG ReadCP;
|
|
|
|
PUCHAR FontBitField = NULL;
|
|
|
|
|
|
|
|
/* CAB-specific data */
|
|
|
|
HANDLE FileSectionHandle;
|
|
|
|
PUCHAR FileBuffer = NULL;
|
|
|
|
SIZE_T FileSize = 0;
|
|
|
|
PCFHEADER CabFileHeader;
|
|
|
|
union
|
|
|
|
{
|
|
|
|
PCFFILE CabFile;
|
|
|
|
PVOID Buffer;
|
|
|
|
} Data;
|
|
|
|
PCFFILE FoundFile = NULL;
|
|
|
|
PSTR FileName;
|
|
|
|
USHORT Index;
|
|
|
|
|
|
|
|
if (CodePage == LastLoadedCodepage)
|
|
|
|
return TRUE;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Open the *uncompressed* fonts archive file.
|
|
|
|
*/
|
|
|
|
InitializeObjectAttributes(&ObjectAttributes,
|
|
|
|
&FontFile,
|
|
|
|
OBJ_CASE_INSENSITIVE,
|
|
|
|
NULL,
|
|
|
|
NULL);
|
|
|
|
|
|
|
|
Status = NtOpenFile(&FileHandle,
|
|
|
|
GENERIC_READ | SYNCHRONIZE,
|
|
|
|
&ObjectAttributes,
|
|
|
|
&IoStatusBlock,
|
|
|
|
FILE_SHARE_READ,
|
|
|
|
FILE_SYNCHRONOUS_IO_NONALERT);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("Error: Cannot open '%wZ' (0x%lx)\n", &FontFile, Status);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Load it.
|
|
|
|
*/
|
|
|
|
Status = NtCreateSection(&FileSectionHandle,
|
|
|
|
SECTION_ALL_ACCESS,
|
|
|
|
0, 0,
|
|
|
|
PAGE_READONLY,
|
|
|
|
SEC_COMMIT,
|
|
|
|
FileHandle);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtCreateSection failed (0x%lx)\n", Status);
|
|
|
|
goto Exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
Status = NtMapViewOfSection(FileSectionHandle,
|
|
|
|
NtCurrentProcess(),
|
|
|
|
(PVOID*)&FileBuffer,
|
|
|
|
0, 0, NULL,
|
|
|
|
&FileSize,
|
|
|
|
ViewUnmap,
|
|
|
|
0,
|
|
|
|
PAGE_READONLY);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("NtMapViewOfSection failed (0x%lx)\n", Status);
|
|
|
|
goto Exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Wrap in SEH to protect against ill-formed file */
|
|
|
|
_SEH2_TRY
|
|
|
|
{
|
|
|
|
DPRINT("Cabinet file '%wZ' opened and mapped to 0x%p\n",
|
|
|
|
&FontFile, FileBuffer);
|
|
|
|
|
|
|
|
CabFileHeader = (PCFHEADER)FileBuffer;
|
|
|
|
|
|
|
|
/* Validate the CAB file */
|
|
|
|
if (FileSize <= sizeof(CFHEADER) ||
|
|
|
|
CabFileHeader->Signature != CAB_SIGNATURE ||
|
|
|
|
CabFileHeader->Version != CAB_VERSION ||
|
|
|
|
CabFileHeader->FolderCount == 0 ||
|
|
|
|
CabFileHeader->FileCount == 0 ||
|
|
|
|
CabFileHeader->FileTableOffset < sizeof(CFHEADER))
|
|
|
|
{
|
|
|
|
DPRINT1("Cabinet file '%wZ' has an invalid header\n", &FontFile);
|
|
|
|
Status = STATUS_UNSUCCESSFUL;
|
|
|
|
_SEH2_YIELD(goto Exit);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find the font file within the archive.
|
|
|
|
*/
|
|
|
|
RtlStringCbPrintfA(FontName, sizeof(FontName),
|
|
|
|
"%u-8x8.bin", CodePage);
|
|
|
|
|
|
|
|
/* Read the file table, find the file of interest and the end of the table */
|
|
|
|
Data.CabFile = (PCFFILE)(FileBuffer + CabFileHeader->FileTableOffset);
|
|
|
|
for (Index = 0; Index < CabFileHeader->FileCount; ++Index)
|
|
|
|
{
|
|
|
|
FileName = (PSTR)(Data.CabFile + 1);
|
|
|
|
|
|
|
|
if (!FoundFile)
|
|
|
|
{
|
|
|
|
// Status = RtlCharToInteger(FileName, 0, &ReadCP);
|
|
|
|
// if (NT_SUCCESS(Status) && (ReadCP == CodePage))
|
|
|
|
if (_stricmp(FontName, FileName) == 0)
|
|
|
|
{
|
|
|
|
/* We've got the correct file. Save the offset and
|
|
|
|
* loop through the rest of the file table to find
|
|
|
|
* the position, where the actual data starts. */
|
|
|
|
FoundFile = Data.CabFile;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Move to the next file (go past the filename NULL terminator) */
|
|
|
|
Data.CabFile = (PCFFILE)(strchr(FileName, 0) + 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!FoundFile)
|
|
|
|
{
|
|
|
|
DPRINT("File '%S' not found in cabinet '%wZ'\n",
|
|
|
|
FontName, &FontFile);
|
|
|
|
Status = STATUS_OBJECT_NAME_NOT_FOUND;
|
|
|
|
_SEH2_YIELD(goto Exit);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Extract the font file.
|
|
|
|
*/
|
|
|
|
/* Verify the font file size; we only support a fixed 256-char 8-bit font */
|
|
|
|
if (FoundFile->FileSize != 256 * 8)
|
|
|
|
{
|
|
|
|
DPRINT1("File of size %lu is not of the expected size %lu\n",
|
|
|
|
FoundFile->FileSize, 256 * 8);
|
|
|
|
Status = STATUS_INVALID_BUFFER_SIZE;
|
|
|
|
_SEH2_YIELD(goto Exit);
|
|
|
|
}
|
|
|
|
|
|
|
|
FontBitField = RtlAllocateHeap(RtlGetProcessHeap(), 0, FoundFile->FileSize);
|
|
|
|
if (!FontBitField)
|
|
|
|
{
|
|
|
|
DPRINT1("ExAllocatePoolWithTag(%lu) failed\n", FoundFile->FileSize);
|
|
|
|
Status = STATUS_NO_MEMORY;
|
|
|
|
_SEH2_YIELD(goto Exit);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 8 = Size of a CFFOLDER structure (see cabman). As we don't need
|
|
|
|
* the values of that structure, just increase the offset here. */
|
|
|
|
Data.Buffer = (PVOID)((ULONG_PTR)Data.Buffer + 8); // sizeof(CFFOLDER);
|
|
|
|
Data.Buffer = (PVOID)((ULONG_PTR)Data.Buffer + FoundFile->FileOffset);
|
|
|
|
|
|
|
|
/* Data.Buffer now points to the actual data of the RAW font */
|
|
|
|
RtlCopyMemory(FontBitField, Data.Buffer, FoundFile->FileSize);
|
|
|
|
Status = STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
_SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
|
|
|
|
{
|
|
|
|
Status = _SEH2_GetExceptionCode();
|
|
|
|
DPRINT1("TuiSetConsoleOutputCP - Caught an exception, Status = 0x%08lx\n", Status);
|
|
|
|
}
|
|
|
|
_SEH2_END;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Load the font.
|
|
|
|
*/
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
ASSERT(FoundFile);
|
|
|
|
ASSERT(FontBitField);
|
|
|
|
Status = NtDeviceIoControlFile(hNtConddHandle,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
NULL,
|
|
|
|
&IoStatusBlock,
|
|
|
|
IOCTL_CONSOLE_LOADFONT,
|
|
|
|
FontBitField,
|
|
|
|
FoundFile->FileSize,
|
|
|
|
NULL,
|
|
|
|
0);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (FontBitField)
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, FontBitField);
|
|
|
|
|
|
|
|
Exit:
|
|
|
|
if (FileBuffer)
|
|
|
|
NtUnmapViewOfSection(NtCurrentProcess(), FileBuffer);
|
|
|
|
|
|
|
|
if (FileSectionHandle)
|
|
|
|
NtClose(FileSectionHandle);
|
|
|
|
|
|
|
|
NtClose(FileHandle);
|
|
|
|
|
|
|
|
if (NT_SUCCESS(Status))
|
|
|
|
LastLoadedCodepage = CodePage;
|
|
|
|
|
|
|
|
return NT_SUCCESS(Status);
|
|
|
|
}
|
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
static BOOL
|
2021-07-03 23:46:52 +00:00
|
|
|
TuiInit(IN UINT OemCP)
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
[BLUE] Improve initialization and interfacing with INBV.
CORE-15901
This fixes display reset transition when an external module acquired
INBV ownership and then released it, similarly to what was done in
commit 0ad65796 for VIDEOPRT.
For this a backup screenbuffer is used to store the contents of the
screen just before an INBV screen acquire transition, and these contents
are restored when it is detected that INBV ownership has been released.
Also, the active text font associated with the active console code-page
is restored, as well as the cursor state and shape.
In addition, any user of BLUE.SYS is now required to explicitly issue
a new IOCTL_CONSOLE_RESET_SCREEN to either enable or disable the screen.
This allows avoiding nasty unwanted screen mode switches when a handle
to the \Device\BlueScreen device is opened but no screen mode switch was
actually wanted - This "fixes" this annoyance on ReactOS and Windows,
when these are running witha VGA-compatible video driver and one wants
to look at properties of the \Device\BlueScreen device using
Sysinternals' WinObj.
Following this, we don't need to check anymore for explicit INBV
ownership by issuing calls to InbvCheckDisplayOwnership(), but instead
we check whether the screen has beeen manually enabled using the
aforementioned IOCTL. This partly supersedes commit 8b553a4b, and allows
fixing the second bug, namely that if we start ReactOS without the
/NOGUIBOOT option (and thus, INBV is active during boot), USETUP would
not show up anything because BLUE.SYS wouldn't display anything on screen.
See CORE-15901.
[USETUP][CONSRV] Call IOCTL_CONSOLE_RESET_SCREEN to tell BlueScreen device to enable the screen.
2019-12-15 02:37:52 +00:00
|
|
|
BOOL Success;
|
2010-05-30 20:00:17 +00:00
|
|
|
CONSOLE_SCREEN_BUFFER_INFO ScrInfo;
|
|
|
|
DWORD BytesReturned;
|
|
|
|
WNDCLASSEXW wc;
|
2013-01-04 00:41:10 +00:00
|
|
|
ATOM ConsoleClassAtom;
|
2010-05-30 20:00:17 +00:00
|
|
|
USHORT TextAttribute = FOREGROUND_BLUE | FOREGROUND_GREEN | FOREGROUND_RED;
|
2005-05-08 04:07:56 +00:00
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
/* Exit if we were already initialized */
|
|
|
|
if (ConsInitialized) return TRUE;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize the TUI front-end:
|
|
|
|
* - load the console driver,
|
[BLUE] Improve initialization and interfacing with INBV.
CORE-15901
This fixes display reset transition when an external module acquired
INBV ownership and then released it, similarly to what was done in
commit 0ad65796 for VIDEOPRT.
For this a backup screenbuffer is used to store the contents of the
screen just before an INBV screen acquire transition, and these contents
are restored when it is detected that INBV ownership has been released.
Also, the active text font associated with the active console code-page
is restored, as well as the cursor state and shape.
In addition, any user of BLUE.SYS is now required to explicitly issue
a new IOCTL_CONSOLE_RESET_SCREEN to either enable or disable the screen.
This allows avoiding nasty unwanted screen mode switches when a handle
to the \Device\BlueScreen device is opened but no screen mode switch was
actually wanted - This "fixes" this annoyance on ReactOS and Windows,
when these are running witha VGA-compatible video driver and one wants
to look at properties of the \Device\BlueScreen device using
Sysinternals' WinObj.
Following this, we don't need to check anymore for explicit INBV
ownership by issuing calls to InbvCheckDisplayOwnership(), but instead
we check whether the screen has beeen manually enabled using the
aforementioned IOCTL. This partly supersedes commit 8b553a4b, and allows
fixing the second bug, namely that if we start ReactOS without the
/NOGUIBOOT option (and thus, INBV is active during boot), USETUP would
not show up anything because BLUE.SYS wouldn't display anything on screen.
See CORE-15901.
[USETUP][CONSRV] Call IOCTL_CONSOLE_RESET_SCREEN to tell BlueScreen device to enable the screen.
2019-12-15 02:37:52 +00:00
|
|
|
* - open BlueScreen device and enable it,
|
2013-04-11 23:37:09 +00:00
|
|
|
* - set default screen attributes,
|
|
|
|
* - grab the console size.
|
|
|
|
*/
|
2013-01-13 19:50:52 +00:00
|
|
|
ScmLoadDriver(L"Blue");
|
2009-05-19 20:25:46 +00:00
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
ConsoleDeviceHandle = CreateFileW(L"\\\\.\\BlueScreen",
|
|
|
|
FILE_ALL_ACCESS,
|
|
|
|
0, NULL,
|
|
|
|
OPEN_EXISTING,
|
|
|
|
0, NULL);
|
2015-03-08 13:52:06 +00:00
|
|
|
if (ConsoleDeviceHandle == INVALID_HANDLE_VALUE)
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2010-05-30 20:00:17 +00:00
|
|
|
DPRINT1("Failed to open BlueScreen.\n");
|
|
|
|
return FALSE;
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
|
|
|
|
[BLUE] Improve initialization and interfacing with INBV.
CORE-15901
This fixes display reset transition when an external module acquired
INBV ownership and then released it, similarly to what was done in
commit 0ad65796 for VIDEOPRT.
For this a backup screenbuffer is used to store the contents of the
screen just before an INBV screen acquire transition, and these contents
are restored when it is detected that INBV ownership has been released.
Also, the active text font associated with the active console code-page
is restored, as well as the cursor state and shape.
In addition, any user of BLUE.SYS is now required to explicitly issue
a new IOCTL_CONSOLE_RESET_SCREEN to either enable or disable the screen.
This allows avoiding nasty unwanted screen mode switches when a handle
to the \Device\BlueScreen device is opened but no screen mode switch was
actually wanted - This "fixes" this annoyance on ReactOS and Windows,
when these are running witha VGA-compatible video driver and one wants
to look at properties of the \Device\BlueScreen device using
Sysinternals' WinObj.
Following this, we don't need to check anymore for explicit INBV
ownership by issuing calls to InbvCheckDisplayOwnership(), but instead
we check whether the screen has beeen manually enabled using the
aforementioned IOCTL. This partly supersedes commit 8b553a4b, and allows
fixing the second bug, namely that if we start ReactOS without the
/NOGUIBOOT option (and thus, INBV is active during boot), USETUP would
not show up anything because BLUE.SYS wouldn't display anything on screen.
See CORE-15901.
[USETUP][CONSRV] Call IOCTL_CONSOLE_RESET_SCREEN to tell BlueScreen device to enable the screen.
2019-12-15 02:37:52 +00:00
|
|
|
Success = TRUE;
|
|
|
|
if (!DeviceIoControl(ConsoleDeviceHandle, IOCTL_CONSOLE_RESET_SCREEN,
|
|
|
|
&Success, sizeof(Success), NULL, 0,
|
|
|
|
&BytesReturned, NULL))
|
|
|
|
{
|
|
|
|
DPRINT1("Failed to enable the screen.\n");
|
|
|
|
CloseHandle(ConsoleDeviceHandle);
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
2021-07-03 23:46:52 +00:00
|
|
|
if (!TuiSetConsoleOutputCP(ConsoleDeviceHandle, OemCP))
|
2009-05-18 12:43:12 +00:00
|
|
|
{
|
2009-08-11 20:23:18 +00:00
|
|
|
DPRINT1("Failed to load the font for codepage %d\n", OemCP);
|
2009-05-18 12:43:12 +00:00
|
|
|
/* Let's suppose the font is good enough to continue */
|
|
|
|
}
|
|
|
|
|
2009-08-11 20:23:18 +00:00
|
|
|
if (!DeviceIoControl(ConsoleDeviceHandle, IOCTL_CONSOLE_SET_TEXT_ATTRIBUTE,
|
|
|
|
&TextAttribute, sizeof(TextAttribute), NULL, 0,
|
|
|
|
&BytesReturned, NULL))
|
|
|
|
{
|
[BLUE] Improve initialization and interfacing with INBV.
CORE-15901
This fixes display reset transition when an external module acquired
INBV ownership and then released it, similarly to what was done in
commit 0ad65796 for VIDEOPRT.
For this a backup screenbuffer is used to store the contents of the
screen just before an INBV screen acquire transition, and these contents
are restored when it is detected that INBV ownership has been released.
Also, the active text font associated with the active console code-page
is restored, as well as the cursor state and shape.
In addition, any user of BLUE.SYS is now required to explicitly issue
a new IOCTL_CONSOLE_RESET_SCREEN to either enable or disable the screen.
This allows avoiding nasty unwanted screen mode switches when a handle
to the \Device\BlueScreen device is opened but no screen mode switch was
actually wanted - This "fixes" this annoyance on ReactOS and Windows,
when these are running witha VGA-compatible video driver and one wants
to look at properties of the \Device\BlueScreen device using
Sysinternals' WinObj.
Following this, we don't need to check anymore for explicit INBV
ownership by issuing calls to InbvCheckDisplayOwnership(), but instead
we check whether the screen has beeen manually enabled using the
aforementioned IOCTL. This partly supersedes commit 8b553a4b, and allows
fixing the second bug, namely that if we start ReactOS without the
/NOGUIBOOT option (and thus, INBV is active during boot), USETUP would
not show up anything because BLUE.SYS wouldn't display anything on screen.
See CORE-15901.
[USETUP][CONSRV] Call IOCTL_CONSOLE_RESET_SCREEN to tell BlueScreen device to enable the screen.
2019-12-15 02:37:52 +00:00
|
|
|
DPRINT1("Failed to set text attribute.\n");
|
2009-08-11 20:23:18 +00:00
|
|
|
}
|
|
|
|
|
2010-05-30 20:00:17 +00:00
|
|
|
ActiveConsole = NULL;
|
2013-04-11 23:37:09 +00:00
|
|
|
InitializeListHead(&VirtConsList);
|
|
|
|
InitializeCriticalSection(&ActiveVirtConsLock);
|
|
|
|
|
2013-01-04 00:41:10 +00:00
|
|
|
if (!DeviceIoControl(ConsoleDeviceHandle, IOCTL_CONSOLE_GET_SCREEN_BUFFER_INFO,
|
|
|
|
NULL, 0, &ScrInfo, sizeof(ScrInfo), &BytesReturned, NULL))
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
[BLUE] Improve initialization and interfacing with INBV.
CORE-15901
This fixes display reset transition when an external module acquired
INBV ownership and then released it, similarly to what was done in
commit 0ad65796 for VIDEOPRT.
For this a backup screenbuffer is used to store the contents of the
screen just before an INBV screen acquire transition, and these contents
are restored when it is detected that INBV ownership has been released.
Also, the active text font associated with the active console code-page
is restored, as well as the cursor state and shape.
In addition, any user of BLUE.SYS is now required to explicitly issue
a new IOCTL_CONSOLE_RESET_SCREEN to either enable or disable the screen.
This allows avoiding nasty unwanted screen mode switches when a handle
to the \Device\BlueScreen device is opened but no screen mode switch was
actually wanted - This "fixes" this annoyance on ReactOS and Windows,
when these are running witha VGA-compatible video driver and one wants
to look at properties of the \Device\BlueScreen device using
Sysinternals' WinObj.
Following this, we don't need to check anymore for explicit INBV
ownership by issuing calls to InbvCheckDisplayOwnership(), but instead
we check whether the screen has beeen manually enabled using the
aforementioned IOCTL. This partly supersedes commit 8b553a4b, and allows
fixing the second bug, namely that if we start ReactOS without the
/NOGUIBOOT option (and thus, INBV is active during boot), USETUP would
not show up anything because BLUE.SYS wouldn't display anything on screen.
See CORE-15901.
[USETUP][CONSRV] Call IOCTL_CONSOLE_RESET_SCREEN to tell BlueScreen device to enable the screen.
2019-12-15 02:37:52 +00:00
|
|
|
DPRINT1("Failed to get console info.\n");
|
|
|
|
Success = FALSE;
|
2013-04-11 23:37:09 +00:00
|
|
|
goto Quit;
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
2010-05-30 20:00:17 +00:00
|
|
|
PhysicalConsoleSize = ScrInfo.dwSize;
|
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
/* Register the TUI notification window class */
|
2010-05-30 20:00:17 +00:00
|
|
|
RtlZeroMemory(&wc, sizeof(WNDCLASSEXW));
|
|
|
|
wc.cbSize = sizeof(WNDCLASSEXW);
|
2013-01-04 00:41:10 +00:00
|
|
|
wc.lpszClassName = TUI_CONSOLE_WINDOW_CLASS;
|
2010-05-30 20:00:17 +00:00
|
|
|
wc.lpfnWndProc = TuiConsoleWndProc;
|
2013-04-11 23:37:09 +00:00
|
|
|
wc.cbWndExtra = 0;
|
2013-02-10 12:36:57 +00:00
|
|
|
wc.hInstance = ConSrvDllInstance;
|
2013-01-04 00:41:10 +00:00
|
|
|
|
|
|
|
ConsoleClassAtom = RegisterClassExW(&wc);
|
|
|
|
if (ConsoleClassAtom == 0)
|
2006-10-09 04:00:34 +00:00
|
|
|
{
|
[BLUE] Improve initialization and interfacing with INBV.
CORE-15901
This fixes display reset transition when an external module acquired
INBV ownership and then released it, similarly to what was done in
commit 0ad65796 for VIDEOPRT.
For this a backup screenbuffer is used to store the contents of the
screen just before an INBV screen acquire transition, and these contents
are restored when it is detected that INBV ownership has been released.
Also, the active text font associated with the active console code-page
is restored, as well as the cursor state and shape.
In addition, any user of BLUE.SYS is now required to explicitly issue
a new IOCTL_CONSOLE_RESET_SCREEN to either enable or disable the screen.
This allows avoiding nasty unwanted screen mode switches when a handle
to the \Device\BlueScreen device is opened but no screen mode switch was
actually wanted - This "fixes" this annoyance on ReactOS and Windows,
when these are running witha VGA-compatible video driver and one wants
to look at properties of the \Device\BlueScreen device using
Sysinternals' WinObj.
Following this, we don't need to check anymore for explicit INBV
ownership by issuing calls to InbvCheckDisplayOwnership(), but instead
we check whether the screen has beeen manually enabled using the
aforementioned IOCTL. This partly supersedes commit 8b553a4b, and allows
fixing the second bug, namely that if we start ReactOS without the
/NOGUIBOOT option (and thus, INBV is active during boot), USETUP would
not show up anything because BLUE.SYS wouldn't display anything on screen.
See CORE-15901.
[USETUP][CONSRV] Call IOCTL_CONSOLE_RESET_SCREEN to tell BlueScreen device to enable the screen.
2019-12-15 02:37:52 +00:00
|
|
|
DPRINT1("Failed to register TUI console wndproc.\n");
|
|
|
|
Success = FALSE;
|
2006-10-09 04:00:34 +00:00
|
|
|
}
|
2013-01-04 00:41:10 +00:00
|
|
|
else
|
|
|
|
{
|
[BLUE] Improve initialization and interfacing with INBV.
CORE-15901
This fixes display reset transition when an external module acquired
INBV ownership and then released it, similarly to what was done in
commit 0ad65796 for VIDEOPRT.
For this a backup screenbuffer is used to store the contents of the
screen just before an INBV screen acquire transition, and these contents
are restored when it is detected that INBV ownership has been released.
Also, the active text font associated with the active console code-page
is restored, as well as the cursor state and shape.
In addition, any user of BLUE.SYS is now required to explicitly issue
a new IOCTL_CONSOLE_RESET_SCREEN to either enable or disable the screen.
This allows avoiding nasty unwanted screen mode switches when a handle
to the \Device\BlueScreen device is opened but no screen mode switch was
actually wanted - This "fixes" this annoyance on ReactOS and Windows,
when these are running witha VGA-compatible video driver and one wants
to look at properties of the \Device\BlueScreen device using
Sysinternals' WinObj.
Following this, we don't need to check anymore for explicit INBV
ownership by issuing calls to InbvCheckDisplayOwnership(), but instead
we check whether the screen has beeen manually enabled using the
aforementioned IOCTL. This partly supersedes commit 8b553a4b, and allows
fixing the second bug, namely that if we start ReactOS without the
/NOGUIBOOT option (and thus, INBV is active during boot), USETUP would
not show up anything because BLUE.SYS wouldn't display anything on screen.
See CORE-15901.
[USETUP][CONSRV] Call IOCTL_CONSOLE_RESET_SCREEN to tell BlueScreen device to enable the screen.
2019-12-15 02:37:52 +00:00
|
|
|
Success = TRUE;
|
2013-01-04 00:41:10 +00:00
|
|
|
}
|
2007-10-19 23:21:45 +00:00
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
Quit:
|
[BLUE] Improve initialization and interfacing with INBV.
CORE-15901
This fixes display reset transition when an external module acquired
INBV ownership and then released it, similarly to what was done in
commit 0ad65796 for VIDEOPRT.
For this a backup screenbuffer is used to store the contents of the
screen just before an INBV screen acquire transition, and these contents
are restored when it is detected that INBV ownership has been released.
Also, the active text font associated with the active console code-page
is restored, as well as the cursor state and shape.
In addition, any user of BLUE.SYS is now required to explicitly issue
a new IOCTL_CONSOLE_RESET_SCREEN to either enable or disable the screen.
This allows avoiding nasty unwanted screen mode switches when a handle
to the \Device\BlueScreen device is opened but no screen mode switch was
actually wanted - This "fixes" this annoyance on ReactOS and Windows,
when these are running witha VGA-compatible video driver and one wants
to look at properties of the \Device\BlueScreen device using
Sysinternals' WinObj.
Following this, we don't need to check anymore for explicit INBV
ownership by issuing calls to InbvCheckDisplayOwnership(), but instead
we check whether the screen has beeen manually enabled using the
aforementioned IOCTL. This partly supersedes commit 8b553a4b, and allows
fixing the second bug, namely that if we start ReactOS without the
/NOGUIBOOT option (and thus, INBV is active during boot), USETUP would
not show up anything because BLUE.SYS wouldn't display anything on screen.
See CORE-15901.
[USETUP][CONSRV] Call IOCTL_CONSOLE_RESET_SCREEN to tell BlueScreen device to enable the screen.
2019-12-15 02:37:52 +00:00
|
|
|
if (!Success)
|
2013-04-11 23:37:09 +00:00
|
|
|
{
|
|
|
|
DeleteCriticalSection(&ActiveVirtConsLock);
|
|
|
|
CloseHandle(ConsoleDeviceHandle);
|
|
|
|
}
|
|
|
|
|
[BLUE] Improve initialization and interfacing with INBV.
CORE-15901
This fixes display reset transition when an external module acquired
INBV ownership and then released it, similarly to what was done in
commit 0ad65796 for VIDEOPRT.
For this a backup screenbuffer is used to store the contents of the
screen just before an INBV screen acquire transition, and these contents
are restored when it is detected that INBV ownership has been released.
Also, the active text font associated with the active console code-page
is restored, as well as the cursor state and shape.
In addition, any user of BLUE.SYS is now required to explicitly issue
a new IOCTL_CONSOLE_RESET_SCREEN to either enable or disable the screen.
This allows avoiding nasty unwanted screen mode switches when a handle
to the \Device\BlueScreen device is opened but no screen mode switch was
actually wanted - This "fixes" this annoyance on ReactOS and Windows,
when these are running witha VGA-compatible video driver and one wants
to look at properties of the \Device\BlueScreen device using
Sysinternals' WinObj.
Following this, we don't need to check anymore for explicit INBV
ownership by issuing calls to InbvCheckDisplayOwnership(), but instead
we check whether the screen has beeen manually enabled using the
aforementioned IOCTL. This partly supersedes commit 8b553a4b, and allows
fixing the second bug, namely that if we start ReactOS without the
/NOGUIBOOT option (and thus, INBV is active during boot), USETUP would
not show up anything because BLUE.SYS wouldn't display anything on screen.
See CORE-15901.
[USETUP][CONSRV] Call IOCTL_CONSOLE_RESET_SCREEN to tell BlueScreen device to enable the screen.
2019-12-15 02:37:52 +00:00
|
|
|
ConsInitialized = Success;
|
|
|
|
return Success;
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
|
|
|
|
|
|
|
|
/******************************************************************************
|
|
|
|
* TUI Console Driver *
|
|
|
|
******************************************************************************/
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static VOID NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiDeinitFrontEnd(IN OUT PFRONTEND This /*,
|
2014-08-11 20:55:50 +00:00
|
|
|
IN PCONSRV_CONSOLE Console */);
|
2013-06-23 00:18:47 +00:00
|
|
|
|
2014-08-11 20:55:50 +00:00
|
|
|
static NTSTATUS NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiInitFrontEnd(IN OUT PFRONTEND This,
|
2014-08-11 20:55:50 +00:00
|
|
|
IN PCONSRV_CONSOLE Console)
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2013-06-23 00:18:47 +00:00
|
|
|
PTUI_CONSOLE_DATA TuiData;
|
|
|
|
HANDLE ThreadHandle;
|
|
|
|
|
|
|
|
if (This == NULL || Console == NULL)
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
if (GetType(Console->ActiveBuffer) != TEXTMODE_BUFFER)
|
|
|
|
return STATUS_INVALID_PARAMETER;
|
2013-06-23 00:18:47 +00:00
|
|
|
|
|
|
|
TuiData = ConsoleAllocHeap(HEAP_ZERO_MEMORY, sizeof(TUI_CONSOLE_DATA));
|
|
|
|
if (!TuiData)
|
|
|
|
{
|
|
|
|
DPRINT1("CONSRV: Failed to create TUI_CONSOLE_DATA\n");
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
2014-12-14 21:51:32 +00:00
|
|
|
// Console->FrontEndIFace.Context = (PVOID)TuiData;
|
2015-03-08 13:52:06 +00:00
|
|
|
TuiData->Console = Console;
|
|
|
|
TuiData->ActiveBuffer = Console->ActiveBuffer;
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiData->hWindow = NULL;
|
|
|
|
|
|
|
|
InitializeCriticalSection(&TuiData->Lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HACK: Resize the console since we don't support for now changing
|
|
|
|
* the console size when we display it with the hardware.
|
|
|
|
*/
|
|
|
|
// Console->ConsoleSize = PhysicalConsoleSize;
|
|
|
|
// ConioResizeBuffer(Console, (PTEXTMODE_SCREEN_BUFFER)(Console->ActiveBuffer), PhysicalConsoleSize);
|
|
|
|
|
|
|
|
// /* The console cannot be resized anymore */
|
|
|
|
// Console->FixedSize = TRUE; // MUST be placed AFTER the call to ConioResizeBuffer !!
|
2013-10-10 01:16:02 +00:00
|
|
|
// // TermResizeTerminal(Console);
|
2013-06-23 00:18:47 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Contrary to what we do in the GUI front-end, here we create
|
|
|
|
* an input thread for each console. It will dispatch all the
|
|
|
|
* input messages to the proper console (on the GUI it is done
|
|
|
|
* via the default GUI dispatch thread).
|
|
|
|
*/
|
|
|
|
ThreadHandle = CreateThread(NULL,
|
|
|
|
0,
|
|
|
|
TuiConsoleThread,
|
|
|
|
(PVOID)TuiData,
|
|
|
|
0,
|
|
|
|
NULL);
|
|
|
|
if (NULL == ThreadHandle)
|
|
|
|
{
|
|
|
|
DPRINT1("CONSRV: Unable to create console thread\n");
|
|
|
|
// TuiDeinitFrontEnd(Console);
|
|
|
|
TuiDeinitFrontEnd(This);
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
CloseHandle(ThreadHandle);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Insert the newly created console in the list of virtual consoles
|
|
|
|
* and activate it (give it the focus).
|
|
|
|
*/
|
|
|
|
EnterCriticalSection(&ActiveVirtConsLock);
|
|
|
|
InsertTailList(&VirtConsList, &TuiData->Entry);
|
|
|
|
ActiveConsole = TuiData;
|
|
|
|
LeaveCriticalSection(&ActiveVirtConsLock);
|
|
|
|
|
|
|
|
/* Finally, initialize the frontend structure */
|
2014-12-14 21:51:32 +00:00
|
|
|
This->Context = TuiData;
|
|
|
|
This->Context2 = NULL;
|
2013-06-23 00:18:47 +00:00
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static VOID NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiDeinitFrontEnd(IN OUT PFRONTEND This)
|
|
|
|
{
|
2014-08-11 20:55:50 +00:00
|
|
|
// PCONSRV_CONSOLE Console = This->Console;
|
2015-03-08 13:52:06 +00:00
|
|
|
PTUI_CONSOLE_DATA TuiData = This->Context;
|
2013-04-11 23:37:09 +00:00
|
|
|
|
|
|
|
/* Close the notification window */
|
|
|
|
DestroyWindow(TuiData->hWindow);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Set the active console to the next one
|
|
|
|
* and remove the console from the list.
|
|
|
|
*/
|
|
|
|
EnterCriticalSection(&ActiveVirtConsLock);
|
|
|
|
ActiveConsole = GetNextConsole(TuiData);
|
|
|
|
RemoveEntryList(&TuiData->Entry);
|
|
|
|
|
|
|
|
// /* Switch to next console */
|
|
|
|
// if (ActiveConsole == TuiData)
|
|
|
|
// if (ActiveConsole->Console == Console)
|
|
|
|
// {
|
|
|
|
// ActiveConsole = (TuiData->Entry.Flink != TuiData->Entry ? GetNextConsole(TuiData) : NULL);
|
|
|
|
// }
|
|
|
|
|
|
|
|
// if (GetNextConsole(TuiData) != TuiData)
|
|
|
|
// {
|
|
|
|
// TuiData->Entry.Blink->Flink = TuiData->Entry.Flink;
|
|
|
|
// TuiData->Entry.Flink->Blink = TuiData->Entry.Blink;
|
|
|
|
// }
|
|
|
|
|
|
|
|
LeaveCriticalSection(&ActiveVirtConsLock);
|
|
|
|
|
|
|
|
/* Switch to the next console */
|
|
|
|
if (NULL != ActiveConsole) ConioDrawConsole(ActiveConsole->Console);
|
|
|
|
|
2014-12-14 21:51:32 +00:00
|
|
|
This->Context = NULL;
|
2013-04-11 23:37:09 +00:00
|
|
|
DeleteCriticalSection(&TuiData->Lock);
|
2013-05-12 00:20:15 +00:00
|
|
|
ConsoleFreeHeap(TuiData);
|
2013-04-11 23:37:09 +00:00
|
|
|
}
|
2010-05-30 20:00:17 +00:00
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static VOID NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiDrawRegion(IN OUT PFRONTEND This,
|
|
|
|
SMALL_RECT* Region)
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2015-03-08 13:52:06 +00:00
|
|
|
PTUI_CONSOLE_DATA TuiData = This->Context;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff = TuiData->Console->ActiveBuffer;
|
2010-05-30 20:00:17 +00:00
|
|
|
PCONSOLE_DRAW ConsoleDraw;
|
2015-03-08 13:52:06 +00:00
|
|
|
DWORD BytesReturned;
|
2010-05-30 20:00:17 +00:00
|
|
|
UINT ConsoleDrawSize;
|
2004-01-11 17:31:16 +00:00
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
if (TuiData != ActiveConsole) return;
|
|
|
|
if (GetType(Buff) != TEXTMODE_BUFFER) return;
|
2004-01-11 17:31:16 +00:00
|
|
|
|
2010-05-30 20:00:17 +00:00
|
|
|
ConsoleDrawSize = sizeof(CONSOLE_DRAW) +
|
|
|
|
(ConioRectWidth(Region) * ConioRectHeight(Region)) * 2;
|
2013-05-12 00:20:15 +00:00
|
|
|
ConsoleDraw = ConsoleAllocHeap(0, ConsoleDrawSize);
|
2010-05-30 20:00:17 +00:00
|
|
|
if (NULL == ConsoleDraw)
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2013-05-12 00:20:15 +00:00
|
|
|
DPRINT1("ConsoleAllocHeap failed\n");
|
2010-05-30 20:00:17 +00:00
|
|
|
return;
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
2010-05-30 20:00:17 +00:00
|
|
|
ConsoleDraw->X = Region->Left;
|
|
|
|
ConsoleDraw->Y = Region->Top;
|
|
|
|
ConsoleDraw->SizeX = ConioRectWidth(Region);
|
|
|
|
ConsoleDraw->SizeY = ConioRectHeight(Region);
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
ConsoleDraw->CursorX = Buff->CursorPosition.X;
|
|
|
|
ConsoleDraw->CursorY = Buff->CursorPosition.Y;
|
2005-05-08 04:07:56 +00:00
|
|
|
|
2013-06-14 01:10:43 +00:00
|
|
|
TuiCopyRect((PCHAR)(ConsoleDraw + 1), (PTEXTMODE_SCREEN_BUFFER)Buff, Region);
|
2005-05-08 04:07:56 +00:00
|
|
|
|
2013-01-04 00:41:10 +00:00
|
|
|
if (!DeviceIoControl(ConsoleDeviceHandle, IOCTL_CONSOLE_DRAW,
|
|
|
|
NULL, 0, ConsoleDraw, ConsoleDrawSize, &BytesReturned, NULL))
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2010-05-30 20:00:17 +00:00
|
|
|
DPRINT1("Failed to draw console\n");
|
2013-05-12 00:20:15 +00:00
|
|
|
ConsoleFreeHeap(ConsoleDraw);
|
2010-05-30 20:00:17 +00:00
|
|
|
return;
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
|
|
|
|
2013-05-12 00:20:15 +00:00
|
|
|
ConsoleFreeHeap(ConsoleDraw);
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static VOID NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiWriteStream(IN OUT PFRONTEND This,
|
|
|
|
SMALL_RECT* Region,
|
|
|
|
SHORT CursorStartX,
|
|
|
|
SHORT CursorStartY,
|
|
|
|
UINT ScrolledLines,
|
|
|
|
PWCHAR Buffer,
|
|
|
|
UINT Length)
|
2013-05-29 00:29:07 +00:00
|
|
|
{
|
2015-03-08 13:52:06 +00:00
|
|
|
PTUI_CONSOLE_DATA TuiData = This->Context;
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff = TuiData->Console->ActiveBuffer;
|
2013-06-14 01:10:43 +00:00
|
|
|
PCHAR NewBuffer;
|
|
|
|
ULONG NewLength;
|
|
|
|
DWORD BytesWritten;
|
2013-05-29 00:29:07 +00:00
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
if (TuiData != ActiveConsole) return;
|
|
|
|
if (GetType(Buff) != TEXTMODE_BUFFER) return;
|
2013-05-29 00:29:07 +00:00
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
NewLength = WideCharToMultiByte(TuiData->Console->OutputCodePage, 0,
|
2013-06-14 01:10:43 +00:00
|
|
|
Buffer, Length,
|
|
|
|
NULL, 0, NULL, NULL);
|
|
|
|
NewBuffer = RtlAllocateHeap(RtlGetProcessHeap(), 0, NewLength * sizeof(CHAR));
|
|
|
|
if (!NewBuffer) return;
|
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
WideCharToMultiByte(TuiData->Console->OutputCodePage, 0,
|
2013-06-14 01:10:43 +00:00
|
|
|
Buffer, Length,
|
|
|
|
NewBuffer, NewLength, NULL, NULL);
|
|
|
|
|
|
|
|
if (!WriteFile(ConsoleDeviceHandle, NewBuffer, NewLength * sizeof(CHAR), &BytesWritten, NULL))
|
2013-05-29 00:29:07 +00:00
|
|
|
{
|
|
|
|
DPRINT1("Error writing to BlueScreen\n");
|
|
|
|
}
|
2013-06-14 01:10:43 +00:00
|
|
|
|
|
|
|
RtlFreeHeap(RtlGetProcessHeap(), 0, NewBuffer);
|
2013-05-29 00:29:07 +00:00
|
|
|
}
|
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
static VOID NTAPI
|
|
|
|
TuiRingBell(IN OUT PFRONTEND This)
|
|
|
|
{
|
|
|
|
Beep(800, 200);
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static BOOL NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiSetCursorInfo(IN OUT PFRONTEND This,
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff)
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2015-03-08 13:52:06 +00:00
|
|
|
PTUI_CONSOLE_DATA TuiData = This->Context;
|
2010-06-08 06:38:14 +00:00
|
|
|
CONSOLE_CURSOR_INFO Info;
|
2010-05-30 20:00:17 +00:00
|
|
|
DWORD BytesReturned;
|
2004-01-11 17:31:16 +00:00
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
if (TuiData != ActiveConsole) return TRUE;
|
|
|
|
if (TuiData->Console->ActiveBuffer != Buff) return TRUE;
|
|
|
|
if (GetType(Buff) != TEXTMODE_BUFFER) return FALSE;
|
2004-01-11 17:31:16 +00:00
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
Info.dwSize = ConioEffectiveCursorSize(TuiData->Console, 100);
|
2010-06-08 06:38:14 +00:00
|
|
|
Info.bVisible = Buff->CursorInfo.bVisible;
|
|
|
|
|
2013-01-04 00:41:10 +00:00
|
|
|
if (!DeviceIoControl(ConsoleDeviceHandle, IOCTL_CONSOLE_SET_CURSOR_INFO,
|
|
|
|
&Info, sizeof(Info), NULL, 0, &BytesReturned, NULL))
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2010-05-30 20:00:17 +00:00
|
|
|
DPRINT1( "Failed to set cursor info\n" );
|
|
|
|
return FALSE;
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
|
|
|
|
2010-05-30 20:00:17 +00:00
|
|
|
return TRUE;
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static BOOL NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiSetScreenInfo(IN OUT PFRONTEND This,
|
|
|
|
PCONSOLE_SCREEN_BUFFER Buff,
|
|
|
|
SHORT OldCursorX,
|
|
|
|
SHORT OldCursorY)
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2015-03-08 13:52:06 +00:00
|
|
|
PTUI_CONSOLE_DATA TuiData = This->Context;
|
2010-05-30 20:00:17 +00:00
|
|
|
CONSOLE_SCREEN_BUFFER_INFO Info;
|
|
|
|
DWORD BytesReturned;
|
2004-01-11 17:31:16 +00:00
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
if (TuiData != ActiveConsole) return TRUE;
|
|
|
|
if (TuiData->Console->ActiveBuffer != Buff) return TRUE;
|
2013-05-29 00:29:07 +00:00
|
|
|
if (GetType(Buff) != TEXTMODE_BUFFER) return FALSE;
|
2004-01-11 17:31:16 +00:00
|
|
|
|
[CONSOLE.DLL-KERNEL32-CONSRV]
Fix the console properties dialog, when launching and transmitting console properties. Before, the properties dialog was directly launched by the console server (consrv), running with CSRSS (System) privileges, what constituted a security hole. Now, I create a remote thread in the running process owning the console for launching the properties dialog (thus it has only user privileges, and not System ones anymore). For that purpose, I basically took the technique described in the following paper (Cesar Cerrudo, "Story of a dumb patch", http://www.argeniss.com/research/MSBugPaper.pdf or http://www.scn.rain.com/~neighorn/PDF/MSBugPaper.pdf), where basically the console server shares the console properties via a shared memory section with the console properties dialog dll. The address of the thread which launches the dialog in the context of the console app is given to the console server the same way as we do for the control handler (called e.g. when you press Ctrl-C, etc...)
Of course this is quite hackish, because you have the GUI interface split between the console server and the console properties dialog dll. Something far more elegant would be to put all the GUI thingie into a dedicated dll or exe, running with the same privileges as the console program itself (a kind of console -- or terminal -- emulator).
[CONSOLE.DLL]
Fix retriving / setting colors.c and other things.
[CONSRV.DLL]
- Fix retrieving / setting console properties from the registry (via the HKCU\Console\* keys), via the shell shortcuts (not totally done at the moment, because somebody has to implement properly that thing : http://msdn.microsoft.com/en-us/library/windows/desktop/bb773359(v=vs.85).aspx (NT_CONSOLE_PROPS structure stored as a shortcut data block) (at application launching time), and via the console properties dialog.
- Few DPRINTs removed.
svn path=/branches/ros-csrss/; revision=58415
2013-03-03 15:35:12 +00:00
|
|
|
Info.dwCursorPosition = Buff->CursorPosition;
|
2013-05-29 00:29:07 +00:00
|
|
|
Info.wAttributes = ((PTEXTMODE_SCREEN_BUFFER)Buff)->ScreenDefaultAttrib;
|
2004-01-11 17:31:16 +00:00
|
|
|
|
2013-01-04 00:41:10 +00:00
|
|
|
if (!DeviceIoControl(ConsoleDeviceHandle, IOCTL_CONSOLE_SET_SCREEN_BUFFER_INFO,
|
|
|
|
&Info, sizeof(CONSOLE_SCREEN_BUFFER_INFO), NULL, 0,
|
|
|
|
&BytesReturned, NULL))
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2010-05-30 20:00:17 +00:00
|
|
|
DPRINT1( "Failed to set cursor position\n" );
|
|
|
|
return FALSE;
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
|
|
|
|
2010-05-30 20:00:17 +00:00
|
|
|
return TRUE;
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static VOID NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiResizeTerminal(IN OUT PFRONTEND This)
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2013-04-11 23:37:09 +00:00
|
|
|
}
|
2004-01-11 17:31:16 +00:00
|
|
|
|
2015-03-08 13:52:06 +00:00
|
|
|
static VOID NTAPI
|
|
|
|
TuiSetActiveScreenBuffer(IN OUT PFRONTEND This)
|
|
|
|
{
|
|
|
|
// PGUI_CONSOLE_DATA GuiData = This->Context;
|
|
|
|
// PCONSOLE_SCREEN_BUFFER ActiveBuffer;
|
|
|
|
// HPALETTE hPalette;
|
|
|
|
|
|
|
|
// EnterCriticalSection(&GuiData->Lock);
|
|
|
|
// GuiData->WindowSizeLock = TRUE;
|
|
|
|
|
|
|
|
// InterlockedExchangePointer(&GuiData->ActiveBuffer,
|
|
|
|
// ConDrvGetActiveScreenBuffer(GuiData->Console));
|
|
|
|
|
|
|
|
// GuiData->WindowSizeLock = FALSE;
|
|
|
|
// LeaveCriticalSection(&GuiData->Lock);
|
|
|
|
|
|
|
|
// ActiveBuffer = GuiData->ActiveBuffer;
|
|
|
|
|
|
|
|
// /* Change the current palette */
|
|
|
|
// if (ActiveBuffer->PaletteHandle == NULL)
|
|
|
|
// {
|
|
|
|
// hPalette = GuiData->hSysPalette;
|
|
|
|
// }
|
|
|
|
// else
|
|
|
|
// {
|
|
|
|
// hPalette = ActiveBuffer->PaletteHandle;
|
|
|
|
// }
|
|
|
|
|
|
|
|
// DPRINT("GuiSetActiveScreenBuffer using palette 0x%p\n", hPalette);
|
|
|
|
|
|
|
|
// /* Set the new palette for the framebuffer */
|
|
|
|
// SelectPalette(GuiData->hMemDC, hPalette, FALSE);
|
|
|
|
|
|
|
|
// /* Specify the use of the system palette for the framebuffer */
|
|
|
|
// SetSystemPaletteUse(GuiData->hMemDC, ActiveBuffer->PaletteUsage);
|
|
|
|
|
|
|
|
// /* Realize the (logical) palette */
|
|
|
|
// RealizePalette(GuiData->hMemDC);
|
|
|
|
|
|
|
|
// GuiResizeTerminal(This);
|
|
|
|
// // ConioDrawConsole(Console);
|
|
|
|
}
|
|
|
|
|
|
|
|
static VOID NTAPI
|
|
|
|
TuiReleaseScreenBuffer(IN OUT PFRONTEND This,
|
|
|
|
IN PCONSOLE_SCREEN_BUFFER ScreenBuffer)
|
|
|
|
{
|
|
|
|
// PGUI_CONSOLE_DATA GuiData = This->Context;
|
|
|
|
|
|
|
|
// /*
|
|
|
|
// * If we were notified to release a screen buffer that is not actually
|
|
|
|
// * ours, then just ignore the notification...
|
|
|
|
// */
|
|
|
|
// if (ScreenBuffer != GuiData->ActiveBuffer) return;
|
|
|
|
|
|
|
|
// /*
|
|
|
|
// * ... else, we must release our active buffer. Two cases are present:
|
|
|
|
// * - If ScreenBuffer (== GuiData->ActiveBuffer) IS NOT the console
|
|
|
|
// * active screen buffer, then we can safely switch to it.
|
|
|
|
// * - If ScreenBuffer IS the console active screen buffer, we must release
|
|
|
|
// * it ONLY.
|
|
|
|
// */
|
|
|
|
|
|
|
|
// /* Release the old active palette and set the default one */
|
|
|
|
// if (GetCurrentObject(GuiData->hMemDC, OBJ_PAL) == ScreenBuffer->PaletteHandle)
|
|
|
|
// {
|
|
|
|
// /* Set the new palette */
|
|
|
|
// SelectPalette(GuiData->hMemDC, GuiData->hSysPalette, FALSE);
|
|
|
|
// }
|
|
|
|
|
|
|
|
// /* Set the adequate active screen buffer */
|
|
|
|
// if (ScreenBuffer != GuiData->Console->ActiveBuffer)
|
|
|
|
// {
|
|
|
|
// GuiSetActiveScreenBuffer(This);
|
|
|
|
// }
|
|
|
|
// else
|
|
|
|
// {
|
|
|
|
// EnterCriticalSection(&GuiData->Lock);
|
|
|
|
// GuiData->WindowSizeLock = TRUE;
|
|
|
|
|
|
|
|
// InterlockedExchangePointer(&GuiData->ActiveBuffer, NULL);
|
|
|
|
|
|
|
|
// GuiData->WindowSizeLock = FALSE;
|
|
|
|
// LeaveCriticalSection(&GuiData->Lock);
|
|
|
|
// }
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static VOID NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiRefreshInternalInfo(IN OUT PFRONTEND This)
|
2013-04-11 23:37:09 +00:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static VOID NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiChangeTitle(IN OUT PFRONTEND This)
|
2013-04-11 23:37:09 +00:00
|
|
|
{
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static BOOL NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiChangeIcon(IN OUT PFRONTEND This,
|
2014-03-08 15:31:05 +00:00
|
|
|
HICON IconHandle)
|
2010-05-12 03:34:02 +00:00
|
|
|
{
|
2013-01-20 22:26:06 +00:00
|
|
|
return TRUE;
|
2010-05-12 03:34:02 +00:00
|
|
|
}
|
|
|
|
|
2019-04-28 00:40:20 +00:00
|
|
|
static HDESK NTAPI
|
|
|
|
TuiGetThreadConsoleDesktop(IN OUT PFRONTEND This)
|
|
|
|
{
|
|
|
|
// PTUI_CONSOLE_DATA TuiData = This->Context;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static HWND NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiGetConsoleWindowHandle(IN OUT PFRONTEND This)
|
2013-03-08 23:37:11 +00:00
|
|
|
{
|
2014-12-14 21:51:32 +00:00
|
|
|
PTUI_CONSOLE_DATA TuiData = This->Context;
|
2013-04-11 23:37:09 +00:00
|
|
|
return TuiData->hWindow;
|
2013-03-08 23:37:11 +00:00
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static VOID NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiGetLargestConsoleWindowSize(IN OUT PFRONTEND This,
|
|
|
|
PCOORD pSize)
|
2010-05-12 03:34:02 +00:00
|
|
|
{
|
2013-04-11 23:37:09 +00:00
|
|
|
if (!pSize) return;
|
|
|
|
*pSize = PhysicalConsoleSize;
|
2010-05-12 03:34:02 +00:00
|
|
|
}
|
|
|
|
|
2014-04-22 03:44:13 +00:00
|
|
|
static BOOL NTAPI
|
|
|
|
TuiGetSelectionInfo(IN OUT PFRONTEND This,
|
|
|
|
PCONSOLE_SELECTION_INFO pSelectionInfo)
|
|
|
|
{
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static BOOL NTAPI
|
2013-10-12 15:37:50 +00:00
|
|
|
TuiSetPalette(IN OUT PFRONTEND This,
|
|
|
|
HPALETTE PaletteHandle,
|
|
|
|
UINT PaletteUsage)
|
|
|
|
{
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2021-07-03 22:41:33 +00:00
|
|
|
static BOOL NTAPI
|
|
|
|
TuiSetCodePage(IN OUT PFRONTEND This,
|
|
|
|
UINT CodePage)
|
|
|
|
{
|
2021-07-03 22:51:49 +00:00
|
|
|
// PTUI_CONSOLE_DATA TuiData = This->Context;
|
|
|
|
|
|
|
|
// TODO: Verify that the console is the visible one.
|
|
|
|
// Only then can we change the output code page font.
|
|
|
|
|
|
|
|
if (!TuiSetConsoleOutputCP(ConsoleDeviceHandle, CodePage))
|
|
|
|
{
|
|
|
|
DPRINT1("Failed to load the font for codepage %d\n", CodePage);
|
|
|
|
/* Let's suppose the font is good enough to continue */
|
|
|
|
return FALSE;
|
|
|
|
}
|
2021-07-03 22:41:33 +00:00
|
|
|
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static ULONG NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiGetDisplayMode(IN OUT PFRONTEND This)
|
2013-05-29 00:29:07 +00:00
|
|
|
{
|
|
|
|
return CONSOLE_FULLSCREEN_HARDWARE; // CONSOLE_FULLSCREEN;
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static BOOL NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiSetDisplayMode(IN OUT PFRONTEND This,
|
|
|
|
ULONG NewMode)
|
2013-05-29 00:29:07 +00:00
|
|
|
{
|
|
|
|
// if (NewMode & ~(CONSOLE_FULLSCREEN_MODE | CONSOLE_WINDOWED_MODE))
|
|
|
|
// return FALSE;
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static INT NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiShowMouseCursor(IN OUT PFRONTEND This,
|
|
|
|
BOOL Show)
|
2013-06-01 22:49:50 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static BOOL NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiSetMouseCursor(IN OUT PFRONTEND This,
|
2014-03-08 15:31:05 +00:00
|
|
|
HCURSOR CursorHandle)
|
2013-06-01 22:49:50 +00:00
|
|
|
{
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static HMENU NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiMenuControl(IN OUT PFRONTEND This,
|
2014-03-08 15:31:05 +00:00
|
|
|
UINT CmdIdLow,
|
|
|
|
UINT CmdIdHigh)
|
2013-05-30 00:50:03 +00:00
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2013-10-12 15:44:22 +00:00
|
|
|
static BOOL NTAPI
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiSetMenuClose(IN OUT PFRONTEND This,
|
|
|
|
BOOL Enable)
|
2013-05-30 00:50:03 +00:00
|
|
|
{
|
2013-06-01 22:49:50 +00:00
|
|
|
return TRUE;
|
2013-05-30 00:50:03 +00:00
|
|
|
}
|
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
static FRONTEND_VTBL TuiVtbl =
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2013-06-23 00:18:47 +00:00
|
|
|
TuiInitFrontEnd,
|
|
|
|
TuiDeinitFrontEnd,
|
2010-05-30 20:00:17 +00:00
|
|
|
TuiDrawRegion,
|
2013-05-29 00:29:07 +00:00
|
|
|
TuiWriteStream,
|
2015-03-08 13:52:06 +00:00
|
|
|
TuiRingBell,
|
2010-05-30 20:00:17 +00:00
|
|
|
TuiSetCursorInfo,
|
|
|
|
TuiSetScreenInfo,
|
2013-04-11 23:37:09 +00:00
|
|
|
TuiResizeTerminal,
|
2015-03-08 13:52:06 +00:00
|
|
|
TuiSetActiveScreenBuffer,
|
|
|
|
TuiReleaseScreenBuffer,
|
2013-04-11 23:37:09 +00:00
|
|
|
TuiRefreshInternalInfo,
|
2010-05-30 20:00:17 +00:00
|
|
|
TuiChangeTitle,
|
|
|
|
TuiChangeIcon,
|
2019-04-28 00:40:20 +00:00
|
|
|
TuiGetThreadConsoleDesktop,
|
2013-03-08 23:37:11 +00:00
|
|
|
TuiGetConsoleWindowHandle,
|
2013-05-29 00:29:07 +00:00
|
|
|
TuiGetLargestConsoleWindowSize,
|
2014-04-22 03:44:13 +00:00
|
|
|
TuiGetSelectionInfo,
|
2013-10-12 15:37:50 +00:00
|
|
|
TuiSetPalette,
|
2021-07-03 22:41:33 +00:00
|
|
|
TuiSetCodePage,
|
2013-05-29 00:29:07 +00:00
|
|
|
TuiGetDisplayMode,
|
|
|
|
TuiSetDisplayMode,
|
2013-06-01 22:49:50 +00:00
|
|
|
TuiShowMouseCursor,
|
|
|
|
TuiSetMouseCursor,
|
2013-05-30 00:50:03 +00:00
|
|
|
TuiMenuControl,
|
|
|
|
TuiSetMenuClose,
|
2004-01-11 17:31:16 +00:00
|
|
|
};
|
|
|
|
|
2013-06-23 00:18:47 +00:00
|
|
|
static BOOLEAN
|
|
|
|
IsConsoleMode(VOID)
|
2004-01-11 17:31:16 +00:00
|
|
|
{
|
2013-06-23 00:18:47 +00:00
|
|
|
return (BOOLEAN)NtUserCallNoParam(NOPARAM_ROUTINE_ISCONSOLEMODE);
|
|
|
|
}
|
2006-10-09 04:00:34 +00:00
|
|
|
|
2013-06-23 00:18:47 +00:00
|
|
|
NTSTATUS NTAPI
|
|
|
|
TuiLoadFrontEnd(IN OUT PFRONTEND FrontEnd,
|
2015-03-24 23:58:44 +00:00
|
|
|
IN OUT PCONSOLE_STATE_INFO ConsoleInfo,
|
|
|
|
IN OUT PCONSOLE_INIT_INFO ConsoleInitInfo,
|
|
|
|
IN HANDLE ConsoleLeaderProcessHandle)
|
2013-06-23 00:18:47 +00:00
|
|
|
{
|
|
|
|
if (FrontEnd == NULL || ConsoleInfo == NULL)
|
2013-04-11 23:37:09 +00:00
|
|
|
return STATUS_INVALID_PARAMETER;
|
|
|
|
|
2013-06-23 00:18:47 +00:00
|
|
|
/* We must be in console mode already */
|
|
|
|
if (!IsConsoleMode()) return STATUS_UNSUCCESSFUL;
|
2013-05-29 00:29:07 +00:00
|
|
|
|
2013-04-11 23:37:09 +00:00
|
|
|
/* Initialize the TUI terminal emulator */
|
2013-06-23 00:18:47 +00:00
|
|
|
if (!TuiInit(ConsoleInfo->CodePage)) return STATUS_UNSUCCESSFUL;
|
2013-05-29 00:29:07 +00:00
|
|
|
|
2013-06-23 00:18:47 +00:00
|
|
|
/* Finally, initialize the frontend structure */
|
2014-12-14 21:51:32 +00:00
|
|
|
FrontEnd->Vtbl = &TuiVtbl;
|
|
|
|
FrontEnd->Context = NULL;
|
|
|
|
FrontEnd->Context2 = NULL;
|
2013-04-11 23:37:09 +00:00
|
|
|
|
2013-06-23 00:18:47 +00:00
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
2006-10-09 04:00:34 +00:00
|
|
|
|
2013-06-23 00:18:47 +00:00
|
|
|
NTSTATUS NTAPI
|
|
|
|
TuiUnloadFrontEnd(IN OUT PFRONTEND FrontEnd)
|
|
|
|
{
|
|
|
|
if (FrontEnd == NULL) return STATUS_INVALID_PARAMETER;
|
2014-12-14 21:51:32 +00:00
|
|
|
if (FrontEnd->Context) TuiDeinitFrontEnd(FrontEnd);
|
2004-01-11 17:31:16 +00:00
|
|
|
|
2010-05-30 20:00:17 +00:00
|
|
|
return STATUS_SUCCESS;
|
2004-01-11 17:31:16 +00:00
|
|
|
}
|
|
|
|
|
2013-06-23 00:18:47 +00:00
|
|
|
#endif
|
|
|
|
|
2004-01-11 17:31:16 +00:00
|
|
|
/* EOF */
|