Виртуализация Legacy API и сосуществование с более современным API?

Question

Я не хочу, чтобы этот вопрос был пламенной приманкой, но я буду использовать Microsoft и их win32 API в качестве примера устаревшего API.

Теперь меня интересует то, что Microsoft тратит много своих денег и энергии на поддержание своего устаревшего API, включая все «глюки / ошибки / обходные пути», которые необходимы для того, чтобы API функционировал одинаково. Теперь я знаю, что в Windows 7 они предоставляют клиенту возможность запускать свое приложение на виртуальной машине «Windows XP», что было бы для них одним из способов начать очистку своего win32 API, потому что они могли бы затем вытолкнуть все приложение в виртуальную машину "Windows XP".

Итак, что меня интересует, так это то, можно ли виртуализировать устаревший API таким образом, чтобы клиент / программа все еще мог получить к нему доступ и использовать его, но в то же время иметь возможность использовать преимущества более новой версии / API ? Потому что, насколько я понимаю, если приложение запускается на виртуальной машине "Windows XP", оно не сможет получить доступ к какой-либо более новой API / функции Windows 7.

Answer 1

Что меня удивляет в этом вопросе, так это то, что Windows занимается этим с тех пор, как NT появилась в середине девяностых. Так NT запускает программы для DOS и Win16 и всегда так делает. Уровень виртуализации NTVDM запускает 16-разрядные приложения под Win32 с очень небольшой специальной поддержкой со стороны базовой ОС. Это только один пример, другой - это WINE, который, насколько я понимаю, выполняет довольно разумную работу по запуску приложений для Windows поверх набора API, который сильно отличается от Windows. Так что это определенно возможно.

Более актуальным вопросом было бы, почему Microsoft рассмотрела бы это. Чтобы вы думали, что это необходимо, вы должны думать о двух вещах. 1) Есть что-то лучше заменить Win32 API и 2) Поддержка Win32 API - это бремя.

Оба из них сомнительны. В случае обязанностей ядра, таких как доступ к оборудованию, а также синхронизация и выполнение потоков, процессов и памяти, Win32 API выполняет довольно хорошую работу и в конечном итоге довольно близко к тому, что на самом деле делает ядро. Если вы думаете, что есть лучший API, то это должно означать, что есть и лучшее ядро. Лично я не думаю, что NT нуждается в замене прямо сейчас. Для графики и управления окнами gdi32 немного длиннее в зубе. Но Microsoft решила эту проблему, создав WPF прямо рядом с ним. Это тогда приводит к бремени вопроса. Конечно, есть два API, которые нужно поддерживать, но если вы виртуализируете GDI поверх WPF, вам все равно придется поддерживать оба API, так что в этом нет никакой выгоды. Преимущество параллельной работы обоих заключается в том, что GDI уже существует и уже протестирован. Все, что вам нужно сделать, - это исправить случайную ошибку, тогда как новый уровень виртуализации придется писать и тестировать заново, что отнимает время на то, чтобы сделать WPF лучше.

С точки зрения поддержки бэк-компата, это не такая большая нагрузка, как кажется. Это в основном тестовый вопрос - вы должны проверить, что поведение API не меняется, но опять же - эти тесты уже написаны, так что на самом деле это не какая-то дополнительная работа.

Итак, чтобы ответить на вопрос вопросом, зачем они беспокоятся?

Answer 2

Это интересный вопрос, по крайней мере для меня, вот некоторые из моих мыслей.

Ваше понимание верно, приложение, работающее на виртуальной машине XP, имеет доступ только к API Win32, предоставляемым XP на виртуальной машине. Один из многих способов, которыми я видел подход Microsoft к расширению определенных API, заключается в создании новых функций с расширенной / фиксированной функциональностью и присвоении новой функции имени, добавляя Ex и даже ExEx к исходному имени, например

GetVersion
GetVersionEx

Для функций, которые принимают указатели на структуры, структуры «версионируются» с использованием размера структуры для определения требуемой функциональности, поэтому старый код будет передавать предыдущий размер структуры, в то время как более новый код будет передаваться в более новая более крупная структура и функции API соответственно.

I догадываюсь , проблема заключается в том, что это уже не просто различия в том, как работает API, а в большей степени интеграция в функционирование операционной системы и внутренних структур, которые имеют достаточно значительные изменения, что, вероятно, плохо написанный код эффективно нарушен.

Что касается вашего настоящего вопроса, я думаю, это было бы довольно сложно. Даже если подумать, что ОС сможет отрегулировать, как она выполняет код на основе целевой версии ОС в заголовке PE исполняемого файла, что произойдет, если в процесс, нацеленный на последнюю ОС, будет загружена более новая библиотека DLL, как теперь ОС? справиться с этим, когда код выполняется? ИМХО, я думаю, что это будет очень сложно, из-за ловушек, которые в конечном итоге потерпят неудачу.

Конечно, это только мои грубые мысли по этой теме, поэтому я могу ошибаться на 100%, и есть простой подход, который просто не приходит в голову.