Mengapa OS 64 bit tidak dapat menjalankan aplikasi 16 bit?

38

Mengapa demikian:

OS 32-bit, ketika diinstal pada CPU 64-bit, dapat menjalankan aplikasi 16-bit lama,
tetapi jika Anda menginstal OS 64-bit tidak dapat menjalankan aplikasi tersebut secara langsung dan memerlukan semacam emulasi (itu tidak selalu bekerja dengan sempurna)?

Untuk lebih spesifik, saya memiliki prosesor 64-bit (Intel Core 2 Duo). Ketika saya menginstal Windows XP dan Windows 7 (keduanya 32-bit), mereka dapat menjalankan aplikasi Windows DOS dan 616-bit yang lama.

Sekarang saya telah menginstal edisi Windows 7. 64-bit. Mengapa tidak bisa menjalankan aplikasi yang sama lagi?

— fixer1234
sumber

3

Saya pikir itu kurang berkaitan dengan bit dan lebih banyak dengan sistem operasi tamu. OS apa yang Anda maksudkan secara khusus?

— Pekka mendukung GoFundMonica

Apakah ini akan berjalan di bawah DOSBox?

— Penguat

1

Ada utilitas bernama DOSBOX yang merupakan emulator 16 bit yang memberikan program 16 bit Anda komputer 16 bit virtual untuk dikerjakan, dan gratis.

Saya setuju dengan Pekka, faktanya adalah sistem 64-bit (perangkat keras) dapat menjalankan kode 16-bit (heck, bahkan kode 1-bit jika OS dirancang demikian). Tangkapan sebenarnya adalah bahwa CPU tidak dapat langsung menjalankan kode 16-bit karena hal-hal seperti ukuran pointer yang berbeda, tetapi masalah ini dapat diabstraksi oleh OS. Keterbatasan ini adalah tiruan yang dipaksakan Microsoft untuk menyederhanakan hal-hal (meskipun mereka masih ditiru 32-bit karena masih ada begitu banyak kode 32-bit). Ada OS lain (* nix?) Yang dapat menjalankan kode 16-bit tanpa masalah.

— Synetech

Anda membingungkan Windows dengan semua OS.

— Ken Sharp

24

Dari pemahaman saya, itu karena ketika menjalankan dalam Long Mode (x64 asli), CPU itu sendiri tidak mendukung masuk ke mode 16 bit. Lihat Wikipedia . Jadi, untuk mendukung mode 16 bit, NTVDM (lapisan 16 bit pada Windows) harus sepenuhnya meniru prosesor 16 bit.

Saya kira mereka ditimbang menerapkan kembali emulasi layer vs menggunakan perangkat lunak virtualisasi yang sudah ada (VirtualPC, VirtualBox) untuk menangani ini, dan diputuskan untuk memotong VDM.

— Matt Sieker
sumber

6

Mengutip dari Wikipedia : Versi Windows NT untuk arsitektur 64-bit (x64 dan IA-64) tidak termasuk NTVDM dan tidak dapat menjalankan aplikasi DOS atau 16-bit Windows. Ini karena, dalam CPU x86-64, mode 8086 virtual tersedia sebagai sub-mode hanya dalam mode lawasnya (untuk menjalankan sistem operasi 16-dan 32-bit), bukan dalam mode asli, mode panjang 64-bit; reset keras dari CPU diperlukan untuk beralih ke mode lama. Jadi satu-satunya cara NTVDM bekerja sejauh ini tidak tersedia lagi dan banyak VM tersedia, jadi NTVDM terputus.

— Joey

5

Yuck, saya tidak percaya mereka membuang mode V86. Mungkin juga melemparkan mode nyata sepenuhnya dan menuntut boot loader 32/64 bit jika Anda akan melakukannya.

— Brian Knoblauch

5

Itulah yang sebenarnya terjadi, M. Knoblauch. Mesin x86 modern dengan firmware EFI langsung beralih dari mode tidak nyata dalam beberapa instruksi pertamanya menjadi mode terlindungi 64/32-bit. Boot loader memang program mode terproteksi 64/32-bit. Itulah aplikasi boot EFI. Tidak ada penggunaan mode nyata atau mode yang dilindungi v8086 di mana pun dalam proses.

