Một chú chó đối đầu với stack đồ họa Windows 3.1

 (wuffs.org)
2 điểm bởi GN⁺ 2025-01-06 | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi cố dùng Windows 3.11 trên Asus Eee PC 1000H đời 2008 với màn hình 1024x600, các giới hạn của VGA mặc định và driver Microsoft Super VGA 256 màu đã lộ rõ
  • Hỗ trợ Super VGA của Windows 3.x không dựa trên một chuẩn chung, mà được thiết kế theo các phần mở rộng riêng của từng card; Intel GMA 950 của Eee PC không nằm trong danh sách được hỗ trợ
  • SVGAPatch sửa Microsoft svga256.drv để dùng các lệnh gọi VBE, cho phép xuất hình 256 màu ở độ phân giải cao, nhưng vẫn còn lỗi GUI bị hỏng sau khi chuyển màn hình DOS
  • Phân tích ngược cho thấy thiết lập mode ban đầu đã được đổi sang VBE, nhưng đường dẫn thiết lập lại khi chuyển màn hình vẫn gọi mode 30h dành cho Tseng ET4000 và thiết lập VBE scan line trong trạng thái text mode
  • Bản vá bổ sung đã giảm lỗi hỏng hình khi quay từ phiên DOS toàn màn hình về GUI, nhưng chưa xử lý triệt để cả trạng thái bank switching, nên trên Eee PC thật chỉ đạt mức GUI và chế độ cửa sổ có thể khôi phục được

Khôi phục đồ họa Windows 3.11 trên Eee PC

  • Thiết bị mục tiêu là Asus Eee PC 1000H mua năm 2008; do không hỗ trợ x86_64 nên hiện nay cũng khó chạy hầu hết các bản phân phối Linux mới
  • Mục tiêu là chạy Windows 3.11 for Workgroups trên chiếc netbook này với đầu ra video tốt hơn
  • Đầu ra mặc định là VGA 640x480 16 màu, nên trên màn hình 1024x600 trông không đẹp và tỷ lệ khung hình cũng không khớp
  • Bộ cài Windows 3.11 có kèm driver cho các bộ điều hợp video cũ, nhưng không hỗ trợ Intel GMA 950 của Eee PC
  • Driver Super VGA đi kèm có vẻ hỗ trợ tối đa 1024x768 256 màu, nhưng trong môi trường này nó báo lỗi và Windows không khởi động được

Khác biệt giữa VGA, SVGA và VBE

  • VGA là một bộ điều khiển video cụ thể do IBM thiết kế vào thập niên 1980, chứ không chỉ đơn giản là đầu nối analog màu xanh hay độ phân giải 640x480
  • SVGA gần với một thuật ngữ gom nhóm “những thứ phát triển hơn VGA cơ bản” hơn là một chuẩn; phần mềm phải hỗ trợ trực tiếp phần mở rộng riêng của từng card
  • Danh sách hỗ trợ của driver SVGA 256 màu của Microsoft gồm các dòng sau
    • ATI VGA series
    • Cirrus Logic VGA
    • Oak Technology VGA
    • Paradise VGA
    • Trident VGA
    • Tseng VGA
    • Video Seven VGA
    • Western Digital VGA
  • VBE(VESA BIOS Extensions) cho phép xử lý các chức năng ngoài VGA thông qua một giao diện chung, nhưng Windows 3.x không kèm driver VBE trực tiếp
  • VBE9x và VBEMP của BearWindows lần lượt cho phép dùng VBE trên Windows 9x và NT, nhưng không có phiên bản cho Windows 3.x

Những gì SVGAPatch giải quyết và những gì còn bỏ ngỏ

  • SVGAPatch vá driver Super VGA 256 màu của Microsoft để dùng VBE
  • Driver đã vá có thể hiển thị đúng các màn hình như 1024x600, nhưng phát sinh xung đột về tương thích DOS
  • Windows 3.1 Enhanced Mode có thể chạy đồng thời ứng dụng Windows đồ họa và ứng dụng DOS, đồng thời cũng có thể mở DOS prompt ở dạng cửa sổ hoặc toàn màn hình
  • Sau khi áp dụng SVGAPatch, các vấn đề sau được tái hiện
    • Khi vào chế độ DOS toàn màn hình rồi quay lại GUI Windows, màn hình bị hỏng
    • Trong một số trường hợp, chỉ cần mở DOS prompt dạng cửa sổ cũng làm hỏng màn hình
    • Lỗi tái hiện trên DOSBox, 86Box và Eee PC thật, nhưng cách hỏng hơi khác nhau
  • Một driver mới riêng biệt là PluMGMK/vbesvga.drv hỗ trợ cả chế độ true color, nhưng ở đây hướng phân tích là sửa mã Microsoft và SVGAPatch

