В этом выпуске мы познакомимся с нововведениями ОС Windows Vista в области управления памятью, а также с главными усовершенствованиями в области запуска системы, завершения работы и управления электропитанием (часть 1).

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

В ОС Windows Vista впервые представлены четыре новые технологии увеличения производительности: SuperFetch, ReadyBoost, ReadyBoot и ReadyDrive. Они будут подробно рассмотрены далее в этой статье.

Динамическое адресное пространство ядра

ОС Windows и приложения, выполняемые под ее управлением, сталкиваются с ограничениями адресного пространства 32-разрядных процессоров. Размер адресного пространства ядра ОС Windows по умолчанию ограничен значением 2 Гбайт (половина 32-разрядного виртуального адресного пространства). Вторая половина зарезервирована для использования процессом, выполняющимся в текущий момент на ЦП. На свою половину памяти ядро должно отобразить себя, драйверы устройств, кэш файловой системы, стеки ядра, структуры данных кода для каждого сеанса, а также невыгружаемые (заблокированные в физической памяти) и выгружаемые буферы, выделенные драйверами устройств. В операционных системах, предшествовавших ОС Windows Vista, диспетчер памяти распределял адресные пространства для перечисленных нужд в момент загрузки системы. Этот негибкий механизм приводил иногда к ситуациям, когда некоторые области адресного пространства оказывались исчерпанными, в то время как в других еще оставалось много свободного места. Нехватка адресного пространства в одной из областей может привести к сбоям в работе приложений и нарушить операции ввода-вывода, выполняемые драйверами устройств.

В 32-разрядной версии ОС Windows Vista диспетчер памяти динамически распределяет адресное пространство ядра, выделяя и освобождая адресное пространство с учетом потребностей текущей рабочей нагрузки. Таким образом, количество виртуальной памяти, используемое для хранения выгружаемых буферов, может увеличиваться, когда этого требуют драйверы устройств, и уменьшаться, когда драйверы устройств освобождают память. Это позволяет ОС Windows Vista поддерживать более широкий диапазон рабочих нагрузок, а 32-разрядная версия следующего выпуска ОС Windows Server® (кодовое название «Longhorn») сможет поддерживать больше одновременно работающих пользователей сервера терминалов.

Конечно, в 64-разрядной версии ОС Windows Vista пределы адресных пространств не представляют практических ограничений, поэтому они не требуют каких-либо особых мер и установлены на максимальные значения.

Приоритеты памяти

Помимо приоритетов ввода-вывода (которые обсуждались в предыдущем выпуске), в ОС Windows Vista появились также и приоритеты памяти. Чтобы понять, как система использует приоритеты памяти, нужно разобраться, как в диспетчере памяти реализован кэш памяти, называемый списком ожидания (Standby List). Во всех версиях ОС Windows, предшествовавших Windows Vista, физическая страница, затребованная системой у приложения (размер страницы обычно составляет 4 Кбайт), помещалась диспетчером памяти в конец списка ожидания. Если процессу снова требовался доступ к этой странице, диспетчер памяти извлекал ее из списка ожидания и вновь назначал процессу. Если процессу требовалась новая страница физической памяти, но свободной памяти не было, диспетчер памяти отдавал процессу страницу из начала списка ожидания. В такой схеме все страницы в списке ожидания были равнозначны, и порядок страниц определялся только временем их помещения в список.

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

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

Функция SuperFetch

Среди существенных изменений в работе диспетчера памяти – изменение способа управления физической памятью. У способа управления на основе списка ожидания, который использовался в предыдущих версиях ОС Windows, есть два ограничения. Во-первых, приоритет страниц определяется только на основании предшествующего поведения процессов без предсказания возможных будущих требований процессов к памяти. Во-вторых, определение приоритета осуществляется только на основании списка страниц памяти, которыми процесс владеет в конкретный момент времени. Эти недостатки могут привести к таким последствиям, как «послеобеденный синдром», когда пользователь оставляет на некоторое время свое рабочее место, и на компьютере запускается системное приложение, интенсивно работающее с памятью (например, выполняется сканирование диска антивирусом или производится дефрагментация диска). Работа такого приложения приводит к тому, что данные пользовательских приложений, которые находились в кэше, оказываются перезаписанными. Вернувшись на рабочее место, пользователь в течение некоторого времени страдает от низкой производительности, поскольку приложения запрашивают свои данные и код с диска.

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

