Что такое nt драйвер

Обновлено: 18.05.2024

The Manufacturer section identifies the manufacturer of one or more devices that can be installed by using the INF file.

Entries

manufacturer-identifier
Uniquely identifies a manufacturer and an INF section that contains information that identifies a manufacturer's device models. Each manufacturer-identifier entry must exist on a separate line and use the following format:

These entries are defined as follows:

manufacturer-name
Identifies the devices' manufacturer. The INF must also contain a corresponding INF Models section of the same name. The maximum length of a manufacturer's name, in characters, is LINE_LEN. (An entry specified in this manner cannot be localized.)

strkey
Specifies a token, unique within the INF file that represents the name of a manufacturer. Each such %strkey% token must be defined in an INF Strings section of the INF file.

models-section-name
Specifies an INF-writer-defined name for the per-manufacturer INF Models section within the INF file. This value must be unique within the INF file and must follow the general rules for defining section names. For more information about these rules, see General Syntax Rules for INF Files.

TargetOSVersion
Specifies one or more target operating system versions with which various INF Models sections can be used. Windows chooses the INF Models section that most closely matches the operating system version on which it is executing.

For a description of the TargetOSVersion decoration, see the following Remarks section, and related info in Example 3 below.

Important: Starting with Windows Server 2003 SP1, INF files must decorate models-section-name entries in the INF Manufacturer section, as well as the associated INF Models section names, with .ntia64 or .ntamd64 platform extensions to specify non-x86 target operating system versions. These platform extensions are not required in INF files for x86-based target operating system versions or non-PnP driver INF files, such as file system driver INF files for x64-based architectures.

Remarks

Any INF file that installs one or more devices must have a Manufacturer section. An IHV/OEM-supplied INF file typically specifies only a single entry in this section. If multiple entries are specified, each entry must be on a separate line of the INF.

Using a %strkey%=models-section-name entry simplifies the localization of the INF file for the international market, as described in Creating International INF Files and the reference page for the INF Strings section.

If an INF file specifies one or more entries in the manufacturer-name format, each such entry implicitly specifies the name of the corresponding Models section elsewhere in the INF.

You can think of each system-supplied INF file's Manufacturer section as a table of contents, because this section sets up the installation of every manufacturer's device models for a device setup class. Each entry in an INF file's Manufacturer section specifies both an easily localizable %strkey% token for the name of a manufacturer and a unique-to-the-INF per-manufacturer Models section name.

The models-section-name entries in the Manufacturer section can be decorated to specify target operating system versions. Different INF Models sections can be specified for different versions of the operating system. The specified versions indicate operating system versions with which the INF Models sections is used. If no versions are specified, Windows uses a specified Models section for all versions of all operating systems.

For Windows XP to Windows 10, version 1511, the format of TargetOSVersion decoration is as follows:

Starting with Windows 10, version 1607 (Build 14310 and later), the format of the TargetOSVersion decoration is as follows:

Each field is defined as follows:

nt
Specifies the target operating system is NT-based. Windows 2000 and later versions of Windows are all NT-based.

Architecture
Identifies the hardware platform. If specified, this must be x86, ia64, amd64, arm, or arm64.

Prior to Windows Server 2003 SP1, if Architecture is not specified, the associated INF Models section can be used with any hardware platform.

Starting with Windows Server 2003 SP1, Architecture must be specified in INF Models sections names for non-x86 target operating system versions. Architecture is optional in INF Models section names for x86-based target operating system versions.

OSMajorVersion
A number that represents the operating system's major version number. The following table defines the major version for the Windows operating system.

Windows version	Major version
Windows 10	10
Windows Server 2012 R2	6
Windows 8.1	6
Windows Server 2012	6
Windows 8	6
Windows Server 2008 R2	6
Windows 7	6
Windows Server 2008	6
Windows Vista	6
Windows Server 2003 R2	5
Windows Server 2003	5
Windows XP	5
Windows 2000	5

OSMinorVersion
A number that represents the operating system's minor version number. The following table defines the minor version for the Windows operating system.