— JdeBP

3

-1. WINE mendukung menjalankan aplikasi Windows 16-bit dalam mode VM86 di Linux 64-bit. tangkapan layar . Halaman Proyek V86-64 . Jawaban Mehrdad sepertinya alasan yang lebih meyakinkan.

— Hugh Allen

3

@HughAllen: halaman itu saat ini mengatakan "Saat ini versi 64-bit kernel linux tidak mendukung mode V86 karena tidak didukung dalam mode operasi asli (mode lama) dari prosesor ini." dan "Tambalan ini sangat eksperimental ." Jawaban singkatnya adalah bahwa meskipun dimungkinkan untuk menjalankan kode 16-bit, dengan keluar dari mode panjang sepenuhnya, tidak masuk akal untuk melakukannya.

— Harry Johnston

14

Karena pegangan 64-bit memiliki 32 bit signifikan :

Perhatikan bahwa Windows 64-bit tidak mendukung menjalankan aplikasi berbasis Windows 16-bit.
Alasan utama adalah bahwa pegangan memiliki 32 bit signifikan pada Windows 64-bit.
Oleh karena itu, pegangan tidak dapat dipotong dan diteruskan ke aplikasi 16-bit tanpa kehilangan data.

Di Windows, program menyebarkan "handle" ke OS dan sebaliknya (yang merupakan angka yang digunakan OS untuk secara unik mengidentifikasi sumber daya tertentu, seperti jendela).

Untuk mendukung program 16-bit, Windows 32-bit hanya menghasilkan sebuah pegangan yang memiliki 16 bit signifikan - 16 bit atas diabaikan oleh OS (meskipun program tidak memanfaatkan fakta ini). Jadi tidak ada program yang dapat berinteraksi dengan lebih dari ¹⁶ objek, yang sebenarnya agak rendah.

Namun, untuk meningkatkan ini, Windows 64-bit meningkatkan jumlah bit yang signifikan dalam sebuah pegangan menjadi 32. Tetapi sekarang itu berarti bahwa pegangan tidak dapat diteruskan ke program 16-bit tanpa kehilangan informasi. Jadi program 16-bit tidak dapat berjalan di Windows 64-bit.

— Mehrdad
sumber

3

@ Joey: Saya tidak mengerti apa yang Anda katakan. Jika OS adalah Windows 64-bit, maka aplikasi 16-bit tidak dapat berjalan di atasnya, titik. Saya tidak melihat bagaimana fakta bahwa itu adalah aplikasi "DOS" atau "Windows" mengubah apa pun di sini - bagaimanapun, pegangan harus dipotong oleh aplikasi.

— Mehrdad

1

Aplikasi DOS tidak memiliki pegangan. Bahkan, mereka (biasanya) bahkan tidak tahu sedang berjalan di Windows.

— Joey

1

... sebenarnya, bahkan kode Win16 seharusnya tidak terlalu menjadi masalah, sekarang saya memikirkannya. Yang Anda butuhkan hanyalah tabel pencarian.

— Harry Johnston

1

@ HarryJohnston: Saya pikir Anda melewatkan masalahnya. Apa yang Anda usulkan harus terjadi dengan "tabel pencarian" imajiner Anda ketika sebuah aplikasi memanggil EnumWindowsdan ada lebih dari 2 ^ 16 jendela dalam sistem?

— Mehrdad

1

Saya berbicara tentang pegangan kernel sesuai artikel, bukan pegangan jendela. Mereka hal yang sangat berbeda. Apakah aplikasi 16-bit bahkan melihat windows 32-bit? Tampaknya tidak mungkin, karena struktur pesannya berbeda; apa yang akan terjadi jika aplikasi 16-bit dikirimi pesan dengan wParam 32-bit? Juga, perhatikan bahwa jumlah maksimum pegangan jendela masih 2 ^ 16 menurut msdn.microsoft.com/en-us/library/windows/desktop/…

— Harry Johnston

10

Untuk Windows, itu karena versi OS x86 menyertakan emulasi 16-bit yang memungkinkan mereka untuk menjalankan proses DOS yang lebih lama. Pada versi x64, mereka sudah harus meniru eksekusi x86 (mereka menyebutnya WoW64) untuk memungkinkan proses 32-bit berjalan, dan saya kira menggunakan Wow64 untuk lebih lanjut meniru emulator 16-bit yang disebabkan terlalu banyak masalah.

Sejumlah proses 16-bit yang dikenali akan berjalan karena emulasi dikodekan keras untuk menanganinya, tetapi sisanya tidak berfungsi karena emulasi tidak termasuk dalam x64.

Lihat "Tidak ada kode 16-bit" di artikel MSKB: http://support.microsoft.com/kb/282423

— SqlRyan
sumber

14

Tidak ada persaingan yang terjadi - x86 / 64 dapat menjalankan hal-hal ini secara asli. Namun ada API thunking yang terjadi. Microsoft telah memilih kesempatan ini untuk pensiun teknologi yang secara signifikan sudah tua dan sebagian besar tidak digunakan.

— Chris K

@ Chris Kaminski - Saya terkejut bahwa mereka akan melakukan itu sebagai keputusan arsitektur - x86 vs x64 - yang bertentangan dengan mengatakan "Baiklah - ini Windows 7, dan kami tidak menjalankan proses 16-bit lagi". Apalagi dengan "Windows XP Mode" sekarang tertanam di 7, sepertinya waktu yang tepat untuk memotong dukungan bahkan di versi x86.

— SqlRyan

@ Chris Kaminski: Setelah memikirkannya lagi, saya pikir itu harus ditiru, bukan hanya semacam penghinaan API. Jika itu bisa menjalankan kode dari bit-build yang berbeda secara native, lalu mengapa x64 memiliki Wow64 untuk menjalankan aplikasi 32-bit - bukankah itu akan berjalan secara native juga?

— SqlRyan

@darthcoder: CPU tidak mendukung mode 8086 virtual yang diperlukan oleh NTVDM dalam mode panjang (64 bit). Oleh karena itu baik NTVDM harus menjadi VM penuh, meniru semua atau memotong. Karena sudah ada cukup banyak VM di luar sana (dan MS juga memilikinya) itu bukan keputusan yang sulit. Saya tidak berpikir itu ada hubungannya dengan berapa umur itu atau berapa banyak digunakan.

— Joey

rwmnau: Untuk WoW64 tidak ada emulasi yang terjadi (kecuali untuk Itanium). x64-64 CPU masih mendukung instruksi 32-bit sehingga hampir semua yang harus Windows lakukan adalah mengganti CPU dalam mode 32-bit dan mengacaukannya dengan beberapa petunjuk.

— Joey

3

Perbaiki saya jika saya salah, tetapi menurut pemahaman saya, ini hanya karena masalah khusus Windows sehingga NTVDM menggunakan mode virtual 8086. Mode kompatibilitas pada prosesor x64 (berjalan dalam mode lama) mendukung mode terlindungi 'bersih' penuh, 16 dan 32 bit dari apa yang saya temukan di sini: http://en.wikipedia.org/wiki/Long_mode , tetapi tidak sebagian dari 386 tambahan seperti mode 8086 virtual. Jadi kemungkinan besar tidak didukung karena tidak membuahkan hasil bagi Microsoft untuk memprogram ulang NTVDM, yang mungkin memerlukan penambahan beberapa emulasi karena beberapa aplikasi mode terproteksi 16-bit dapat menggunakan virtual 8086, bahkan jika kebanyakan tidak. Saya kira dengan tenaga kerja yang cukup dimungkinkan untuk menulis sesuatu lebih cepat daripada dosbox berjalan dalam mode lama, karena ada dukungan perangkat keras untuk aplikasi 16bit.

— Michael
sumber

−1. Pengalamatan mode 16 bit alias segmen 16 bit didukung melalui tabel deskriptor lokal. . Bahkan winedvm di Linux tidak hanya itu! Bahkan ada pengganti tidak resmi yang disebut otvdm .

