У меня вопрос такой. Работа заставила заняться изучением Windows API (до того специализировался на UNIX/POSIX/Sys V системах), в ходе этого процесса запнулся об один вопрос, ответа на который не могу найти. Изучая подноготную метода CreateProcess обратил внимание вот на какую, с моей точки зрения, странность. (далее в соответствии с тем что написано у Руссиновича и Jeffrey Richter, Programming Applications for Microsoft Windows). На определенном этапе подготовки процесса к началу работы исполнительная система (Executive) отправляет процессу csrss сообщение (каким образом ? LPC ?) о новом процессе, csrss создает СВОЙ объект процесс (собственно и Executive и ядро уже создали к этому времени EPROCESS и KPROCESS, причем один является частью другого и это логично, потому как планировщик ядра , как я понял, интересует только PCB). Далее создается первичный тред процесса, в создании которого так же участвует Windows Environment Subsystem (насколько я понимаю в этом участвует именно csrss). Для чего такая сложная схема ? Каким образом userspace процесс csrss КОНКРЕТНО участвует в создании процесса и треда и почему создание "легковестной" структуры, которая по идее должна управляться ядром, настолько усложнено ? К сожалению из открытых источников (как и из вышеперчисленных книг) не могу найти ответа на этот вопрос, кроме общих фраз о том что csrss занимается управлением потоками в системе Windows, что , конечно, "ни о чем".
В csrss когда то была оконная подсистема, потому csrss предоставлял подсистемам полный environment для контроля процессов и потоков.
Потом оконную подсистему перенесли в ядро и в csrss остались по сути мелочи — консольные окна, определенный функционал касающийся .ini файлов, ну и в ХР+ туда засунули парсинг манифестов.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, ononim, Вы писали:
G>>Заранее спасибо за ответ.
O>В csrss когда то была оконная подсистема, потому csrss предоставлял подсистемам полный environment для контроля процессов и потоков. O>Потом оконную подсистему перенесли в ядро и в csrss остались по сути мелочи — консольные окна, определенный функционал касающийся .ini файлов, ну и в ХР+ туда засунули парсинг манифестов.
Да, насколько я понимаю, в csrss раньше было то, что сейчас находится в win32k.sys, то есть функционал, который экспортируется user32.dll и gdi32.dll — окна, сообщения и отрисовка.
Однако ничегошеньки конкретного не говорится в источниках про роль csrss в упрвлении потоками, тем не менее на этот квази-процесс везде ссылаются как на управляющий потоками.
Оно для программирования под Win32 не то чтобы надо, просто самому интересен путь взаимодействия компонентов. Опять же для чего создается некая структура описывающая процесс ?
Для чего оповещается подсистема из environment-а ? Собственно у меня почему возник вопрос — я привык, разрабатывая приложение, понимать суть происходящего. В этом смысле в
UNIX-ах проблем с вышеуказанным нет. В Windows-же непонятно. Например, если я делую fork, и в родчиненном процессе что-то происходит я могу подождать его вызовом wait/waitpid.
Что делать в Win32 не совсем понятно — если CreateProcess возвращает управление тогда, когда создался и инициализировался процесс, но не создался первичный поток и не загрузились dlls,
то как я могу отследить статус созданного процесса , поскольку он может вылететь еще на этапе инициализации или даже загрузки dlls ? В EPROCESS есть такое понятие LCP порт исключений,
как-то могу я эти исключения перехватывать.. в общем пока что ничего непонятно
O>>В csrss когда то была оконная подсистема, потому csrss предоставлял подсистемам полный environment для контроля процессов и потоков. O>>Потом оконную подсистему перенесли в ядро и в csrss остались по сути мелочи — консольные окна, определенный функционал касающийся .ini файлов, ну и в ХР+ туда засунули парсинг манифестов.
G>Да, насколько я понимаю, в csrss раньше было то, что сейчас находится в win32k.sys, то есть функционал, который экспортируется user32.dll и gdi32.dll — окна, сообщения и отрисовка. G>Однако ничегошеньки конкретного не говорится в источниках про роль csrss в упрвлении потоками, тем не менее на этот квази-процесс везде ссылаются как на управляющий потоками.
Нууу.. подсистемам в т.ч. оконной надо знать когда потоки стартуют и дохнут — для того чтобы например разрушать окна.
G>Оно для программирования под Win32 не то чтобы надо, просто самому интересен путь взаимодействия компонентов. Опять же для чего создается некая структура описывающая процесс ?
Ну блин. csrss ведет свой список процессов и потоков чтобы точно знать в каждый момент времени кто есть кто. Ведет он его в виде неких структур-описателей, всего-то. Рассматривайте csrss как хост-процес некоего экзоядра.
G>Для чего оповещается подсистема из environment-а ? Собственно у меня почему возник вопрос — я привык, разрабатывая приложение, понимать суть происходящего. В этом смысле в G>UNIX-ах проблем с вышеуказанным нет. В Windows-же непонятно. Например, если я делую fork, и в родчиненном процессе что-то происходит я могу подождать его вызовом wait/waitpid. G>Что делать в Win32 не совсем понятно — если CreateProcess возвращает управление тогда, когда создался и инициализировался процесс, но не создался первичный поток и не загрузились dlls,
И в винде вы можете ждать хэндл процесса. Причем тут длл?
G>то как я могу отследить статус созданного процесса , поскольку он может вылететь еще на этапе инициализации или даже загрузки dlls ? В EPROCESS есть такое понятие LCP порт исключений, G>как-то могу я эти исключения перехватывать.. в общем пока что ничего непонятно
Ой блин горе от ума. WaitForSingleObject(pi.hProcess, timeout)
Как много веселых ребят, и все делают велосипед...
Пожалуйста, уважайте коллег и не допускайте излишнего цитирования. Для неуважающих напомню, что есть правила форума и ресурса + санкции за несоблюдение оных. Модератор
Спасибо, буду пробовать ! Как раз чтоб не делать велосипед, я и спрашиваю. И к тому же горе не от ума, а от временной безграмотности в данном вопросе
Здравствуйте, ononim, Вы писали:
G>>Заранее спасибо за ответ.
O>В csrss когда то была оконная подсистема, потому csrss предоставлял подсистемам полный environment для контроля процессов и потоков. O>Потом оконную подсистему перенесли в ядро и в csrss остались по сути мелочи — консольные окна, определенный функционал касающийся .ini файлов, ну и в ХР+ туда засунули парсинг манифестов.
А я думаю что все "сложности" которые описанны, растут из-за того что есть еще POSIX и OS/2. Из за того и такой итерационный и запутанный механизм. Но то что графическая подсистема жила в юзер моде согласен и бала до жути тормозной, но и тогда запуск был практически такой как и сейчас.
Правда, Ложь — мне все одно — я имею свое мнение.
Если функция недокументированна — это не значит, что ее не используют все ваши конкуренты в своих продуктах.
Любой строй переходный и отрицать это значит быть закостенелым идиотом.
O>>В csrss когда то была оконная подсистема, потому csrss предоставлял подсистемам полный environment для контроля процессов и потоков. O>>Потом оконную подсистему перенесли в ядро и в csrss остались по сути мелочи — консольные окна, определенный функционал касающийся .ini файлов, ну и в ХР+ туда засунули парсинг манифестов. СР>А я думаю что все "сложности" которые описанны, растут из-за того что есть еще POSIX и OS/2. Из за того и такой итерационный и запутанный механизм. Но то что графическая подсистема жила в юзер моде согласен и бала до жути тормозной, но и тогда запуск был практически такой как и сейчас.
На самом деле идея просто замечательная, но ее сгубило офигенно тормозное переключение контекстов в винде, изза которого IPC на несколько порядков медленнее сисколла.
Впрочем, я не знаю широко используемой оси где бы переключение контекстов было хотя бы почти таким же быстрым как сисколл.
Как много веселых ребят, и все делают велосипед...
В современных Windows существует несколько подсистем. Основные используемые сейчас, это Native и Win32 (второе есть надстройка над первым). Для того, чтобы создать процесс, работающий с поддержкой подсистемы Native (такой процесс работает с базовыми сервисами ядра и о других подсистемах не ведает), всех этих телодвижений с CSR не требуется, достаточно позвать NtCreateProcess(), NtCreateThread() из ntdll.dll и готово. Но процессу, который планирует работать в окружении и с поддержкой CSR, этого мало. Ему нужно заручиться этой поддержкой непосредственно у CSR. И именно для этого функция CreateProcess() посылает необходимые сообщения в csrss.exe. К слову, CSR это не только окна, это ещё и сеансы, например. С практической точки зрения это выглядит именно так, а история и теория описана товарищами чуть выше.