Windows version	Minor version
Windows 10	0
Windows Server 2012 R2	3
Windows 8.1	3
Windows Server 2012	2
Windows 8	2
Windows Server 2008 R2	1
Windows 7	1
Windows Server 2008	0
Windows Vista	0
Windows Server 2003 R2	2
Windows Server 2003	2
Windows XP	1
Windows 2000	0

ProductType
A number that represents one of the VER_NT_xxxx flags defined in Winnt.h, such as the following:

0x0000001 (VER_NT_WORKSTATION)

0x0000002 (VER_NT_DOMAIN_CONTROLLER)

0x0000003 (VER_NT_SERVER)

If a product type is specified, the INF file is used only if the operating system matches the specified product type. If the INF supports multiple product types for a single operating system version, multiple TargetOSVersion entries are required.

SuiteMask
A number representing a combination of one or more of the VER_SUITE_xxxx flags defined in Winnt.h. These flags include the following:

0x00000001 (VER_SUITE_SMALLBUSINESS)

0x00000002 (VER_SUITE_ENTERPRISE)

0x00000004 (VER_SUITE_BACKOFFICE)

0x00000008 (VER_SUITE_COMMUNICATIONS)

0x00000010 (VER_SUITE_TERMINAL)

0x00000020 (VER_SUITE_SMALLBUSINESS_RESTRICTED)

0x00000040 (VER_SUITE_EMBEDDEDNT)

0x00000080 (VER_SUITE_DATACENTER)

0x00000100 (VER_SUITE_SINGLEUSERTS)

0x00000200 (VER_SUITE_PERSONAL)

0x00000400 (VER_SUITE_SERVERAPPLIANCE)

If one or more suite mask values are specified, the INF is used only if the operating system matches all the specified product suites. If the INF supports multiple product suite combinations for a single operating system version, multiple TargetOSVersion entries are required.

BuildNumber
A number that represents the minimum OS build number of the Windows 10 release to which the section is applicable, starting with build 14310 or later.

The build number is assumed to be relative to some specific OS major/minor version only, and may be reset for some future OS major/minor version. Any build number specified by the TargetOSVersion decoration is evaluated only when the OS major/minor version of the TargetOSVersion matches the current OS (or AltPlatformInfo) version exactly. If the current OS version is greater than the OS version specified by the TargetOSVersion decoration (OSMajorVersion,OSMinorVersion), the section is considered applicable regardless of the build number specified. Likewise, if the current OS version is less than the OS version specified by TargetOSVersion decoration, the section is not applicable.

If build number is supplied, the OS version and BuildNumber of the TargetOSVersion decoration must both be greater than the OS version and build number of the Windows 10 build 14310 where this decoration was first introduced. Earlier versions of the operating system without these changes (for example, Windows 10 build 10240) will not parse unknown decorations, so an attempt to target these earlier builds will actually prevent that OS from considering the decoration valid at all.

Important We highly recommend that you always decorate models-section-name entries in the Manufacturer and Models sections with platform extensions for target operating systems of Windows XP or later versions of Windows. For x86-based hardware platforms, you should avoid the use of the .nt platform extension and use .ntx86 instead.

If your INF contains Manufacturer section entries with decorations, it must also include INF Models sections with names that match the operating system decorations. For example, if an INF contains the following Manufacturer section:

%FooCorp%=FooMfg, NTx86. 0x80, NTamd64

Then the INF must also contain INF Models sections with the following names:

[FooMfg.NTx86. 0x80]

This name applies to the Data Center suite of Windows XP and later versions of Windows on x86-based hardware platforms.

[FooMfg.NTamd64]

This name applies to all product types and suites of Windows XP and later versions of Windows on x64-based hardware platforms.

During installation, Windows selects an INF Models section in the following way:

If Windows is running in an x86-based version of the operating system (Windows XP or later versions) that includes the Data Center product suite, Windows selects the [FooMfg.NTx86. 0x80]Models section.
If Windows is running in an x64-based version of the operating system (Windows XP or later versions) for any product suite, Windows selects the [FooMfg.NTamd64]Models section.

If the INF is intended for use with operating system versions earlier than Windows XP, it must also contain an undecorated Models section named [FooMfg].

If an INF supports multiple manufacturers, these rules must be followed for each manufacturer.

The following are additional examples of TargetOSVersion decorations:

%FooCorp% = FooMfg, NTx86

In this example, the resultant INF Models section name is [FooMfg.NTx86], and is applicable for any x86 version of the operating system (Windows XP or later).

%FooCorp% = FooMfg, NT.7.8

In this example, for version 7.8 and later of the operating system, the resultant INF Models section name is [FooMfg.NT.7.8]. For earlier versions of the operating system such as Windows XP, [FooMfg.NT] is used.

Setup's selection of which INF Models section to use is based on the following rules:

If the INF contains INF Models sections for several major or minor operating system version numbers, Windows uses the section with the highest version numbers that are not higher than the operating system version on which the installation is taking place.
If the INF Models sections that match the operating system version also include product type and/or product suite decorations, Windows selects the section that most closely matches the running operating system.

Suppose, for example, Windows is executing on Windows XP (version 5.1), without the Data Center product suite, and it finds the following entry in a Manufacturer section:

%FooCorp%=FooMfg, NT, NT.5, NT.5.5, NT. 0x80

In this case, Windows looks for an INF Models section named [FooMfg.NT.5]. Windows also uses the [FooMfg.NT.5] section if it is executing on a Datacenter version of Windows XP, because a specific version number takes precedence over the product type and suite mask.

If you want an INF to explicitly exclude a specific operating system version, product type, or suite, create an empty INF Models section. For example, an empty section named [FooMfg.NTx86.6.0] prohibits installation on x86-based operating system versions 6.0 and higher.

Examples

This example shows a Manufacturer section typical to an INF for a single IHV.

The next example shows part of a Manufacturer section typical to an INF for a device-class-specific installer:

The following example shows a Manufacturer section that is specific to x86 platforms, Windows XP and later:

The following example shows a Manufacturer section that is specific to x64 platforms, Windows 10 build 14393 and later:

The following two examples show skeletal INF files with a variety of OS-specific INF Models sections:

Note: When specifying multiple TargetOSVersions, string them together in one entry as seen in this example. Do not represent each target as a separate entry.

Несколько дней назад в сеть просочился образ ранней версии Windows 11. Различные издательства провели тесты по производительности и пришли к неутешительному выводу: Windows 11 в среднем работает хуже, чем Windows 10. Но расстраиваться рано! Проблемы производительности могут быть связаны с «сыростью» слитого образа и нюансами совместимости с текущими программами. Так или иначе, 24 июня состоится официальная презентация нового поколения операционных систем Windows, которая, возможно, даст ответы на многие вопросы. Если сегодня у вас есть настроение для ностальгии, предлагаем вам окунуться в мир Windows: познакомиться с историей, как менялась ось и что у нее внутри.

История Windows

В начале 80 годов прошлого века компания IBM работала над персональным компьютером на базе процессора Intel 8088. С середины 70 годов компания Microsoft была основным поставщиком Basic для восьмибитных микрокомпьютеров. Когда IBM обратилась к Microsoft для лицензирования Basic для их нового компьютера IBM PC, Microsoft согласилась, а также посоветовала обратиться к компании Digital Research для лицензирования операционной системы CP/M. Но, получилось так, что глава Digital Research не нашел в своем графике времени для встречи для IBM, и IBM снова обратилась к Microsoft, теперь уже с просьбой решить вопрос операционной системы для IBM PC. Microsoft купила клон ОС CP/M у компании Seattle Computer Products и перенесла её на IBM PC. Итоговым названием получившейся ОС стало MS-DOS 1.0.

Первые продукты с названием «Windows» от Microsoft не были операционными системами. Это были графические среды для MS-DOS. На фоне успеха, в том числе и коммерческого, пользовательского интерфейса на Apple Lisa, компания решила реализовать графический интерфейс на IBM PC с MS-DOS. В отличии от относительно дешевых IBM PC, Apple Lisa стоили дорого (почти 10 тысяч долларов), и немногие покупатели могли позволить купить их. Microsoft решила занять нишу дешевых компьютеров с графическим интерфейсом. При этом низкая стоимость достигалась экономией на комплектующих и более низкая производительность, по сравнению с Lisa, избежать не получилось. Так, в 1985, 1987 и в 1990 выходят первые три версии Windows — 1.0, 2.0 и 3.0. Причем за первые шесть месяцев после релиза Windows 3.0 было продано более 1 миллиона экземпляров. Дальнейшее развитие Windows можно разделить на два направления — Windows на базе MS-DOS и Windows на базе NT.

