Tại sao HĐH 64 bit không thể chạy ứng dụng 16 bit?

38

Tại sao:

HĐH 32 bit, khi được cài đặt trên CPU 64 bit, có thể chạy các ứng dụng 16 bit cũ,
Nhưng nếu bạn cài đặt HĐH 64 bit, nó không thể chạy các ứng dụng đó trực tiếp và cần một số mô phỏng (không phải lúc nào cũng hoạt động hoàn hảo)?

Để cụ thể hơn, tôi có bộ xử lý 64 bit (Intel Core 2 Duo). Khi tôi cài đặt Windows XP và Windows 7 (cả 32 bit), chúng có thể chạy các ứng dụng Windows cũ và 616 bit.

Bây giờ tôi đã cài đặt phiên bản 64 bit của Windows 7. Tại sao nó không thể chạy các ứng dụng tương tự nữa?

— người sửa chữa1234
nguồn

3

Tôi nghĩ rằng điều đó ít liên quan đến các bit và nhiều hơn với hệ điều hành khách. Bạn đang đề cập đến hệ điều hành nào?

— Pekka hỗ trợ GoFundMonica

Nó sẽ chạy trong DOSBox?

— Chim cánh cụt

1

Có một tiện ích gọi là DOSBOX, trình giả lập 16 bit cung cấp cho chương trình 16 bit của bạn một máy tính ảo 16 bit để hoạt động và miễn phí.

Tôi đồng ý với Pekka, thực tế là một hệ thống 64 bit (phần cứng) có thể chạy mã 16 bit (quái, thậm chí là mã 1 bit nếu HĐH được thiết kế như vậy). Điều hấp dẫn thực sự là CPU không thể chạy trực tiếp mã 16 bit do những thứ như kích thước con trỏ khác nhau, nhưng những vấn đề này có thể được HĐH trừu tượng hóa. Giới hạn này là một giới hạn nhân tạo mà Microsoft áp đặt để đơn giản hóa mọi thứ (mặc dù họ vẫn mô phỏng 32 bit vì vẫn còn quá nhiều mã 32 bit). Có các HĐH khác (* nix?) Có thể chạy mã 16 bit mà không gặp sự cố.

— Synetech

Bạn đang nhầm lẫn Windows với tất cả các hệ điều hành.

— Ken Sharp

24

Theo hiểu biết của tôi, đó là vì khi chạy ở Chế độ dài (bản gốc x64), bản thân CPU không hỗ trợ chuyển sang chế độ 16 bit. Xem Wikipedia . Vì vậy, để hỗ trợ chế độ 16 bit, NTVDM (lớp 16 bit trong Windows) sẽ phải mô phỏng hoàn toàn bộ xử lý 16 bit.

Tôi cho rằng họ đã cân nhắc việc thực hiện lại một lớp mô phỏng so với việc sử dụng phần mềm ảo hóa đã tồn tại (VirtualPC, VirtualBox) để xử lý việc này và đã quyết định cắt VDM.

— Matt Sieker
nguồn

6

Trích dẫn từ Wikipedia : Các phiên bản Windows NT cho kiến trúc 64 bit (x64 và IA-64) không bao gồm NTVDM và không thể chạy các ứng dụng Windows của DOS hoặc 16 bit. Điều này là do, trong CPU x86-64, chế độ ảo 8086 chỉ có sẵn ở chế độ phụ ở chế độ cũ (để chạy hệ điều hành 16 và 32 bit), không phải ở chế độ dài 64 bit gốc; Cần thiết lập lại cứng CPU để chuyển sang chế độ cũ. Vì vậy, cách duy nhất mà NTVDM đã hoạt động cho đến nay không còn nữa và các máy ảo đầy đủ đã xuất hiện rất nhiều, vì vậy NTVDM đã bị cắt.

— Joey

5

Ái chà, tôi không thể tin rằng họ đã bỏ chế độ V86. Cũng có thể ném hoàn toàn chế độ thực và yêu cầu bộ tải khởi động 32/64 bit nếu bạn định làm điều đó.

— Brian Knoblauch

5

Đó chính xác là những gì đã xảy ra, M. Knoblauch. Một máy x86 hiện đại với phần sụn EFI đi thẳng từ chế độ không thực trong một vài hướng dẫn đầu tiên sang chế độ được bảo vệ 64/32-bit. Các bộ tải khởi động thực sự là các chương trình chế độ được bảo vệ 64/32-bit. Đó là những gì ứng dụng khởi động EFI. Không sử dụng chế độ thực hoặc chế độ được bảo vệ v8086 ở bất cứ đâu trong quy trình.

