2012-10-22 23:55:51 +00:00
|
|
|
/*
|
|
|
|
|
* COPYRIGHT: See COPYING in the top level directory
|
|
|
|
|
* PROJECT: ReactOS Console Server DLL
|
2015-10-05 12:21:25 +00:00
|
|
|
* FILE: win32ss/user/winsrv/consrv/init.c
|
2012-10-22 23:55:51 +00:00
|
|
|
* 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"
|
2014-02-04 19:54:42 +00:00
|
|
|
|
2013-04-07 23:18:59 +00:00
|
|
|
#include "api.h"
|
|
|
|
|
#include "procinit.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
|
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,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvGetConsoleNumberOfFonts,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvGetConsoleNumberOfInputEvents,
|
|
|
|
|
SrvGetConsoleScreenBufferInfo,
|
|
|
|
|
SrvGetConsoleCursorInfo,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvGetConsoleMouseInfo,
|
|
|
|
|
SrvGetConsoleFontInfo,
|
|
|
|
|
SrvGetConsoleFontSize,
|
|
|
|
|
SrvGetConsoleCurrentFont,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvSetConsoleMode,
|
|
|
|
|
SrvSetConsoleActiveScreenBuffer,
|
|
|
|
|
SrvFlushConsoleInputBuffer,
|
2013-04-09 15:21:14 +00:00
|
|
|
SrvGetLargestConsoleWindowSize,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvSetConsoleScreenBufferSize,
|
2012-11-07 21:10:48 +00:00
|
|
|
SrvSetConsoleCursorPosition,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvSetConsoleCursorInfo,
|
2013-04-09 15:21:14 +00:00
|
|
|
SrvSetConsoleWindowInfo,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvScrollConsoleScreenBuffer,
|
2012-11-07 21:10:48 +00:00
|
|
|
SrvSetConsoleTextAttribute,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvSetConsoleFont,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvSetConsoleIcon,
|
|
|
|
|
SrvReadConsole,
|
|
|
|
|
SrvWriteConsole,
|
|
|
|
|
SrvDuplicateHandle,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvGetHandleInformation,
|
|
|
|
|
SrvSetHandleInformation,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvCloseHandle,
|
|
|
|
|
SrvVerifyConsoleIoHandle,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvAllocConsole, // Not present in Win7
|
|
|
|
|
SrvFreeConsole, // Not present in Win7
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvGetConsoleTitle,
|
|
|
|
|
SrvSetConsoleTitle,
|
|
|
|
|
SrvCreateConsoleScreenBuffer,
|
2013-05-29 00:29:07 +00:00
|
|
|
SrvInvalidateBitMapRect,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvVDMConsoleOperation,
|
2013-06-01 22:49:50 +00:00
|
|
|
SrvSetConsoleCursor,
|
|
|
|
|
SrvShowConsoleCursor,
|
2013-05-30 00:50:03 +00:00
|
|
|
SrvConsoleMenuControl,
|
2013-08-12 16:12:58 +00:00
|
|
|
SrvSetConsolePalette,
|
2013-04-01 00:23:34 +00:00
|
|
|
SrvSetConsoleDisplayMode,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvRegisterConsoleVDM,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvGetConsoleHardwareState,
|
|
|
|
|
SrvSetConsoleHardwareState,
|
2013-04-01 00:23:34 +00:00
|
|
|
SrvGetConsoleDisplayMode,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvAddConsoleAlias,
|
|
|
|
|
SrvGetConsoleAlias,
|
|
|
|
|
SrvGetConsoleAliasesLength,
|
|
|
|
|
SrvGetConsoleAliasExesLength,
|
|
|
|
|
SrvGetConsoleAliases,
|
|
|
|
|
SrvGetConsoleAliasExes,
|
|
|
|
|
SrvExpungeConsoleCommandHistory,
|
|
|
|
|
SrvSetConsoleNumberOfCommands,
|
|
|
|
|
SrvGetConsoleCommandHistoryLength,
|
|
|
|
|
SrvGetConsoleCommandHistory,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvSetConsoleCommandHistoryMode, // Not present in Vista+
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvGetConsoleCP,
|
|
|
|
|
SrvSetConsoleCP,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvSetConsoleKeyShortcuts,
|
2013-05-30 00:50:03 +00:00
|
|
|
SrvSetConsoleMenuClose,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvConsoleNotifyLastClose,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvGenerateConsoleCtrlEvent,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvGetConsoleKeyboardLayoutName,
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvGetConsoleWindow,
|
2013-08-30 17:53:45 +00:00
|
|
|
SrvGetConsoleCharType,
|
|
|
|
|
SrvSetConsoleLocalEUDC,
|
|
|
|
|
SrvSetConsoleCursorMode,
|
|
|
|
|
SrvGetConsoleCursorMode,
|
|
|
|
|
SrvRegisterConsoleOS2,
|
|
|
|
|
SrvSetConsoleOS2OemFormat,
|
|
|
|
|
SrvGetConsoleNlsMode,
|
|
|
|
|
SrvSetConsoleNlsMode,
|
|
|
|
|
SrvRegisterConsoleIME, // Not present in Win7
|
|
|
|
|
SrvUnregisterConsoleIME, // Not present in Win7
|
|
|
|
|
// SrvQueryConsoleIME, // Added only in Vista and Win2k8, not present in Win7
|
|
|
|
|
SrvGetConsoleLangId,
|
|
|
|
|
SrvAttachConsole, // Not present in Win7
|
2012-10-22 23:55:51 +00:00
|
|
|
SrvGetConsoleSelectionInfo,
|
|
|
|
|
SrvGetConsoleProcessList,
|
2013-08-30 17:53:45 +00:00
|
|
|
|
|
|
|
|
SrvGetConsoleHistory, // Added in Vista+
|
|
|
|
|
SrvSetConsoleHistory, // Added in Vista+
|
|
|
|
|
// SrvSetConsoleCurrentFont, // Added in Vista+
|
|
|
|
|
// SrvSetScreenBufferInfo, // Added in Vista+
|
|
|
|
|
// SrvConsoleClientConnect, // Added in Win7
|
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,
|
2013-08-30 17:53:45 +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,
|
2013-08-30 17:53:45 +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,
|
2013-04-09 15:21:14 +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,
|
2013-04-09 15:21:14 +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,
|
2013-08-30 17:53:45 +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,
|
2013-08-30 17:53:45 +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,
|
2013-05-29 00:29:07 +00:00
|
|
|
FALSE, // SrvInvalidateBitMapRect,
|
2013-08-30 17:53:45 +00:00
|
|
|
FALSE, // SrvVDMConsoleOperation,
|
2013-06-01 22:49:50 +00:00
|
|
|
FALSE, // SrvSetConsoleCursor,
|
|
|
|
|
FALSE, // SrvShowConsoleCursor,
|
2013-05-30 00:50:03 +00:00
|
|
|
FALSE, // SrvConsoleMenuControl,
|
2013-08-12 16:12:58 +00:00
|
|
|
FALSE, // SrvSetConsolePalette,
|
2013-04-01 00:23:34 +00:00
|
|
|
FALSE, // SrvSetConsoleDisplayMode,
|
2013-08-30 17:53:45 +00:00
|
|
|
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,
|
2013-04-01 00:23:34 +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,
|
2013-08-30 17:53:45 +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,
|
2013-08-30 17:53:45 +00:00
|
|
|
FALSE, // SrvSetConsoleKeyShortcuts,
|
2013-05-30 00:50:03 +00:00
|
|
|
FALSE, // SrvSetConsoleMenuClose,
|
2013-08-30 17:53:45 +00:00
|
|
|
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,
|
2013-08-30 17:53:45 +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,
|
2013-08-30 17:53:45 +00:00
|
|
|
FALSE, // SrvGetConsoleCharType,
|
|
|
|
|
FALSE, // SrvSetConsoleLocalEUDC,
|
|
|
|
|
FALSE, // SrvSetConsoleCursorMode,
|
|
|
|
|
FALSE, // SrvGetConsoleCursorMode,
|
|
|
|
|
FALSE, // SrvRegisterConsoleOS2,
|
|
|
|
|
FALSE, // SrvSetConsoleOS2OemFormat,
|
|
|
|
|
FALSE, // SrvGetConsoleNlsMode,
|
|
|
|
|
FALSE, // SrvSetConsoleNlsMode,
|
|
|
|
|
FALSE, // SrvRegisterConsoleIME,
|
|
|
|
|
FALSE, // SrvUnregisterConsoleIME,
|
|
|
|
|
// FALSE, // SrvQueryConsoleIME,
|
|
|
|
|
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,
|
2013-08-30 17:53:45 +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, // SrvGetConsoleHistory,
|
|
|
|
|
FALSE, // SrvSetConsoleHistory
|
2013-08-30 17:53:45 +00:00
|
|
|
// FALSE, // SrvSetConsoleCurrentFont,
|
|
|
|
|
// FALSE, // SrvSetScreenBufferInfo,
|
|
|
|
|
// FALSE, // SrvConsoleClientConnect,
|
2012-10-22 23:55:51 +00:00
|
|
|
};
|
|
|
|
|
|
[CSR]
During my investigations for making working Win2k3 csrsrv.dll (or other CSR servers) into ROS (to compare our behaviour with our own csrsrv.dll and Win2k3 one), I hit a problem: if I test a checked-build version of csrsrv (or other CSR servers), everything was fine when they were loaded, but if I use a release-build version (i.e. without any debug information), I systematically hit a memory access violation which was traced back to the moment when a CSR server's CsrInitialization entry point was called.
So I did the experiment, where I used our (debug-build) csrsrv with a free-build win2k3 CSR server dll (it was winsrv.dll, and I retested with basesrv.dll after). I hit the access violation. But if I took a debug-build version of winsrv.dll, everything was OK.
I then added in our csrsrv' server.c file the following line (around line 212 of the current file version):
DPRINT1("%s ; ServerDll->ValidTable = 0x%p ; ServerDll->NameTable = 0x%p ; ServerDll->SizeOfProcessData = %d ; ServerDll->ConnectCallback = 0x%p\n", DllString, ServerDll->ValidTable, ServerDll->NameTable, ServerDll->SizeOfProcessData, ServerDll->ConnectCallback);
and I saw that, when using a debug-build win2k3 CSR server, everything was fine (in particular the ServerDll->SizeOfProcessData member contained a reasonable value, e.g. a size of 88 bytes), whereas if I used a free-build version, I got an off-by-one problem, with the ServerDll->ValidTable pointer valid but the ServerDll->NameTable member being equal to 88 (i.e. invalid pointer) and the ServerDll->SizeOfProcessData member being equal to a very large value, which looked like a pointer value.
After more investigations, I saw that in debug-build CSR servers the list of API names were stored, whereas it was not the case in free-build versions. Therefore I concluded that the API names table was included *ONLY* in debug builds and not in release builds.
Hence, to be able to test in ROS either debug-builds or release-builds versions of Windows CSR servers in ROS (and vice-versa), I introduced a #define called CSR_DBG, which is defined only if the DBG macro is != 0, and which is not defined otherwise. When the CSR_DBG flag is defined, API names tables are added in CSR servers and otherwise, they are not.
Therefore, we are now able to test debug-build Windows CSR servers in ROS (the default possibility) or free-build versions of these CSR servers (but first, we have to build the other ones without the CSR_DBG flag, to avoid the off-by-one problem described above).
svn path=/trunk/; revision=60560
2013-10-06 13:33:17 +00:00
|
|
|
/*
|
|
|
|
|
* On Windows Server 2003, CSR Servers contain
|
|
|
|
|
* the API Names Table only in Debug Builds.
|
|
|
|
|
*/
|
|
|
|
|
#ifdef CSR_DBG
|
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",
|
2013-08-30 17:53:45 +00:00
|
|
|
"GetConsoleNumberOfFonts",
|
2012-10-22 23:55:51 +00:00
|
|
|
"GetConsoleNumberOfInputEvents",
|
|
|
|
|
"GetConsoleScreenBufferInfo",
|
|
|
|
|
"GetConsoleCursorInfo",
|
2013-08-30 17:53:45 +00:00
|
|
|
"GetConsoleMouseInfo",
|
|
|
|
|
"GetConsoleFontInfo",
|
|
|
|
|
"GetConsoleFontSize",
|
|
|
|
|
"GetConsoleCurrentFont",
|
2012-10-22 23:55:51 +00:00
|
|
|
"SetConsoleMode",
|
|
|
|
|
"SetConsoleActiveScreenBuffer",
|
|
|
|
|
"FlushConsoleInputBuffer",
|
2013-04-09 15:21:14 +00:00
|
|
|
"GetLargestConsoleWindowSize",
|
2012-10-22 23:55:51 +00:00
|
|
|
"SetConsoleScreenBufferSize",
|
2012-11-07 21:10:48 +00:00
|
|
|
"SetConsoleCursorPosition",
|
2012-10-22 23:55:51 +00:00
|
|
|
"SetConsoleCursorInfo",
|
2013-04-09 15:21:14 +00:00
|
|
|
"SetConsoleWindowInfo",
|
2012-10-22 23:55:51 +00:00
|
|
|
"ScrollConsoleScreenBuffer",
|
2012-11-07 21:10:48 +00:00
|
|
|
"SetConsoleTextAttribute",
|
2013-08-30 17:53:45 +00:00
|
|
|
"SetConsoleFont",
|
2012-10-22 23:55:51 +00:00
|
|
|
"SetConsoleIcon",
|
|
|
|
|
"ReadConsole",
|
|
|
|
|
"WriteConsole",
|
|
|
|
|
"DuplicateHandle",
|
2013-08-30 17:53:45 +00:00
|
|
|
"GetHandleInformation",
|
|
|
|
|
"SetHandleInformation",
|
2012-10-22 23:55:51 +00:00
|
|
|
"CloseHandle",
|
|
|
|
|
"VerifyConsoleIoHandle",
|
|
|
|
|
"AllocConsole",
|
|
|
|
|
"FreeConsole",
|
|
|
|
|
"GetConsoleTitle",
|
|
|
|
|
"SetConsoleTitle",
|
|
|
|
|
"CreateConsoleScreenBuffer",
|
2013-05-29 00:29:07 +00:00
|
|
|
"InvalidateBitMapRect",
|
2013-08-30 17:53:45 +00:00
|
|
|
"VDMConsoleOperation",
|
2013-06-01 22:49:50 +00:00
|
|
|
"SetConsoleCursor",
|
|
|
|
|
"ShowConsoleCursor",
|
2013-05-30 00:50:03 +00:00
|
|
|
"ConsoleMenuControl",
|
2013-08-12 16:12:58 +00:00
|
|
|
"SetConsolePalette",
|
2013-04-01 00:23:34 +00:00
|
|
|
"SetConsoleDisplayMode",
|
2013-08-30 17:53:45 +00:00
|
|
|
"RegisterConsoleVDM",
|
2012-10-22 23:55:51 +00:00
|
|
|
"GetConsoleHardwareState",
|
|
|
|
|
"SetConsoleHardwareState",
|
2013-04-01 00:23:34 +00:00
|
|
|
"GetConsoleDisplayMode",
|
2012-10-22 23:55:51 +00:00
|
|
|
"AddConsoleAlias",
|
|
|
|
|
"GetConsoleAlias",
|
|
|
|
|
"GetConsoleAliasesLength",
|
|
|
|
|
"GetConsoleAliasExesLength",
|
|
|
|
|
"GetConsoleAliases",
|
|
|
|
|
"GetConsoleAliasExes",
|
|
|
|
|
"ExpungeConsoleCommandHistory",
|
|
|
|
|
"SetConsoleNumberOfCommands",
|
|
|
|
|
"GetConsoleCommandHistoryLength",
|
|
|
|
|
"GetConsoleCommandHistory",
|
2013-08-30 17:53:45 +00:00
|
|
|
"SetConsoleCommandHistoryMode",
|
2012-10-22 23:55:51 +00:00
|
|
|
"GetConsoleCP",
|
|
|
|
|
"SetConsoleCP",
|
2013-08-30 17:53:45 +00:00
|
|
|
"SetConsoleKeyShortcuts",
|
2013-05-30 00:50:03 +00:00
|
|
|
"SetConsoleMenuClose",
|
2013-08-30 17:53:45 +00:00
|
|
|
"ConsoleNotifyLastClose",
|
2012-10-22 23:55:51 +00:00
|
|
|
"GenerateConsoleCtrlEvent",
|
2013-08-30 17:53:45 +00:00
|
|
|
"GetConsoleKeyboardLayoutName",
|
2012-10-22 23:55:51 +00:00
|
|
|
"GetConsoleWindow",
|
2013-08-30 17:53:45 +00:00
|
|
|
"GetConsoleCharType",
|
|
|
|
|
"SetConsoleLocalEUDC",
|
|
|
|
|
"SetConsoleCursorMode",
|
|
|
|
|
"GetConsoleCursorMode",
|
|
|
|
|
"RegisterConsoleOS2",
|
|
|
|
|
"SetConsoleOS2OemFormat",
|
|
|
|
|
"GetConsoleNlsMode",
|
|
|
|
|
"SetConsoleNlsMode",
|
|
|
|
|
"RegisterConsoleIME",
|
|
|
|
|
"UnregisterConsoleIME",
|
|
|
|
|
// "QueryConsoleIME",
|
|
|
|
|
"GetConsoleLangId",
|
2013-01-13 17:07:25 +00:00
|
|
|
"AttachConsole",
|
2012-10-22 23:55:51 +00:00
|
|
|
"GetConsoleSelectionInfo",
|
|
|
|
|
"GetConsoleProcessList",
|
2013-08-30 17:53:45 +00:00
|
|
|
|
2012-10-22 23:55:51 +00:00
|
|
|
"GetConsoleHistory",
|
2013-03-09 21:08:23 +00:00
|
|
|
"SetConsoleHistory",
|
2013-08-30 17:53:45 +00:00
|
|
|
// "SetConsoleCurrentFont",
|
|
|
|
|
// "SetScreenBufferInfo",
|
|
|
|
|
// "ConsoleClientConnect",
|
2012-11-07 21:10:48 +00:00
|
|
|
};
|
[CSR]
During my investigations for making working Win2k3 csrsrv.dll (or other CSR servers) into ROS (to compare our behaviour with our own csrsrv.dll and Win2k3 one), I hit a problem: if I test a checked-build version of csrsrv (or other CSR servers), everything was fine when they were loaded, but if I use a release-build version (i.e. without any debug information), I systematically hit a memory access violation which was traced back to the moment when a CSR server's CsrInitialization entry point was called.
So I did the experiment, where I used our (debug-build) csrsrv with a free-build win2k3 CSR server dll (it was winsrv.dll, and I retested with basesrv.dll after). I hit the access violation. But if I took a debug-build version of winsrv.dll, everything was OK.
I then added in our csrsrv' server.c file the following line (around line 212 of the current file version):
DPRINT1("%s ; ServerDll->ValidTable = 0x%p ; ServerDll->NameTable = 0x%p ; ServerDll->SizeOfProcessData = %d ; ServerDll->ConnectCallback = 0x%p\n", DllString, ServerDll->ValidTable, ServerDll->NameTable, ServerDll->SizeOfProcessData, ServerDll->ConnectCallback);
and I saw that, when using a debug-build win2k3 CSR server, everything was fine (in particular the ServerDll->SizeOfProcessData member contained a reasonable value, e.g. a size of 88 bytes), whereas if I used a free-build version, I got an off-by-one problem, with the ServerDll->ValidTable pointer valid but the ServerDll->NameTable member being equal to 88 (i.e. invalid pointer) and the ServerDll->SizeOfProcessData member being equal to a very large value, which looked like a pointer value.
After more investigations, I saw that in debug-build CSR servers the list of API names were stored, whereas it was not the case in free-build versions. Therefore I concluded that the API names table was included *ONLY* in debug builds and not in release builds.
Hence, to be able to test in ROS either debug-builds or release-builds versions of Windows CSR servers in ROS (and vice-versa), I introduced a #define called CSR_DBG, which is defined only if the DBG macro is != 0, and which is not defined otherwise. When the CSR_DBG flag is defined, API names tables are added in CSR servers and otherwise, they are not.
Therefore, we are now able to test debug-build Windows CSR servers in ROS (the default possibility) or free-build versions of these CSR servers (but first, we have to build the other ones without the CSR_DBG flag, to avoid the off-by-one problem described above).
svn path=/trunk/; revision=60560
2013-10-06 13:33:17 +00:00
|
|
|
#endif
|
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
|
|
|
|
|
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.
|
|
|
|
|
**************************************************************************/
|
|
|
|
|
|
2013-05-12 00:20:15 +00:00
|
|
|
NTSTATUS Status = STATUS_SUCCESS;
|
2013-07-06 19:47:53 +00:00
|
|
|
PCONSOLE_PROCESS_DATA TargetProcessData;
|
2013-03-30 21:25:27 +00:00
|
|
|
|
|
|
|
|
/* An empty target process is invalid */
|
|
|
|
|
if (!TargetProcess) return STATUS_INVALID_PARAMETER;
|
|
|
|
|
|
|
|
|
|
TargetProcessData = ConsoleGetPerProcessData(TargetProcess);
|
|
|
|
|
|
|
|
|
|
/* Initialize the new (target) process */
|
2013-05-12 00:20:15 +00:00
|
|
|
RtlZeroMemory(TargetProcessData, sizeof(*TargetProcessData));
|
2013-03-30 21:25:27 +00:00
|
|
|
TargetProcessData->Process = TargetProcess;
|
2014-09-07 22:53:49 +00:00
|
|
|
TargetProcessData->ConsoleHandle = NULL;
|
|
|
|
|
TargetProcessData->ConsoleApp = FALSE;
|
2013-03-30 21:25:27 +00:00
|
|
|
|
2013-05-12 00:20:15 +00:00
|
|
|
/*
|
|
|
|
|
* The handles table gets initialized either when inheriting from
|
|
|
|
|
* another console process, or when creating a new console.
|
|
|
|
|
*/
|
2013-03-30 21:25:27 +00:00
|
|
|
TargetProcessData->HandleTableSize = 0;
|
|
|
|
|
TargetProcessData->HandleTable = NULL;
|
|
|
|
|
|
|
|
|
|
RtlInitializeCriticalSection(&TargetProcessData->HandleTableLock);
|
|
|
|
|
|
|
|
|
|
/* Do nothing if the source process is NULL */
|
|
|
|
|
if (!SourceProcess) return STATUS_SUCCESS;
|
|
|
|
|
|
2013-05-12 00:20:15 +00:00
|
|
|
// SourceProcessData = ConsoleGetPerProcessData(SourceProcess);
|
2013-03-30 21:25:27 +00:00
|
|
|
|
|
|
|
|
/*
|
2013-05-12 00:20:15 +00:00
|
|
|
* If the child process is a console application and the parent process is
|
|
|
|
|
* either a console application or just has a valid console (with a valid
|
|
|
|
|
* handles table: this can happen if it is a GUI application having called
|
|
|
|
|
* AllocConsole), then try to inherit handles from the parent process.
|
2013-03-30 21:25:27 +00:00
|
|
|
*/
|
2014-09-07 22:53:49 +00:00
|
|
|
if (TargetProcess->Flags & CsrProcessIsConsoleApp /* && SourceProcessData->ConsoleHandle != NULL */)
|
2013-03-30 21:25:27 +00:00
|
|
|
{
|
2013-05-12 00:20:15 +00:00
|
|
|
PCONSOLE_PROCESS_DATA SourceProcessData = ConsoleGetPerProcessData(SourceProcess);
|
2014-08-31 14:04:03 +00:00
|
|
|
PCONSRV_CONSOLE SourceConsole;
|
2013-03-30 21:25:27 +00:00
|
|
|
|
2013-05-12 00:20:15 +00:00
|
|
|
/* Validate and lock the parent's console */
|
2014-05-04 00:01:48 +00:00
|
|
|
if (ConSrvValidateConsole(&SourceConsole,
|
2013-07-06 19:47:53 +00:00
|
|
|
SourceProcessData->ConsoleHandle,
|
|
|
|
|
CONSOLE_RUNNING, TRUE))
|
2013-05-12 00:20:15 +00:00
|
|
|
{
|
|
|
|
|
/* Inherit the parent's handles table */
|
|
|
|
|
Status = ConSrvInheritHandlesTable(SourceProcessData, TargetProcessData);
|
2014-09-07 22:53:49 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
2013-05-12 00:20:15 +00:00
|
|
|
{
|
2014-09-07 22:53:49 +00:00
|
|
|
DPRINT1("Inheriting handles table failed\n");
|
2013-05-12 00:20:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Unlock the parent's console */
|
2013-07-06 19:47:53 +00:00
|
|
|
LeaveCriticalSection(&SourceConsole->Lock);
|
2013-05-12 00:20:15 +00:00
|
|
|
}
|
2013-03-30 21:25:27 +00:00
|
|
|
}
|
|
|
|
|
|
2013-05-12 00:20:15 +00:00
|
|
|
return Status;
|
2013-03-30 21:25:27 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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;
|
2013-08-19 18:14:43 +00:00
|
|
|
PCONSRV_API_CONNECTINFO ConnectInfo = (PCONSRV_API_CONNECTINFO)ConnectionInfo;
|
2013-03-30 21:25:27 +00:00
|
|
|
PCONSOLE_PROCESS_DATA ProcessData = ConsoleGetPerProcessData(CsrProcess);
|
|
|
|
|
|
|
|
|
|
if ( ConnectionInfo == NULL ||
|
|
|
|
|
ConnectionInfoLength == NULL ||
|
2014-09-07 22:53:49 +00:00
|
|
|
*ConnectionInfoLength != sizeof(*ConnectInfo) )
|
2013-03-30 21:25:27 +00:00
|
|
|
{
|
2014-12-16 20:15:35 +00:00
|
|
|
DPRINT1("CONSRV: Connection failed - ConnectionInfo = 0x%p ; ConnectionInfoLength = 0x%p (%lu), expected %lu\n",
|
2013-08-30 11:36:22 +00:00
|
|
|
ConnectionInfo,
|
|
|
|
|
ConnectionInfoLength,
|
|
|
|
|
ConnectionInfoLength ? *ConnectionInfoLength : (ULONG)-1,
|
2014-09-07 22:53:49 +00:00
|
|
|
sizeof(*ConnectInfo));
|
2014-12-16 20:15:35 +00:00
|
|
|
|
2013-03-30 21:25:27 +00:00
|
|
|
return STATUS_UNSUCCESSFUL;
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-04 17:38:36 +00:00
|
|
|
/* Set Control-Dispatcher handler */
|
|
|
|
|
ProcessData->CtrlRoutine = ConnectInfo->CtrlRoutine;
|
|
|
|
|
|
2013-03-30 21:25:27 +00:00
|
|
|
/* If we don't need a console, then get out of here */
|
2014-09-07 22:53:49 +00:00
|
|
|
DPRINT("ConnectInfo->IsConsoleApp = %s\n", ConnectInfo->IsConsoleApp ? "True" : "False");
|
|
|
|
|
if (!ConnectInfo->IsConsoleApp) return STATUS_SUCCESS;
|
|
|
|
|
|
|
|
|
|
/* If we don't inherit from an existing console, then create a new one... */
|
|
|
|
|
if (ConnectInfo->ConsoleStartInfo.ConsoleHandle == NULL)
|
2013-03-30 21:25:27 +00:00
|
|
|
{
|
2015-03-11 01:21:29 +00:00
|
|
|
CONSOLE_INIT_INFO ConsoleInitInfo;
|
|
|
|
|
|
2013-04-06 13:40:34 +00:00
|
|
|
DPRINT("ConSrvConnect - Allocate a new console\n");
|
2013-03-30 21:25:27 +00:00
|
|
|
|
2015-03-11 01:21:29 +00:00
|
|
|
/* Initialize the console initialization info structure */
|
|
|
|
|
ConsoleInitInfo.ConsoleStartInfo = &ConnectInfo->ConsoleStartInfo;
|
|
|
|
|
ConsoleInitInfo.IsWindowVisible = ConnectInfo->IsWindowVisible;
|
|
|
|
|
ConsoleInitInfo.TitleLength = ConnectInfo->TitleLength;
|
|
|
|
|
ConsoleInitInfo.ConsoleTitle = ConnectInfo->ConsoleTitle;
|
|
|
|
|
ConsoleInitInfo.DesktopLength = 0;
|
|
|
|
|
ConsoleInitInfo.Desktop = NULL;
|
|
|
|
|
ConsoleInitInfo.AppNameLength = ConnectInfo->AppNameLength;
|
|
|
|
|
ConsoleInitInfo.AppName = ConnectInfo->AppName;
|
|
|
|
|
ConsoleInitInfo.CurDirLength = ConnectInfo->CurDirLength;
|
|
|
|
|
ConsoleInitInfo.CurDir = ConnectInfo->CurDir;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Contrary to the case of SrvAllocConsole, the desktop string is
|
|
|
|
|
* allocated in the process' heap, so we need to retrieve it by
|
|
|
|
|
* using NtReadVirtualMemory.
|
|
|
|
|
*/
|
|
|
|
|
if (ConnectInfo->DesktopLength)
|
|
|
|
|
{
|
|
|
|
|
ConsoleInitInfo.DesktopLength = ConnectInfo->DesktopLength;
|
|
|
|
|
|
|
|
|
|
ConsoleInitInfo.Desktop = ConsoleAllocHeap(HEAP_ZERO_MEMORY,
|
|
|
|
|
ConsoleInitInfo.DesktopLength);
|
|
|
|
|
if (ConsoleInitInfo.Desktop == NULL)
|
|
|
|
|
return STATUS_NO_MEMORY;
|
|
|
|
|
|
|
|
|
|
Status = NtReadVirtualMemory(ProcessData->Process->ProcessHandle,
|
|
|
|
|
ConnectInfo->Desktop,
|
|
|
|
|
ConsoleInitInfo.Desktop,
|
|
|
|
|
ConsoleInitInfo.DesktopLength,
|
|
|
|
|
NULL);
|
|
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
|
{
|
|
|
|
|
ConsoleFreeHeap(ConsoleInitInfo.Desktop);
|
|
|
|
|
return Status;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-30 21:25:27 +00:00
|
|
|
/*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
2013-05-12 00:20:15 +00:00
|
|
|
* ConSrvAllocateConsole will free our old handles table
|
|
|
|
|
* and recreate a new valid one.
|
2013-03-30 21:25:27 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* Initialize a new Console owned by the Console Leader Process */
|
|
|
|
|
Status = ConSrvAllocateConsole(ProcessData,
|
2014-09-07 22:53:49 +00:00
|
|
|
&ConnectInfo->ConsoleStartInfo.InputHandle,
|
|
|
|
|
&ConnectInfo->ConsoleStartInfo.OutputHandle,
|
|
|
|
|
&ConnectInfo->ConsoleStartInfo.ErrorHandle,
|
|
|
|
|
&ConsoleInitInfo);
|
2015-03-11 01:21:29 +00:00
|
|
|
|
|
|
|
|
/* Free our local desktop string if any */
|
|
|
|
|
if (ConsoleInitInfo.DesktopLength)
|
|
|
|
|
ConsoleFreeHeap(ConsoleInitInfo.Desktop);
|
|
|
|
|
|
|
|
|
|
/* Check for success */
|
2013-03-30 21:25:27 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
|
{
|
|
|
|
|
DPRINT1("Console allocation failed\n");
|
|
|
|
|
return Status;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else /* We inherit it from the parent */
|
|
|
|
|
{
|
2013-04-06 13:40:34 +00:00
|
|
|
DPRINT("ConSrvConnect - Reuse current (parent's) console\n");
|
2013-03-30 21:25:27 +00:00
|
|
|
|
|
|
|
|
/* Reuse our current console */
|
|
|
|
|
Status = ConSrvInheritConsole(ProcessData,
|
2014-09-07 22:53:49 +00:00
|
|
|
ConnectInfo->ConsoleStartInfo.ConsoleHandle,
|
2013-03-30 21:25:27 +00:00
|
|
|
FALSE,
|
2014-11-22 22:13:08 +00:00
|
|
|
NULL, // &ConnectInfo->ConsoleStartInfo.InputHandle,
|
|
|
|
|
NULL, // &ConnectInfo->ConsoleStartInfo.OutputHandle,
|
|
|
|
|
NULL, // &ConnectInfo->ConsoleStartInfo.ErrorHandle,
|
|
|
|
|
&ConnectInfo->ConsoleStartInfo);
|
2013-03-30 21:25:27 +00:00
|
|
|
if (!NT_SUCCESS(Status))
|
|
|
|
|
{
|
|
|
|
|
DPRINT1("Console inheritance failed\n");
|
|
|
|
|
return Status;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-04 17:38:36 +00:00
|
|
|
/* Set the Property-Dialog handler */
|
2014-09-07 22:53:49 +00:00
|
|
|
ProcessData->PropRoutine = ConnectInfo->PropRoutine;
|
2013-03-30 21:25:27 +00:00
|
|
|
|
|
|
|
|
return STATUS_SUCCESS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
VOID
|
|
|
|
|
NTAPI
|
2014-12-16 20:15:35 +00:00
|
|
|
ConSrvDisconnect(IN PCSR_PROCESS CsrProcess)
|
2013-03-30 21:25:27 +00:00
|
|
|
{
|
2014-12-16 20:15:35 +00:00
|
|
|
PCONSOLE_PROCESS_DATA ProcessData = ConsoleGetPerProcessData(CsrProcess);
|
2013-03-30 21:25:27 +00:00
|
|
|
|
|
|
|
|
/**************************************************************************
|
|
|
|
|
* This function is called whenever a new process (GUI or CUI) is destroyed.
|
|
|
|
|
**************************************************************************/
|
|
|
|
|
|
2013-07-06 19:47:53 +00:00
|
|
|
if ( ProcessData->ConsoleHandle != NULL ||
|
|
|
|
|
ProcessData->HandleTable != NULL )
|
2013-03-30 21:25:27 +00:00
|
|
|
{
|
2013-04-06 13:40:34 +00:00
|
|
|
DPRINT("ConSrvDisconnect - calling ConSrvRemoveConsole\n");
|
2013-03-30 21:25:27 +00:00
|
|
|
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 */
|
2013-05-12 00:20:15 +00:00
|
|
|
ConSrvHeap = RtlGetProcessHeap();
|
|
|
|
|
/*
|
|
|
|
|
// We can use our own heap instead of the CSR heap to investigate heap corruptions :)
|
2013-05-04 21:03:27 +00:00
|
|
|
ConSrvHeap = RtlCreateHeap(HEAP_GROWABLE |
|
|
|
|
|
HEAP_PROTECTION_ENABLED |
|
|
|
|
|
HEAP_FREE_CHECKING_ENABLED |
|
|
|
|
|
HEAP_TAIL_CHECKING_ENABLED |
|
|
|
|
|
HEAP_VALIDATE_ALL_ENABLED,
|
|
|
|
|
NULL, 0, 0, NULL, NULL);
|
2013-05-04 19:28:36 +00:00
|
|
|
if (!ConSrvHeap) return STATUS_NO_MEMORY;
|
2013-05-12 00:20:15 +00:00
|
|
|
*/
|
2012-10-22 23:55:51 +00:00
|
|
|
|
2014-05-04 00:01:48 +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;
|
[CSR]
During my investigations for making working Win2k3 csrsrv.dll (or other CSR servers) into ROS (to compare our behaviour with our own csrsrv.dll and Win2k3 one), I hit a problem: if I test a checked-build version of csrsrv (or other CSR servers), everything was fine when they were loaded, but if I use a release-build version (i.e. without any debug information), I systematically hit a memory access violation which was traced back to the moment when a CSR server's CsrInitialization entry point was called.
So I did the experiment, where I used our (debug-build) csrsrv with a free-build win2k3 CSR server dll (it was winsrv.dll, and I retested with basesrv.dll after). I hit the access violation. But if I took a debug-build version of winsrv.dll, everything was OK.
I then added in our csrsrv' server.c file the following line (around line 212 of the current file version):
DPRINT1("%s ; ServerDll->ValidTable = 0x%p ; ServerDll->NameTable = 0x%p ; ServerDll->SizeOfProcessData = %d ; ServerDll->ConnectCallback = 0x%p\n", DllString, ServerDll->ValidTable, ServerDll->NameTable, ServerDll->SizeOfProcessData, ServerDll->ConnectCallback);
and I saw that, when using a debug-build win2k3 CSR server, everything was fine (in particular the ServerDll->SizeOfProcessData member contained a reasonable value, e.g. a size of 88 bytes), whereas if I used a free-build version, I got an off-by-one problem, with the ServerDll->ValidTable pointer valid but the ServerDll->NameTable member being equal to 88 (i.e. invalid pointer) and the ServerDll->SizeOfProcessData member being equal to a very large value, which looked like a pointer value.
After more investigations, I saw that in debug-build CSR servers the list of API names were stored, whereas it was not the case in free-build versions. Therefore I concluded that the API names table was included *ONLY* in debug builds and not in release builds.
Hence, to be able to test in ROS either debug-builds or release-builds versions of Windows CSR servers in ROS (and vice-versa), I introduced a #define called CSR_DBG, which is defined only if the DBG macro is != 0, and which is not defined otherwise. When the CSR_DBG flag is defined, API names tables are added in CSR servers and otherwise, they are not.
Therefore, we are now able to test debug-build Windows CSR servers in ROS (the default possibility) or free-build versions of these CSR servers (but first, we have to build the other ones without the CSR_DBG flag, to avoid the off-by-one problem described above).
svn path=/trunk/; revision=60560
2013-10-06 13:33:17 +00:00
|
|
|
#ifdef CSR_DBG
|
2012-10-22 23:55:51 +00:00
|
|
|
LoadedServerDll->NameTable = ConsoleServerApiNameTable;
|
[CSR]
During my investigations for making working Win2k3 csrsrv.dll (or other CSR servers) into ROS (to compare our behaviour with our own csrsrv.dll and Win2k3 one), I hit a problem: if I test a checked-build version of csrsrv (or other CSR servers), everything was fine when they were loaded, but if I use a release-build version (i.e. without any debug information), I systematically hit a memory access violation which was traced back to the moment when a CSR server's CsrInitialization entry point was called.
So I did the experiment, where I used our (debug-build) csrsrv with a free-build win2k3 CSR server dll (it was winsrv.dll, and I retested with basesrv.dll after). I hit the access violation. But if I took a debug-build version of winsrv.dll, everything was OK.
I then added in our csrsrv' server.c file the following line (around line 212 of the current file version):
DPRINT1("%s ; ServerDll->ValidTable = 0x%p ; ServerDll->NameTable = 0x%p ; ServerDll->SizeOfProcessData = %d ; ServerDll->ConnectCallback = 0x%p\n", DllString, ServerDll->ValidTable, ServerDll->NameTable, ServerDll->SizeOfProcessData, ServerDll->ConnectCallback);
and I saw that, when using a debug-build win2k3 CSR server, everything was fine (in particular the ServerDll->SizeOfProcessData member contained a reasonable value, e.g. a size of 88 bytes), whereas if I used a free-build version, I got an off-by-one problem, with the ServerDll->ValidTable pointer valid but the ServerDll->NameTable member being equal to 88 (i.e. invalid pointer) and the ServerDll->SizeOfProcessData member being equal to a very large value, which looked like a pointer value.
After more investigations, I saw that in debug-build CSR servers the list of API names were stored, whereas it was not the case in free-build versions. Therefore I concluded that the API names table was included *ONLY* in debug builds and not in release builds.
Hence, to be able to test in ROS either debug-builds or release-builds versions of Windows CSR servers in ROS (and vice-versa), I introduced a #define called CSR_DBG, which is defined only if the DBG macro is != 0, and which is not defined otherwise. When the CSR_DBG flag is defined, API names tables are added in CSR servers and otherwise, they are not.
Therefore, we are now able to test debug-build Windows CSR servers in ROS (the default possibility) or free-build versions of these CSR servers (but first, we have to build the other ones without the CSR_DBG flag, to avoid the off-by-one problem described above).
svn path=/trunk/; revision=60560
2013-10-06 13:33:17 +00:00
|
|
|
#endif
|
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;
|
2014-11-23 15:50:49 +00:00
|
|
|
LoadedServerDll->ShutdownProcessCallback = ConsoleClientShutdown;
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* EOF */
|