Функция SuperFetch реализована в библиотеке %SystemRoot%\System32\Sysmain.dll; она выполняется в качестве службы Windows внутри процесса Service Host (%SystemRoot%\System32\Svchost.exe). Благодаря поддержке со стороны диспетчера памяти эта схема позволяет службе получать историю обращений к страницам памяти и отдавать диспетчеру памяти указания по предварительной загрузке данных или кода из файлов на диске или из файла подкачки в список ожидания, а также присваивать приоритет страницам памяти. Служба SuperFetch существенно расширяет отслеживание страниц памяти, учитывая страницы, которые были ранее загружены в память, но впоследствии освобождены диспетчером памяти для других данных и кода. Эта информация хранится в папке %SystemRoot%\Prefetch в виде файлов сценариев с расширением «.db» вместе со стандартными файлами упреждающего чтения, используемыми для оптимизации запуска приложений. Располагая подробной информацией об использовании памяти, служба SuperFetch может осуществлять предварительную загрузку данных и кода при освобождении физической памяти.

Когда освобождается память (например, при завершении работы приложения или когда приложение освобождает выделенную память), служба SuperFetch дает диспетчеру памяти инструкцию загрузить недавно выгруженные данные и код. Эта процедура осуществляется со скоростью в несколько страниц в секунду с приоритетом ввода-вывода «Very Low» (очень низкий), поэтому предварительная загрузка не мешает работе пользовательских и других активных приложений. Благодаря этому, когда пользователь оставляет свое рабочее место на время обеденного перерыва, и фоновые задачи, интенсивно работающие с памятью, приводят к выгрузке страниц памяти активных пользовательских приложений, службе SuperFetch зачастую удается вернуть большинство страниц в память еще до того, как пользователь вернется на рабочее место. У службы SuperFetch есть также специальные сценарии поддержки гибернации, ждущего режима, быстрого переключения пользователей (FUS) и запуска приложений. Например, когда система переходит в режим гибернации, служба SuperFetch сохраняет в файле гибернации данные и код, доступ к которым вероятнее всего потребуется после загрузки системы, с учетом истории предыдущих переходов в режим гибернации. В случае возобновления работы ОС Windows XP из режима гибернации при обращении к данным, находившимся в кэше до перехода в режим гибернации, необходимо было заново считывать эти данные с диска.

На врезке «Наблюдение за службой SuperFetch» представлены краткие результаты влияния службы SuperFetch на объем доступной памяти.

Наблюдение за службой SuperFetch

После работы в течение некоторого времени в ОС Windows Vista пользователь может заметить, что на вкладке «Быстродействие» диспетчера задач показатель свободной физической памяти становится невысоким. Это объясняется тем, что служба SuperFetch и стандартное кэширование Windows используют всю доступную физическую память для кэширования данных с диска. Например, если сразу после загрузки системы открыть диспетчер задач, можно заметить, что показатель свободной памяти уменьшается, в то время как показатель кэшированной памяти увеличивается. Если запустить приложение, использующее для работы большой объем памяти, а затем завершить его работу (подойдет любой бесплатный «оптимизатор памяти», который выделяет большое количество памяти и затем освобождает ее), или просто скопировать очень большой файл, показатель свободной памяти возрастет, и на графике использования физической памяти будет наблюдаться падение по мере того, как в систему возвращается освобожденная память. Однако через некоторое время служба SuperFetch снова заполнит кэш данными, которые были вытеснены из памяти, и показатель кэшированной памяти возрастет, а показатель свободной памяти уменьшится.

Функция ReadyBoost

Скорость работы ЦП и памяти гораздо выше скорости работы жесткого диска, из-за чего жесткие диски часто являются узким местом для производительности системы. Операции произвольного дискового ввода-вывода особенно сильно влияют на производительность, потому что время позиционирования головок жестких дисков (порядка 10 мс) – это вечность для современных процессоров с тактовой частотой 3 ГГц. Хотя оперативная память идеально подходит для кэширования дисковых данных, ее стоимость сравнительно высока. Флэш-память обычно дешевле оперативной памяти, при этом время произвольного доступа у флэш-памяти может быть на порядок меньше, чем у жесткого диска. Поэтому в ОС Windows Vista добавлена функция под названием ReadyBoost, которая позволяет воспользоваться преимуществами запоминающих устройств на основе флэш-памяти, создавая на них промежуточный уровень кэширования, логически расположенный между оперативной памятью и жесткими дисками.

