Чому 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

Я думаю, що це менше стосується бітів і більше з гостьовою операційною системою. Які ОС ви конкретно маєте на увазі?

— Pekka підтримує GoFundMonica

Чи буде він працювати під DOSBox?

— Пінгват

1

Існує утиліта під назвою DOSBOX - це 16-бітний емулятор, який дає вашій 16-бітній програмі віртуальний 16-бітний комп'ютер для роботи та її безкоштовний.

Я погоджуюся з Pekka, факт полягає в тому, що 64-розрядна (апаратна) система може запускати 16-бітний код (чорт, навіть 1-бітний код, якщо ОС була спроектована). Справжня суть полягає в тому, що процесор не може безпосередньо запускати 16-бітний код через такі речі, як різний розмір вказівника, але ці проблеми можуть бути усунені ОС. Обмеження є штучним, яке корпорація Майкрософт запровадила для спрощення речей (хоча вони все ще емулювали 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 було скорочено.

— Joey

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.
Основна причина полягає в тому, що в 64-розрядних Windows ручки мають 32 значущі біти.
Тому ручки не можуть бути усічені та передані 16-бітовим програмам без втрати даних.

У Windows програми передають навколо "ручки" ОС і навпаки (це числа, які ОС використовує для унікальної ідентифікації певного ресурсу, наприклад, вікна).

Для підтримки 16-бітних програм, 32-бітна Windows , тільки генерує маркери , які мають 16 значущих біт - в 16 старших біта ігноруються ОС (навіть якщо програми не повинні скористатися цим фактом). Тому жодна програма не може взаємодіяти з більш ніж ^{16 16} об’єктами, що насправді є досить низьким.

Однак, щоб покращити це, 64-розрядна Windows збільшила кількість значущих бітів в ручці до 32. Але тепер це означає, що ручки не можуть передаватися 16-бітовим програмам без втрати інформації. Отже, 16-бітні програми не можуть працювати в 64-бітних Windows.

— Мехрдад
джерело

3

@Joey: Я не розумію, що ти кажеш. Якщо в ОС 64-розрядна Windows, то 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 vs x64 - на відміну від того, щоб сказати "Гаразд - це Windows 7, і ми вже не працюємо з 16-бітовими процесами". Тим більше, що в режимі Windows XP, який зараз вбудований у 7, здається, що ідеальний час знизити підтримку навіть у версії x86.

— SqlRyan

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

— SqlRyan

@darthcoder: ЦП просто не підтримує віртуальний режим 8086, необхідний NTVDM у довгому (64 бітному) режимі. Тому або NTVDM повинен був би стати повноправним представником віртуальних програм, емулюючи все або перерізати. Оскільки там вже є достатня кількість віртуальних машин (і в MS теж є), це було не важким рішенням. Я не думаю, що це має нічого спільного з тим, скільки років це було або скільки використовувалося.

— Joey

rwmnau: Для WoW64 емуляція не відбувається (крім Itanium). x64-64 процесори все ще підтримують 32-розрядні інструкції, тому майже все, що потрібно зробити Windows, - це переключити процесор у 32-бітний режим і зіпсувати декілька покажчиків.

— Joey

3

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

— MichaelS
джерело

−1. 16-бітовий режим адресації aka 16-бітовий сегмент підтримується через локальну таблицю дескрипторів. . Насправді winedvm на Linux робить саме це! Існує навіть неофіційна заміна під назвою otvdm .

— користувач2284570

Ну, наскільки я розумію (вінний розчин) містить емулятор процесора. Таким чином, він не використовує віртуальний режим 8086. Це саме рішення, яке, можливо, може бути реалізовано в NTVDM, не емулюючи цілий ПК, як DOSBOX (з Win16). А якщо ви скажете, що 16-бітний захищений режим підтримується в довгому режимі, то що робити з додатками реального режиму Win16?

— MichaelS

Він містить емулятор, але якщо в Windows знайдеться спосіб зміни локальної таблиці дескрипторів, то взагалі ніякої емуляції не потрібно. Щодо реального режиму вони також можуть бути імітовані таким чином, як це робив Dosemu (принаймні версія Linux). Спочатку Ntvdm був розроблений для того, щоб запускати програму Dos на таких платформах, як Mips або PowerPc, що підтримувалася в попередній версії Windows. Це просто необов'язкова функція, яку потрібно включити під час компіляції. І, схоже, витік вихідного коду, що дозволяє комусь робити саме це: columbia.edu/~em36/ntvdmx64.html

— користувач2284570

3

Ситуація різна для додатків Dos та 16-бітних програм Windows.

Для додатків Dos проблема полягає в тому, що віртуальний режим 8086 недоступний у тривалому режимі. Це обмеження архітектури процесора.

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

— підключити
джерело

1

це лише тому, що в 64-розрядних Windows немає NTVDM. Процесор все ще може запускати 16-бітний код у режимі сумісності. З посібника від Intel: "Режим сумісності (підрежим режиму IA-32e) - Режим сумісності дозволяє запускати більшість застарілих 16-бітних та 32-бітних програм без повторної компіляції в 64-бітній операційній системі"

— phuclv

Як я розумію, режим сумісності дозволяє 16-бітний захищений режим, але не віртуальний 8086 режим.

— підключіть

2

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

— Стівен С
джерело

Це має сенс, за винятком того, що Windows 7 32bit все ще підтримує його, тому, мабуть, варто використовувати те, що вони вже є, але не повторно виконувати його (як це було б потрібно для x86-64 через відсутність режиму віртуального 8086

— Earlz

Я думав, що "ми не хочемо підтримувати складну кодову базу". Якби вони зберігалися в 16-бітних, їм, можливо, довелося б підтримувати програмне забезпечення, яке датується 80-ми. Це може включати в себе некрасиві хаки, щоб Lotus 1-2-3 все ще працював.

— Джо Плант

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

— користувач2284570