2012-10-22 23:55:51 +00:00
|
|
|
/*
|
|
|
|
* COPYRIGHT: See COPYING in the top level directory
|
|
|
|
* PROJECT: ReactOS Console Server DLL
|
|
|
|
* FILE: win32ss/user/consrv/init.c
|
|
|
|
* PURPOSE: Initialization
|
|
|
|
* PROGRAMMERS: Hermes Belusca-Maito (hermes.belusca@sfr.fr)
|
|
|
|
*/
|
|
|
|
|
2013-03-09 21:08:23 +00:00
|
|
|
/* INCLUDES *******************************************************************/
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
#include "consrv.h"
|
2012-10-23 22:31:36 +00:00
|
|
|
#include "conio.h"
|
2013-03-30 18:44:56 +00:00
|
|
|
#include "console.h"
|
2012-10-22 23:55:51 +00:00
|
|
|
|
|
|
|
#define NDEBUG
|
|
|
|
#include <debug.h>
|
|
|
|
|
2013-03-09 21:08:23 +00:00
|
|
|
/* GLOBALS ********************************************************************/
|
|
|
|
|
2012-11-07 21:10:48 +00:00
|
|
|
HINSTANCE ConSrvDllInstance = NULL;
|
2012-10-22 23:55:51 +00:00
|
|
|
|
|
|
|
/* Memory */
|
2013-03-09 21:08:23 +00:00
|
|
|
HANDLE ConSrvHeap = NULL; // Our own heap.
|
2012-10-22 23:55:51 +00:00
|
|
|
|
2013-03-09 21:08:23 +00:00
|
|
|
// Windows Server 2003 table from http://j00ru.vexillium.org/csrss_list/api_list.html#Windows_2k3
|
|
|
|
// plus a little bit of Windows 7.
|
2013-03-10 19:37:33 +00:00
|
|
|
PCSR_API_ROUTINE ConsoleServerApiDispatchTable[ConsolepMaxApiNumber - CONSRV_FIRST_API_NUMBER] =
|
2012-10-22 23:55:51 +00:00
|
|
|
{
|
2012-11-07 21:10:48 +00:00
|
|
|
SrvOpenConsole,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvGetConsoleInput,
|
|
|
|
SrvWriteConsoleInput,
|
|
|
|
SrvReadConsoleOutput,
|
|
|
|
SrvWriteConsoleOutput,
|
2012-11-07 21:10:48 +00:00
|
|
|
SrvReadConsoleOutputString,
|
|
|
|
SrvWriteConsoleOutputString,
|
|
|
|
SrvFillConsoleOutput,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvGetConsoleMode,
|
|
|
|
// SrvGetConsoleNumberOfFonts,
|
|
|
|
SrvGetConsoleNumberOfInputEvents,
|
|
|
|
SrvGetConsoleScreenBufferInfo,
|
|
|
|
SrvGetConsoleCursorInfo,
|
|
|
|
// SrvGetConsoleMouseInfo,
|
|
|
|
// SrvGetConsoleFontInfo,
|
|
|
|
// SrvGetConsoleFontSize,
|
|
|
|
// SrvGetConsoleCurrentFont,
|
|
|
|
SrvSetConsoleMode,
|
|
|
|
SrvSetConsoleActiveScreenBuffer,
|
|
|
|
SrvFlushConsoleInputBuffer,
|
|
|
|
// SrvGetLargestConsoleWindowSize,
|
|
|
|
SrvSetConsoleScreenBufferSize,
|
2012-11-07 21:10:48 +00:00
|
|
|
SrvSetConsoleCursorPosition,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvSetConsoleCursorInfo,
|
|
|
|
// SrvSetConsoleWindowInfo,
|
|
|
|
SrvScrollConsoleScreenBuffer,
|
2012-11-07 21:10:48 +00:00
|
|
|
SrvSetConsoleTextAttribute,
|
2012-10-22 23:55:51 +00:00
|
|
|
// SrvSetConsoleFont,
|
|
|
|
SrvSetConsoleIcon,
|
|
|
|
SrvReadConsole,
|
|
|
|
SrvWriteConsole,
|
|
|
|
SrvDuplicateHandle,
|
|
|
|
// SrvGetHandleInformation,
|
|
|
|
// SrvSetHandleInformation,
|
|
|
|
SrvCloseHandle,
|
|
|
|
SrvVerifyConsoleIoHandle,
|
|
|
|
SrvAllocConsole,
|
|
|
|
SrvFreeConsole,
|
|
|
|
SrvGetConsoleTitle,
|
|
|
|
SrvSetConsoleTitle,
|
|
|
|
SrvCreateConsoleScreenBuffer,
|
|
|
|
// SrvInvalidateBitMapRect,
|
|
|
|
// SrvVDMConsoleOperation,
|
2012-11-07 21:10:48 +00:00
|
|
|
// SrvSetConsoleCursor,
|
2012-10-22 23:55:51 +00:00
|
|
|
// SrvShowConsoleCursor,
|
|
|
|
// SrvConsoleMenuControl,
|
|
|
|
// SrvSetConsolePalette,
|
|
|
|
// SrvSetConsoleDisplayMode,
|
|
|
|
// SrvRegisterConsoleVDM,
|
|
|
|
SrvGetConsoleHardwareState,
|
|
|
|
SrvSetConsoleHardwareState,
|
|
|
|
// SrvGetConsoleDisplayMode,
|
|
|
|
SrvAddConsoleAlias,
|
|
|
|
SrvGetConsoleAlias,
|
|
|
|
SrvGetConsoleAliasesLength,
|
|
|
|
SrvGetConsoleAliasExesLength,
|
|
|
|
SrvGetConsoleAliases,
|
|
|
|
SrvGetConsoleAliasExes,
|
|
|
|
SrvExpungeConsoleCommandHistory,
|
|
|
|
SrvSetConsoleNumberOfCommands,
|
|
|
|
SrvGetConsoleCommandHistoryLength,
|
|
|
|
SrvGetConsoleCommandHistory,
|
|
|
|
// SrvSetConsoleCommandHistoryMode,
|
|
|
|
SrvGetConsoleCP,
|
|
|
|
SrvSetConsoleCP,
|
|
|
|
// SrvSetConsoleKeyShortcuts,
|
|
|
|
// SrvSetConsoleMenuClose,
|
|
|
|
// SrvConsoleNotifyLastClose,
|
|
|
|
SrvGenerateConsoleCtrlEvent,
|
|
|
|
// SrvGetConsoleKeyboardLayoutName,
|
|
|
|
SrvGetConsoleWindow,
|
|
|
|
// SrvGetConsoleCharType,
|
|
|
|
// SrvSetConsoleLocalEUDC,
|
|
|
|
// SrvSetConsoleCursorMode,
|
|
|
|
// SrvGetConsoleCursorMode,
|
|
|
|
// SrvRegisterConsoleOS2,
|
|
|
|
// SrvSetConsoleOS2OemFormat,
|
|
|
|
// SrvGetConsoleNlsMode,
|
|
|
|
// SrvSetConsoleNlsMode,
|
|
|
|
// SrvRegisterConsoleIME,
|
|
|
|
// SrvUnregisterConsoleIME,
|
|
|
|
// SrvGetConsoleLangId,
|
2013-01-13 17:07:25 +00:00
|
|
|
SrvAttachConsole,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvGetConsoleSelectionInfo,
|
|
|
|
SrvGetConsoleProcessList,
|
|
|
|
SrvGetConsoleHistory,
|
2013-03-09 21:08:23 +00:00
|
|
|
SrvSetConsoleHistory,
|
2012-10-22 23:55:51 +00:00
|
|
|
};
|
|
|
|
|
2013-03-10 19:37:33 +00:00
|
|
|
BOOLEAN ConsoleServerApiServerValidTable[ConsolepMaxApiNumber - CONSRV_FIRST_API_NUMBER] =
|
2012-10-22 23:55:51 +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
|
|
|
FALSE, // SrvOpenConsole,
|
|
|
|
FALSE, // SrvGetConsoleInput,
|
|
|
|
FALSE, // SrvWriteConsoleInput,
|
|
|
|
FALSE, // SrvReadConsoleOutput,
|
|
|
|
FALSE, // SrvWriteConsoleOutput,
|
|
|
|
FALSE, // SrvReadConsoleOutputString,
|
|
|
|
FALSE, // SrvWriteConsoleOutputString,
|
|
|
|
FALSE, // SrvFillConsoleOutput,
|
|
|
|
FALSE, // SrvGetConsoleMode,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvGetConsoleNumberOfFonts,
|
[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
|
|
|
FALSE, // SrvGetConsoleNumberOfInputEvents,
|
|
|
|
FALSE, // SrvGetConsoleScreenBufferInfo,
|
|
|
|
FALSE, // SrvGetConsoleCursorInfo,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvGetConsoleMouseInfo,
|
|
|
|
// FALSE, // SrvGetConsoleFontInfo,
|
|
|
|
// FALSE, // SrvGetConsoleFontSize,
|
|
|
|
// FALSE, // SrvGetConsoleCurrentFont,
|
[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
|
|
|
FALSE, // SrvSetConsoleMode,
|
|
|
|
FALSE, // SrvSetConsoleActiveScreenBuffer,
|
|
|
|
FALSE, // SrvFlushConsoleInputBuffer,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvGetLargestConsoleWindowSize,
|
[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
|
|
|
FALSE, // SrvSetConsoleScreenBufferSize,
|
|
|
|
FALSE, // SrvSetConsoleCursorPosition,
|
|
|
|
FALSE, // SrvSetConsoleCursorInfo,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvSetConsoleWindowInfo,
|
[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
|
|
|
FALSE, // SrvScrollConsoleScreenBuffer,
|
|
|
|
FALSE, // SrvSetConsoleTextAttribute,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvSetConsoleFont,
|
[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
|
|
|
FALSE, // SrvSetConsoleIcon,
|
|
|
|
FALSE, // SrvReadConsole,
|
|
|
|
FALSE, // SrvWriteConsole,
|
|
|
|
FALSE, // SrvDuplicateHandle,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvGetHandleInformation,
|
|
|
|
// FALSE, // SrvSetHandleInformation,
|
[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
|
|
|
FALSE, // SrvCloseHandle,
|
|
|
|
FALSE, // SrvVerifyConsoleIoHandle,
|
|
|
|
FALSE, // SrvAllocConsole,
|
|
|
|
FALSE, // SrvFreeConsole,
|
|
|
|
FALSE, // SrvGetConsoleTitle,
|
|
|
|
FALSE, // SrvSetConsoleTitle,
|
|
|
|
FALSE, // SrvCreateConsoleScreenBuffer,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvInvalidateBitMapRect,
|
|
|
|
// FALSE, // SrvVDMConsoleOperation,
|
2012-11-07 21:10:48 +00:00
|
|
|
// FALSE, // SrvSetConsoleCursor,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvShowConsoleCursor,
|
|
|
|
// FALSE, // SrvConsoleMenuControl,
|
|
|
|
// FALSE, // SrvSetConsolePalette,
|
|
|
|
// FALSE, // SrvSetConsoleDisplayMode,
|
|
|
|
// FALSE, // SrvRegisterConsoleVDM,
|
[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
|
|
|
FALSE, // SrvGetConsoleHardwareState,
|
|
|
|
FALSE, // SrvSetConsoleHardwareState,
|
2012-10-22 23:55:51 +00:00
|
|
|
// TRUE, // SrvGetConsoleDisplayMode,
|
[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
|
|
|
FALSE, // SrvAddConsoleAlias,
|
|
|
|
FALSE, // SrvGetConsoleAlias,
|
|
|
|
FALSE, // SrvGetConsoleAliasesLength,
|
|
|
|
FALSE, // SrvGetConsoleAliasExesLength,
|
|
|
|
FALSE, // SrvGetConsoleAliases,
|
|
|
|
FALSE, // SrvGetConsoleAliasExes,
|
|
|
|
FALSE, // SrvExpungeConsoleCommandHistory,
|
|
|
|
FALSE, // SrvSetConsoleNumberOfCommands,
|
|
|
|
FALSE, // SrvGetConsoleCommandHistoryLength,
|
|
|
|
FALSE, // SrvGetConsoleCommandHistory,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvSetConsoleCommandHistoryMode,
|
[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
|
|
|
FALSE, // SrvGetConsoleCP,
|
|
|
|
FALSE, // SrvSetConsoleCP,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvSetConsoleKeyShortcuts,
|
|
|
|
// FALSE, // SrvSetConsoleMenuClose,
|
|
|
|
// FALSE, // SrvConsoleNotifyLastClose,
|
[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
|
|
|
FALSE, // SrvGenerateConsoleCtrlEvent,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvGetConsoleKeyboardLayoutName,
|
[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
|
|
|
FALSE, // SrvGetConsoleWindow,
|
2012-10-22 23:55:51 +00:00
|
|
|
// FALSE, // SrvGetConsoleCharType,
|
|
|
|
// FALSE, // SrvSetConsoleLocalEUDC,
|
|
|
|
// FALSE, // SrvSetConsoleCursorMode,
|
|
|
|
// FALSE, // SrvGetConsoleCursorMode,
|
|
|
|
// FALSE, // SrvRegisterConsoleOS2,
|
|
|
|
// FALSE, // SrvSetConsoleOS2OemFormat,
|
|
|
|
// FALSE, // SrvGetConsoleNlsMode,
|
|
|
|
// FALSE, // SrvSetConsoleNlsMode,
|
|
|
|
// FALSE, // SrvRegisterConsoleIME,
|
|
|
|
// FALSE, // SrvUnregisterConsoleIME,
|
|
|
|
// FALSE, // SrvGetConsoleLangId,
|
[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
|
|
|
FALSE, // SrvAttachConsole,
|
|
|
|
FALSE, // SrvGetConsoleSelectionInfo,
|
|
|
|
FALSE, // SrvGetConsoleProcessList,
|
|
|
|
FALSE, // SrvGetConsoleHistory,
|
|
|
|
FALSE, // SrvSetConsoleHistory
|
2012-10-22 23:55:51 +00:00
|
|
|
};
|
|
|
|
|
2013-03-10 19:37:33 +00:00
|
|
|
PCHAR ConsoleServerApiNameTable[ConsolepMaxApiNumber - CONSRV_FIRST_API_NUMBER] =
|
2012-10-22 23:55:51 +00:00
|
|
|
{
|
2012-11-07 21:10:48 +00:00
|
|
|
"OpenConsole",
|
2012-10-22 23:55:51 +00:00
|
|
|
"GetConsoleInput",
|
|
|
|
"WriteConsoleInput",
|
|
|
|
"ReadConsoleOutput",
|
|
|
|
"WriteConsoleOutput",
|
2012-11-07 21:10:48 +00:00
|
|
|
"ReadConsoleOutputString",
|
|
|
|
"WriteConsoleOutputString",
|
|
|
|
"FillConsoleOutput",
|
2012-10-22 23:55:51 +00:00
|
|
|
"GetConsoleMode",
|
|
|
|
// "GetConsoleNumberOfFonts",
|
|
|
|
"GetConsoleNumberOfInputEvents",
|
|
|
|
"GetConsoleScreenBufferInfo",
|
|
|
|
"GetConsoleCursorInfo",
|
|
|
|
// "GetConsoleMouseInfo",
|
|
|
|
// "GetConsoleFontInfo",
|
|
|
|
// "GetConsoleFontSize",
|
|
|
|
// "GetConsoleCurrentFont",
|
|
|
|
"SetConsoleMode",
|
|
|
|
"SetConsoleActiveScreenBuffer",
|
|
|
|
"FlushConsoleInputBuffer",
|
|
|
|
// "GetLargestConsoleWindowSize",
|
|
|
|
"SetConsoleScreenBufferSize",
|
2012-11-07 21:10:48 +00:00
|
|
|
"SetConsoleCursorPosition",
|
2012-10-22 23:55:51 +00:00
|
|
|
"SetConsoleCursorInfo",
|
|
|
|
// "SetConsoleWindowInfo",
|
|
|
|
"ScrollConsoleScreenBuffer",
|
2012-11-07 21:10:48 +00:00
|
|
|
"SetConsoleTextAttribute",
|
2012-10-22 23:55:51 +00:00
|
|
|
// "SetConsoleFont",
|
|
|
|
"SetConsoleIcon",
|
|
|
|
"ReadConsole",
|
|
|
|
"WriteConsole",
|
|
|
|
"DuplicateHandle",
|
|
|
|
// "GetHandleInformation",
|
|
|
|
// "SetHandleInformation",
|
|
|
|
"CloseHandle",
|
|
|
|
"VerifyConsoleIoHandle",
|
|
|
|
"AllocConsole",
|
|
|
|
"FreeConsole",
|
|
|
|
"GetConsoleTitle",
|
|
|
|
"SetConsoleTitle",
|
|
|
|
"CreateConsoleScreenBuffer",
|
|
|
|
// "InvalidateBitMapRect",
|
|
|
|
// "VDMConsoleOperation",
|
2012-11-07 21:10:48 +00:00
|
|
|
// "SetConsoleCursor",
|
2012-10-22 23:55:51 +00:00
|
|
|
// "ShowConsoleCursor",
|
|
|
|
// "ConsoleMenuControl",
|
|
|
|
// "SetConsolePalette",
|
|
|
|
// "SetConsoleDisplayMode",
|
|
|
|
// "RegisterConsoleVDM",
|
|
|
|
"GetConsoleHardwareState",
|
|
|
|
"SetConsoleHardwareState",
|
|
|
|
// "GetConsoleDisplayMode",
|
|
|
|
"AddConsoleAlias",
|
|
|
|
"GetConsoleAlias",
|
|
|
|
"GetConsoleAliasesLength",
|
|
|
|
"GetConsoleAliasExesLength",
|
|
|
|
"GetConsoleAliases",
|
|
|
|
"GetConsoleAliasExes",
|
|
|
|
"ExpungeConsoleCommandHistory",
|
|
|
|
"SetConsoleNumberOfCommands",
|
|
|
|
"GetConsoleCommandHistoryLength",
|
|
|
|
"GetConsoleCommandHistory",
|
|
|
|
// "SetConsoleCommandHistoryMode",
|
|
|
|
"GetConsoleCP",
|
|
|
|
"SetConsoleCP",
|
|
|
|
// "SetConsoleKeyShortcuts",
|
|
|
|
// "SetConsoleMenuClose",
|
|
|
|
// "ConsoleNotifyLastClose",
|
|
|
|
"GenerateConsoleCtrlEvent",
|
|
|
|
// "GetConsoleKeyboardLayoutName",
|
|
|
|
"GetConsoleWindow",
|
|
|
|
// "GetConsoleCharType",
|
|
|
|
// "SetConsoleLocalEUDC",
|
|
|
|
// "SetConsoleCursorMode",
|
|
|
|
// "GetConsoleCursorMode",
|
|
|
|
// "RegisterConsoleOS2",
|
|
|
|
// "SetConsoleOS2OemFormat",
|
|
|
|
// "GetConsoleNlsMode",
|
|
|
|
// "SetConsoleNlsMode",
|
|
|
|
// "RegisterConsoleIME",
|
|
|
|
// "UnregisterConsoleIME",
|
|
|
|
// "GetConsoleLangId",
|
2013-01-13 17:07:25 +00:00
|
|
|
"AttachConsole",
|
2012-10-22 23:55:51 +00:00
|
|
|
"GetConsoleSelectionInfo",
|
|
|
|
"GetConsoleProcessList",
|
|
|
|
"GetConsoleHistory",
|
2013-03-09 21:08:23 +00:00
|
|
|
"SetConsoleHistory",
|
2012-11-07 21:10:48 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
/* FUNCTIONS ******************************************************************/
|
|
|
|
|
2013-03-30 21:25:27 +00:00
|
|
|
NTSTATUS
|
|
|
|
ConSrvInheritHandlesTable(IN PCONSOLE_PROCESS_DATA SourceProcessData,
|
|
|
|
IN PCONSOLE_PROCESS_DATA TargetProcessData);
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
ConSrvNewProcess(PCSR_PROCESS SourceProcess,
|
|
|
|
PCSR_PROCESS TargetProcess)
|
|
|
|
{
|
|
|
|
/**************************************************************************
|
|
|
|
* This function is called whenever a new process (GUI or CUI) is created.
|
|
|
|
*
|
|
|
|
* Copy the parent's handles table here if both the parent and the child
|
|
|
|
* processes are CUI. If we must actually create our proper console (and
|
|
|
|
* thus do not inherit from the console handles of the parent's), then we
|
|
|
|
* will clean this table in the next ConSrvConnect call. Why we are doing
|
|
|
|
* this? It's because here, we still don't know whether or not we must create
|
|
|
|
* a new console instead of inherit it from the parent, and, because in
|
|
|
|
* ConSrvConnect we don't have any reference to the parent process anymore.
|
|
|
|
**************************************************************************/
|
|
|
|
|
|
|
|
PCONSOLE_PROCESS_DATA SourceProcessData, TargetProcessData;
|
|
|
|
|
|
|
|
/* An empty target process is invalid */
|
|
|
|
if (!TargetProcess) return STATUS_INVALID_PARAMETER;
|
|
|
|
|
|
|
|
TargetProcessData = ConsoleGetPerProcessData(TargetProcess);
|
|
|
|
|
|
|
|
/**** HACK !!!! ****/ RtlZeroMemory(TargetProcessData, sizeof(*TargetProcessData));
|
|
|
|
|
|
|
|
/* Initialize the new (target) process */
|
|
|
|
TargetProcessData->Process = TargetProcess;
|
|
|
|
TargetProcessData->ConsoleEvent = NULL;
|
|
|
|
TargetProcessData->Console = TargetProcessData->ParentConsole = NULL;
|
|
|
|
TargetProcessData->ConsoleApp = ((TargetProcess->Flags & CsrProcessIsConsoleApp) ? TRUE : FALSE);
|
|
|
|
|
|
|
|
// Testing
|
|
|
|
TargetProcessData->HandleTableSize = 0;
|
|
|
|
TargetProcessData->HandleTable = NULL;
|
|
|
|
|
|
|
|
RtlInitializeCriticalSection(&TargetProcessData->HandleTableLock);
|
|
|
|
|
|
|
|
/* Do nothing if the source process is NULL */
|
|
|
|
if (!SourceProcess) return STATUS_SUCCESS;
|
|
|
|
|
|
|
|
SourceProcessData = ConsoleGetPerProcessData(SourceProcess);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If both of the processes (parent and new child) are console applications,
|
|
|
|
* then try to inherit handles from the parent process.
|
|
|
|
*/
|
|
|
|
if ( SourceProcessData->Console != NULL && /* SourceProcessData->ConsoleApp */
|
|
|
|
TargetProcessData->ConsoleApp )
|
|
|
|
{
|
|
|
|
NTSTATUS Status;
|
|
|
|
|
|
|
|
Status = ConSrvInheritHandlesTable(SourceProcessData, TargetProcessData);
|
|
|
|
if (!NT_SUCCESS(Status)) return Status;
|
|
|
|
|
|
|
|
/* Temporary save the parent's console */
|
|
|
|
TargetProcessData->ParentConsole = SourceProcessData->Console;
|
|
|
|
}
|
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
ConSrvConnect(IN PCSR_PROCESS CsrProcess,
|
|
|
|
IN OUT PVOID ConnectionInfo,
|
|
|
|
IN OUT PULONG ConnectionInfoLength)
|
|
|
|
{
|
|
|
|
/**************************************************************************
|
|
|
|
* This function is called whenever a CUI new process is created.
|
|
|
|
**************************************************************************/
|
|
|
|
|
|
|
|
NTSTATUS Status = STATUS_SUCCESS;
|
|
|
|
PCONSOLE_CONNECTION_INFO ConnectInfo = (PCONSOLE_CONNECTION_INFO)ConnectionInfo;
|
|
|
|
PCONSOLE_PROCESS_DATA ProcessData = ConsoleGetPerProcessData(CsrProcess);
|
|
|
|
|
|
|
|
if ( ConnectionInfo == NULL ||
|
|
|
|
ConnectionInfoLength == NULL ||
|
|
|
|
*ConnectionInfoLength != sizeof(CONSOLE_CONNECTION_INFO) )
|
|
|
|
{
|
|
|
|
DPRINT1("CONSRV: Connection failed\n");
|
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If we don't need a console, then get out of here */
|
|
|
|
if (!ConnectInfo->ConsoleNeeded || !ProcessData->ConsoleApp) // In fact, it is for GUI apps.
|
|
|
|
{
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If we don't have a console, then create a new one... */
|
|
|
|
if (!ConnectInfo->Console ||
|
|
|
|
ConnectInfo->Console != ProcessData->ParentConsole)
|
|
|
|
{
|
|
|
|
DPRINT1("ConSrvConnect - Allocate a new console\n");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We are about to create a new console. However when ConSrvNewProcess
|
|
|
|
* was called, we didn't know that we wanted to create a new console and
|
|
|
|
* therefore, we by default inherited the handles table from our parent
|
|
|
|
* process. It's only now that we notice that in fact we do not need
|
|
|
|
* them, because we've created a new console and thus we must use it.
|
|
|
|
*
|
|
|
|
* Therefore, free the console we can have and our handles table,
|
|
|
|
* and recreate a new one later on.
|
|
|
|
*/
|
|
|
|
ConSrvRemoveConsole(ProcessData);
|
|
|
|
|
|
|
|
/* Initialize a new Console owned by the Console Leader Process */
|
|
|
|
Status = ConSrvAllocateConsole(ProcessData,
|
|
|
|
&ConnectInfo->InputHandle,
|
|
|
|
&ConnectInfo->OutputHandle,
|
|
|
|
&ConnectInfo->ErrorHandle,
|
|
|
|
&ConnectInfo->ConsoleStartInfo);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("Console allocation failed\n");
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
else /* We inherit it from the parent */
|
|
|
|
{
|
|
|
|
DPRINT1("ConSrvConnect - Reuse current (parent's) console\n");
|
|
|
|
|
|
|
|
/* Reuse our current console */
|
|
|
|
Status = ConSrvInheritConsole(ProcessData,
|
|
|
|
ConnectInfo->Console,
|
|
|
|
FALSE,
|
|
|
|
NULL, // &ConnectInfo->InputHandle,
|
|
|
|
NULL, // &ConnectInfo->OutputHandle,
|
|
|
|
NULL); // &ConnectInfo->ErrorHandle);
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
{
|
|
|
|
DPRINT1("Console inheritance failed\n");
|
|
|
|
return Status;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return it to the caller */
|
|
|
|
ConnectInfo->Console = ProcessData->Console;
|
|
|
|
|
|
|
|
/* Input Wait Handle */
|
|
|
|
ConnectInfo->InputWaitHandle = ProcessData->ConsoleEvent;
|
|
|
|
|
|
|
|
/* Set the Property Dialog Handler */
|
|
|
|
ProcessData->PropDispatcher = ConnectInfo->PropDispatcher;
|
|
|
|
|
|
|
|
/* Set the Ctrl Dispatcher */
|
|
|
|
ProcessData->CtrlDispatcher = ConnectInfo->CtrlDispatcher;
|
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
ConSrvDisconnect(PCSR_PROCESS Process)
|
|
|
|
{
|
|
|
|
PCONSOLE_PROCESS_DATA ProcessData = ConsoleGetPerProcessData(Process);
|
|
|
|
|
|
|
|
/**************************************************************************
|
|
|
|
* This function is called whenever a new process (GUI or CUI) is destroyed.
|
|
|
|
**************************************************************************/
|
|
|
|
|
|
|
|
if ( ProcessData->Console != NULL ||
|
|
|
|
ProcessData->HandleTable != NULL )
|
|
|
|
{
|
|
|
|
DPRINT1("ConSrvDisconnect - calling ConSrvRemoveConsole\n");
|
|
|
|
ConSrvRemoveConsole(ProcessData);
|
|
|
|
}
|
|
|
|
|
|
|
|
RtlDeleteCriticalSection(&ProcessData->HandleTableLock);
|
|
|
|
}
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
CSR_SERVER_DLL_INIT(ConServerDllInitialization)
|
|
|
|
{
|
2013-03-09 21:08:23 +00:00
|
|
|
/* Initialize the memory */
|
|
|
|
ConSrvHeap = RtlGetProcessHeap();
|
2012-10-22 23:55:51 +00:00
|
|
|
|
2013-01-24 22:41:33 +00:00
|
|
|
ConSrvInitConsoleSupport();
|
2012-10-22 23:55:51 +00:00
|
|
|
|
|
|
|
/* Setup the DLL Object */
|
|
|
|
LoadedServerDll->ApiBase = CONSRV_FIRST_API_NUMBER;
|
|
|
|
LoadedServerDll->HighestApiSupported = ConsolepMaxApiNumber;
|
|
|
|
LoadedServerDll->DispatchTable = ConsoleServerApiDispatchTable;
|
|
|
|
LoadedServerDll->ValidTable = ConsoleServerApiServerValidTable;
|
|
|
|
LoadedServerDll->NameTable = ConsoleServerApiNameTable;
|
2012-11-13 21:11:30 +00:00
|
|
|
LoadedServerDll->SizeOfProcessData = sizeof(CONSOLE_PROCESS_DATA);
|
2013-01-24 22:41:33 +00:00
|
|
|
LoadedServerDll->ConnectCallback = ConSrvConnect;
|
|
|
|
LoadedServerDll->DisconnectCallback = ConSrvDisconnect;
|
|
|
|
LoadedServerDll->NewProcessCallback = ConSrvNewProcess;
|
|
|
|
// LoadedServerDll->HardErrorCallback = ConSrvHardError;
|
2013-03-09 21:08:23 +00:00
|
|
|
LoadedServerDll->ShutdownProcessCallback = NULL;
|
2012-10-22 23:55:51 +00:00
|
|
|
|
2013-02-10 12:36:57 +00:00
|
|
|
ConSrvDllInstance = LoadedServerDll->ServerHandle;
|
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
/* All done */
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
BOOL
|
2012-10-24 21:37:22 +00:00
|
|
|
WINAPI
|
2012-11-07 21:10:48 +00:00
|
|
|
DllMain(IN HINSTANCE hInstanceDll,
|
2012-10-22 23:55:51 +00:00
|
|
|
IN DWORD dwReason,
|
|
|
|
IN LPVOID lpReserved)
|
|
|
|
{
|
2013-03-09 21:08:23 +00:00
|
|
|
UNREFERENCED_PARAMETER(hInstanceDll);
|
2012-10-22 23:55:51 +00:00
|
|
|
UNREFERENCED_PARAMETER(dwReason);
|
|
|
|
UNREFERENCED_PARAMETER(lpReserved);
|
|
|
|
return TRUE;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* EOF */
|