Cấu trúc stack đồ họa Windows 3.x

  • Windows 3.x Enhanced Mode có cấu trúc trong đó Virtual Machine Manager ở protected mode 32-bit tạo nhiều VM, và Standard mode Windows chạy bên trong VM đầu tiên
  • Khi chọn bộ điều hợp video trong Windows Setup, không chỉ một driver đơn lẻ mà nhiều thành phần được cài cùng nhau
    • Grabber: được hiểu là chịu trách nhiệm render ứng dụng DOS ở chế độ cửa sổ
    • Display Driver: chịu trách nhiệm khởi tạo phần cứng và render GUI trong VM Windows chính; trong Windows 3.x, nó cũng tự triển khai phần lớn GDI
    • Virtual Display Device(VDD): chạy như một phần của Virtual Machine Manager, multiplex giữa ứng dụng DOS và phần cứng VGA thật
  • Các mục SVGA 256 màu dùng cùng một driver, được phân biệt bằng thiết lập độ phân giải và DPI trong SYSTEM.INI
  • SVGAPatch chỉ sửa Display Driver, không đụng đến SVGA VDD
  • Cuối cùng, cần hiểu cùng lúc Display Driver, VDD và các thay đổi không công khai do SVGAPatch tạo ra để khoanh vùng nguyên nhân hỏng màn hình

Tài liệu và công cụ dùng để phân tích ngược

  • Tài liệu tham khảo gồm Windows 3.x VDDVGA và Windows 3.1 DDK
  • Windows 3.1 DDK bao gồm các mã nguồn sau
    • Mã nguồn Display Driver cho VGA, IBM 8514, Video 7, SVGA 16 màu
    • Mã nguồn VDD cho VGA, IBM 8514, Video 7, SVGA 16 màu
    • Gần như toàn bộ mã nguồn Grabber
    • Rất ít tài liệu
  • Nhưng SVGA Display Driver 256 màu và mã nguồn VDD liên quan, tức những thứ thật sự cần, lại không có trong đó
  • IDA và Ghidra được dùng để phân tích svga256.drv và vddsvga.386
  • Ghidra đọc được .drv, nhưng VDD là VxD nên cần LX loader riêng, và có hạn chế khi xử lý tệp trộn lẫn mã 32-bit và 16-bit

Phân tích bên trong svga256.drv

  • svga256.drv có các hàm export như GETCHARWIDTH, STRETCHBLT, VIDEOINIT_ATI, có thể đối chiếu với mã nguồn DDK
  • Một số hàm gần như giống mã nguồn driver VGA, nhưng cũng có khác biệt như GETCHARWIDTH thiếu chức năng hiệu chỉnh chiều rộng bold font
  • Trong REALIZEOBJECT, có các khác biệt trông như mã của driver VGA và driver Video 7 bị trộn với nhau, và logic xử lý màu cũng khác
  • Chỉ các hàm GDI thì khó giải thích tương tác với bộ điều hợp video, nên phân tích tiếp sang đường khởi tạo physical_enable

physical_enable và cách driver SVGA của Microsoft hoạt động

  • Khi chọn “Super VGA (800x600, 256 colours, small fonts)” trong Windows Setup, SYSTEM.INI nhận các giá trị sau
    • dpi=96
    • resolution=2
  • Sau khi khởi động, driver đã vá ghi thêm các giá trị sau
    • svgamode=48
    • ChipSet=Tseng ET4000
    • LatchCapable=No
  • physical_enable là hàm khởi tạo cốt lõi: nó đặt video mode và duyệt danh sách mode được hỗ trợ để tìm mode theo chipset hoạt động được
  • Logic gốc của Microsoft có bảng mode được hỗ trợ theo từng độ phân giải, và thử từng mode bằng SetAndValidateMode
  • Nếu thành công, nó tìm và gọi hàm khởi tạo theo chipset, hàm thiết lập bank, v.v., rồi tiếp tục đặt palette, khởi tạo framebuffer và thiết lập địa chỉ VDD

Thay đổi thực tế của SVGAPatch

  • SVGAPatch đổi ID hàm của mục chipset đầu tiên trong ba danh sách độ phân giải thành 2000, đồng thời ghi đè SetAndValidateMode và một số hàm theo chipset
  • Các thay đổi chính như sau
    • SetAndValidateMode: thay vì thiết lập mode dựa trên VGA BIOS cũ, yêu cầu video mode mở rộng bằng VBE 4F02h
    • SETBANK_TRIDENT: thay vì ghi thanh ghi riêng của Trident, di chuyển cửa sổ bộ nhớ video bằng VBE 4F05h
    • VIDEOINIT_TRIDENT: thay vì ghi VGA CRTC Offset Register, thiết lập độ dài scan line bằng VBE 4F06h
  • Sau khi vá, mục đầu tiên trong danh sách mode được hỗ trợ thành công, và các hàm viết lại gắn với ID hàm 2000 được dùng
  • Lý do giá trị Tseng ET4000 được ghi vào SYSTEM.INI là vì tên của mục đầu tiên trong danh sách được lưu nguyên, dù giá trị đó thực tế không được dùng

VDD và DspDrvr_Addresses

  • VDD xử lý bằng ảo hóa tình huống chương trình DOS kỳ vọng mình độc quyền phần cứng thật
  • Mỗi VM có một instance của cấu trúc VDD_CB_Struc; cấu trúc này chứa flag, bản sao trạng thái bộ điều khiển VGA, và thông tin cấp phát bộ nhớ video theo từng VM
  • VDD có mã theo từng vendor để phát hiện bộ điều hợp VGA cụ thể và thay đổi cách lưu, khôi phục, mô phỏng các thanh ghi nhất định
  • DspDrvr_Addresses là service để Display Driver chuyển thông tin địa chỉ cho VDD; theo chú thích, DX là trường dành riêng và phải bằng 0, nhưng mã VGA VDD thực tế có hành vi đặc biệt khi DX khác 0
  • SVGA VDD có đường dẫn mới khi DX == 2, và SVGA256.DRV gọi hàm này với các giá trị sau
    • BX = 0xFFFF
    • DX = 2
    • DS:SI trỏ tới byte trạng thái shadow memory

Khoanh vùng nguyên nhân bằng DOSBox-X

  • Dùng Video debug overlay và debugger của DOSBox-X để so sánh trạng thái VGA trước và sau khi chuyển DOS prompt toàn màn hình
  • Chú thích mode hiển thị và trạng thái thanh ghi khác nhau giữa trạng thái GUI bình thường, DOS bình thường, GUI bị hỏng và DOS bị hỏng
  • Để kiểm tra liệu flag VDD vendor-specific có bị bật sai hay không, DOSBox-X được sửa để dump bộ nhớ vật lý, nhưng trong DOSBox flag đó không bật
  • Khi so sánh thanh ghi VGA, giá trị scan_len bên trong DOSBox khác nhau giữa trạng thái bình thường và trạng thái hỏng
    • DOS bình thường là 40
    • DOS bị hỏng là 296
    • GUI bình thường là 128
    • GUI bị hỏng là 256
  • Phần triển khai VESA Scan Line API của DOSBox tính scan_len khác nhau tùy theo video mode hiện tại, và điểm này được thu hẹp thành nghi vấn chính

Manh mối quyết định: đặt VBE scan line trong text mode

  • Khi thêm log thiết lập VESA scan line vào DOSBox-X, bắt được lệnh gọi sau
    • VESA_ScanLineLength(subcall=2, val=1024, bytes=2, pixels=1024, lines=4768)
    • Mode hiện tại là M_TEXT
  • Display Driver đặt độ dài scan line thành 1024 byte bằng VBE 4F06h, nhưng DOSBox coi hiện tại là text mode nên trạng thái nội bộ bị tính sai
  • Khi Windows khởi động, thiết lập scan line diễn ra bình thường ở SVGA 800x600 và trạng thái M_LIN8
  • Khi mở DOS prompt toàn màn hình rồi nhấn Alt+Enter để quay lại GUI, luồng sau xảy ra
    • Một đoạn mã nào đó yêu cầu chuyển sang mode 30h, tức số thập phân 48
    • patched display driver đặt độ dài scan line trong trạng thái text mode
    • Trạng thái nội bộ của DOSBox và trạng thái dựa trên thanh ghi VGA bị lệch nhau
  • Mode 30h là giá trị mode 800x600 của Tseng ET4000 đã bị SVGAPatch hijack

Đường chuyển màn hình bị bỏ sót

  • Windows 3.1 Display Driver hook INT 2Fh để nhận lệnh chuyển màn hình
  • Driver VGA xử lý bốn lệnh sau, nhưng driver SVGA256 chỉ hỗ trợ SCREEN_SWITCH_OUT và SCREEN_SWITCH_IN
    • SCREEN_SWITCH_OUT
    • SCREEN_SWITCH_IN
    • SAVE_DEV_REGS
    • RES_DEV_REGS
  • Hàm có vấn đề là dev_to_foreground, được gọi khi quay lại GUI Windows
  • dev_to_foreground của SVGA256 hoạt động theo luồng sau
    • Gọi farsetmode
    • farsetmode đặt mode 48
    • Gọi VideoInit theo chipset
    • Đặt enabled_flag thành 0xFF
    • Gọi Windows API SetPalette
  • SVGAPatch đã đổi đường thiết lập mode lúc khởi tạo sang VBE, nhưng không đổi đường đặt lại mode khi chuyển màn hình

