Почему 64-битная ОС не может запустить 16-битное приложение?

38

Почему это так:

32-разрядная ОС, установленная на 64-разрядном процессоре, может запускать старые 16-разрядные приложения,
но если вы устанавливаете 64-битную ОС, она не может запускать эти приложения напрямую и нуждается в какой-то эмуляции (это не всегда работает идеально)?

Если быть более точным, у меня есть 64-разрядный процессор (Intel Core 2 Duo). Когда у меня были установлены Windows XP и Windows 7 (обе 32-битные), они могли запускать старые приложения для DOS и 616-битные Windows.

Теперь я установил 64-разрядную версию Windows 7. Почему она больше не может запускать те же приложения?

— fixer1234
источник

3

Я думаю, что это связано не столько с битами, сколько с гостевой операционной системой. На какие ОС вы конкретно ссылаетесь?

— Пекка поддерживает GoFundMonica

Будет ли он работать под DOSBox?

— Penguat

1

Существует утилита под названием DOSBOX, это 16-битный эмулятор, который дает вашей 16-битной программе виртуальный 16-битный компьютер для работы на нем и бесплатно.

Я согласен с Pekka в том, что 64-битная (аппаратная) система может выполнять 16-битный код (черт, даже 1-битный код, если ОС была спроектирована таким образом). Суть в том, что ЦП не может напрямую запускать 16-битный код из-за таких вещей, как разный размер указателя, но ОС может устранить эти проблемы. Ограничение является искусственным, которое Microsoft наложило для упрощения вещей (хотя они все еще эмулировали 32-битный, потому что все еще так много 32-битного кода). Существуют и другие ОС (* nix?), Которые могут без проблем запускать 16-битный код.

— Synetech

Вы путаете Windows со всеми ОС.

— Кен Шарп

24

Насколько я понимаю, это потому, что при работе в длинном режиме (собственно x64), сам процессор не поддерживает переход в 16-битный режим. Смотрите Википедию . Таким образом, для поддержки 16-битного режима NTVDM (16-битный уровень в Windows) должен полностью эмулировать 16-битный процессор.

Я предполагаю, что они взвесили повторную реализацию уровня эмуляции по сравнению с использованием уже существующего программного обеспечения для виртуализации (VirtualPC, VirtualBox), чтобы решить эту проблему, и было решено сократить VDM.

— Мэтт Зикер
источник

6

Цитата из Википедии : Версии Windows NT для 64-битных архитектур (x64 и IA-64) не включают NTVDM и не могут запускать приложения DOS или 16-битные Windows. Это связано с тем, что в процессоре x86-64 виртуальный режим 8086 доступен в качестве подрежима только в его устаревшем режиме (для 16- и 32-разрядных операционных систем), а не в собственном 64-разрядном длинном режиме; для переключения в унаследованный режим требуется полная перезагрузка процессора. Таким образом, единственный способ, которым NTVDM работал до сих пор, больше не доступен, и полных виртуальных машин достаточно, поэтому NTVDM был сокращен.

— Джои

5

Фу, я не могу поверить, что они сбросили режим V86. Можно также полностью сбросить реальный режим и потребовать 32/64 битных загрузчиков, если вы собираетесь это сделать.

— Брайан Кноблаух

5

Это именно то, что уже произошло, М. Кноблаух. Современная машина x86 с прошивкой EFI сразу переходит из нереального режима в своих первых инструкциях в 64/32-битный защищенный режим. Загрузчики действительно являются 64/32-битными программами в защищенном режиме. Вот что такое загрузочные приложения EFI. В этом процессе нигде не используется реальный режим или защищенный режим v8086.

— JdeBP

3

-1. WINE поддерживает запуск 16-битных приложений Windows в режиме VM86 на 64-битной Linux. скриншот . V86-64 Страница проекта . Ответ Мердада кажется более веской причиной.

— Хью Аллен

3

@HughAllen: на этой странице в настоящее время написано: «В настоящее время в 64-битной версии ядра Linux отсутствует поддержка режима V86, поскольку он не поддерживается в основном режиме работы (длинном режиме) этих процессоров». и «Этот патч очень экспериментальный ». Короткий ответ заключается в том, что, хотя можно запустить 16-битный код, полностью выйдя из длинного режима, это не имеет смысла .

— Гарри Джонстон

14

Поскольку 64-битные дескрипторы имеют 32 значащих бита :

Обратите внимание, что 64-разрядная версия Windows не поддерживает запуск 16-разрядных приложений для Windows.
Основная причина в том, что дескрипторы имеют 32 значащих бита в 64-битной Windows.
Поэтому дескрипторы не могут быть усечены и переданы 16-разрядным приложениям без потери данных.

В Windows программы передают «дескрипторы» ОС и наоборот (это числа, которые ОС использует для уникальной идентификации конкретного ресурса, такого как окно).

Для поддержки 16-битных программ 32-битная Windows генерирует только дескрипторы, которые имеют 16 значащих битов - 16 старших бит игнорируются ОС (даже если программы не используют этот факт в своих интересах). Таким образом, ни одна программа не может взаимодействовать с более чем 2 ¹⁶ объектами, что на самом деле довольно мало.

Однако, чтобы улучшить это, 64-битная Windows увеличила количество значащих бит в дескрипторе до 32. Но теперь это означает, что дескрипторы не могут быть переданы в 16-битные программы без потери информации. Таким образом, 16-битные программы не могут работать в 64-битной Windows.

— Mehrdad
источник

3

@Joey: я не понимаю, что ты говоришь. Если операционная система Windows 64-разрядная, то 16-разрядные приложения не могут работать на ней, точка. Я не вижу, как тот факт, что они являются приложениями «DOS» или «Windows», что-то здесь меняет - в любом случае, приложения должны были бы усекать дескрипторы.

— Мердад

1

DOS-приложения не имеют ручек. На самом деле, они (обычно) даже не знают, что работают под Windows.

— Джои

1

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

— Гарри Джонстон

1

@HarryJohnston: я думаю, что вы упускаете проблему. Что, по вашему мнению, должно произойти с вашей воображаемой «таблицей поиска» при вызове приложения, когда в EnumWindowsсистеме более 2 ^ 16 окон?

— Мердад

1

Я говорил о дескрипторах ядра согласно статье, а не о дескрипторах окна. Это совершенно разные вещи. 16-битные приложения видят даже 32-битные окна? Это кажется маловероятным, потому что структуры сообщений различны; что произойдет, если 16-битному приложению будет отправлено сообщение с 32-битным wParam? Также обратите внимание, что максимальное количество оконных дескрипторов по-прежнему составляет 2 ^ 16 в соответствии с msdn.microsoft.com/en-us/library/windows/desktop/…

— Гарри Джонстон

10

Для Windows это потому, что версии ОС x86 включают 16-битную эмуляцию, которая позволяет им запускать эти старые процессы DOS. В версиях x64 им уже приходится эмулировать выполнение x86 (они называют его WoW64), чтобы позволить запускаться 32-разрядным процессам, и я предполагаю, что использование Wow64 для дальнейшей эмуляции 16-разрядного эмулятора вызвало слишком много проблем.

Несколько распознанных 16-битных процессов будут работать, потому что эмуляция жестко запрограммирована, но остальные не работают, потому что эмуляция не включена в x64.

Смотрите "Нет 16-битного кода" в статье MSKB: http://support.microsoft.com/kb/282423

— SqlRyan
источник

14

Эмуляция не происходит - x86 / 64 может запускать эти вещи изначально. Тем не менее, существует API-интерфейс. Microsoft выбрала эту возможность, чтобы удалить устаревшую и в основном неиспользуемую технологию.

— Крис К

@Chris Kaminski - я удивлен, что они сделали бы это как архитектурное решение - x86 против x64 - вместо того, чтобы сказать: «Хорошо - это Windows 7, и мы больше не запускаем 16-битные процессы». Особенно в «Windows XP Mode», который теперь встроен в 7, кажется, что это идеальное время, чтобы сократить поддержку даже в версии x86.

— SqlRyan

@Chris Kaminski: После долгих размышлений я думаю, что это должно быть имитировать, а не просто что-то вроде API-хакерства. Если он может запускать код другой битовой сборки нативно, то почему в x64 должен быть Wow64 для запуска 32-битных приложений - разве они не будут работать нативно?

— SqlRyan

@darthcoder: CPU просто не поддерживает режим виртуального 8086, требуемый NTVDM в длинном (64-битном) режиме. Поэтому либо НТВДМ должен был стать полноценной ВМ, эмулировать все или быть обрезанным. Поскольку уже есть достаточно виртуальных машин (и у MS тоже есть), это не было трудным решением. Я не думаю, что это имеет какое-либо отношение к тому, сколько лет это было или сколько использовалось.

— Джои

rwmnau: для WoW64 эмуляция не происходит (кроме Itanium). Процессоры x64-64 по-прежнему поддерживают 32-разрядные инструкции, поэтому почти все, что нужно Windows, - это переключить процессор в 32-разрядный режим и использовать несколько указателей.

— Джои

3

Поправьте меня, если я ошибаюсь, но, насколько я понимаю, именно из-за проблемы Windows NTVDM использует виртуальный режим 8086. Режим совместимости на процессорах x64 (работающих в длинном режиме) поддерживает полностью «чистый» защищенный режим, 16 и 32-битный из того, что я нашел здесь: http://en.wikipedia.org/wiki/Long_mode , но не некоторые из 386 дополнений, таких как виртуальный режим 8086. Таким образом, он не поддерживается, скорее всего, потому что Microsoft не окупает перепрограммирование NTVDM, что, вероятно, потребует добавления дополнительной эмуляции, потому что некоторые приложения в 16-битном защищенном режиме могут использовать виртуальный 8086, даже если большинство этого не делают. Я полагаю, что при достаточном труде можно написать что-то быстрее, чем dosbox, работающий в длинном режиме, поскольку есть аппаратная поддержка 16-битных приложений.

— Michaels
источник

-1. 16-битная адресация в 16-битном сегменте поддерживается через локальную таблицу дескрипторов. , На самом деле, winedvm на Linux делает именно это! Там даже неофициальная замена называется otvdm .

— user2284570

Ну, насколько я понимаю, это (Wine Solution) содержит эмулятор процессора. Так что он не использует виртуальный режим 8086. Это именно то решение, которое потенциально может быть реализовано в NTVDM без эмуляции всего ПК, как это делает DOSBOX (с Win16). И если вы скажете, что в длинном режиме поддерживается 16-битный защищенный режим, то как насчет приложений реального режима Win16?

— MichaelS

Он содержит эмулятор, но если в Windows найден способ изменить таблицу локальных дескрипторов, то никакой эмуляции не потребуется. О реальном режиме их также можно эмулировать так, как это делает Dosemu (по крайней мере, версия для Linux). Ntvdm изначально был разработан для того, чтобы позволить запускать программу Dos на платформах, таких как Mips или PowerPc, которые были поддержаны в предыдущей версии Windows. Это просто дополнительная функция, которая должна быть включена во время компиляции. И, похоже, исходный код был пропущен, что позволило кому-то сделать это: columbia.edu/~em36/ntvdmx64.html

— user2284570

3

Ситуация отличается для приложений Dos и 16-битных приложений Windows.

Для приложений Dos проблема заключается в том, что виртуальный режим 8086 недоступен в длинном режиме. Это ограничение архитектуры процессора.

Для 16-битных приложений Windows (которые работают в 16-битном защищенном режиме) причина в том, что MS не была готова выполнить работу по реализации подходящего уровня совместимости. Забавно, что Wine прекрасно способен запускать 16-битные приложения Windows на 64-битной Linux.

— plugwash
источник

1

это просто потому, что в 64-битной Windows нет NTVDM. Процессор все еще может запускать 16-битный код в режиме совместимости. Из руководства Intel: «Режим совместимости (подрежим режима IA-32e). Режим совместимости позволяет большинству устаревших 16-разрядных и 32-разрядных приложений работать без перекомпиляции в 64-разрядной операционной системе»

— phuclv

Насколько я понимаю, режим совместимости допускает 16-битный защищенный режим, но не виртуальный режим 8086.

— штепсельная стирка

2

Я думаю, что наиболее вероятная причина в том, что лишь крошечный процент владельцев ПК действительно хотят иметь возможность запускать старые 16-битные приложения на своем новом 64-битном оборудовании. Microsoft, вероятно, полагала, что не стоит продолжать поддерживать 16-битные приложения.

— Стивен С
источник

Это имеет смысл, за исключением того, что Windows 7 32bit по-прежнему поддерживает его, поэтому, очевидно, стоит использовать то, что у них уже есть, но не переопределять его (как было бы необходимо для x86-64 из-за отсутствия режима virtual-8086

— Earlz

Я думал, что «мы не хотим поддерживать сложную кодовую базу». Если бы они оставались в 16-битном режиме, им, возможно, пришлось бы поддерживать программное обеспечение, которое датируется 80-ми годами. Это может включать в себя уродливые хаки, чтобы Lotus 1-2-3 все еще работал.

— Джо Планте

@Earlz да, но я думаю, что это реальный ответ, так как реальное решение для доступа к таблице Local Descriptor для 16 битов - это сделать это напрямую, а не через режим Vm86. Microsoft просто не стала переносить их код. На самом деле существует неофициальная замена программного обеспечения, разработанная для 64-битных версий Windows .

— user2284570