Как команды и программы взаимодействуют с ОС Windows
Как программы, созданные для Windows, взаимодействуют с ядром Windows NT или выдают команды?
А как ядро возвращает какие-либо данные?
3 ответа
Чтобы ответить на этот вопрос, важно понять разницу между режимом пользователя и режима ядра. Режим ядра является наиболее привилегированным режимом ЦП, где исполняемый код имеет полный доступ к оборудованию. Он используется для самой низкой функциональности операционной системы. Пользовательский режим является гораздо более ограниченным режимом процессора. Это предотвращает прямой доступ кода к оборудованию. Приложения запускаются в пользовательском режиме. Конечно, им все равно нужно как-то получить доступ к аппаратному обеспечению, поэтому им нужно вызвать ядро.
Вот к чему ведет ваш вопрос. Чтобы код пользовательского режима мог вызывать ядро, ядро 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, не позволяя им напрямую вызывать сервисы ядра.
Попробуйте прочитать это: Глава 5 - Архитектура рабочей станции Windows NT 4.0. Этого должно быть достаточно, чтобы начать.
В конце концов, некоторые API встроены непосредственно в некоторые пользовательские библиотеки DLL. Они выполняются напрямую. Другие требуют помощи / услуг в режиме ядра.
Для них (я цитирую по ссылке выше)
Приложение использует API для графического вызова библиотеки динамических ссылок пользовательского режима. Компонент, который реализует вызов, выполняет исполнительный вызов режима ядра, чтобы переключить его поток и скопировать его параметры вызова из своего стека пользовательского режима в его стек режима ядра. Затем регистр стека процессора переключается в режим ядра. Теперь поток может работать в исполнительной власти.
Приложения взаимодействуют с защищенными подсистемами, используя локальные вызовы процедур (LPC), независимый от приложения метод связи между компонентами на одном компьютере. После того как поток переключен в режим ядра, микроядро планирует LPC для доставки.
Используя Fast LPC, оптимизированный метод связи, микроядро распознает, что вызов из приложения включает поток в подсистеме среды. Он считает поток вызывающего приложения и поток принимающей подсистемы парным. Получающий поток теперь может использовать не истекшее время из отправляющего потока.
Параметры графического вызова передаются в поток принимающей подсистемы. Принимающий поток переключается обратно в режим пользователя для выполнения графического запроса.
Подсистема завершает свою задачу и затем возвращает управление ожидающему вызывающему потоку в приложении тем же методом.
Вызывающий поток (из DLL) переключается обратно в режим пользователя, прежде чем вернуть управление приложению.
Инженеры операционной системы Microsoft также использовали концепцию окна общей памяти для ускорения обмена данными. Данные помещаются во временное окно совместно используемой памяти, управляемое диспетчером процессов в программе Executive. Это позволяет приложению видеть в памяти подсистемы и обмениваться данными без использования LPC. Однако, поскольку поток приложения должен по-прежнему выполняться в исполнительной системе, переходы режима ядра / пользователя и переключатели потоков все еще необходимы.
Здесь есть некоторые заметки о том, как exactly завершен ли вызов (какая команда ASM используется): Диспетчер системных вызовов на x86, если он вам нужен.
Чувак, это очень широкий вопрос.
Я рекомендую книгу Windows Internals By Mark Russinovich et ag, если вы действительно хотите понять это. Еще одна хорошая книга - это классические операционные системы Deitel et al.
Начните, однако, с Inside Windows NT от Helen Custer (издание 1) - это очень простая книга (обратите внимание, что последняя ссылка содержит изображение обложки издания 2 - что более подробно).
Хорошо в двух словах.
Существует множество протоколов для связи между компонентами Windows. Большинство из них будут использовать передачу данных через некоторую общую память (например, буферы, стек и т. Д.) В конце дня. Но протоколы могут быть очень сложными и разными для разных коммуникаций.
Я предлагаю вам взглянуть на вышеперечисленные книги и определить, как сочетается архитектура операционной системы Windows. Отсюда вы увидите, как взаимодействуют различные компоненты.
(применяя умник) - Поверьте мне, это отличные книги для изучения Windows и операционных систем в целом, если это то, что плавает на вашей лодке.