Как команды и программы взаимодействуют с ОС Windows - PullRequest
3 голосов
/ 06 сентября 2011

Как программы, созданные для Windows, взаимодействуют с ядром Windows NT или выдают команды для него?

А как ядро ​​возвращает какие-либо данные?

Ответы [ 3 ]

0 голосов
/ 06 сентября 2011

Попробуйте прочитать это: Глава 5 - Архитектура рабочей станции Windows NT 4.0 . Для начала должно хватить.

В конце концов, некоторые API встроены непосредственно в некоторые пользовательские библиотеки DLL. Они выполняются напрямую. Другие требуют помощи / услуг в режиме ядра.

Для этих (я цитирую по ссылке выше)

Приложение использует API для графического вызова пользовательского режима. библиотека динамических ссылок. Компонент, который реализует вызов, делает вызов ловушки в режиме ядра исполнительному органу для переключения потока и копирования его параметры вызова из стека режима пользователя в стек режима ядра. Затем регистр стека процессора переключается на ядро Режим. Теперь поток может запускаться в Executive.

Приложения связываются с защищенными подсистемами, используя локальные вызовы процедур (LPC), независимый от приложения метод связь между компонентами на одном компьютере. После поток переключается в режим ядра, микроядро планирует LPC для доставки.

Использование Fast LPC, оптимизированного метода связи, Microkernel признает, что вызов из приложения включает в себя поток в подсистема среды. Он считает вызывающий поток приложения и поток принимающей подсистемы для сопряжения. Принимающая нить может теперь используйте не истекшее время из потока отправки.

Параметры графического вызова передаются в принимающую подсистему. нить. Принимающий поток переключается обратно в режим пользователя для выполнения графический запрос.

Подсистема завершает свою задачу и затем возвращает управление ожидание вызывающего потока в приложении тем же методом.

Вызывающий поток (из DLL) переключается обратно в режим пользователя до возврат управления приложению.

Инженеры операционной системы Microsoft также использовали концепцию общего доступа. Окно памяти для ускорения связи. Данные помещаются во временный окно общей памяти, управляемое диспетчером процессов в Должностное лицо. Это позволяет приложению видеть в памяти подсистемы и обмениваться данными без использования LPC. Тем не менее, потому что приложение поток все еще должен работать в исполнительном режиме, переходах из режима ядра в пользовательский режим и резьбовые переключатели все еще требуются.

Здесь есть некоторые заметки о том, как exactly выполняется вызов (для чего используется команда ASM): Диспетчер системных вызовов на x86 , если вам это нужно.

0 голосов
/ 23 ноября 2013

Чтобы ответить на этот вопрос, важно понять разницу между режимом пользователя и режима ядра.Режим ядра является наиболее привилегированным режимом ЦП, где исполняемый код имеет полный доступ к оборудованию.Он используется для самой низкой функциональности операционной системы.Пользовательский режим является гораздо более ограниченным режимом процессора.Это предотвращает прямой доступ кода к оборудованию.Приложения запускаются в пользовательском режиме.Конечно, им все равно нужно как-то получить доступ к аппаратному обеспечению, поэтому им нужно обратиться к ядру.

Вот к чему приводит ваш вопрос.Чтобы код пользовательского режима мог вызывать ядро, ядро ​​Windows устанавливает точку входа.В системах на базе x86 эта точка входа является либо программным прерыванием (int 2e), либо инструкцией sysenter / syscall.Выполнение этих инструкций приводит к переключению режима ЦП, переводя ЦП из режима пользователя в режим ядра.Как только процессор переключил режимы, он вызывает функцию, указанную ядром.В Windows эта функция является диспетчером системных служб.

Диспетчер системных служб отвечает за вызов службы ядра, которую хочет код пользовательского режима.Он берет номер функции, указанный в коде пользовательского режима, и ищет его в таблице дескрипторов системных служб (SSDT).SSDT - это в основном список указателей на функции для каждого ядра.Как только он идентифицирует правильную службу ядра, он вызывает ее с аргументами, которые также указано приложением в режиме пользователя.После завершения работы службы ядра ЦПУ возвращается к приложению либо с помощью инструкции iret (если она поступает из программного прерывания), либо с помощью sysexit / sysret (если она поступает из sysenter / syscall).

Все это звучит вполнесложный, и именно поэтому Windows скрывает эти детали от программистов.Вместо того, чтобы требовать от них прямой связи с ядром через точку входа, которую устанавливает ядро, Windows предоставляет программистам несколько библиотек DLL, которые делают это для них.

Теперь вот, где это снова становится несколько сложнее.Процесс вызова служб ядра из пользовательского режима реализован в ntdll.dll, но большинство программистов не использует ntdll.dll напрямую.Вместо этого он экспортирует общий набор служб ядра, который называется Native API.Кроме того, Win32 API реализован в kernel32.dll.Большинство функций в kernel32.dll - это просто оболочки функций в ntdll.dll.

Вы можете спросить, почему это делается.Почему бы просто не вызвать kernel32.dll напрямую вызывать функции ядра?Причина этого заключается в том, чтобы учитывать разные многопользовательские API-интерфейсы.Windows NT была разработана для поддержки нескольких API, не только Win32, но также POSIX и OS / 2.Каждый API пользовательского режима вызывает ntdll.dll для реализации своих собственных API, не позволяя им напрямую вызывать службы ядра.

0 голосов
/ 06 сентября 2011

Чувак, это очень широкий вопрос.

Я рекомендую книгу Windows Internals Автор Mark Russinovich et ag , если вы действительно хотите понять это. Еще одна хорошая книга - классические Операционные системы от Deitel et al .

Начните, однако, с Внутри Windows NT Хелен Кастер ( редакция 1 ) - это очень простая книга (обратите внимание, что в последней ссылке есть изображение обложки издания 2 - которая путь способ более подробно).

Хорошо в двух словах.

Существует множество протоколов для обмена данными между компонентами Windows. Большинство из них будут использовать передачу данных через некоторую общую память (например, буферы, стек и т. Д.) В конце дня. Но протоколы могут быть очень сложными и разными для разных коммуникаций.

Мое предложение для вас: посмотрите на вышеприведенные книги и определите, как архитектура операционной системы Windows сочетается. Отсюда вы увидите, как взаимодействуют различные компоненты.

(применяя умник) - поверьте мне, это отличные книги для изучения Windows и операционных систем в целом, если это то, что плавает на вашей лодке.

...