Cải thiện khôi phục GUI bằng bản vá bổ sung

  • Mã setmode ban đầu có cấu trúc ngắn: đưa wGraphicsMode vào ax, gọi INT 10h, rồi gọi ptr_videoinit
  • Mã mới được chèn vào vùng trống còn lại sau SetAndValidateMode đã được SVGAPatch rút ngắn
    • Đưa giá trị CurrentHeight trừ 1 vào cx
    • Gọi SetAndValidateMode
    • Gọi ptr_videoinit
  • Lệnh đầu tiên của setmode được đổi thành nhảy tới mã mới, để khi chuyển màn hình cũng đi qua đường thiết lập mode dựa trên VBE
  • Sau sửa đổi này, màn hình không còn bị hỏng khi vào phiên DOS toàn màn hình rồi quay lại GUI
  • Tuy nhiên, vẫn còn vấn đề các chấm xuất hiện lại khi đi từ chế độ cửa sổ sang toàn màn hình

Vấn đề bank switching còn lại

  • Khi xem bộ nhớ VGA B8000 trong debugger DOSBox, nội dung văn bản vẫn tồn tại nhưng không hiện trên màn hình
  • Điểm nghi vấn là bank switching, được driver dùng để truy cập nhiều bộ nhớ video hơn
  • Sau khi thêm lệnh in trạng thái SVGA bank vào DOSBox-X, xác nhận rằng khi quay lại toàn màn hình, bộ điều hợp VGA vẫn nằm ở bank sai
  • Đã chèn routine mới vào dev_to_background để cố đưa bank về 0, nhưng vấn đề không được khắc phục
  • Phần triển khai VBE 4F05h của DOSBox ghi vào VGA CRTC register 0x6A, và khi dev_to_background được gọi thì VDD đã ở trạng thái trap các lệnh ghi, nên đã quá muộn

Kết quả thử nghiệm driver gốc và driver đã vá

  • Khi thử driver SVGA 256 màu gốc của Microsoft trong 86Box với nhiều card giả lập, kết quả không đồng đều ngay cả trong danh sách hỗ trợ
    • Cirrus Logic GD5420 (ISA): hoạt động
    • Tseng Labs ET4000AX: hoạt động
    • Oak OTI-077: màn hình hỏng khi mở DOS prompt dạng cửa sổ lần đầu, toàn màn hình có sọc dọc
    • Trident TVGA 8900D: màn hình hỏng trong DOS prompt toàn màn hình, chế độ cửa sổ bình thường
    • ATI VGA Wonder XL, Paradise PVGA1A, Video 7 VGA 1024i ở một số độ phân giải: Windows không khởi động được
  • Có lưu ý rằng 86Box không cung cấp đúng các card y hệt và độ chính xác giả lập cũng không chắc chắn
  • Kết quả thử driver dựa trên SVGAPatch đã sửa với các card mới hơn cũng khác nhau theo từng card
    • Matrox Millennium II: rất chậm, DOS dạng cửa sổ hoạt động nhưng toàn màn hình bị hỏng
    • 3dfx Voodoo Banshee: mở DOS dạng cửa sổ làm hỏng GUI, nhưng chuyển toàn màn hình hoạt động
    • S3 Trio3D/2X: màn hình hỏng khi Windows khởi động, nhưng sau DOS prompt rồi thoát khỏi toàn màn hình thì 1024x768 hiển thị bình thường
    • 3dfx Voodoo3 3500 SI: tương tự Banshee, nhưng toàn màn hình chỉ hoạt động một lần