Функция ReadyBoost состоит из службы, реализованной в файле %SystemRoot%\System32\Emdmgmt.dll, которая выполняется в процессе Service Host, и драйвера фильтра томов %SystemRoot%\System32\Drivers\Ecache.sys (EMD – это сокращение от рабочего названия функции ReadyBoost «External Memory Device» (внешнее устройство памяти), которое использовалось в процессе ее разработки). При подключении запоминающего устройства флэш-памяти к компьютеру служба ReadyBoost определяет производительность этого устройства и записывает результат в раздел реестра HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Emdmgmt, как показано на рис. 1.

Если объем памяти устройства от 256 МБ до 32 ГБ, скорость передачи для произвольных операций чтения блоками по 4 КБ превышает 2,5 МБ/с, скорость передачи для произвольных операций записи блоками по 512 КБ превышает 1,75 МБ/с, и это устройство еще не используется для кэширования, служба ReadyBoost предложит выделить до 4 ГБайт памяти этого устройства для кэширования дисков. (Хотя служба ReadyBoost может работать с разделами NTFS, максимальный объем кэша ограничен 4 ГБ для совместимости с файловой системой FAT32). Если пользователь соглашается, служба создает в корневой папке устройства файл кэша с именем ReadyBoost.sfcache и отдает службе SuperFetch указание заполнить кэш в фоновом режиме.

После инициализации кэширования службой ReadyBoost драйвер устройства Ecache.sys перехватывает все обращения чтения и записи к локальным жестким дискам (например, диску C:\) и копирует записываемые данные в созданный службой файл кэширования. Драйвер Ecache.sys осуществляет сжатие данных, достигая обычно степени сжатия 2:1, поэтому кэш объемом 4 ГБ, как правило, содержит около 8 ГБ данных. Драйвер шифрует каждый записываемый блок с помощью ключа сеанса, генерируемого случайным образом при каждой загрузке системы; при этом используется алгоритм AES. Шифрование обеспечивает конфиденциальность данных, содержащихся в кэше, на случай извлечения устройства.

Если служба ReadyBoost определяет, что осуществляется произвольное чтение данных, и эти данные есть в кэше, данные извлекаются из кэша. Но ввиду того, что у жестких дисков скорость последовательного чтения выше, чем у флэш-памяти, операции последовательного чтения осуществляются непосредственно с диска, даже если эти данные есть в кэше.

Функция ReadyBoot

Если в системе установлено менее 512 МБ оперативной памяти, механизм упреждающего чтения при загрузке ОС Windows Vista не отличается от механизма, использовавшегося при загрузке ОС Windows XP. Если же размер оперативной памяти превышает 700 МБ, то для оптимизации процесса загрузки используется кэш в ОЗУ. Размер этого кэша зависит от общего объема доступной памяти; он достаточно велик, чтобы обеспечить эффективное кэширование, но оставляет при этом достаточно свободной памяти для нормального выполнения процедуры загрузки системы.

После каждой загрузки системы служба ReadyBoost (та же самая служба, которая реализует описанную выше функцию ReadyBoost) в моменты простоя ЦП планирует кэширование для следующей загрузки системы. Она анализирует информацию об обращениях к файлам за пять предыдущих загрузок и определяет, к каким файлам производились обращения, и где эти файлы расположены на диске. Обработанная информация об обращениях сохраняется в папке %SystemRoot%\Prefetch\Readyboot в виде файлов с расширением «.fx», а план кэширования сохраняется в разделе реестра HKLM\System\CurrentControlSet\Services\Ecache\Parameters в виде значений типа REG_BINARY с именами, соответствующими именам внутренних дисков.

Кэширование реализуется с помощью того же драйвера, что и в функции ReadyBoost (драйвер Ecache.sys), но управление заполнением кэша во время загрузки осуществляется службой ReadyBoost. Хотя кэш загрузки сжимается так же, как и кэш ReadyBoost, есть еще одно отличие между управлением кэшем в функциях ReadyBoost и ReadyBoot. В отличие от функции ReadyBoost, в режиме ReadyBoot содержимое кэша не изменяется при операциях чтения и записи, а определяется только обновлениями, вносимыми службой ReadyBoost. Служба ReadyBoost удаляет кэш через 90 секунд после начала загрузки или в случае, если требуется дополнительная оперативная память. Статистика использования кэша записывается в раздел реестра HKLM\System\CurrentControlSet\Services\Ecache\Parameters\ReadyBootStats, как показано на рис. 2. Измерение производительности, проведенное в корпорации Майкрософт, показало, что при использовании функции ReadyBoot производительность увеличивается примерно на 20 процентов по сравнению с технологией упреждающего чтения, используемой при загрузке ОС Windows XP.