Windows 1.01

Windows 9x

Windows на базе MS-DOS или Windows 9x не были первыми ОС от Microsoft, но они продолжали «старые традиции» и были построены на основе 16-битного кода MS-DOS. В августе 1995 года была выпущена Windows 95 — первая система семейства Windows 9x. Она уже была полноценной операционной системой с соответствующими возможностями. Однако у системы были проблемы с безопасностью (например, не было «администратора») и с изоляцией приложений. Зависание 16-битного приложения приводило к блокировке всей системы. Проблемы со стабильностью достались и Windows 98 и Windows ME, которые отличались от выпуска 95 года рядом небольших обновлений.

Windows NT

В целом, к концу 80-х годов в Microsoft появилось понимание о необходимости разработки операционной системы не на базе MS-DOS. Параллельно с разработкой софта, связанного с MS-DOS, Microsoft наняла команду инженеров из компании DEC для разработки новой 32-битной операционной системы. Главой группы стал Дэйв Катлер — один из главных разработчиков ОС VMS. Новая система была названа NT — от сокращения New Technology. Основной упор при разработке NT делался на безопасность и надежность системы, а также на совместимость с Windows на MS-DOS. Так получилось, что опыт при разработке VMS повлиял на NT и сходство между ними стало причиной спора между DEC и Microsoft. По итогу спор был решен во внесудебном порядке.

Дэйв Катлер

Первая система Windows называлась Windows NT 3.1 и была выпущена в 1993 году. Это была первая ОС от Microsoft. Индекс 3.1 был выбран для соответствия Windows 3.1 на MS-DOS. Эта версия не имела особого успеха. Для NT требовалось больше памяти, 32-разрядных приложений на рынке было мало, возникали проблемы с совместимостью драйвером. Достичь поставленных целей смогли в NT 3.5. А первым серьезным обновлением для NT стала версия 4.0 в 96 году. Теперь эта система была мощна, надежна и безопасна, а также обеспечивала тот же интерфейс, что и Windows 95 (которая к тому моменту была чрезвычайно популярной).

Windows NT 3.1

В 2000 году вышла новая версия Windows — Windows 2000. Она развивала идеи, заложенные в системы NT. Был добавлена технология Plug-and-Play, управление электропитанием и улучшен интерфейс пользователя.

Windows 2000

Успех Windows 2000 задал вектор развития для следующего поколения — Windows XP. В «хрюшке» Microsoft улучшила совместимость, интерфейс стал более дружелюбным. Стратегия Microsoft завоевывать аудиторию уже знакомыми системами дала плоды — за несколько лет Windows XP была установлена на сотнях миллионах ПК. Эпоха MS-DOS подошла к концу.

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

Первоначальные планы Microsoft по поводу Vista были настолько обширны, что через несколько лет после начала разработки проект пришлось сильно ограничить. Vista включала в себе 70 миллионов строк кода, часть которого составлял «причесанный» код XP. Неудача Vista отчасти с тем, что она вышла не в то время. На 2006 год пришелся бум недорогих компьютеров, которые не могли обеспечить достаточную для Vista производительность.

Windows Vista

Проблемы Vista были учтены при разработке Windows 7. Microsoft уделила большее внимание тестированию и производительности новой системы. Windows 7 быстро вытеснила Vista, а затем и XP, став самой популярной версией Windows до появления Windows 10 (сейчас Windows 7 на втором месте по популярности).

Бум смартфонов в начале 2010-х подтолкнул Microsoft к созданию операционной системы, которую можно было бы развернуть на разных устройствах: на телефонах, планшетах, приставках и т. д. В результате этой работы мир узрел Windows 8. «Восьмерка» построена на модульном подходе MinWin для получения небольшого ядра ОС, которое можно было бы расширить на линейку других типов устройств. Но аудитория встретила холодно такой подход. Многие люди критиковали «смартфоноподобный» интерфейс на ПК, отсутствие кнопки пуск. Для решения многих проблем Microsoft выпустила обновление под названием Windows 8.1, которая, помимо исправления имеющихся ошибок, добавила новые функции.