— JdeBP

3

-1. WINE hỗ trợ chạy các ứng dụng Windows 16 bit ở chế độ VM86 trên Linux 64 bit. ảnh chụp màn hình . Trang dự án V86-64 . Câu trả lời của Mehrdad có vẻ như là lý do hấp dẫn hơn.

— Hugh Allen

3

@HughAllen: trang đó hiện đang nói "Phiên bản 64 bit của kernel linux thiếu hỗ trợ chế độ V86 vì nó không được hỗ trợ ở chế độ hoạt động gốc (chế độ dài) của các bộ xử lý này." và "Bản vá này rất thử nghiệm ." Câu trả lời ngắn gọn là mặc dù có thể chạy mã 16 bit, nhưng bằng cách thoát hoàn toàn chế độ dài, việc làm như vậy là không hợp lý .

— Harry Johnston

14

Bởi vì tay cầm 64 bit có 32 bit đáng kể :

Lưu ý rằng Windows 64 bit không hỗ trợ chạy các ứng dụng dựa trên Windows 16 bit.
Lý do chính là các thẻ điều khiển có 32 bit đáng kể trên Windows 64 bit.
Do đó, các thẻ điều khiển không thể được cắt bớt và chuyển đến các ứng dụng 16 bit mà không mất dữ liệu.

Trong Windows, các chương trình chuyển xung quanh "tay cầm" cho HĐH và ngược lại (là những con số mà HĐH sử dụng để xác định duy nhất một tài nguyên cụ thể, như cửa sổ).

Để hỗ trợ các chương trình 16 bit, Windows 32 bit chỉ tạo ra một tay cầm có 16 bit đáng kể - 16 bit trên bị HĐH bỏ qua (mặc dù các chương trình không được lợi dụng thực tế này). Vì vậy, không có chương trình nào có thể tương tác với hơn 2 ¹⁶ đối tượng, điều này thực sự khá thấp.

Tuy nhiên, để cải thiện điều này, Windows 64 bit đã tăng số lượng bit đáng kể trong một tay cầm lên 32. Nhưng bây giờ điều đó có nghĩa là các tay cầm không thể được chuyển đến các chương trình 16 bit mà không mất thông tin. Vì vậy, các chương trình 16 bit không thể chạy trên Windows 64 bit.

— Mehrdad
nguồn

3

@Joey: Tôi không hiểu bạn đang nói gì. Nếu HĐH là Windows 64 bit, thì các ứng dụng 16 bit không thể chạy trên hệ điều hành đó. Tôi không thấy thực tế rằng ứng dụng "DOS" hay "Windows" thay đổi bất cứ điều gì ở đây - dù bằng cách nào, các tay cầm sẽ cần phải được cắt bớt bởi ứng dụng.

— Mehrdad

1

Các ứng dụng DOS không có tay cầm. Trên thực tế, họ (thường) thậm chí không biết họ đang chạy trên Windows.

— Joey

1

... thực ra, ngay cả mã Win16 cũng không phải là vấn đề quá lớn, bây giờ tôi nghĩ về nó. Tất cả những gì bạn cần là một bảng tra cứu.

— Harry Johnston

1

@HarryJohnston: Tôi nghĩ bạn đang thiếu vấn đề. Bạn đề xuất điều gì sẽ xảy ra với "bảng tra cứu" tưởng tượng của bạn khi một ứng dụng gọi EnumWindowsvà có hơn 2 ^ 16 cửa sổ trong hệ thống?

— Mehrdad

1

Tôi đã nói về xử lý kernel theo bài viết, không phải xử lý cửa sổ. Chúng là những thứ hoàn toàn khác nhau. Các ứng dụng 16 bit thậm chí có nhìn thấy các cửa sổ 32 bit không? Có vẻ như không thể, bởi vì các cấu trúc tin nhắn là khác nhau; Điều gì sẽ xảy ra nếu một ứng dụng 16 bit được gửi tin nhắn với wParam 32 bit? Ngoài ra, lưu ý rằng số lượng tay cầm cửa sổ tối đa vẫn là 2 ^ 16 theo msdn.microsoft.com/en-us/l Library / windows / desktop / Lỗi

— Harry Johnston

10

Đối với Windows, đó là vì các phiên bản x86 của HĐH bao gồm mô phỏng 16 bit cho phép chúng chạy các quy trình DOS cũ hơn. Trong các phiên bản x64, họ đã phải mô phỏng thực thi x86 (họ gọi nó là WoW64) để cho phép các tiến trình 32 bit chạy và tôi đoán sử dụng Wow64 để mô phỏng thêm trình giả lập 16 bit gây ra quá nhiều vấn đề.

Một số ít các quy trình 16 bit được công nhận sẽ chạy vì mô phỏng được mã hóa cứng để xử lý chúng, nhưng phần còn lại không hoạt động vì mô phỏng không được bao gồm trong x64.

Xem "Không có mã 16 bit" tại bài viết của MSKB: http://support.microsoft.com/kb/282423

— SqlRyan
nguồn

14

Không có sự mô phỏng nào đang diễn ra - x86 / 64 có thể chạy những thứ này một cách tự nhiên. Có thunking API đang diễn ra tuy nhiên. Microsoft đã chọn cơ hội này để nghỉ hưu một công nghệ cũ và hầu hết chưa được sử dụng.

— Chris K

@Chris Kaminski - Tôi ngạc nhiên rằng họ sẽ làm điều đó như một quyết định kiến trúc - x86 so với x64 - trái ngược với câu nói "Được thôi - đó là Windows 7 và chúng tôi sẽ không chạy các quy trình 16 bit nữa". Đặc biệt với "Chế độ Windows XP" hiện được nhúng vào 7, có vẻ như đây là thời điểm hoàn hảo để cắt giảm hỗ trợ ngay cả trong phiên bản x86.

— SqlRyan

@Chris Kaminski: Sau khi suy nghĩ thêm, tôi nghĩ rằng nó phải được mô phỏng theo nó, không chỉ là một loại API-mucking. Nếu nó có thể chạy mã của một công cụ xây dựng bit khác, thì tại sao x64 lại có Wow64 để chạy các ứng dụng 32 bit - những ứng dụng này có chạy tự nhiên không?

— SqlRyan

@darthcoder: CPU đơn giản là không hỗ trợ chế độ 8086 ảo mà NTVDM yêu cầu ở chế độ dài (64 bit). Do đó, NTVDM sẽ phải trở thành một VM đầy đủ, mô phỏng mọi thứ hoặc bị cắt. Vì đã có đủ máy ảo (và MS cũng có một máy) nên đó không phải là một quyết định khó khăn. Tôi không nghĩ nó có liên quan gì đến tuổi đó hoặc mức độ sử dụng.

— Joey

rwmnau: Đối với WoW64, không có sự mô phỏng nào đang diễn ra (ngoại trừ Itanium). CPU x64-64 vẫn hỗ trợ các hướng dẫn 32 bit, vì vậy hầu như tất cả các Windows phải làm là chuyển CPU ở chế độ 32 bit và gây rối với một vài con trỏ.

— Joey

3

Sửa lỗi cho tôi nếu tôi sai, nhưng theo tôi hiểu thì đó chỉ là do vấn đề cụ thể của Windows mà NTVDM đang sử dụng chế độ ảo 8086. Chế độ tương thích trên bộ xử lý x64 (chạy ở chế độ dài) hỗ trợ chế độ được bảo vệ 'sạch' đầy đủ, 16 và 32 bit so với những gì tôi tìm thấy ở đây: http://en.wikipedia.org/wiki/Long_mode , nhưng không phải là một số 386 bổ sung như chế độ ảo 8086. Vì vậy, nó không được hỗ trợ nhiều nhất vì Microsoft không trả tiền cho Microsoft để lập trình lại NTVDM, điều này có thể sẽ yêu cầu thêm một số mô phỏng vì một số ứng dụng chế độ được bảo vệ 16 bit có thể sử dụng ảo 8086, ngay cả khi hầu hết không. Tôi cho rằng với đủ lao động, có thể viết một cái gì đó nhanh hơn dosbox chạy ở chế độ dài, vì có hỗ trợ phần cứng cho các ứng dụng 16 bit.

— Michael
nguồn