Функция ReadyDrive

ReadyDrive – это функция ОС Windows Vista, использующая возможности новых гибридных жестких дисков (дисков H-HDD). Гибридный жесткий диск представляет собой жесткий диск со встроенной энергонезависимой флэш-памятью (известной также под названием NVRAM). Как правило, гибридные жесткие диски содержат от 50 МБ до 512 МБ кэш-памяти, но ОС Windows Vista поддерживает кэши размером до 2 ТБ.

Чтобы определить, какие данные следует поместить во флэш-память, ОС Windows Vista использует команды ATA-8. Например, при завершении работы система сохраняет в этом кэше данные для загрузки, что позволяет ускорить следующий запуск системы. При переходе в режим гибернации в кэше сохраняются некоторые части файла гибернации, что ускоряет возобновление работы. Поскольку кэш активен даже когда диск остановлен, система может использовать флэш-память для кэширования записи на диск, что позволяет не раскручивать диск, если компьютер питается от аккумулятора. Остановка диска позволяет существенно снизить энергопотребление по сравнению с обычным режимом работы.

База данных конфигурации загрузки

В ОС Windows Vista усовершенствовано несколько аспектов процедур загрузки и завершения работы. Улучшение процедуры загрузки достигается благодаря следующим нововведениям: использование базы данных конфигурации загрузки (BCD), в которой хранится конфигурация запуска системы и ОС; новая последовательность и организация процесса загрузки системы; новая архитектура входа в систему, а также поддержка служб с отложенным автозапуском. Усовершенствования процесса завершения работы в ОС Windows Vista включают уведомление служб Windows перед завершением работы, упорядочение завершения работы служб и существенно переработанное управление переходами между режимами энергопотребления в операционной системе.

Одним из самых заметных изменений процесса загрузки системы является отсутствие файла Boot.ini в корневой папке системного тома. Это объясняется тем, что конфигурация загрузки, которая раньше хранилась в этом файле, теперь хранится в базе данных BCD. Одной из причин использования базы данных BCD в ОС Windows Vista является объединение двух поддерживаемых в ОС Windows архитектур загрузки: основной загрузочной записи (MBR) и расширяемого интерфейса микропрограмм (EFI). Загрузочная запись MBR обычно используется на компьютерах с архитектурами x86 и x64, а интерфейс EFI – в системах Itanium (хотя в ближайшем будущем, вероятно, будут поставляться и рабочие станции с поддержкой EFI). Использование базы данных BCD позволяет абстрагироваться от микропрограмм и обеспечивает ряд дополнительных преимуществ по сравнению с использованием файла Boot.ini, например поддержку строк в формате Юникод и поддержку исполнения альтернативных предзагрузочных программ.

Фактически база данных BCD хранится на диске в кусте реестра, загружаемом в реестр ОС Windows для доступа с помощью программных интерфейсов реестра. На платформах PC она хранится в файле \Boot\Bcd на системном томе. На системах EFI база данных хранится в системном разделе EFI. После загрузки куста он появляется в разделе реестра HKLM\Bcd00000000. Внутренний формат этой базы данных не документируется, поэтому для ее редактирования используются специальные инструменты, например программа %SystemRoot%\System32\Bcdedit.exe. Для поддержки сценариев и специализированных редакторов доступны интерфейсы для управления базой данных BCD с помощью инструментария WMI. Изменять и добавлять основные параметры, такие как команды отладки ядра, можно также с помощью программы настройки системы (%SystemRoot%\System32\Msconfig.exe).

Параметры загрузки, относящиеся ко всей платформе, например выбор ОС по умолчанию и время задержки меню загрузки, отделены в базе данных BCD от параметров, относящихся к конкретным операционным системам, таких как параметры загрузки ОС и путь к системному загрузчику. Если запустить программу Bcdedit без параметров командной строки, сперва в разделе «Windows Boot Manager» будут выведены параметры, относящиеся к платформе, а затем в разделе «Windows Boot Loader» – параметры для конкретной ОС, как показано на рис. 3.

Во время загрузки установленной ОС Windows Vista новая схема загрузки разделяет задачи, выполнявшиеся в более ранних версиях ОС Windows одним системным загрузчиком Ntldr, между двумя программами – \BootMgr и %SystemRoot%\System32\Winload.exe. Программа BootMgr считывает базу данных BCD и отображает меню загрузки операционной системы, а программа Winload.exe осуществляет загрузку операционной системы. При «чистой» загрузке системы программа Winload.exe загружает драйверы устройств, необходимые для запуска системы, и основные файлы операционной системы, включая ядро Ntoskrnl.exe, а затем передает управление операционной системе. В случае возобновления работы из режима гибернации программа Winload.exe запускает программу %SystemRoot%\System32\Winresume.exe для загрузки данных из файла гибернации в оперативную память и возобновления работы ОС.

Загрузчик Bootmgr также поддерживает исполнение дополнительных предзагрузочных программ. В составе ОС Windows Vista поставляется программа диагностики оперативной памяти (\Boot\Memtest.exe), которая уже включена в меню загрузки. Сторонние разработчики могут добавлять собственные предзагрузочные программы, которые будут отображаться в меню загрузки Bootmgr.

Процесс загрузки системы

В предыдущих версиях ОС Windows взаимосвязь между различными системными процессами не была очевидной. Например, в процессе загрузки системы диспетчер интерактивного входа в систему (%SystemRoot%\System32\Winlogon.exe) запускал службу подсистемы локального администратора безопасности (Lsass.exe) и диспетчер управления службами (Services.exe). Далее система использовала контейнер пространств имен (сеанс) для изоляции процессов, запущенных в различных сеансах входа в систему. Однако в операционных системах, предшествовавших ОС Windows Vista пользователь, вошедший в консоль, использовал сеанс 0, в котором работают и системные процессы. Это создавало потенциальную угрозу для безопасности. Примером такой угрозы стала одна плохо написанная служба Windows, работавшая в сеансе 0 и отображавшая пользовательский интерфейс в интерактивной консоли, позволяя вредоносным программам атаковать окно этой службы методом «подрывной атаки» (shatter attack), получая административные привилегии.

Для устранения подобных проблем в ОС Windows Vista было реструктурировано несколько системных процессов. Диспетчер сеансов (Smss.exe) – это первый процесс пользовательского режима, запускаемый во время загрузки, как и в предыдущих версиях ОС Windows. Однако в ОС Windows Vista диспетчер сеансов запускает еще одну свою копию для настройки сеанса 0, который выделен исключительно для системных процессов. Процесс диспетчера сеансов для сеанса 0 запускает приложение инициализации Windows (Wininit.exe), процесс подсистемы Windows (Csrss.exe) для сеанса 0, а затем завершает свою работу. Далее приложение инициализации Windows запускает диспетчер управления службами, подсистему локального администратора безопасности и новый процесс – диспетчер локальных сеансов (Lsm.exe), который управляет сеансами терминального сервера на этом компьютере.

Когда пользователь входит в систему, первоначально запущенный диспетчер сеансов запускает еще одну свою копию для настройки нового сеанса. Вновь запущенный процесс Smss.exe запускает процесс подсистемы Windows и процесс Winlogon для нового сеанса. На рабочей станции запуск диспетчером сеансов собственных копий для инициализации каждого нового сеанса не дает никаких преимуществ. Но в случае работы на сервере Windows Server «Longhorn», выступающем в роли терминального сервера, копии диспетчера будут работать одновременно, обеспечивая более быстрый вход в систему нескольких пользователей.

В новой архитектуре все системные процессы, включая службы Windows, изолированы в сеансе 0. Если служба Windows, запущенная в сеансе 0, отображает пользовательский интерфейс, служба обнаружения интерактивных служб (%SystemRoot%\System32\UI0Detect.exe) запускает собственную копию в контексте безопасности любого выполнившего вход администратора и выводит сообщение, показанное на рис. 4. Если администратор принимает предложение просмотреть сообщение, служба выполняет переключение рабочего стола на рабочий стол служб Windows, где администратор получает доступ к пользовательскому интерфейсу службы, а затем переключается назад на свой рабочий стол. На врезке «Просмотр отношений между процессами загрузки» можно более подробно ознакомиться с тем, что происходит во время загрузки системы.

Просмотр отношений между процессами загрузки

Для просмотра дерева загрузки процессов ОС Windows Vista можно воспользоваться программой Process Explorer от компании Sysinternals (microsoft.com/technet/sysinternals).

На снимке экрана присутствует столбец Session (Сеанс), который можно добавить с помощью диалогового окна выбора столбцов в программе Process Explorer. Выделен первоначальный процесс Smss.exe. Ниже него в сеансе 0 находятся процессы Csrss.exe и Wininit.exe, выровненные по левому краю, потому что их родительский процесс, экземпляр процесса Smss.exe, выполнивший настройку сеанса 0, завершил свою работу. Три дочерних процесса, порожденные процессом Wininit.exe – Services.exe, Lsass.exe и Lsm.exe.

Также в программе Process Explorer виден ряд процессов, запущенных в сеансе 1. Это сеанс, вход в который выполнен пользователем с помощью подключения к удаленному рабочему столу. Процессы, запущенные в рамках одной учетной записи с программой Process Explorer, выделены синим цветом. Наконец, сеанс 2 был инициализирован для подготовки к консольному входу пользователя в систему и созданию нового сеанса входа. Именно в этом сеансе запущен процесс Winlogon, использующий процесс LogonUI, чтобы предложить пользователю нажать сочетание клавиш Ctrl+Alt+Delete для входа в систему, и в которой процесс Logonui.exe затем попросит пользователя ввести свои учетные данные.

Поставщики учетных данных

Архитектура процесса входа в систему также поменялась в ОС Windows Vista. В предыдущих версиях ОС Windows процесс Winlogon загружал указанную в реестре динамическую библиотеку GINA, которая отображала пользовательский интерфейс для входа в систему, запрашивающий у пользователей ввод учетных данных. К сожалению, в модели GINA есть ряд ограничений: может быть использована только одна библиотека GINA; разработка полнофункциональной библиотеки GINA сложна для сторонних разработчиков; сторонние библиотеки GINA с нестандартным пользовательским интерфейсом меняют привычное взаимодействие с пользователем.

Вместо модели GINA в ОС Windows Vista используется архитектура поставщиков учетных данных. Процесс Winlogon запускает отдельный процесс – сервер пользовательского интерфейса входа в систему (Logonui.exe), который выполняет загрузку поставщиков учетных данных, настроенных в разделе реестра HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Authentication\Credential Providers. Процесс Logonui может работать с несколькими поставщиками учетных данных одновременно. ОС Windows Vista поставляется с двумя поставщиками учетных данных: интерактивным поставщиком (Authui.dll) и поставщиком смарт-карт (Smart-cardcredentialprovider.dll). Для унификации взаимодействия с пользователем процесс LogonUI управляет пользовательским интерфейсом, который видят конечные пользователи. Он также позволяет поставщикам учетных данных добавлять собственные отображаемые элементы, такие как текст, значки и поля ввода.

Службы с отложенным автозапуском

Пользователь, выполнивший вход в систему сразу после ее запуска, как правило, сталкивается с некоторой задержкой, прежде чем завершится настройка рабочего стола и можно будет свободно взаимодействовать с оболочкой системы и запускаемыми приложениями. Это происходит из-за того, что во время входа пользователя в систему диспетчер управления службами запускает множество служб Windows, настроенных как службы с автоматическим запуском и активируемые в процессе загрузки системы. Многие службы при инициализации выполняют операции, интенсивно потребляющие вычислительные и дисковые ресурсы, что приводит к замедлению процессу входа пользователя в систему. Для борьбы с этой проблемой в ОС Windows Vista введен новый тип запуска служб – отложенный автоматический запуск. Этот режим могут использовать службы, которые не обязаны быть активными сразу после загрузки системы.

Диспетчер управления службами запускает службы, настроенные на отложенный автоматический запуск, только после завершения запуска всех служб, настроенных на автоматический запуск. Диспетчер устанавливает первоначальному потоку таких служб приоритет THREAD_PRIORITY_LOWEST (наинизший приоритет потока). Установка такого приоритета приводит к тому, что все операции ввода-вывода, выполняемые потоком, выполняются с приоритетом «Very Low» (очень низкий). Когда служба завершает инициализацию, диспетчер управления службами устанавливает ей приоритет «Normal» (обычный). Сочетание отложенного запуска, низкого приоритета использования ЦП и памяти, а также фонового приоритета дисковых операций приводит к существенному снижению воздействия запуска таких служб на процесс входа пользователя в систему. Многие службы Windows, включая фоновую интеллектуальную службу передачи (BITS), клиент Windows Update и службу Windows Media® Center, используют этот метод запуска для увеличения производительности процесса входа в систему сразу после загрузки.