И вот, к 2015 году Microsoft выпускает Windows 10. При разработке Microsoft продолжала развитие идеи единой системы для разных устройств. В «десятке» появилась голосовая помощница Кортана, вернули меню «Пуск», улучшена системная безопасность.

Технические аспекты

Чтобы осветить все технические аспекты и тонкости операционной системы Windows понадобится не менее 1000 страниц. Для особо любопытных советуем 7-е издание «Внутреннего устройства Windows« Марка Руссиновича, специалиста по внутреннему устройству Windows. Также можно почитать «Современные операционные системы« Эндрю Таненбаума и «Operating System Concepts«: в обеих книгах есть главы, посвященные Windows. Здесь же ограничимся рассмотрением инструментов взаимодействия приложений пользователя с операционной системой (Windows API) и архитектуры «оси».

Архитектура

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

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

Упрощенная схема архитектуры Windows

Вторая линия разделяет компоненты режима ядра и гипервизор (Hyper-V). Гипервизор перехватывает многие привилегированные операции, выполняемые ядром, и эмулирует их таким образом, чтобы позволить на одной и той же машине одновременно работать нескольким операционными системам. Гипервизор работает на том же уровне привилегий процессора (0), что и ядро. Но из-за использования специализированных команд процессора (VT-x у процессоров Intel, SVM у АMD) он может изолироваться от ядра с сохранением контроля над ним и приложениями. Поэтому некоторые иногда применяют термин «кольцо -1».

Четыре базовых типа процессов пользовательского режима:

Пользовательские процессы. Эти процессы относятся к одному из следующих типов: 32- или 64-разрядные приложения Windows (приложения Windows Apps, работающие на базе среды Windows Runtime в Windows 8 и выше, включаются в эту категорию), 16-разрядные приложения Windows 3.1, 16-разрядные приложения MS-DOS, 32- и 64-разрядные приложения POSIX. Заметим, что 16-разрядные приложения могут выполняться только в 32-разрядных версиях Windows, а приложения POSIX в Windows 8 уже не поддерживаются.
Процессы служб. В эту категорию входят процессы, являющиеся хостами для служб Windows (например, службы планировщика задач и диспетчер печати). Обычно к службам предъявляется требование независимости выполнения от входа пользователя. Многие серверные приложения Windows (например, Microsoft SQL Server и Microsoft Exchange Server) также включают компоненты, выполняемые как службы.
Системные процессы. Фиксированные процессы, такие как процесс входа или диспетчер сеансов, не являются службами Windows. Другими словами, они не запускаются диспетчером служб.
Серверные процессы подсистем среды. Такие процессы реализуют часть поддержки среды ОС, предоставляемой пользователю и программисту. Изначально в Windows NT было три подсистемы среды: Windows, POSIX и OS/2. Подсистема OS/2 включалась только до Windows 2000, подсистема POSIX в последний раз была включена в Windows XP.Ultimate- и Enterprise-выпуски клиента Windows 7. Все серверные версии Windows 2008 R2 включают поддержку расширенной подсистемы POSIX, называемой SUA (Subsystem for UNIX-based Applications). Сейчас подсистема SUA не поддерживается и уже не включается как необязательное часть в версии Windows (Windows 10 версии 1607 включает подсистему Windows для Linux — WSL, Windows Subsystem for Linux).

Компоненты режима ядра:

Исполнительная система. Она содержит базовые сервисные функции ОС: управление памятью, управление процессами и потоками, безопасность, ввод/вывод, сетевая поддержка и межпроцессные коммуникации.
Ядро Windows. Низкоуровневые функции ОС: планирование потоков, диспетчеризация прерываний и исключений и многопроцессорная синхронизация. Также ядро предоставляет набор функций и базовых объектов, которые используются исполнительной системой для реализации высокоуровневых конструкций.
Драйверы устройств. Сюда входят как драйверы физических устройств, преобразующие вызовы пользовательских функций ввода/вывода в конкретные запросы ввода/вывода к устройству, так и драйверы устройств, не относящихся к физическому оборудованию, например драйверы файловой системы или сетевые драйверы.
Слой абстрагирования оборудования (HAL). Прослойка кода, изолирующее ядро, драйверы устройств и прочий исполняемый код Windows от платформенно-зависимых различий в работе оборудования, например различий между системными платами.
Оконная и графическая система. Реализация функций графического интерфейса (GUI), также известных как функции GDI: работа с окнами, элементы пользовательского интерфейса и графический вывод.
Уровень гипервизора. Включает всего-навсего один компонент: сам гипервизор. В этой среде нет ни драйверов, ни других модулей. При этом сам гипервизор состоит из нескольких внутренних уровней и служб: собственный диспетчер памяти, планировщик виртуальных процессов, управление прерываниями и таймером, функции синхронизации, разделы (экземпляры виртуальных машин) и внутрипроцессные коммуникации (IPC, Inter-Process Communication) и многие другие.

Имя файла	Компоненты
Ntoskrnl.exe	Исполнительная система и ядро
Hal.dll	HAL
Win32k.sys	Часть подсистемы Windows режима ядра (GUI)
Hvix64.exe (Intel), Hvax64.exe (AMD)	Гипервизор
.sys в \SystemRoot\System32\Drivers	Основные файлы драйверов: DirectX, Volume Manager, TCP/IP и поддержка ACPI
Ntdll.dll	Внутренние вспомогательные функции и заглушки диспетчеризации системных сервисных функций
Kernel32.dll, Advapi32.dll, User32.dll, Gdi32.dll	Dll основных подсистем Windows

Windows API

Windows API (Application Programming Interface) — это программный интерфейс пользовательского режима для Windows. До появления 64-разрядной версии операционной системы программный интерфейс 32-разрядных версий Windows назывался Win32 API в отличие от исходного 16-разрядного Windows API (программный интерфейс для исходных 16-разрядных версий Windows). На данный момент термин Windows API или Win32 API относят как к 32-разрядным, так и к 64-разрядным версиям.

В «доисторические времена» Windows API состоял только из функций в стиле C. Выбор языка C был обусловлен тем, что написанный на нем код также мог использоваться из других языков. Он являлся достаточно низкоуровневым для предоставления сервиса ОС. Но огромное количество функций в сочетании с недостаточной последовательностью выбора имен и отсутствием логических группировок (вроде пространств имен C++) привели к тому, что в некоторых новых API используется другой механизм — модель COM.

WinRT

В Windows 8 появился новый API и исполнительная среда поддержки Windows Runtime (WinRT). WinRT состоит из платформенных сервисов, предназначенных для разработчиков приложений Windows Apps (приложения Windows Apps подходят для устройств, начиная от миниатюрных IoT-устройств до телефонов, планшетов, десктопных систем, ноутбуков и даже Xbox One и Microsoft HoloLens).

То, что принято называть «графикой в ядре» обычно относится к win32k. Win32k.sys представляет собой ядерную часть графической подсистемы. Загружается пользовательским процессом smss.exe в процессе инициализации всех остальных подсистем. Путь к исполняемому образу для «kmode» подсистемы прописан здесь:

Как же это происходит?

Здесь (на стек трейсе в нижней части скриншота) хорошо видно, что инициирует загрузку win32k процесс пользовательского режима smss (который в том числе инициализирует файлы подкачки, реестр, переменные окружения, сохраняет дамп памяти, если до этого был bugcheck, при посредстве wininit запускает service control manager и local security authority subsystem, создает logon сессии и т.п..), а одна из первых вещей, которые делает сам win32k — это «налаживание связей» с ядром. И вот зачем: win32k находится на более высоком уровне по сравнению с ядром, поэтому ядро не может иметь зависимость (под «зависимостью» в данном случае понимается классический «reason to change») от (конкретной реализации) win32k, но и ядро и win32k могут безопасно зависеть от интерфейса. Таким интерфейсом является структура KWIN32_CALLOUTS_FPNS и функция для регистрации конкретной реализации этого интерфейса в ядре — PsEstablishWin32Callouts.

Кроме того, win32k регистрирует несколько типов объектов (в частности Desktop и WindowStation) через интерфейсы общего назначения, предоставляемые Object Manager-ом.