— user2284570

Nah, menurut pemahaman saya itu (solusi anggur) berisi emulator CPU. Jadi tidak menggunakan mode virtual 8086. Itulah solusi yang, berpotensi, dapat diimplementasikan dalam NTVDM, tanpa meniru seluruh PC, seperti DOSBOX (dengan Win16). Dan jika Anda mengatakan bahwa mode 16 bit terproteksi didukung dalam mode panjang, lalu bagaimana dengan Win16 real-mode apps?

— MichaelS

Ini berisi emulator tetapi jika cara untuk memodifikasi tabel deskriptor lokal ditemukan pada Windows, maka tidak ada emulasi sama sekali akan diperlukan. Tentang mode nyata, mereka juga dapat ditiru sedemikian rupa seperti yang dilakukan oleh Dosemu (versi Linux setidaknya). Ntvdm awalnya dirancang untuk memungkinkan menjalankan program Dos pada platform seperti Mips atau PowerPc yang didukung di Windows versi Sebelumnya. Ini hanya Fitur opsional yang perlu diaktifkan pada waktu kompilasi. Dan tampaknya kode sumber bocor yang memungkinkan seseorang melakukan hal itu: columbia.edu/~em36/ntvdmx64.html

— user2284570

3

Situasinya berbeda untuk aplikasi Dos dan aplikasi 16 bit windows.

Untuk aplikasi Dos masalahnya adalah mode virtual 8086 tidak tersedia dalam mode lama. Ini adalah batasan arsitektur CPU.

Untuk aplikasi Windows 16 bit (yang berjalan dalam mode 16 bit protected) alasannya adalah bahwa MS tidak siap untuk melakukan pekerjaan untuk mengimplementasikan lapisan kompatibilitas yang sesuai. Amusingly Wine sangat mampu menjalankan aplikasi windows 16 bit di linux 64-bit.

— plugwash
sumber

1

itu hanya karena tidak ada NTVDM di Windows 64-bit. CPU masih dapat menjalankan kode 16-bit dalam mode kompatibilitas. Dari manual Intel: "Mode kompatibilitas (sub-mode mode IA-32e) - Mode kompatibilitas memungkinkan sebagian besar aplikasi 16-bit dan 32-bit lama dijalankan tanpa kompilasi ulang di bawah sistem operasi 64-bit"

— phuclv

Seperti yang saya pahami, mode kompatibilitas memungkinkan mode 16 bit yang dilindungi, tetapi bukan mode 8086 virtual.

— plugwash

2

Saya pikir alasan yang paling mungkin adalah bahwa hanya sebagian kecil pemilik PC yang benar-benar ingin dapat menjalankan aplikasi 16 bit lama pada perangkat keras 64 bit baru mereka. Microsoft mungkin berpikir bahwa itu tidak layak ketika mereka terus mendukung aplikasi 16 bit.

— Stephen C
sumber

Ini masuk akal kecuali untuk Windows 7 32bit masih mendukungnya, jadi tampaknya layak untuk menggunakan apa yang sudah mereka miliki tetapi tidak mengimplementasikannya kembali (seperti yang diperlukan untuk x86-64 karena tidak ada mode virtual-8086

— Earlz

Saya berpikir bahwa "kami tidak ingin mempertahankan basis kode yang rumit". Jika mereka tetap dalam 16-bit, mereka mungkin harus mendukung perangkat lunak yang tanggal kembali ke tahun 80-an. Ini mungkin termasuk menempatkan hacks jelek sehingga Lotus 1-2-3 masih berfungsi.

— Joe Plante

@ Earlz ya tapi saya pikir ini adalah jawaban nyata sebagai solusi nyata untuk mengakses tabel Descriptor Lokal selama 16 bit adalah dengan melakukannya secara langsung dan tidak melalui mode Vm86. Microsoft sama sekali tidak repot-repot porting kode mereka. Sebenarnya ada pengganti perangkat lunak Ntᴠᴅᴍ tidak resmi yang dirancang untuk Windows 64-bit asli .

— user2284570