В новой версии Windows версии используется ошибка в коде ядра, который обрабатывает полосы прокрутки. Это заставило меня задуматься. Почему окна обрабатывают полосы прокрутки в ядре, а не в пользовательском режиме? Исторические причины? Означает ли любая другая ОС это?Почему окна обрабатывают полосы прокрутки в ядре?
TL; DR: Microsoft пожертвовала обеспечением безопасности.
Полосы прокрутки немного особенные в Windows. Большинство полос прокрутки не являются реальными окнами, но реализованы как decorations в «родительском» окне. Это приводит нас к более общему вопросу; почему окна, реализованные в режиме ядра в Windows?
Давайте рассмотрим альтернативные варианты:
Альтернатива 1 имеет большое преимущество при работе с ваши собственные окна; нет переключения контекста/ядра. Конечно, проблема заключается в том, что окна из разных процессов живут на одном экране, и кто-то должен отвечать за решение, какое окно активно, и координировать изменения, когда пользователь переключается в другое окно. Это кто-то должен был бы быть специальным системным процессом или ядром, потому что эта информация не может быть обработана, она должна храниться где-то глобально. Этот двойной информационный дизайн будет сложным, потому что глобальный менеджер окон не может доверять информации о каждом процессе. Я уверен, что в этом теоретическом дизайне есть масса других недостатков, но я не собираюсь тратить на это больше времени.
Windows NT 3 реализован вариант альтернативной 2. Оконный менеджер был переведен в режим ядра в NT 4 в основном для performance reasons:
... менеджер окон (USER) и интерфейс графических устройств (GDI), был перенесен из подсистемы Win32 в Windows NT Executive. Win32 Драйверы устройств пользовательского режима, включая графический дисплей и драйвер принтера , также были перенесены в Исполнительный орган. Эти изменения - , предназначенные для упрощения обработки графики, уменьшения требований к памяти, и повышения производительности.
... и далее вниз в том же документе есть более технические детали и обоснование:
Когда Windows NT была первой разработана подсистема среды Win32 была разработана в качестве партнера к окружающей среде подсистем, поддерживающих приложений в MS-DOS, POSIX и OS/2. Однако приложения и другие подсистемы, необходимые для использования функций графики, окон и сообщений в подсистеме Win32. Чтобы избежать дублирования этих функций , подсистема Win32 использовалась в качестве сервера для графических функций для всех подсистем.
Этот дизайн работал с уважением для Windows NT 3.5 и 3.51, но он недооценил громкость и частоту графических вызовов.Наличие функционирует как базовое, как обмен сообщениями и управление окнами в отдельном процессе , вызвало существенные издержки памяти от клиента/сервера передача сообщений, сбор данных и управление несколькими потоками. В нем также требовалось несколько контекстных переключателей, которые потребляют циклы процессора как , а также память. Объем графических запросов поддержки в секунду ухудшил производительность системы. Было ясно, что редизайн этого аспекта в Windows NT 4.0 может вернуть эти потраченные впустую системы и повысить производительность.
Другие подсистемы не актуальны в наши дни, но проблемы с производительностью остаются.
Если мы посмотрим на простую функцию, например IsWindowVisible, тогда при работе диспетчера окон в режиме ядра не так много накладных расходов: функция выполнит пару инструкций в пользовательском режиме, а затем переключит CPU на 0, вся операция (проверка обработанного обработчика окна и если он действителен, получить видимое свойство) выполняется в режиме ядра. Затем он переключается обратно в пользовательский режим, и это примерно так.
Если оконный менеджер живет в другом процессе, то вы, по крайней мере, удвоите количество переходов ядра, и вы должны каким-то образом передать функции ввода и вывода в процесс диспетчера окон и вы должны каким-то образом привести к процессу оконного менеджера выполняться, пока вы ждете результата. NT 3 сделал это, используя комбинацию общей памяти, LPC и неясную функцию, называемую спаренными потоками.
Серверная часть USER32 и GDI32 используется для запуска в пользовательском режиме. Он был размещен в процессе подсистемы клиент-сервер, CSRSS.EXE, который работает как учетная запись SYSTEM. NT 4 переместили их в режим ядра (win32k.sys) по соображениям производительности. – eryksun
IIRC, Microsoft также заявила, что упростила переход от режима пользователя к режиму ядра во время работы графического интерфейса. По-видимому, графическая подсистема до NT 4 имела специально сопряженные потоки режима пользователя и ядра и существовал некоторый настраиваемый механизм перехода от одного к другому. По-видимому, было сложно доказать свойства безопасности для этого перехода, и избавление от него упростило процесс сертификации. (Я не уверен, какую сертификацию они собирались в то время, возможно, была Orange Book.) –