Trạng thái cuối cùng trên Eee PC

  • Trên Eee PC thật, GUI hoạt động bình thường
  • Chuyển DOS prompt toàn màn hình vẫn bị hỏng, nhưng biểu hiện khác DOSBox
  • Trong DOSBox hiện text mode với nhiều ký tự bị hỏng, còn trên Eee PC là GUI bị hỏng với một số màu biến mất
  • Có thể khôi phục bằng cách chuyển lại sang chế độ cửa sổ
  • SVGAPatch ban đầu chỉ cần mở prompt dạng cửa sổ đã làm hỏng toàn bộ GUI và phải khởi động lại OS, nhưng driver đã sửa cải thiện đáng kể so với vậy
  • Với giải pháp tốt hơn, hướng được chọn là tiếp tục theo dõi PluMGMK/vbesvga.drv đang được phát triển tích cực

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-01-06
Ý kiến trên Hacker News

  • Bỏ qua chuyện hỗ trợ SVGA, điều luôn khiến tôi ngạc nhiên là khi cài Windows 3.x lên một PC hỗ trợ các chuẩn hiện đại, VGA cơ bản chạy ngay, trong khi trên Linux/BSD hiện đại, nếu không có driver phù hợp và file cấu hình thủ công thì ngay cả framebuffer VGA tăng tốc phần mềm cơ bản trong Xorg/Wayland cũng khó dùng được
    Dự án XFree86 đã chết có lẽ là nỗ lực gần nhất với kiểu “cứ chạy được”, nhưng vẫn còn xa, và có vẻ cách tiếp cận đó không được giữ lại trong fork Xorg

    • XFree86 cũng không làm gì khác Xorg trong chuyện này
      Nếu khởi động bằng CSM trên PC hiện đại, dù không nên khuyến nghị, Xorg đáng ra phải chạy video BIOS bằng x86emu và khởi lên với backend VBE; còn nếu khởi động bằng EFI, modesetting dựa trên efifb đáng ra phải chạy trên mode mà firmware và bootloader để lại
      Tuy nhiên đây là việc dễ hơn với hệ điều hành 16-bit hoặc 32-bit. Thiết lập mode VESA cần lời gọi real mode 16-bit, và dù về danh nghĩa ở giai đoạn sau của chuẩn có entry point 32-bit, hầu như chẳng nơi nào triển khai đúng. Khi đã vào mode 64-bit thì không thể dùng vm86, nên không thể gọi mã 16-bit từ user space; vì vậy cần x86emu để đọc mã video BIOS và chạy nó trong trình giả lập x86, nhưng không phải lúc nào cũng hoàn hảo
    • Linux có vgafb/vesafb, nên nếu bản phân phối được cấu hình phù hợp thì có thể làm được
      Tuy nhiên trải nghiệm thường có hiệu năng và chất lượng thấp, và người dùng có thể không biết nguyên nhân, nên có vẻ một số hoặc đa số bản phân phối không bật mặc định. Ngày nay gần như mọi GPU đều được hỗ trợ native, nên chắc cũng chẳng có động lực tạo popup kiểu “bạn đang dùng VGA/VESA không tăng tốc, hãy sửa đi”
    • Chuyện lâu rồi, nhưng tôi nhớ X từng có driver VGA phổ dụng “cứ chạy được”. Ý là giờ nó không còn nữa à?
    • X11 đã có driver VESA từ lâu, nhưng số pixel phải xử lý tăng nhanh theo độ phân giải nên khả năng mở rộng hiệu năng kém
      Các bản phân phối Linux có thể boot mà tôi dùng trong công việc, chủ yếu là GRML và Clonezilla, nhờ hỗ trợ KMS nên khi boot tự động khớp với màn hình hoặc độ phân giải native của KVM ảo, và hoạt động khá tốt. Anaconda, tức trình cài đặt họ RedHat, và trình cài đặt Debian cũng chuyển sang độ phân giải native khi boot
      Các trình cài đặt GUI dùng trực tiếp VESA trên X11
      Fork Xorg từ lâu cũng đã hỗ trợ “boot không cần file cấu hình”. Tôi đã không quản lý file cấu hình từ rất lâu rồi, và như vậy hài lòng hơn nhiều. Xem https://www.xkcd.com/963/
    • Tôi xem Xorg gần như là XFree86 đã được dọn dẹp hệ thống build

  • GUI Windows 3.1 ngày xưa trông trực quan, hiệu quả và dễ dùng hơn nhiều so với ngày nay
    https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...
    Với màn hình độ phân giải thấp như trong bài, Win11 rốt cuộc sẽ trông thế nào? Start menu của Win11 gần như không dùng được ngoài việc nhập từ khóa rồi cầu nguyện với mạch điện
    Giả thuyết ngây thơ của tôi là Windows NT và 2000 là điểm tối ưu, rồi sau đó các product manager bắt đầu phù phép. KDE và Gnome thì không thay đổi nhiều, nhưng càng theo thời gian lại càng trông hấp dẫn hơn :)

    • Tôi nghĩ phiên bản “tốt” cuối cùng là Windows 7. Nó giống NT/2000 nhưng đẹp hơn nhờ phần cứng đồ họa tốt hơn, và XP trước đó cũng vậy. Vista về bản thân UI cũng ổn, các khiếm khuyết nằm ở chỗ khác
      Windows 8 đã phá hỏng mọi thứ và Windows chưa bao giờ hồi phục. Tôi nghĩ có hai lý do: sự trỗi dậy của nền tảng di động và sự lười biếng của Microsoft
      Giờ phát sinh một vấn đề khó giải: nhiều ứng dụng có riêng phiên bản desktop và mobile. Một bên là màn hình lớn với bàn phím/chuột, bên kia là màn hình cảm ứng nhỏ, nên một ứng dụng desktop tốt và một ứng dụng mobile tốt phải hoàn toàn khác nhau. Nhưng người ta vẫn muốn hai phiên bản tạo cảm giác quen thuộc với người dùng, nên dù cố gắng hết sức cũng phải thỏa hiệp
      Microsoft lẽ ra vẫn có thể làm khá tốt, nhưng họ đã không làm. Nhìn Control Panel là thấy rõ. Settings, Control Panel mới, đã có từ thời Windows 8, tức 12 năm trước, vậy mà vẫn chưa chuyển hết mọi chức năng của Control Panel cũ sang, nên vẫn cần cả hai. Vài tháng trước họ định thử chuyển hẳn, nhưng chưa sẵn sàng, và tôi cũng không biết sau này có sẵn sàng không. Hơn nữa họ thường xuyên gỡ các tùy chọn tùy biến được ưa chuộng, và phong cách giữa các ứng dụng đi kèm cũng không nhất quán. Đây không chỉ là vấn đề gây tranh cãi, mà là tệ một cách khách quan
      Một yếu tố khác không thể chỉ đổ cho Microsoft và Windows là các nhà phát triển ứng dụng ưu tiên branding và tính nhất quán nội bộ hơn là tích hợp với hệ điều hành. Nhiều UI hiện đại chỉ là trang web được render bằng engine trình duyệt như Electron, không dùng control native của hệ điều hành, bỏ qua theme và tự vẽ cả phần trang trí cửa sổ. Hệ điều hành có thể không nhất quán, nhưng các nhà phát triển ứng dụng cũng chẳng giúp gì
    • Flat design gần như là thảm họa đối với ngành. Skeuomorphism thực ra cũng là flat design dán thêm hình ảnh, nên cũng khá tệ
      Windows Forms đã làm đúng rất nhiều thứ, và nếu phải chọn một ký hiệu còn thiếu thì có lẽ là “đang hoạt động nhưng không thể chỉnh sửa”
    • Theo lời đồn, Windows 11 vốn là Windows 10X được làm cả cho điện thoại và máy tính bảng. Start menu có vẻ chịu ảnh hưởng khá nhiều từ Android: hiển thị phẳng mọi thứ đã cài và thúc đẩy người dùng tìm kiếm nhiều hơn
      Dù vậy tôi đồng ý. Bản beta Win10 từng có dạng kết hợp giữa tile và danh sách kiểu Windows 7, vốn là cách kéo dài đến Windows 2000, và tôi nghĩ đó là đỉnh cao. Nó có thể có ưu điểm của cả hai. Notification area thì luôn yếu, còn panel Settings thì tệ so với Control Panel. Tất nhiên Control Panel cũng lộn xộn và phức tạp, nên việc nó có phải tốt nhất hay không vẫn có thể tranh luận

  • Tác giả nói rằng màn hình bị vỡ khi mở prompt DOS ở chế độ cửa sổ; điều này có thể xảy ra vì prompt DOS chạy trong một VM riêng, tức chế độ V86, và gọi VGA ROM BIOS bằng INT 10h
    VGA ROM BIOS của thiết bị này có lẽ là một wrapper trên VBE, nghĩa là có thể chứa các lệnh IN/OUT truy cập vào các cổng I/O VBE là 0x1CE và 0x1CF. Những thao tác đọc/ghi như vậy phát sinh trong DOS VM, nếu VMM không ảo hóa, về cơ bản sẽ đi thẳng tới phần cứng thật
    Đây là vấn đề phổ biến mà các tác giả driver hiển thị Windows 3.x/9x phải xử lý, nhưng số cổng I/O cần ảo hóa lại khác nhau tùy từng adapter đồ họa. Win95 DDK có ví dụ dùng các dịch vụ VMM là Install_IO_Handler và Enable/Disable_Global_Trapping để thiết lập trap cổng I/O, rồi trong handler trap dùng VDD_Get_VM_Info để xác định VM nào hiện đang sở hữu CRTC. Nhờ đó handler trap có thể quyết định có gửi I/O xuống phần cứng hay không, hoặc ảo hóa theo cách nào. Một chính sách ảo hóa tốt để bắt đầu là đơn giản bỏ qua các lệnh ghi từ VM không phải chủ sở hữu CRTC, rồi thêm độ phức tạp cần thiết về sau

  • Virtual Display Device(VDD) chạy như một phần của trình quản lý máy ảo nền tảng, và hoạt động giống một bộ ghép kênh cho phần cứng video. Nếu ứng dụng DOS ở toàn màn hình thì lệnh được chuyển trực tiếp tới adapter VGA “thật”; nếu không thì VDD sẽ mô phỏng
    Việc người khác tái khám phá cấu trúc này khá thú vị. Cá nhân tôi thấy đây là một cấu trúc đi trước thời đại đáng kể, còn có trước các hypervisor hiện đại có hardware passthrough. Bản thân GUI Windows 3.x, bao gồm các tiến trình đa nhiệm ưu tiên, thực chất chạy như một tiến trình DOS chế độ bảo vệ mở rộng bên trong một VM chạy DOS, còn kernel hypervisor VMM32 thì ghép kênh giữa nó và các VM tiến trình DOS khác. Vì vậy một phần của driver hiển thị tương tác với “phần cứng” bên dưới GDI, còn phần khác chạy ở ring 0 để ảo hóa phần cứng và ghép kênh với các VM khác
    Điều này có thể sửa trong DOSBox, nhưng bản sửa đó sẽ bị gắn với adapter video cụ thể mà DOSBox mô phỏng. Thứ mong muốn không phải vậy, mà là làm cho bản vá VBE tổng quát hoạt động tốt hơn
    Tôi từng viết driver framebuffer VESA cho Win9x dành cho Intel GMA950 và còn thêm tăng tốc cơ bản, tức các lệnh blitter và fill; khi gặp gần như cùng vấn đề, tôi đã hiểu vì sao Win9x không có driver VESA tổng quát. VDD phải biết cách lưu và khôi phục trạng thái GPU, mà các chi tiết đó dĩ nhiên phụ thuộc vào nhà cung cấp. Tôi cũng từng nghĩ tới vài ý tưởng có thể làm theo cách tổng quát, chẳng hạn mô phỏng hoặc theo dõi VBIOS để xem mỗi lần chuyển mode thì nó chạm vào những cổng và MMIO nào, nhưng chưa triển khai được
    Trong DOSBox thì hiện ra chế độ văn bản đầy ký tự hỏng, còn trên Eee PC thì hiện GUI lỗi, mất một số màu
    Trông như các thanh ghi palette không được lưu/khôi phục đúng cách. Ngoài ra, lỗi vỡ ở phần trên màn hình có thể tránh được bằng cách chuyển mặt phẳng hiển thị độ phân giải cao lên trên mốc 256K, để lại 256K đầu của VRAM cho các mặt phẳng VGA và mô phỏng VGA. May là Intel GMA có khá nhiều tài liệu công khai. Không phải tài liệu của 900 và 950, mà là tài liệu 810/815 và từ 965 trở đi, nhưng hầu hết thanh ghi và lệnh không thay đổi, nên vẫn có thể tham khảo chi tiết

  • “Không có hỗ trợ x86_64 nên cũng không chạy được phần lớn các bản phân phối Linux hiện đại”, nhưng Eee của tôi vẫn sống ổn với Debian 32-bit
    Firefox quá nặng nên gần như rất ì ạch, nhưng stream video bằng mpv thì vẫn đủ dùng. Tôi chủ yếu dùng nó như một chiếc máy đánh chữ ít yếu tố gây xao nhãng, có thể chạy pandoc khi công việc viết sách bị dồn lại

    • Tôi hoàn toàn đồng ý rằng khi viết thì một máy tính có tối thiểu yếu tố gây xao nhãng là tốt. Cho mục đích đó tôi dùng WordPerfect 5.1 trên PS/2 386SX
      Tôi từng thích EEE vì cực kỳ dễ mang theo, nhưng thấy bàn phím quá nhỏ để gõ nghiêm túc
    • Nếu coi như dùng mà không có web hay ứng dụng hiện đại, thì những thứ như Haiku OS có thể là một use case thú vị
      Tôi từng dùng thử trên PC; đúng là phần mềm khả dụng quá thiếu để trở thành hệ điều hành hằng ngày thực sự, nhưng với các mục đích kết nối thấp như máy đánh chữ và mail thì nó đem lại cảm giác là một hệ điều hành rất thú vị
      Tôi thích cảm giác nhất quán từ UI, phần mềm cơ bản cho tới filesystem. Nếu tôi hiểu đúng, filesystem là biểu diễn của mọi dữ liệu, “file” có thể có metadata tùy ý, và gần như mọi thứ đều làm được trong trình quản lý file. Toàn bộ filesystem giống một cơ sở dữ liệu NoSQL, và các ứng dụng cũng tiếp nhận điều đó một cách tự nhiên. Danh bạ là các “file” trong một thư mục, mail cũng là các “file” trong một thư mục, kiểu như vậy
      Hồi đó tôi chưa từng đụng tới BeOS, nhưng vào thập niên 90 khi mức độ kết nối còn thấp, paradigm này có lẽ khá phù hợp. Việc viết một “file” mail khi không có Internet, kéo thả nó vào ổ đĩa mềm, rồi gửi qua Internet trên máy tính khác, tất cả chỉ bằng trình quản lý file, nhất quán đến mức đáng ngạc nhiên
      Đáng tiếc là ngay khi phải tương tác với các máy tính khác không tương thích với filesystem BeOS/Haiku, tính hữu dụng của paradigm này giảm đi. Vì về mặt thống kê, gần như mọi máy tính đều như vậy
      Nhưng với một thiết bị dùng làm máy đánh chữ thì có thể thú vị
    • Theo tôi biết, Debian sẽ loại bỏ hỗ trợ 32-bit x86 trong bản phát hành tiếp theo
    • Tôi từng có một chiếc 1215B nhưng nó đã chết năm ngoái, và giờ tablet Android thay thế nó
      Có vẻ tablet đã quét sạch phân khúc thị trường netbook. Ultraportable hay 2-in-1 thì vẫn còn, nhưng chúng gần như nằm ở đầu đối diện của dải giá

  • Tiêu đề hơi gây nhầm lẫn
    Dù vậy, mỗi lần đọc về cách Windows dựa trên DOS ngày xưa hoạt động bên trong, tôi luôn thấy nể phục. Mọi thứ có vẻ được dán lại bằng băng keo phần mềm, nhưng somehow vẫn chạy

    • Cứ nghe Casey Muratori nói là được. Ý là người ta đã tạo ra một đống abstraction khổng lồ nhưng thực ra không cần thiết, chỉ làm hiệu năng tệ đi

  • Tôi nhớ là khi ET4000H ra mắt, Windows 3.1 khi đó chưa hỗ trợ nó. Tôi gọi cho bộ phận hỗ trợ kỹ thuật của MS thì họ gửi đĩa driver, và 8 tiếng sau nó đến nơi
    Đó là lần hỗ trợ tốt nhất tôi từng nhận được cho một sản phẩm sao chép lậu

    • Nói chính xác thì ET4000H giống ET4000ax vốn đã được Windows 3.0 và 3.1 hỗ trợ, nhưng thay vì DAC 256 màu thì nó có HiDAC, tức true color 15/16-bit
      Ký ức hơi mờ, nhưng có vẻ driver mặc định chạy được chế độ 16 màu, còn từ 256 màu trở lên thì không, và lựa chọn độ phân giải cũng có thể bị hạn chế
      Theo MS, driver hỗ trợ HiDAC được phát hành vào tuần thứ ba của tháng 4 năm 1992, muộn hơn thời điểm tôi nhớ khoảng 1–2 tuần, nên nhìn chung có vẻ khớp

  • Thú vị thật. Tôi có mẫu nhỏ EEEPC 701 và nó vẫn còn chạy, nhưng chưa từng nghĩ đến việc dùng để chơi game retro
    Cái của tôi chỉ đang bám bụi, thử mấy thứ như thế này chắc sẽ vui

    • Có vẻ là nói về 701. 207g không phải tên model Eee PC

  • Tôi thử vô tình so sánh các chú thích nhỏ, và thấy các thay đổi trạng thái tiếp theo mà có lẽ tác giả đã nhìn đến mức bão hòa ngữ nghĩa
    Functional GUI: M_LIN8 G800x600 > 800x600 @00000+100+Dch4
    Functional DOS: M_TEXT T80x25 > 720x400 @00000+050-W
    Broken GUI: M_VGA G400x600 > 400x600 @00000+200-Dch4
    Broken DOS: M_TEXT T80x25 > 720x400 @00000+250-W
    Theo mẫu thì DOS bị hỏng và GUI bị hỏng là 200 hoặc 250, còn bình thường là 100 hoặc 050. Địa chỉ đó là gì vậy?
    GUI bị hỏng không hiểu sao lại ở chế độ M_VGA chứ không phải LIN8. Nó đã xảy ra như thế nào, tại sao lại vậy, và liệu có liên quan đến việc thành 400x600, tức bằng một nửa chiều ngang của 800x600 không? “Chế độ văn bản” thực tế là 720x400, như thấy ở hai chế độ DOS

  • Không biết tác giả có thấy không, nhưng tôi đã báo bài này cho người viết bản vá
    https://www.bttr-software.de/forum/board_entry.php?id=22124#...