Кждый выпуск компанией Microsoft новой версии Windows, особенно начиная с Windows 2000, приносил с собой, с одной стороны, множество новинок, с другой — отбрасывал что-то старое. И это старое касалось в первую очередь обычных пользователей. Появление версии Windows 2000 вызвало проблемы совместимости со многими приложениями Windows 9x, версии Windows XP — проблемы с приложениями Windows 2000. Выпуски пакетов обновлений для Windows XP добавляли трудностей с уже существующими приложениями. А Windows Vista перевернула все с ног на голову. Однако на самом деле все не так плохо, как кажется. И во многих случаях даже лучше.
Несовместимость и ее причины
В статье мы рассмотрим возможности, благодаря которым можно совместить вроде бы несовместимое. Но для начала давайте разберемся, а в чем же все-таки проявляется эта несовместимость и каковы причины ее возникновения.
User account control
Одним из самых заметных нововведений в Windows Vista является механизм контроля учетных записей, или UAC. Этот механизм призван обеспечивать, прежде всего, безопасность как приложений пользователя, так и системы в целом. Несмотря на то что Microsoft настоятельно рекомендует пользователям не работать с правами локального администратора, а производителям программного обеспечения — не писать приложения так, чтобы они требовали административных прав, эта рекомендация не выполнялась. И разработчики Microsoft решили кардинально изменить механизм обеспечения безопасности, в результате появился механизм UAC. По большому счету ничего нового придумано не было. Программные интерфейсы для реализации подобных вещей существовали еще в Windows 2000. При работе с учетной записью обычного пользователя, чтобы запустить некое приложение с правами администратора, необходимо было воспользоваться утилитой runas. Однако это было не очень удобно, поскольку требовалось постоянно вводить пароль администратора.
В Vista все пользователи по умолчанию работают с ограниченными правами. Для пользователей, входящих в группы с администраторскими правами (их список приведен в таблице), при интерактивной регистрации в системе создается два маркера безопасности. Один из них — реальный маркер со всеми правами администратора. Из второго (назовем его «сокращенный» или «отфильтрованный») исключены повышенные привилегии администратора. Однако, если система решает, что приложению нужны повышенные права, она предлагает подтвердить необходимость повышения привилегий для конкретного приложения. В некоторых случаях система не может определить или неверно определяет эту самую необходимость — в таком случае ей нужно подсказать решение. Так или иначе, результат один — запрос на повышение привилегий. Единственное отличие члена привилегированных групп от обычного пользователя с этой точки зрения заключается в том, что администраторам не нужно повторно вводить свой пароль. Им достаточно нажать кнопку, согласившись предоставить приложению повышенные привилегии. У обычного пользователя будут запрошены имя и пароль учетной записи с правами администратора.
Это порождает первую проблему совместимости старых приложений с Windows Vista. Многим приложениям и программам установки нужны административные права для различных целей. В основном это доступ к системным папкам, замена системных файлов, изменение параметров реестра, установка служб и драйверов, создание глобальных объектов. Как видите, действия не совсем корректные в плане безопасности.
Здесь надо отметить, что проблема с доступом в системные области во многом решена благодаря виртуализации. То есть многие системные папки и критичные разделы реестра теперь «виртуализированы», в терминологии Microsoft. Я бы сказал просто — перенаправляются в папки профиля пользователя прозрачно для приложения, которое пытается это сделать. Существует два вида виртуализации. Первый — виртуализация файловой системы, второй — виртуализация реестра. При виртуализации файловой системы применяется драйвер-фильтр, в который жестко зашиты пути, которые виртуализируются системой, а это:
-
%ProgramFiles% (Program Files);
-
%AllUsersProfile% (теперь ProgramData — то, что когда то былоDocuments and SettingsAll Users);
-
%SystemRoot% (Windows);
-
%SystemRoot%System32 (WindowsSystem32).
При этом по умолчанию виртуализация не применяется к процессам, если для них выполняются такие условия:
-
процесс 64-разрядный;
-
в манифесте исполнимого файла есть параметр requestedExecutionLevel; большинство приложений Vista имеют такой манифест;
-
процесс запущен с правами администратора;
-
процессы, запущенные не из интерактивной графической сессии. Можно включить и выключить механизм виртуализации, используя глобальные политики (см. экран 1). Существуют некоторые исключения из правил. Виртуализация не применяется для исполнимых файлов с расширениями exe,.bat,.vbs,.scr и т. д. Идея состоит в том, чтобы при попытке доступа каких-либо приложений к таким файлам, в частности к системным файлам, система явно выдала вам сообщение «Доступ запрещен», чтобы сообщить о подобных попытках. Кроме того, дополнительные исключения, к которым не должна применяться виртуализация на основе расширений или путей, могут быть добавлены в реестре в раздел HKLMSystemCurrentControlSetServicesLuafvParametersExcludedExtensionsAdd.
Виртуализируется или не виртуализируется процесс, вы можете увидеть при помощи стандартного менеджера задач (см. экран 2).
А щелкнув правой кнопкой мыши на имени процесса, можно явно включить виртуализацию для него. Пример показан на экране 3.
В первом случае виртуализация для cmd.exe отключена по умолчанию. После включения виртуализации для процесса выполняемая командным файлом запись удается.
Отмечу также, что виртуализированные файлы не перемещаются вместе с перемещаемым профилем.
Виртуализация реестра работает иначе. По умолчанию виртуализируются подразделы в разделе HKLMSoftware, за исключением:
-
HKLMSoftwareMicrosoft Windows;
-
HMLMSoftwareMicrosoft Windows NT;
-
другие подразделы в разделе Microsoft
Реализация виртуализации также отличается. При работе с реестром дополнительные драйверы не используются. Механизм встроен в ядро операционной системы. Какие разделы виртуализировать, а какие нет, система определяет на основе флагов:
-
REG_KEY_DONT_VIRTUALIZE: отключить виртуализацию;
-
REG_KEY_DONT_SILENT_FAIL: если виртуализация отключена, выдавать access-denied вместо success;
-
REG_KEY_RECURSE_FLAG: переносить на подчиненные разделы.
Посмотреть эти разделы можно при помощи утилиты reg с параметром flags. Также при помощи этой утилиты можно изменять флаги разделов, тем самым включая их виртуализацию. Виртуализированные данные хранятся в реестре, в разделе HKEY_CURRENT_USERSoftwareClassesVirtualStore.
Говоря о виртуализации, нужно помнить, что невиртуализированные приложения могут не видеть виртуализированных данных. Если одно приложение виртуализируется и создает виртуализованные файлы, то приложение, не использующее виртуализацию, не сможет увидеть эти файлы и разделы реестра. Таким образом, этот механизм отчасти может сам по себе создавать несовместимость.
Microsoft настоятельно рекомендует разработчикам писать свои приложения так, чтобы не приходилось прибегать к принудительной виртуализации.
Символические ссылки
Следующая точка несовместимости появляется от того, что разработчики Microsoft стали активнее использовать символические ссылки, или junction points. Это объекты файловой системы, позволяющие добраться до одного и того же каталога двумя разными путями. Например, в Vista нет каталогов Documents and Settings и Default User. Теперь это каталогиUsers и UsersDefault. Однако для обеспечения совместимости с программами, которые явно пытаются использовать старые каталоги, вместо самих каталогов созданы символические ссылки со старыми именами, указывающие на новое расположение этих папок. То есть приложение, явно обратившееся по старому пути, без труда попадет в новое местоположение. Однако стоит обратить внимание на то, что в настройках доступа для таких ссылок явно запрещено перечисление содержимого. Соответственно попытка получить содержимое каталога по символической ссылке ничего не даст, хотя аналогичная команда в оригинальном каталоге выведет содержимое каталога как обычно. Это сделано для того, чтобы не сбивать с толку утилиты резервного копирования.
Session 0 isolation
Следующий механизм, который может вызвать проблемы в работе, — изоляция нулевой сессии, session 0 isolation. Сессия — это объект, содержащий процессы пользователя, их окна. Кроме того, сессия ассоциируется с объектом windows station, который в свою очередь инкапсулирует рабочий стол, мышь и клавиатуру. Нулевая сессия в прошлых версиях Windows была интерактивной, и именно в нее попадал первый интерактивно зарегистрировавшийся пользователь. В результате службы могли создавать окна и получать из окон сообщения, поскольку запускались в нулевой сессии. Поэтому приложения пользователя, а также шпионские программы могли посылать из окон сообщения окнам служб. Как следствие — возможные атаки при помощи сообщений из окон в случае некорректной реализации обработки данных в окнах. В Vista службы решили вынести в отдельную неинтерактивную сессию, правильнее было бы сказать — сессии пользователей отделили от сессии служб. Теперь создать окно в пользовательской сессии служба не может. И это довольно неудобно. Некоторые службы спрашивали у пользователя подтверждения неких действий, отображая окно. Теперь окно отобразится, однако пользователь его не увидит, поскольку оно создается на отдельном рабочем столе. Однако, так сказать, по многочисленным просьбам пользователей, разработчики все-таки обеспечили возможность попасть на этот рабочий стол и нажать кнопку. Обнаружив такое поведение службы, система предложит вам временно перейти на рабочий стол нулевой сессии и нажать на кнопочку. Однако не используйте приложений, которые так делают, это небезопасно.
Самые простые проблемы
Хотя существуют проблемы, которые кажутся простыми, они приносят больше всего неприятностей, поскольку с ними сложнее всего бороться. В нашем случае это проблемы с версиями различных компонентов системы и проверкой присутствия в различных группах.
Бывает так, что приложение или программа установки проверяют версию операционной системы или версию какого-либо ее компонента на каком-то этапе функционирования. В случае если обработка этих значений выполнена корректно, он просто генерирует ошибку или сообщение и продолжает дальше или предлагает пользователю сделать выбор. Но бывает и так, что приложение просто прекращает функционировать, закрывается. Это самое неприятное. О том, что можно сделать в таком случае, — несколько позже.
Похожая ситуация бывает, когда приложение проверяет наличие текущего пользователя в группе администраторов и в случае отсутствия прекращает работу. Вероятно, ему даже не нужны повышенные привилегии в системе, однако оно все равно не работает.
Следующей проблемой может стать некорректное использование рабочего стола. В Windows Vista был переделан механизм отрисовки объектов на рабочем столе. Раньше, каждый объект отрисовывался прямо в буфер экрана. Вследствие этого при зависании приложения и перемещении зависшего окошка по экрану возникали разного рода артефакты, портилось изображение. Теперь все объекты отрисовываются в специальный общий буфер, который затем выводится на экран. В результате система хранит изображение каждого объекта в своем буфере, и приложениям нет необходимости отрисовывать свои окна. Поэтому проблем с артефактами и порчей изображения больше не будет. Этот механизм называется Desktop Windows Manager, DWM (дополнительные сведения можно найти по адресу http://www.osp.ru/win2000/2007/02/4119369/index.html). Такой подход применяется, например, в Mac OS и работает полнофункционально только с активным интерфейсом Aero. Из-за таких изменений некоторые приложения, в частности использующие прозрачные окна или части окон, могут работать неверно. Чтобы избежать такого поведения, Microsoft предлагает использовать специфическую заглушку под названием DisableDWM. О том, как эти прослойки применять, будет рассказано далее.
Средства борьбы
Так что же делать, если приложение не работает? Хотя «еще вчера» оно работало под Windows XP или Windows 2000. Как быть, если это приложение критично для вашего бизнеса?
Microsoft прилагает много усилий для обеспечения совместимости со старыми программами. В частности, с этой целью и был создан специальный механизм обеспечения совместимости, shim engine. Сложно найти аналог этому термину на русском языке, поэтому назову его абстрактно механизмом заплаток или лучше механизмом прослоек, поскольку shim к «заплаткам», т. е. к исправлениям для операционной системы, отношения не имеет. Это специальная оболочка обеспечения совместимости, которая предоставляет пользователям механизмы, при помощи которых можно заставить несовместимые приложения корректно работать в последних версиях операционных систем. Эта оболочка работает в Windows XP и Windows Vista.
Прослойки
Работа с этими прослойками начинается еще на этапе работы загрузчика приложения. Загрузчик проверяет некоторые данные в заголовке исполнимого файла, такие как имя файла, производитель и некоторые другие, с целью идентификации приложения (см. экран 4).
По этим данным происходит поиск приложения в специализированной базе данных прослоек, расположенной в файле C:WINDOWSAppPatchsysmain.sdb. Это системная база, которая входит в поставку и Windows XP, и Windows Vista. Кроме того, она обновляется, используя Windows Update. Поиск также может производиться в базах, созданных пользователями при помощи специализированных утилит, которых мы коснемся ниже. Если это приложение найдено в одной из рабочих баз, инициализируется собственно оболочка совместимости, которая и применяет соответствующие прослойки к этому приложению.
Сами прослойки в большинстве своем представляют собой программные модули, которые эмулируют ожидаемое приложением поведение системы. Для работы они используют различные механизмы, такие как перехват функций API и перенаправление их в один из файлов вида Ac***.dll, содержащих дополнительную обработку или вообще заменяющих оригинальные функции. По словам разработчиков, бывает, что работа некоторых приложений зависит от ошибок в операционной системе. Когда эти ошибки исправляются с очередным обновлением, приложение может перестать работать. В таких случаях приходится эмулировать существовавшие ошибки, чтобы восстановить работоспособность приложения.
В системной базе прослоек в Windows XP SP3 по умолчанию содержится 1936 приложений. В Windows Vista SP1 эта база содержит 5649 поддерживаемых по умолчанию приложений.
Кроме приложений, в этой базе содержится список исправлений, в котором и лежат эти самые прослойки. В Windows XP их 221, а в Windows Vista 340. Также в базе присутствуют те самые режимы совместимости, compatibility modes, часть которых можно увидеть на одной из вкладок свойств исполнимого файла (см. экран 5). На самом деле их гораздо больше, чем отображается на этой вкладке — 18 и 43 для XP и Vista соответственно.
Андрей Вернигора (eosfor@gmail.com) — администратор баз данных и системный администратор на одном из предприятий компании «Укртранснафта». Имеет сертификат MCP
В настоящее время Application Compatibility Toolkit 5.0 можно скачать на сайте Microsoft по адресу http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E-492DD6DA2971&displaylang=en#filelist. Процесс инсталляции приложения стандартный, однако, кроме самого ACT, необходимо поставить утилиту Application Verifier, которую можно найти по адресу http://www.microsoft.com/downloads/details.aspx?familyid=C4A25AB9-649D-4A1B-B4A7-C9D8B095DF18&displaylang=en
Список административных групп :
Встроенная группа «Администраторы»
Администраторы сертификатов
Администраторы домена
Корпоративные администраторы
Администраторы политик
Администраторы схем
Контроллеры домена
Корпоративные контроллеры домена с доступом только для чтения
Контроллеры домена с доступом только для чтения
Оператлры учета
Операторы архива
Операторы шифрования
Операторы настройки сети
Операторы печати
Системные операторы
Серверы RAS
Опытные пользователи
Пред-Windows 2000 доступ