Завершение работы

Одна из проблем, с которыми сталкивались разработчики служб Windows, состоит в том, что по умолчанию у службы есть не более 20 секунд на завершение работы. В операционных системах Windows, предшествовавших ОС Windows Vista, не поддерживалось «чистое» завершение работы, при котором система дожидалась бы полного завершения работы всех служб, потому что в этом случае ошибка в службе могла бы полностью воспрепятствовать завершению работы системы. Некоторым службам, которым при завершении работы необходимо выполнить определенные сетевые операции или сохранить большой объем данных на диск, может потребоваться более продолжительное время для завершения работы, поэтому ОС Windows Vista позволяет службам запросить у системы уведомление о завершении работы.

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

Служба управления групповыми политиками и служба Windows Update используют еще одну возможность управления службами в ОС Windows Vista – упорядочение завершения работы. В предыдущих версиях ОС Windows можно было указать зависимости служб при запуске, и диспетчер управления службами придерживался указанного порядка запуска служб, но только в ОС Windows Vista появилась возможность указать зависимость служб при завершении работы. В ОС Windows Vista службы, которые регистрируют запрос уведомления о завершении работы, могут также включить себя в список, хранящийся в разделе реестра HKLM\System\CurrentControlSet\Control\PreshutdownOrder, и при завершении работы служб диспетчер управления службами будет завершать их работу в указанном порядке. Подробнее об этих возможностях см. врезку «Определение службы с отложенным автозапуском и службы с уведомлением о завершении работы».

Управление электропитанием

Режимы сна и гибернации также являются способами завершения работы, и ошибки в управлении электропитанием в драйверах и приложениях часто становились причиной серьезных проблем для работающих в дороге людей с тех пор, как в ОС Windows 2000 впервые в линейке ОС на базе Windows NT® появилось управление электропитанием. Закрывая крышку ноутбука перед поездкой, пользователи ожидают, что система перейдет в ждущий режим или в режим гибернации. Однако, прибыв на место, многие из них обнаруживали вместо этого горячий чемодан, севший аккумулятор и потерянные данные. Это происходило потому, что ОС Windows всегда запрашивала у приложений и драйверов устройств согласие на переход в другой режим энергопотребления, и одного драйвера или приложения, не отвечающего на запросы, было достаточно, чтобы воспрепятствовать этому переходу.

В ОС Windows Vista диспетчер управления электропитанием, входящий в ядро системы, по прежнему уведомляет драйверы и приложения о смене режима энергопотребления, позволяя им подготовиться к переходу в другой режим. Однако теперь ядро не спрашивает у них разрешения. Более того, диспетчер управления электропитанием ждет ответа приложений не более 20 секунд, а не 2 минуты, как это было в предыдущих версиях ОС Windows. В результате пользователи ОС Windows Vista могут быть уверены в том, что система действительно перейдет в ждущий режим или режим гибернации.

Что дальше

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

Определение службы с отложенным автозапуском и службы с уведомлением о завершении работы

Обновленная встроенная команда SC в ОС Windows Vista показывает службы, настроенные для отложенного автозапуска:

К сожалению, команда SC не выводит список служб, запросивших уведомление о завершении работы. Чтобы узнать, запросила ли служба уведомление о завершении работы, можно воспользоваться программой PsService от компании Sysinternals:

Автор: Марк Руссинович

Марк Руссинович – член технического совета (Technical Fellow) подразделения платформ и служб (Platform and Services Division) корпорации Майкрософт. Он является одним из авторов книги «Microsoft Windows Internals» («Внутренняя структура ОС Microsoft Windows»), вышедшей в издательстве Microsoft Press в 2004 г., и часто выступает на конференциях для IT-специалистов и разработчиков. Марк Руссинович пришел в корпорацию Майкрософт после недавнего приобретения корпорацией компании Winternals Software, одним из основателей которой он являлся. Он также создал веб-ресурс Sysinternals, на котором опубликовал программы Process Explorer, Filemon и Regmon.