Windows 11 vẫn chạy được cả các tệp nhị phân được biên dịch từ 30 năm trước

 (twitter.com/mikko)
1 điểm bởi GN⁺ 2023-08-20 | 1 bình luận | Chia sẻ qua WhatsApp
  • Windows 11 mới nhất có thể chạy một tệp nhị phân được biên dịch vào ngày 18 tháng 8 năm 1993, qua đó làm nổi bật khả năng tương thích ngược lâu dài của Microsoft
  • Chương trình này, tính đến thời điểm được đăng tải, là một tệp nhị phân được tạo ra từ 30 năm trước, cho thấy phần mềm Windows cũ vẫn có thể hoạt động trong môi trường hiện đại
  • Điểm cốt lõi của trường hợp này nằm ở khả năng tương thích ngược, tức là phiên bản hệ điều hành mới vẫn chấp nhận nguyên vẹn các tệp thực thi từ quá khứ
  • Chưa thể xác nhận chỉ từ thông tin được công khai liệu có cần chuyển đổi riêng, biên dịch lại hay thiết lập bổ sung hay không
  • Khả năng chạy các tệp nhị phân cũ là một tín hiệu ổn định quan trọng đối với doanh nghiệp và người dùng cá nhân khi xử lý phần mềm được lưu trữ dài hạn

Trường hợp Windows 11 chạy tệp nhị phân từ 30 năm trước

  • Windows 11 chạy được một tệp nhị phân được biên dịch vào ngày 18 tháng 8 năm 1993
  • Trường hợp này được chia sẻ cùng với đánh giá rằng khả năng tương thích ngược của Microsoft là rất mạnh
  • Thông tin đã được xác nhận chỉ giới hạn ở khả năng thực thi và ngày biên dịch
    • Không bao gồm tên tệp nhị phân, ngôn ngữ phát triển, cách chạy hay có cần thiết lập bổ sung hay không

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-08-20
Ý kiến trên Hacker News

  • Nhân tiện, cũng có bài viết của Joel Spolsky: https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
    Một trong các nhà phát triển SimCity kể rằng trò chơi có một lỗi nghiêm trọng: trên DOS thì tình cờ chạy ổn, nhưng trên Windows lại hỏng. Đó là lỗi dùng lại vùng nhớ đã được giải phóng; các tester của nhóm Windows khi chạy thử các ứng dụng phổ biến đã phát hiện SimCity liên tục bị crash. Các lập trình viên Windows đã disassemble SimCity, lần theo bằng debugger để tìm ra lỗi, rồi thêm mã kiểm tra SimCity có đang chạy hay không; chỉ trong trường hợp đó, bộ cấp phát bộ nhớ sẽ chạy ở một chế độ đặc biệt cho phép tiếp tục dùng bộ nhớ ngay cả sau khi đã giải phóng

    • Một phản ví dụ là Soldier of Fortune, trò này bị hỏng trên Windows hiện đại vì một compatibility hack bị áp dụng sai. Nếu đổi tên file thực thi thì chạy không vấn đề gì
      Cách triển khai tương thích ngược kiểu này khá tệ vì thiếu minh bạch và mang tính vá víu. Những công cụ tương tự cũng từng được dùng để làm hỏng ứng dụng của đối thủ cạnh tranh. Thường thì người dùng phải thử từng chế độ xem nên chạy như phiên bản Windows cũ nào. Linux cũng không khá hơn vì không có ABI ổn định, còn Mac thì là sự pha trộn giữa Rosetta rất tốt và việc ứng dụng bị hỏng không rõ lý do. Không biết FreeBSD có làm tốt hơn không? Hay những hệ điều hành “trưởng thành” đã biến mất như VMS có khá hơn không
    • Ngày nay các bản cập nhật driver GPU nhìn chung cũng theo kiểu này. Thay vì nhà phát triển sửa game, Nvidia tính toán rằng việc sửa lỗi game ở tầng driver GPU rồi phát hành sẽ có lợi cho họ hơn
    • Điều này ngược lại có vẻ là một lập luận rất mạnh rằng nên phá vỡ tương thích ngược. Những hack vô lý như vậy trở thành gánh nặng bảo trì và debug cho ai đó, và như một khoản thuế đè lên toàn bộ hệ điều hành. Thực tế tôi nghĩ dấu vết của nó lộ ra khá nhiều
    • Nếu tìm các chương bonus trong “The Old New Thing” của Raymond Chen, sẽ thấy nhiều ví dụ về việc từng có một nhóm chuyên trách hack Windows để kiểm tra từng ứng dụng phổ biến và làm cho chúng chạy được trên hệ điều hành mới
    • Trong khi đó, driver GPU của Asahi Linux kiểm tra xem chữ cái đầu trong tên tiến trình có phải là X không, nếu đúng thì đơn giản là từ chối
      Kiểu như: tại sao vẫn còn chạy Xorg? Đáng lẽ giờ phải chuyển sang Wayland rồi chứ
      https://social.treehouse.systems/@marcan/110904454552941656

  • Raymond Chen đã cung cấp góc nhìn nội bộ về chủ đề này trong nhiều thập kỷ: https://devblogs.microsoft.com/oldnewthing/

  • Nhờ độ ổn định tổng thể của Windows API, thật thú vị khi Win32/DX, thông qua khối lượng công việc khổng lồ của Wine/Proton, đã trở thành một API “phổ dụng” rất ổn định và đáng tin cậy trên Linux và các hệ điều hành khác. Liên tục thấy các game từ bỏ bản phát hành native cho Linux và chỉ phát hành cho Proton

  • Đây không phải là chuyện điên rồ, mà là mức kỳ vọng đương nhiên đối với công cụ. Cái búa của tôi vẫn đóng hoàn hảo những chiếc đinh mua từ 30 năm trước
    Không thể xây thứ gì đó trên một nền móng chao đảo cứ liên tục phá vỡ tương thích ngược. Cuối cùng thời gian bảo trì sẽ nhiều hơn thời gian tạo ra nó. Rồi người ta lại phát minh lại bánh xe, nhưng với người dùng thì cái bánh xe mới bóng bẩy chưa chắc đã tốt hơn. Phần lớn phần mềm tôi dùng đã hơn 10 năm tuổi; một số vẫn còn được cập nhật, một số thì không, hoặc đã chuyển lên cloud, nên tôi vui vẻ ở lại phía sau

    • Milwaukee vẫn còn sản xuất pin NiCAD cho các dụng cụ của họ vốn đã bị bỏ xa từ lâu
    • Ngược lại, bạn cũng có thể bị trói vĩnh viễn vào những giới hạn ngớ ngẩn như thế này: https://news.ycombinator.com/item?id=14286383

  • Trước đây tôi từng tin như vậy, nhưng giờ thì không
    Những game Steam từng dùng dịch vụ Games for Windows – Live và không được cập nhật sau khi dịch vụ này đóng cửa năm 2014 sẽ không chạy trên Windows 10 trở lên. Lý do là DLL của dịch vụ đó đã bị gỡ bỏ. Có một thời gian mọi người khắc phục bằng cách tải DLL từ các trang bên thứ ba, nhưng giờ cách đó cũng không còn hiệu quả

    • Những game cũ không có DRM hay dịch vụ mạng cũng có thể không chạy vì tương thích đồ họa. Tuy vậy cnc-ddraw cứu được khá nhiều trong số đó: https://github.com/FunkyFr3sh/cnc-ddraw
    • Dù vậy chắc các bản lậu của những game đó vẫn còn chạy được ;)

  • Còn có những ví dụ “điên rồ” hơn
    z/OS(còn gọi là OS360, MVS) hỗ trợ cả các chương trình từ thập niên 1960, và một DE của IBM nói rằng họ vẫn đang dùng một chương trình được biên dịch vào khoảng thời gian nhiệm vụ Apollo 11

    • Trong thế giới mainframe thì chuyện này khá phổ biến. Unisys(trước đây là Univac) vẫn có mainframe Dorado tương thích nhị phân với Univac 1100 ra đời năm 1962
    • DE là gì? Và họ có nói chương trình đó làm gì không?
      Cũng có các hệ thống khác chạy hoặc tự động chuyển đổi binary hơn 30 năm tuổi. IBM i trên POWER(i5/AS400) có lẽ chạy được các chương trình từ thời System/38(1980), còn HPE NonStop(còn gọi là Tandem Guardian) trên X86-64 có thể chạy hoặc chuyển đổi binary từ hệ thống TNS độc quyền ban đầu cuối thập niên 1970 và hệ thống MIPS năm 1991

  • Windows nổi tiếng là ám ảnh với khả năng tương thích ngược, nhưng ứng dụng DOS CLI thì có cảm giác không phải là thách thức quá lớn vì hệ thống con DOS về cơ bản đã đóng băng. Tôi tò mò không biết các chương trình kiểu DOS có yêu cầu cao hơn, hoặc các ứng dụng Win16 đời đầu, sẽ chạy ra sao. Ví dụ như Zortech C++ năm 1986 cùng DOS extender Phar Lap, hoặc Minesweeper của Windows 3.1, liệu có hoạt động không?

    • Đó không phải ứng dụng DOS mà là ứng dụng console Win32. Ứng dụng DOS (dù 16-bit hay 32-bit) hoặc ứng dụng Win16 không chạy native được
    • Zortech C++ từng là bộ công cụ tôi dùng một thời gian và tôi có kỷ niệm tốt về nó. Phar Lap can thiệp quá sâu nên tôi nghĩ khó chạy trên Windows hiện nay, nhưng cũng đáng thử nghiệm. Có lẽ phần lớn các tính năng liên quan đến bộ nhớ mở rộng/expanded giờ sẽ không còn dùng được nữa

  • Đây lẽ ra hoàn toàn không nên được xem là điều gì ghê gớm. Nó nên được coi là chuyện thường ngày và hiển nhiên; nếu không làm được thì phải xem là một thất bại rất đáng xấu hổ và không thể chấp nhận
    Ý tôi không phải là theo tiêu chuẩn hỗn loạn của năm 2023 thì nó không ghê gớm. Ý tôi là đó mới là chuẩn mực mà chúng ta nên hướng tới

    • Đồng ý. Hầu như không có lý do gì để đa số binary biên dịch tĩnh phải ngừng hoạt động

  • Sẽ có người nói Linux cũng như vậy, và về mặt kỹ thuật thì đúng, nhưng thực tế khá khó
    kernel ABI ổn định, nhưng phần còn lại gần như là hỗn loạn thuần túy, do cách ứng dụng thường được đóng gói trên Linux. Bản thân ứng dụng có thể load được (nếu không phải định dạng a.out), nhưng rất có khả năng sẽ thất bại ở khâu load hầu hết thư viện. Cuối cùng sẽ cần một chroot của toàn bộ bản phân phối Linux làm mốc, hoặc một runtime khác, và cũng khó chắc có tìm được kho lưu trữ bản phân phối 30 năm tuổi hay không. Hơn nữa còn phải giả định kernel ABI thực sự không thay đổi một bit nào, và các interface khác như /proc hay /sys cũng không thay đổi. Hình như 30 năm trước còn chưa có /sys. Nếu là ứng dụng Xorg thì tôi sẽ không dám cược tiền ăn trưa vào khả năng tương thích ở mức protocol

    • Trên Linux nó cũng hoạt động theo cùng cách với Windows. Nếu không có thư viện động và cấu hình cần thiết thì sẽ không chạy
      Khó hiểu vì sao đây lại là điểm trừ cho Linux mà không phải cho Windows

  • Tôi luôn thấy tiếc vì phần mềm Mac cũ đơn giản là không chạy nữa. Việc Apple chuyển sang kiến trúc mới có thể là điều không tránh khỏi. Nhưng vấn đề là vài năm sau emulator lại bị hỏng
    Sự tận tâm mà Microsoft thể hiện với khách hàng lẽ ra không nên là điều đáng kinh ngạc như vậy. Mọi công ty đều nên hành xử như thế

    • Apple cũng từng có thời cho phép cài Mac OS X mới nhất lên cả iMac thế hệ đầu (300MHz?) nữa. Có thể phải nâng RAM lên tối đa, nhưng như vậy là đủ và thực tế dùng cũng khá ổn