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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

GetVersion 
GetVersionEx 

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

I Угадай, проблема в том, эффективно нарушается.

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

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