Таким образом НИКАКИХ зависимостей от win32k у ядра нет. Более того, до NT4 все user/gdi API обрабатывалось в csrss и, естественно, тормозило. Начиная с NT4 ЧАСТЬ user/gdi примитивов была перенесена в ядро для повышения производительности.

В общем win32k можно полностью убрать, можно заменить собственной ядерной частью, а можно реализовать все полностью в пользовательском режиме (используя, например, ioctl-ы для связи с ядром), но это будет тормозить. Единственная причина, по которой это не делается — потому что это не нужно. Можно написать по-другому — да, написать существенно лучше — вряд ли. Ну а переписывание ради самого переписывания — не лучшая идея.

Практика — критерий истины или «MinWin на коленке»

Для исключения недоразумений, хочу сразу же сказать: то что я буду делать не является MinWin-ом . Не является уже хотя бы потому, что настоящий MinWin содержит минимальный набор пользовательских (user mode) бинарников, я же собираюсь продемонстрировать полностью загруженное ядро (еще одно отличие — MinWin содержит минимальный набор драйверов, у меня же набор драйверов не меняется по сравнению с обычной загрузкой) вообще без пользовательского режима (ок, один процесс и одна dll-ка там все таки есть, но надо же хоть как то показать пользователю, что что-то происходит). Дополнительным поводом к размышлению может служить то, что настоящий MinWin появился в связи с работой по «расслоению» кода Windows 7, то же, что буду делать я в принципе возможно и на XP и даже на NT3.51

Итак, если вдумчиво прочитать то, что написано в предыдущем разделе, можно догадаться, что нам нужно заменить smss на такой, который не инициализирует подсистемы, но при этом все еще остается более-менее интерактивным. smss.exe — это обычный native процесс (приближенно, native приложение — это такое приложение, которое линкуется только с ntdll.dll и соотственно использует для работы только Native API). К счастью для меня Alex Ionescu — бывший главный разработчик ReactOS — уже написал подобное приложение в рамках (давно закрытого) проекта tinykrnl. Это приложение не собирается под amd64, не собирается на последнем WDK, имеет несколько багов, но в целом работает. Следующую картинку можно открыть архиватором — там содержатся исходники и скомпилированный amd64 бинарник небольшого приложения native.exe:

Прошу меня простить, но я не могу выложить готовый образ потому что это нелегально, поэтому выкладываю код, который может собрать vhd-образ из инсталляционного образа.
Следующий код можно исполнить ТОЛЬКО на Win7. Соханить его куда нибудь во временный каталог под именем, к примеру minwin.ps1, положить рядом install.wim (находится в каталоге \sources) c en-us инсталляционного диска Windows 7 (это важно — копируются только нужные для этой локализации NLS файлы), сохранить в этот каталог файл native.exe из прикрепленной выше картинки, перейти в этот самый каталог в elevated консоли и выполнить следующее:

Для краткости:
1. Рядом в одном каталоге должны лежать следующие файлы: minwin.ps1, install.wim и native.exe
2. Запускать minwin.ps1 нужно только после смены текущего каталога на каталог, содержащий вышеназванные файлы

Дисклеймер: все нижеследующее Вы делаете на свой страх и риск. Команды довольно очевидны и не должны нанести никакого вреда, но это «наколеночное» творчество, поэтому оно не обязано работать в любых условиях. Не выполняйте этот скрипт, если Вы не понимаете значение КАЖДОЙ команды (тем более, что выполнение должно производиться из-под повышенного пользователя). Если нет — ниже приведена картинка того, как это в конце концов выглядит. В упрощенном варианте можно просто переименовать native.exe в smss.exe, скопировать его поверх существующей smss.exe в уже загруженной виртуальной машине (подойдет любая x64 винда — от XP до 7) и перегрузиться.
Сам скрипт:

Выглядит это примерно так:

Если все сделано правильно (и при определенном везении :-) ), то через какое то время в том же каталоге появится файл disk.vhd — его можно запускать в виртуальной машине (тестировалось в VirtualBox, но не вижу причин, по которым это не должно работать в Virtual PC, Hyper-V или еще где нибудь):

Читайте также: