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

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

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

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

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

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

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

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

GetVersion
GetVersionEx

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

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

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

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