−1. Chế độ 16 bit địa chỉ aka phân đoạn 16 bit được hỗ trợ thông qua bảng mô tả cục bộ. . Trong thực tế, winedvm trên Linux làm điều đó! Thậm chí còn có một sự thay thế không chính thức được gọi là otvdm .

— dùng2284570

Theo sự hiểu biết của tôi, nó (giải pháp rượu) có chứa một trình giả lập CPU. Vì vậy, nó không sử dụng chế độ 8086 ảo. Đó chính xác là giải pháp, có khả năng, có thể được triển khai trong NTVDM, mà không cần mô phỏng toàn bộ PC, giống như DOSBOX (với Win16). Và nếu bạn nói rằng chế độ được bảo vệ 16 bit được hỗ trợ ở chế độ dài, vậy còn ứng dụng chế độ thực Win16 thì sao?

— MichaelS

Nó chứa một trình giả lập nhưng nếu tìm thấy cách sửa đổi bảng mô tả cục bộ trên Windows, thì không cần phải mô phỏng. Về chế độ thực, chúng cũng có thể được mô phỏng theo cách được thực hiện bởi Dosemu (ít nhất là phiên bản Linux). Ntvdm ban đầu được thiết kế để cho phép chạy chương trình Dos trên các nền tảng như Mips hoặc PowerPc được hỗ trợ trong phiên bản Windows trước. Đây chỉ là một Tính năng tùy chọn cần được bật trong thời gian biên dịch. Và có vẻ như mã nguồn đã bị rò rỉ cho phép ai đó làm điều đó: columbia.edu/~em36/ntvdmx64.html

— user2284570

3

Tình hình là khác nhau đối với các ứng dụng Dos và các ứng dụng windows 16 bit.

Đối với các ứng dụng Dos, vấn đề là chế độ 8086 ảo không khả dụng ở chế độ dài. Đây là một giới hạn kiến trúc CPU.

Đối với các ứng dụng Windows 16 bit (chạy ở chế độ được bảo vệ 16 bit), lý do là MS không sẵn sàng thực hiện công việc để thực hiện lớp tương thích phù hợp. Amusingly Wine hoàn toàn có khả năng chạy các ứng dụng windows 16 bit trên linux 64 bit.

— cắm điện
nguồn

1

chỉ vì không có NTVDM trong Windows 64 bit. CPU vẫn có thể chạy mã 16 bit ở chế độ tương thích. Từ hướng dẫn của Intel: "Chế độ tương thích (chế độ phụ của chế độ IA-32e) - Chế độ tương thích cho phép hầu hết các ứng dụng 16 bit và 32 bit kế thừa chạy mà không cần biên dịch lại trong hệ điều hành 64 bit"

— phuclv

Theo tôi hiểu, chế độ tương thích cho phép chế độ được bảo vệ 16 bit, nhưng không phải chế độ 8086 ảo.

— cắm vào

2

Tôi nghĩ rằng lý do rất có thể là chỉ có một tỷ lệ nhỏ chủ sở hữu PC thực sự muốn có thể chạy các ứng dụng 16 bit cũ trên phần cứng 64 bit mới của họ. Microsoft có lẽ đã nhận ra rằng nó không xứng đáng với họ trong khi tiếp tục hỗ trợ các ứng dụng 16 bit.

— Stephen C
nguồn

Điều này có ý nghĩa ngoại trừ Windows 7 32bit vẫn hỗ trợ nó, vì vậy rõ ràng đáng để sử dụng những gì họ đã có nhưng không thực hiện lại (như sẽ cần cho x86-64 do không có chế độ ảo 8086

— Earlz

Tôi đã nghĩ rằng "chúng tôi không muốn duy trì một cơ sở mã phức tạp". Nếu họ giữ trong 16 bit, họ có thể đã phải hỗ trợ phần mềm có từ những năm 80. Điều này có thể bao gồm đưa vào các bản hack xấu xí để Lotus 1-2-3 vẫn hoạt động.

— Joe Plante

@Earlz có nhưng tôi nghĩ đây là câu trả lời thực sự là giải pháp thực sự để truy cập bảng Mô tả cục bộ cho 16 bit là thực hiện trực tiếp và không thông qua chế độ Vm86. Microsoft chỉ đơn giản là không bận tâm đến việc chuyển mã của họ. Trên thực tế, có một sự thay thế phần mềm không chính thức Ntᴠᴅᴍ được thiết kế cho Windows 64 bit gốc .

— dùng2284570