Страницы 1
Как и обещал, выкладываю тот самый пост.
Началом я этого треда является эта тема. Там было сказано несколько подобных вещей:
Режим Windows XP в Windows 7 Professional+ является ещё большим костылём, чем вайн, т.к. по сути содержит в себе запускаемую в среде Virtual PC копию Windows XP Professional, в то время, как Wine является лишь загрузчиком Win-приложений в среде *nix + набором библиотек, соответствующих виндовым.
Tiphon, насколько я знаю, в Win7 действительно используется виртуализация для совместимости с WinXP, или это не так?
Окей, давайте теперь я расскажу подробно, как и обещал.
Представим, что мы выпускаем новую версию своей операционной системы и ХОТИМ, чтобы программы написанные и отлаженные под старую версию работали под новой.
Почему-то, вспоминая про совместимость все обыччно говорят про API. На самом деле API - это только одна из частей изменений. Потому что меняется и структура, и службы, и политики безопасности и т.д.
Итак, у нас есть новая система. Мы составляем список изменений и прикидываем по каждому пункту: как это изменение может повлиять на работу старых программ и разрабатываем по этому пункту средства, позволяющие старым программам работать с изменившейся системой.
Разберем конкретный пример:
Допустим в ХР программа могла запущенная пользователем могла писать данные в файл
%ProgramFiles%\MyProgram\file.ini.А в висте и следующих системах у пользователя нет прав записи в папку %ProgramFiles%\MyProgram\file.ini,
Тогда вступает механизм под кличкой UAC Virtualization, который при попытке приложения записать данные в файл %ProgramFiles%\MyProgram\file.ini перенаправляет ее в специальную песочную директорию пользователя по адресу
%USER%\AppData\Local\VirtualStore\Program Files\MyProgram\file.ini
ВОТ - СПИСОК решений по части совместимости XP и Vista. Я ОЧЕНЬ ПРОШУ ПОСМОТРЕТЬ и полистать этот список прежде, чем читать дальше.
Отлично! Теперь вы представляете количество и уровень изменений. Средства для совместимости по этому можно разбить на 3 категории:
1) Implicit. Те, которые работают всегда и для всех. Это те средства, которые помогают старым программам работать, но не оказывают влияния на новые программы.
Раньше пользовательские данные лежали в папке %SYSDRIVE%\Documents and Settings, а в vista пользовательской папкой стала %SYSDRIVE%\Users. Тогда мы просто создаем ссылку Documents and Settings на новую папку Users. Эта ссылка никак не влияет на работу новых программ, но можем помогать старым программам.
2) Explicit. Те средства совместимости, которые могут оказать действия на новые программы, поэтому их надо включать для старых программ и отключать для новых программ.
К этой категории как раз относится API. Для совместимости API обычно используются надстройки/прослойки (layers) и shims, которые переводят вызовы нового формата в старые. Понятно, что вызов функции через любую прослойку будет априори медленнее прямого вызова функции, поэтому для новых программ вызовы должны идти без каких либо прослоек, а для старых - надо включать эти прослойки.
Стоит отметить, что этот раздел как раз и входит в то, что обычно включается выбором "Режим совместимости". Хотя некоторые вещи включаются автоматически по мере того, как программа пытается до них "дотянуться".
3) Manual. Настройки, которые делаются вручную. В этот пункт, например, входит установка и интеграция собственных shim библиотек в систему для какого-нибудь жутко специфического софта, который больше не выпускается (да, так бывает нужно и для этого есть средства) Вообще, можете погуглить (чего делать не будете, но все равно) на MS Application Compatibility Toolkit и почитать, как с ним работать.
Тут надо сказать, что БОЛЬШИНСТВО программ будут работать ИТАК. . Уже во времена XP рекомендации по написанию программ соответствовали рекомендациями для будущей Vista. Просто рекомендации, как обычно, можно не соблюдать...
Конечно, если что-то после изменений в системе не работает, можно было бы ПРОСТО, как с memcpy сказать, что это все проблемы тех, кто не помнит наизусть все спецификации... Но это не путь нормальных мантейнеров по отношению к тому, от чего зависит работа других людей.
Итак, в итоге у нас большинство приложений продолжают работать итак, не замечая перехода на новую систему. Мы выписали все изменения, у нас есть большой круг средств (хорошо документированный, надо сказать), который позволяет исправить проблемы остальных программ. Однако всегда остается почти непредсказуемое "стечение обстоятельств".... Что мы будем делать, если программа по некоему "стечению обстоятельств" все равно не работает?.. - Правильно! Как крайняя мера, мы возьмем какую-нибудь виртуальную машину, поставим на нее старую систему и запустим там эту программу.
Естественно, если нам надо запускать только одну программу, а виртуальная машина позволяет нам такую настройку - мы постараемся настроить ее так, чтобы присутствие самой виртуальной машины при запуске приложения выглядело минимально заметным. Угадайте, что дальше? - Именно так! Дя удобства, майкрософт и предлагает подготовленную, уже настроенную виртуальную машину для таких случаев.
Если у вас на столе стоит настоящий торт, а в витрине магазина стоит пластмассовый торт. Можно ли говорить, что "это СОВЕРШЕННО ОДИНАКОВЫЕ торты, просто один для еды, а второй - нет"?
Так же и тут, я надеюсь вы задумаетесь, где причина, а где - следствие. И какой ответ на вопрос "Но в витрине магазина я тоже видел такую штуку! Разве нет?"
Теперь уже всем совсем удачи!
Редактировался Tiphon (13-01-12 01:33:20)
Квантовая механика - "малопонятный математический курьёз" (с) msAVA - современный учитель.
Неактивен
Страницы 1