ดวลกันระหว่างสุนัขหนึ่งตัวกับสแตกกราฟิกของ Windows 3.1

 (wuffs.org)
2 คะแนน โดย GN⁺ 2025-01-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระหว่างพยายามใช้งาน Windows 3.11 บน Asus Eee PC 1000H รุ่นปี 2008 ให้พอดีกับจอ 1024x600 ก็พบข้อจำกัดของไดรเวอร์ VGA พื้นฐานและไดรเวอร์ Microsoft 256 สี Super VGA
  • การรองรับ Super VGA ของ Windows 3.x ไม่ได้อิงมาตรฐานร่วม แต่เป็นโครงสร้างที่ผูกกับ ส่วนขยายเฉพาะของการ์ดแต่ละรุ่น และ Intel GMA 950 ของ Eee PC ก็ไม่อยู่ในรายการที่รองรับ
  • SVGAPatch เปลี่ยน svga256.drv ของ Microsoft ให้ใช้การเรียก VBE ทำให้แสดงผล 256 สีที่ความละเอียดสูงได้ แต่ยังมีปัญหา GUI เพี้ยนหลังสลับไปหน้าจอ DOS
  • จากการวิเคราะห์ย้อนกลับ พบว่าการตั้งค่าโหมดเริ่มต้นถูกเปลี่ยนเป็น VBE แล้วก็จริง แต่ เส้นทางรีเซ็ตตอนสลับหน้าจอ ยังเรียกโหมด 30h สำหรับ Tseng ET4000 และตั้งค่า VBE scan line ขณะอยู่ใน text mode เหมือนเดิม
  • หลังแพตช์เพิ่ม อาการภาพเพี้ยนตอนกลับจาก DOS แบบเต็มหน้าจอไป GUI ลดลง แต่ก็ยังแก้ สถานะ bank switching ได้ไม่สมบูรณ์ ทำให้บน Eee PC จริงใช้งานได้ในระดับที่กู้คืน GUI และโหมดหน้าต่างได้

กู้กราฟิก Windows 3.11 บน Eee PC

  • อุปกรณ์เป้าหมายคือ Asus Eee PC 1000H ที่ซื้อมาในปี 2008 ซึ่งตอนนี้แม้แต่ Linux ดิสโทรสมัยใหม่ส่วนใหญ่ก็รันได้ยาก เพราะไม่รองรับ x86_64
  • เป้าหมายคือทำให้เน็ตบุ๊กรุ่นนี้รัน Windows 3.11 for Workgroups ด้วยการแสดงผลวิดีโอที่ดีกว่าเดิม
  • การแสดงผลพื้นฐานคือ VGA 640x480 16 สี ซึ่งบนจอ 1024x600 ทั้งดูไม่สวยและสัดส่วนภาพก็ไม่พอดี
  • ตัวติดตั้ง Windows 3.11 มีไดรเวอร์สำหรับอะแดปเตอร์วิดีโอรุ่นเก่ารวมมาให้ แต่ไม่รองรับ Intel GMA 950 ของ Eee PC
  • ไดรเวอร์ Super VGA ที่แถมมาดูเหมือนจะรองรับสูงสุด 1024x768 256 สี แต่ในสภาพแวดล้อมนี้เกิดข้อผิดพลาดจน Windows บูตไม่ขึ้น

ความต่างระหว่าง VGA, SVGA และ VBE

  • VGA คือคอนโทรลเลอร์วิดีโอเฉพาะรุ่นที่ IBM ออกแบบในยุค 1980s ไม่ได้หมายถึงเพียงคอนเน็กเตอร์อนาล็อกสีน้ำเงินหรือความละเอียด 640x480
  • SVGA ใกล้เคียงกับคำเรียกรวมว่า “ก้าวหน้ากว่า VGA พื้นฐาน” มากกว่าจะเป็นมาตรฐานจริง ๆ และซอฟต์แวร์ต้องรองรับส่วนขยายเฉพาะของแต่ละการ์ดโดยตรง
  • รายการที่ไดรเวอร์ 256 สี SVGA ของ Microsoft รองรับมีตระกูลต่อไปนี้
    • 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) ช่วยให้ใช้งานฟังก์ชันนอกเหนือจาก VGA ผ่านอินเทอร์เฟซร่วมได้ แต่ Windows 3.x ไม่มีไดรเวอร์ VBE โดยตรงรวมมาให้
  • VBE9x และ VBEMP ของ BearWindows ช่วยให้ Windows 9x และ NT ใช้ VBE ได้ตามลำดับ แต่ไม่มีเวอร์ชันสำหรับ Windows 3.x

สิ่งที่ SVGAPatch แก้ได้และสิ่งที่ยังค้างอยู่

  • SVGAPatch แพตช์ไดรเวอร์ 256 สี Super VGA ของ Microsoft ให้ใช้ VBE
  • ไดรเวอร์ที่ถูกแพตช์แล้วสามารถแสดงผลจออย่าง 1024x600 ได้ถูกต้อง แต่มีปัญหาปะทะกับความเข้ากันได้ของ DOS
  • Windows 3.1 Enhanced Mode สามารถรันทั้งแอปกราฟิกของ Windows และแอป DOS พร้อมกันได้ และยังเปิด DOS prompt ได้ทั้งแบบหน้าต่างหรือเต็มหน้าจอ
  • หลังใช้ SVGAPatch พบปัญหาต่อไปนี้ซ้ำได้
    • เข้าโหมด DOS เต็มหน้าจอแล้วกลับมาที่ Windows GUI จะเกิดภาพเพี้ยน
    • บางกรณี แค่เปิด DOS prompt แบบหน้าต่างก็ทำให้ภาพเพี้ยน
    • พบอาการนี้ได้ทั้งใน DOSBox, 86Box และ Eee PC จริง แต่รูปแบบความเพี้ยนต่างกันเล็กน้อย
  • ไดรเวอร์ใหม่แยกต่างหาก PluMGMK/vbesvga.drv รองรับถึงโหมด true color แต่การวิเคราะห์ในที่นี้เลือกแก้ต่อจากโค้ดของ Microsoft และ SVGAPatch

โครงสร้างสแตกกราฟิกของ Windows 3.x

  • Windows 3.x Enhanced Mode มีโครงสร้างที่ Virtual Machine Manager แบบ protected mode 32 บิตสร้าง VM หลายตัว และรัน Standard mode Windows อยู่ใน VM ตัวแรก
  • เมื่อเลือกอะแดปเตอร์วิดีโอใน Windows Setup สิ่งที่ติดตั้งไม่ใช่ไดรเวอร์เดี่ยว แต่เป็นหลายองค์ประกอบร่วมกัน
    • Grabber: เข้าใจว่าใช้สำหรับเรนเดอร์แอป DOS แบบหน้าต่าง
    • Display Driver: รับผิดชอบการเริ่มต้นฮาร์ดแวร์และเรนเดอร์ GUI ภายใน Windows VM หลัก และใน Windows 3.x ยังมีการทำ GDI จำนวนมากไว้เองด้วย
    • Virtual Display Device (VDD): รันเป็นส่วนหนึ่งของ Virtual Machine Manager และทำหน้าที่ multiplex ระหว่างแอป DOS กับฮาร์ดแวร์ VGA จริง
  • รายการ 256 สี SVGA ใช้ไดรเวอร์เดียวกัน และแยกกันด้วยค่าความละเอียดกับ DPI ใน SYSTEM.INI
  • SVGAPatch แก้เฉพาะ Display Driver และไม่แตะ SVGA VDD
  • สุดท้ายจึงต้องเข้าใจทั้ง Display Driver, VDD และการเปลี่ยนแปลงแบบไม่เปิดเผยที่ SVGAPatch สร้างขึ้นร่วมกัน จึงจะบีบวงหาสาเหตุของภาพเพี้ยนได้

เอกสารและเครื่องมือที่ใช้ในการวิเคราะห์ย้อนกลับ

  • ใช้ Windows 3.x VDDVGA และ Windows 3.1 DDK เป็นเอกสารอ้างอิง
  • ใน Windows 3.1 DDK มีซอร์สต่อไปนี้รวมอยู่
    • ซอร์ส Display Driver ของ VGA, IBM 8514, Video 7 และ SVGA 16 สี
    • ซอร์ส VDD ของ VGA, IBM 8514, Video 7 และ SVGA 16 สี
    • ซอร์ส Grabber เกือบทั้งหมด
    • เอกสารในปริมาณน้อยมาก
  • แต่ซอร์สที่ต้องการจริงอย่าง 256 สี SVGA Display Driver และ VDD ที่เกี่ยวข้องกลับไม่มีให้
  • ใช้ IDA และ Ghidra ในการวิเคราะห์ svga256.drv และ vddsvga.386
  • Ghidra อ่าน .drv ได้ แต่ VDD เป็น VxD จึงต้องใช้ LX loader แยก และยังมีข้อจำกัดกับไฟล์ที่ผสมโค้ด 32 บิตกับ 16 บิตเข้าด้วยกัน

การวิเคราะห์ภายใน svga256.drv

  • ใน svga256.drv มีฟังก์ชัน export อย่าง GETCHARWIDTH, STRETCHBLT, VIDEOINIT_ATI ทำให้เทียบกับซอร์สใน DDK ได้
  • บางฟังก์ชันแทบเหมือนกับซอร์สไดรเวอร์ VGA แต่บางส่วนก็มีความต่าง เช่น GETCHARWIDTH ที่ไม่มีฟังก์ชันชดเชยความกว้างของ bold font
  • ใน REALIZEOBJECT เห็นความต่างที่เหมือนโค้ดจากไดรเวอร์ VGA และ Video 7 ถูกผสมกัน และลอจิกด้านสีก็แตกต่างกันด้วย
  • เพราะดูจากฟังก์ชัน GDI อย่างเดียวอธิบายการโต้ตอบกับอะแดปเตอร์วิดีโอได้ยาก จึงขยับไปวิเคราะห์เส้นทางเริ่มต้นอย่าง physical_enable

physical_enable กับวิธีทำงานของไดรเวอร์ Microsoft SVGA

  • เมื่อเลือก “Super VGA (800x600, 256 colours, small fonts)” ใน Windows Setup ค่าใน SYSTEM.INI จะเป็นดังนี้
    • dpi=96
    • resolution=2
  • หลังบูต ไดรเวอร์ที่ถูกแพตช์จะเขียนค่าเพิ่มดังนี้
    • svgamode=48
    • ChipSet=Tseng ET4000
    • LatchCapable=No
  • physical_enable คือฟังก์ชันเริ่มต้นหลักที่ตั้งค่าโหมดวิดีโอ และไล่ดูรายการโหมดที่รองรับเพื่อหาโหมดตามชิปเซ็ตที่ใช้งานได้
  • ลอจิกต้นฉบับของ Microsoft มีตารางโหมดที่รองรับตามความละเอียด และใช้ SetAndValidateMode ทดสอบแต่ละโหมด
  • เมื่อสำเร็จ ก็จะค้นหาและเรียกฟังก์ชันเริ่มต้นเฉพาะชิปเซ็ต ฟังก์ชันตั้ง bank และอื่น ๆ ต่อไป รวมถึงตั้ง palette, ล้าง framebuffer และตั้งค่า address ให้ VDD

การเปลี่ยนแปลงจริงที่ SVGAPatch ทำ

  • SVGAPatch เปลี่ยน function ID ของรายการชิปเซ็ตตัวแรกในรายการความละเอียดทั้งสามชุดเป็น 2000 แล้วเขียนทับ SetAndValidateMode กับฟังก์ชันเฉพาะชิปเซ็ตบางส่วน
  • การเปลี่ยนหลักมีดังนี้
    • SetAndValidateMode: จากเดิมที่ตั้งโหมดผ่าน VGA BIOS เปลี่ยนเป็นร้องขอโหมดวิดีโอขยายด้วย VBE 4F02h
    • SETBANK_TRIDENT: จากเดิมเขียนรีจิสเตอร์เฉพาะของ Trident เปลี่ยนเป็นย้ายหน้าต่างหน่วยความจำวิดีโอด้วย VBE 4F05h
    • VIDEOINIT_TRIDENT: จากเดิมเขียน VGA CRTC Offset Register เปลี่ยนเป็นตั้งความยาว scan line ด้วย VBE 4F06h
  • หลังแพตช์ รายการโหมดที่รองรับตัวแรกจะผ่านสำเร็จ และฟังก์ชันที่เขียนใหม่ซึ่งผูกกับ function ID 2000 จะถูกใช้งาน
  • เหตุผลที่ SYSTEM.INI ยังบันทึกค่า Tseng ET4000 ก็เพราะชื่อของรายการแรกยังถูกเก็บไว้เหมือนเดิม แม้ค่าจริงจะไม่ได้ถูกใช้แล้วก็ตาม

VDD กับ DspDrvr_Addresses

  • VDD ใช้ virtualization รับมือกับกรณีที่โปรแกรม DOS คาดว่าจะครอบครองฮาร์ดแวร์จริงแต่เพียงผู้เดียว
  • แต่ละ VM มีอินสแตนซ์ของโครงสร้าง VDD_CB_Struc ซึ่งเก็บแฟลก มิเรอร์สถานะคอนโทรลเลอร์ VGA และข้อมูลการจัดสรรหน่วยความจำวิดีโอต่อ VM
  • ภายใน VDD มีโค้ดเฉพาะผู้ผลิตสำหรับตรวจจับอะแดปเตอร์ VGA บางรุ่น และเปลี่ยนวิธีบันทึก กู้คืน หรือจำลองรีจิสเตอร์บางตัว
  • DspDrvr_Addresses คือ service ที่ Display Driver ใช้ส่งข้อมูล address ให้ VDD โดยในคอมเมนต์ระบุว่า DX เป็นฟิลด์สงวนที่ควรเป็น 0 แต่ในโค้ด VGA VDD จริงกลับมีพฤติกรรมพิเศษเมื่อ DX ไม่เป็น 0
  • ใน SVGA VDD มีเส้นทางใหม่เมื่อ DX == 2 และ SVGA256.DRV เรียกฟังก์ชันนี้ด้วยค่าต่อไปนี้
    • BX = 0xFFFF
    • DX = 2
    • DS:SI ชี้ไปยังไบต์สถานะของ shadow memory

บีบวงหาสาเหตุด้วย DOSBox-X

  • ใช้ Video debug overlay และดีบักเกอร์ของ DOSBox-X เพื่อเทียบสถานะ VGA ก่อนและหลังสลับเข้า DOS prompt แบบเต็มหน้าจอ
  • คำอธิบายโหมดที่แสดงและสถานะรีจิสเตอร์ต่างกันระหว่าง GUI ปกติ, DOS ปกติ, GUI ที่เพี้ยน และ DOS ที่เพี้ยน
  • เพื่อเช็กว่า vendor-specific VDD flag ถูกเปิดผิดหรือไม่ จึงแก้ DOSBox-X ให้ dump หน่วยความจำจริง แต่ใน DOSBox ไม่พบว่าแฟลกดังกล่าวถูกเปิด
  • เมื่อลองเทียบรีจิสเตอร์ VGA พบว่าค่า scan_len ภายใน DOSBox ต่างกันระหว่างสถานะปกติกับสถานะเพี้ยน
    • DOS ปกติ: 40
    • DOS เพี้ยน: 296
    • GUI ปกติ: 128
    • GUI เพี้ยน: 256
  • การทำงานของ VESA Scan Line API ใน DOSBox คำนวณ scan_len ต่างกันตามการตัดสินใจว่าโหมดวิดีโอปัจจุบันคืออะไร และจุดนี้จึงกลายเป็นผู้ต้องสงสัยหลัก

เบาะแสชี้ขาด: การตั้งค่า VBE scan line ใน text mode

  • เมื่อลองเพิ่มล็อกการตั้งค่า VESA scan line ใน DOSBox-X ก็พบการเรียกดังนี้
    • VESA_ScanLineLength(subcall=2, val=1024, bytes=2, pixels=1024, lines=4768)
    • โหมดปัจจุบันคือ M_TEXT
  • Display Driver ตั้งความยาว scan line เป็น 1024 ไบต์ผ่าน VBE 4F06h แต่ DOSBox มองว่าสถานะปัจจุบันยังเป็น text mode จึงคำนวณสถานะภายในผิด
  • ตอนเริ่ม Windows การตั้งค่า scan line ทำงานปกติในโหมด 800x600 SVGA และสถานะ M_LIN8
  • แต่เมื่อเปิด DOS prompt แบบเต็มหน้าจอแล้วกด Alt+Enter เพื่อกลับไป GUI จะเกิดลำดับดังนี้
    • มีโค้ดบางส่วนร้องขอให้สลับไปโหมด 30h หรือเลขฐานสิบ 48
    • patched display driver ตั้งค่า scan line ขณะยังอยู่ใน text mode
    • สถานะภายในของ DOSBox กับสถานะที่อิงรีจิสเตอร์ VGA จึงไม่ตรงกัน
  • โหมด 30h ก็คือค่าโหมด 800x600 ของ Tseng ET4000 ที่ SVGAPatch เข้าไป hijack ไว้นั่นเอง

เส้นทางสลับหน้าจอที่ยังไม่ถูกแพตช์

  • Display Driver ของ Windows 3.1 hook INT 2Fh เพื่อรับคำสั่งสลับหน้าจอ
  • ไดรเวอร์ VGA รองรับคำสั่ง 4 ตัวต่อไปนี้ แต่ไดรเวอร์ SVGA256 รองรับแค่ SCREEN_SWITCH_OUT กับ SCREEN_SWITCH_IN
    • SCREEN_SWITCH_OUT
    • SCREEN_SWITCH_IN
    • SAVE_DEV_REGS
    • RES_DEV_REGS
  • ฟังก์ชันที่มีปัญหาคือ dev_to_foreground ซึ่งถูกเรียกตอนกลับสู่ Windows GUI
  • การทำงานของ dev_to_foreground ใน SVGA256 เป็นดังนี้
    • เรียก farsetmode
    • farsetmode ตั้งโหมด 48
    • เรียก VideoInit ตามชิปเซ็ต
    • ตั้ง enabled_flag เป็น 0xFF
    • เรียก Windows API SetPalette
  • SVGAPatch เปลี่ยนเส้นทางตั้งโหมดในช่วงเริ่มต้นให้เป็น VBE แล้ว แต่ เส้นทางที่ตั้งโหมดซ้ำตอนสลับหน้าจอ ยังไม่ได้เปลี่ยน

ปรับปรุงการกู้ GUI ด้วยแพตช์เพิ่ม

  • เดิมโค้ด setmode มีโครงสร้างสั้น ๆ คือใส่ wGraphicsMode ลง ax เรียก INT 10h แล้วค่อยเรียก ptr_videoinit
  • จึงแทรกโค้ดใหม่ลงในพื้นที่ว่างที่เหลืออยู่หลัง SetAndValidateMode ซึ่ง SVGAPatch ทำให้สั้นลง
    • นำค่า CurrentHeight ลบ 1 แล้วใส่ใน cx
    • เรียก SetAndValidateMode
    • เรียก ptr_videoinit
  • จากนั้นเปลี่ยนคำสั่งแรกของ setmode ให้กระโดดไปยังโค้ดใหม่ เพื่อให้ตอนสลับหน้าจอเองก็วิ่งผ่านเส้นทางตั้งโหมดแบบ VBE ด้วย
  • หลังแก้แบบนี้ เข้าเซสชัน DOS แบบเต็มหน้าจอแล้วกลับมาที่ GUI ได้โดยไม่เกิดภาพเพี้ยนอีกต่อไป
  • อย่างไรก็ตาม ยังเหลือปัญหาที่เมื่อสลับจากโหมดหน้าต่างไปเต็มหน้าจอ จุดบางจุดจะกลับมาอีก

ปัญหา bank switching ที่ยังเหลือ

  • เมื่อดูหน่วยความจำ VGA ที่ B8000 ในดีบักเกอร์ของ DOSBox จะเห็นว่าข้อความยังอยู่ แต่บนหน้าจอกลับไม่แสดง
  • จุดที่น่าสงสัยคือ bank switching ซึ่งไดรเวอร์ใช้เพื่อเข้าถึงหน่วยความจำวิดีโอที่มากขึ้น
  • หลังเพิ่มคำสั่งให้ DOSBox-X แสดงสถานะ SVGA bank ก็พบว่าเมื่อกลับสู่โหมดเต็มหน้าจอ อะแดปเตอร์ VGA ค้างอยู่ที่ bank ผิด
  • มีการใส่รูทีนใหม่ใน dev_to_background เพื่อรีเซ็ต bank กลับเป็น 0 แต่ก็ยังไม่แก้ปัญหา
  • การ implement VBE 4F05h ของ DOSBox เขียนผ่าน VGA CRTC register 0x6A และเมื่อ dev_to_background ถูกเรียก VDD ก็เข้าสู่สถานะดักจับการเขียนแล้ว ทำให้ช้าเกินไป

ผลการทดลองกับไดรเวอร์ต้นฉบับและไดรเวอร์ที่แพตช์

  • เมื่อลองทดสอบไดรเวอร์ SVGA 256 สีต้นฉบับของ Microsoft บนการ์ดจำลองหลายรุ่นใน 86Box พบว่าผลลัพธ์ไม่สม่ำเสมอแม้จะอยู่ในรายการรองรับ
    • Cirrus Logic GD5420 (ISA): ใช้งานได้
    • Tseng Labs ET4000AX: ใช้งานได้
    • Oak OTI-077: เปิด DOS prompt แบบหน้าต่างครั้งแรกแล้วภาพเพี้ยน และแบบเต็มหน้าจอมีเส้นแนวตั้ง
    • Trident TVGA 8900D: DOS prompt แบบเต็มหน้าจอภาพเพี้ยน แต่โหมดหน้าต่างปกติ
    • ATI VGA Wonder XL, Paradise PVGA1A, Video 7 VGA 1024i บางความละเอียดทำให้ Windows เริ่มไม่ขึ้น
  • มีข้อสังเกตว่า 86Box ไม่ได้มีการ์ดรุ่นเดียวกันทุกตัวแบบเป๊ะ ๆ และความแม่นยำของการจำลองก็ยังไม่แน่นอน
  • เมื่อลองทดสอบไดรเวอร์ที่แก้จาก SVGAPatch กับการ์ดรุ่นใหม่ขึ้น ผลลัพธ์ก็ยังแตกต่างกันไปตามการ์ด
    • Matrox Millennium II: ช้ามาก, DOS แบบหน้าต่างใช้ได้ แต่แบบเต็มหน้าจอภาพเพี้ยน
    • 3dfx Voodoo Banshee: เปิด DOS แบบหน้าต่างแล้ว GUI เพี้ยน แต่สลับเต็มหน้าจอได้
    • S3 Trio3D/2X: ตอนเริ่ม Windows หน้าจอเพี้ยน แต่หลังเปิด DOS prompt แล้วออกจากเต็มหน้าจอ 1024x768 กลับมาแสดงผลถูกต้อง
    • 3dfx Voodoo3 3500 SI: คล้าย Banshee แต่โหมดเต็มหน้าจอใช้ได้ครั้งเดียว

สถานะสุดท้ายบน Eee PC

  • บน Eee PC จริง ตัว GUI ทำงานได้ปกติ
  • การสลับไป DOS prompt แบบเต็มหน้าจอยังทำให้ภาพเพี้ยนอยู่ แต่ลักษณะไม่เหมือนใน DOSBox
  • ใน DOSBox จะเห็น text mode ที่ตัวอักษรเพี้ยนจำนวนมาก ส่วนบน Eee PC จะเห็น GUI เพี้ยนที่บางสีหายไป
  • หากสลับกลับเป็นโหมดหน้าต่างก็สามารถกู้คืนได้
  • เดิมที SVGAPatch ทำให้แค่เปิด prompt แบบหน้าต่างก็ทำให้ GUI ทั้งระบบเพี้ยนจนต้องรีสตาร์ต OS แต่ไดรเวอร์ที่แก้แล้วดีขึ้นกว่านั้นมาก
  • ทางเลือกที่ดีกว่าในระยะยาวคือจับตาดู PluMGMK/vbesvga.drv ซึ่งยังมีการพัฒนาอย่างต่อเนื่อง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-06
ความคิดเห็นบน Hacker News

  • แยกจากเรื่องการรองรับ SVGA แล้ว สิ่งที่น่าทึ่งเสมอคือถ้าติดตั้ง Windows 3.x ลงบน PC ที่รองรับมาตรฐานสมัยใหม่ VGA พื้นฐานจะใช้งานได้ทันที แต่ใน Linux/BSD สมัยใหม่ หากไม่มีไดรเวอร์ที่ตรงและไฟล์คอนฟิกแบบตั้งค่าเอง ก็แทบใช้แม้แต่ VGA framebuffer แบบเร่งความเร็วด้วยซอฟต์แวร์พื้นฐานใน Xorg/Wayland ได้ไม่ง่าย
    โปรเจกต์ XFree86 ที่ตายไปแล้วน่าจะเป็นความพยายามที่เข้าใกล้ “ใช้งานได้เลย” แบบนี้ที่สุด แต่ก็ยังอีกไกล และดูเหมือนแนวทางนั้นไม่ได้ถูกเก็บรักษาไว้ใน fork ของ Xorg

    • XFree86 เองก็ไม่ได้ทำอะไรต่างจาก Xorg ในเรื่องนี้
      ถ้าบูต PC รุ่นใหม่ด้วย CSM แม้จะไม่ใช่สิ่งที่ควรแนะนำ แต่ Xorg ควรจะรัน video BIOS ด้วย x86emu แล้วขึ้นมาด้วย VBE backend และถ้าบูตด้วย EFI ก็ควรมี modesetting ที่ใช้ efifb บนโหมดที่เฟิร์มแวร์กับ bootloader ทิ้งไว้ให้
      แต่เรื่องนี้ง่ายกว่าสำหรับระบบปฏิบัติการ 16 บิตหรือ 32 บิต การตั้งค่าโหมด VESA ต้องใช้การเรียกแบบ real mode 16 บิต และแม้ช่วงท้ายของมาตรฐานจะมี entry point แบบ 32 บิตในนาม แต่แทบไม่มีใคร implement อย่างถูกต้อง พอเข้าสู่โหมด 64 บิตก็ใช้ vm86 ไม่ได้ จึงเรียกโค้ด 16 บิตจาก user space ไม่ได้ ด้วยเหตุนี้จึงต้องใช้ x86emu ที่อ่านโค้ด video BIOS แล้วรันใน x86 emulator แต่ก็ไม่ได้สมบูรณ์แบบเสมอไป
    • ใน Linux มี vgafb/vesafb อยู่ ถ้า distro ตั้งค่าไว้อย่างเหมาะสมก็ทำได้
      เพียงแต่มักให้ประสบการณ์ที่ประสิทธิภาพและคุณภาพต่ำ และผู้ใช้อาจไม่รู้สาเหตุ จึงดูเหมือนบาง distro หรือส่วนใหญ่ไม่ได้เปิดเป็นค่าเริ่มต้น ทุกวันนี้ GPU แทบทั้งหมดรองรับแบบ native แล้ว ก็คงไม่มีแรงจูงใจจะทำป๊อปอัปว่า “คุณกำลังใช้ VGA/VESA แบบไม่มี acceleration โปรดแก้ไข”
    • เป็นเรื่องนานมาแล้ว แต่ผมจำได้ว่า X เคยมี ไดรเวอร์ VGA แบบทั่วไป ที่ “ใช้งานได้เลย” หมายความว่าตอนนี้มันไม่มีแล้วหรือ?
    • X11 มี ไดรเวอร์ VESA มาตั้งนานแล้ว แต่จำนวนพิกเซลที่ต้องประมวลผลเพิ่มขึ้นอย่างรวดเร็วตามความละเอียด ทำให้สเกลด้านประสิทธิภาพได้แย่
      Linux distro แบบบูตได้ที่ใช้ในงาน ส่วนใหญ่คือ GRML กับ Clonezilla จะปรับให้เข้ากับหน้าจอระหว่างบูตหรือความละเอียด native ของ virtual KVM โดยอัตโนมัติด้วยการรองรับ KMS และทำงานได้ค่อนข้างดี Anaconda หรือ installer สาย RedHat และ installer ของ Debian ก็ปรับเป็นความละเอียด native ตอนบูตเช่นกัน
      GUI installer ใช้ VESA โดยตรงบน X11
      fork ของ Xorg ก็รองรับ “บูตโดยไม่มีไฟล์คอนฟิก” มานานแล้ว ผมไม่ได้จัดการไฟล์คอนฟิกมานานมาก และแบบนั้นน่าพอใจกว่ามาก ดู https://www.xkcd.com/963/
    • ผมมองว่า Xorg ใกล้เคียงกับ XFree86 ที่จัดระเบียบ build system แล้ว

  • Windows 3.1 GUI สมัยก่อนดูใช้งานง่าย มีประสิทธิภาพ และน่าใช้กว่าสิ่งที่มีในปัจจุบันมาก
    https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...
    ที่ความละเอียดต่ำแบบในบทความ Win11 จะหน้าตาออกมาเป็นยังไงกันนะ? เมนู Start ของ Win11 แทบใช้ไม่ได้ นอกจากพิมพ์คีย์เวิร์ดแล้วสวดภาวนาต่อวงจร
    สมมติฐานแบบซื่อ ๆ คือ Windows NT กับ 2000 เป็นจุดที่ลงตัวที่สุด แล้วหลังจากนั้น product manager ก็ร่ายเวทมนตร์กันมาตลอด ส่วน KDE กับ Gnome ไม่ได้เปลี่ยนไปมากนัก แต่ยิ่งเวลาผ่านไปกลับยิ่งดูน่าสนใจขึ้น :)

    • ผมคิดว่าเวอร์ชัน “ดี” ตัวสุดท้ายคือ Windows 7 คล้ายกับ NT/2000 แต่สวยกว่าเพราะฮาร์ดแวร์กราฟิกดีขึ้น และ XP ก่อนหน้านั้นก็เช่นกัน Vista เอง UI ก็ใช้ได้ ปัญหาอยู่ที่อย่างอื่น
      Windows 8 ทำทุกอย่างพัง และ Windows ก็ไม่เคยฟื้นกลับมาได้ ผมคิดว่าสาเหตุมีสองอย่าง คือการผงาดขึ้นของแพลตฟอร์มมือถือและความขี้เกียจของ Microsoft
      ตอนนี้เกิดปัญหาที่ยากจะแก้คือหลายแอปมีเวอร์ชันเดสก์ท็อปกับเวอร์ชันมือถือแยกกัน เวอร์ชันหนึ่งสำหรับจอใหญ่กับคีย์บอร์ด·เมาส์ อีกเวอร์ชันสำหรับจอสัมผัสขนาดเล็ก ดังนั้นแอปเดสก์ท็อปที่ดีและแอปมือถือที่ดีควรต่างกันโดยสิ้นเชิง แต่เพราะอยากให้ผู้ใช้รู้สึกคุ้นเคยกับทั้งสองเวอร์ชัน แม้พยายามเต็มที่ก็ยังต้องประนีประนอม
      Microsoft น่าจะทำได้ค่อนข้างดี แต่กลับไม่ทำ ดู Control Panel ก็ชัดเจน Settings ซึ่งเป็น Control Panel แบบใหม่มีมาตั้งแต่ Windows 8 หรือ 12 ปีก่อนแล้ว แต่ก็ยังย้ายฟังก์ชันทั้งหมดจาก Control Panel เดิมมาไม่ได้ จนยังต้องใช้ทั้งสองอย่าง เมื่อไม่กี่เดือนก่อนพยายามจะเปลี่ยนไปใช้แบบใหม่ทั้งหมด แต่ยังไม่พร้อม และก็ไม่รู้ว่าจะพร้อมในอนาคตไหม ยิ่งกว่านั้นยังมักลบตัวเลือกปรับแต่งที่ได้รับความนิยม และสไตล์ระหว่างแอปที่ bundle มาก็ไม่สอดคล้องกัน นี่ไม่ใช่แค่เรื่องถกเถียง แต่แย่ในเชิงวัตถุวิสัย
      อีกปัจจัยหนึ่งที่โทษได้ไม่ใช่แค่ Microsoft กับ Windows คือผู้พัฒนาแอปให้ความสำคัญกับ branding และความสอดคล้องภายใน มากกว่าการผสานกับระบบปฏิบัติการ UI สมัยใหม่จำนวนมากเป็นเพียงเว็บเพจที่เรนเดอร์ด้วย browser engine อย่าง Electron ไม่ใช้คอนโทรล native ของระบบปฏิบัติการ เมินธีม และวาด window decoration เอง ระบบปฏิบัติการอาจไม่สอดคล้องก็จริง แต่ผู้พัฒนาแอปก็ไม่ได้ช่วยเลย
    • Flat design แทบเป็นหายนะของวงการ ส่วน skeuomorphism ก็แย่พอสมควรเช่นกัน เพราะโดยพื้นฐานแล้วก็เป็น flat design ที่แปะรูปลงไป
      Windows Forms ทำหลายอย่างได้ถูกต้อง และถ้าจะเลือกสัญลักษณ์ที่ขาดไปอย่างหนึ่ง ผมคิดว่าเป็น “อยู่ในสถานะ active แต่แก้ไขไม่ได้” ประมาณนั้น
    • ตามเรื่องเล่าที่ได้ยินมา Windows 11 เดิมทีคือ Windows 10X ที่กำลังทำสำหรับโทรศัพท์และแท็บเล็ตด้วย เมนู Start ดูได้รับอิทธิพลจาก Android อยู่พอสมควร คือแสดงทุกอย่างที่ติดตั้งไว้แบบแบน ๆ และผลักให้ใช้การค้นหามากขึ้น
      แต่ก็เห็นด้วย Win10 beta เคยมีรูปแบบที่ผสม tiles กับรายการแบบ Windows 7 และแนวทางนั้นสืบย้อนถึง Windows 2000 ได้ ผมจึงคิดว่านั่นคือจุดสูงสุด มันอาจรวมข้อดีของทั้งสองอย่างได้ Notification area อ่อนแอมาโดยตลอด และแผง Settings ก็แย่มากเมื่อเทียบกับ Control Panel แน่นอนว่า Control Panel เองก็รกและซับซ้อน จึงยังถกเถียงได้ว่าเป็นทางเลือกที่ดีที่สุดหรือไม่

  • ผู้เขียนบอกว่าเมื่อเปิดพรอมป์ DOS ในโหมดหน้าต่างแล้วหน้าจอเพี้ยน ซึ่งอาจเกิดจากพรอมป์ DOS ทำงานใน VM แยกต่างหาก หรือก็คือโหมด V86 และเรียก VGA ROM BIOS ผ่าน INT 10h
    VGA ROM BIOS ของเครื่องนี้น่าจะเป็น wrapper บน VBE และนั่นหมายความว่าน่าจะมีคำสั่ง IN/OUT ที่เข้าถึงพอร์ต I/O ของ VBE คือ 0x1CE และ 0x1CF อยู่ด้วย การอ่านและเขียนแบบนี้ที่เกิดใน DOS VM หาก VMM ไม่ได้ทำ virtualize ไว้ โดยพื้นฐานแล้วจะไปถึงฮาร์ดแวร์จริง
    นี่เป็นปัญหาทั่วไปที่ผู้เขียนไดรเวอร์จอภาพของ Windows 3.x/9x ต้องจัดการ แต่หมายเลขพอร์ต I/O ที่ต้องทำ virtualize นั้นแตกต่างกันไปตามกราฟิกอะแดปเตอร์แต่ละตัว ใน Win95 DDK มีตัวอย่างการตั้ง I/O port trap ด้วยบริการ VMM อย่าง Install_IO_Handler และ Enable/Disable_Global_Trapping และใช้ VDD_Get_VM_Info ภายใน trap handler เพื่อพิจารณาว่า VM ใดเป็นเจ้าของ CRTC ปัจจุบัน จากนั้น trap handler จึงตัดสินใจได้ว่าจะส่ง I/O ไปยังฮาร์ดแวร์หรือจะทำ virtualize อย่างไร นโยบาย virtualize ที่ดีสำหรับเริ่มต้นคือทิ้งการเขียนจาก VM ที่ไม่ใช่เจ้าของ CRTC ไปเฉย ๆ แล้วค่อยเพิ่มความซับซ้อนที่จำเป็นภายหลัง

  • Virtual Display Device(VDD) ทำงานเป็นส่วนหนึ่งของตัวจัดการเครื่องเสมือนพื้นฐาน และทำตัวเหมือนมัลติเพล็กเซอร์สำหรับฮาร์ดแวร์วิดีโอ ถ้าแอป DOS อยู่เต็มจอ คำสั่งจะถูกส่งตรงไปยังอะแดปเตอร์ VGA “จริง” ไม่เช่นนั้น VDD จะทำการจำลอง
    น่าสนใจที่คนอื่น ๆ มาค้นพบโครงสร้างแบบนี้อีกครั้ง ส่วนตัวผมมองว่าเป็นโครงสร้างที่ล้ำยุคพอสมควร มาก่อน hypervisor สมัยใหม่ที่มี hardware passthrough เสียอีก ตัว Windows 3.x GUI เอง ซึ่งรวมถึงโปรเซสแบบ preemptive multitasking โดยพื้นฐานแล้วรันเป็นโปรเซส DOS ใน protected mode ที่ขยายเพิ่ม อยู่ภายใน VM ที่มี DOS ทำงานอยู่ และเคอร์เนล hypervisor อย่าง VMM32 ก็ทำ multiplex ระหว่างมันกับ VM ของโปรเซส DOS อื่น ๆ ดังนั้นส่วนหนึ่งของไดรเวอร์จอภาพจึงโต้ตอบกับ “ฮาร์ดแวร์” ใต้ GDI และอีกส่วนหนึ่งทำ virtualize ฮาร์ดแวร์ที่ ring 0 เพื่อ multiplex กับ VM อื่น ๆ
    เรื่องนี้อาจแก้ได้ใน DOSBox แต่การแก้นั้นจะผูกกับวิดีโออะแดปเตอร์เฉพาะที่ DOSBox จำลองอยู่ สิ่งที่ต้องการไม่ใช่แบบนั้น แต่คือทำให้แพตช์ VBE ทั่วไปทำงานได้ดีขึ้น
    ผมเคยเขียน ไดรเวอร์ VESA framebuffer สำหรับ Win9x บน Intel GMA950 และเพิ่ม acceleration พื้นฐานอย่างคำสั่ง blitter กับ fill เข้าไปด้วย ซึ่งแทบจะเจอปัญหาเดียวกัน และทำให้เข้าใจว่าทำไม Win9x จึงไม่มีไดรเวอร์ VESA แบบทั่วไป VDD ต้องรู้วิธีบันทึกและกู้คืนสถานะของ GPU แต่รายละเอียดเหล่านั้นย่อมขึ้นกับผู้ผลิต ผมเคยคิดไอเดียที่อาจทำแบบทั่วไปได้ เช่น จำลองหรือติดตาม VBIOS เพื่อดูว่าทุกครั้งที่สลับโหมดมันแตะพอร์ตและ MMIO อะไรบ้าง แต่ไม่ได้ทำถึงขั้น implementation
    ใน DOSBox จะได้โหมดข้อความที่มีตัวอักษรเพี้ยนเต็มไปหมด ส่วนบน Eee PC จะได้ GUI ที่พังและสีบางส่วนหายไป
    ดูเหมือนว่านี่เกิดจากการบันทึก/กู้คืน palette register ไม่ถูกต้อง นอกจากนี้อาการเพี้ยนด้านบนของหน้าจอสามารถหลีกเลี่ยงได้โดยย้ายระนาบแสดงผลความละเอียดสูงไปไว้เหนือ 256K เพื่อเหลือ VRAM 256K แรกไว้ให้ระนาบ VGA และการจำลอง VGA โชคดีที่ Intel GMA มีเอกสารสาธารณะอยู่พอสมควร แม้จะไม่ใช่เอกสารของ 900 กับ 950 แต่เป็นของ 810/815 และรุ่นตั้งแต่ 965 เป็นต้นไป แต่ register และคำสั่งส่วนใหญ่ไม่ได้เปลี่ยน จึงใช้อ้างอิงรายละเอียดได้

  • ถึงจะบอกว่า “ไม่มีการรองรับ x86_64 เลยรัน Linux distro สมัยใหม่ส่วนใหญ่ไม่ได้” แต่ Eee ของผมยังใช้ Debian 32 บิตได้สบาย
    Firefox หนักเกินไปจนแทบจะอืด แต่การสตรีมวิดีโอด้วย mpv ยังทำได้พอเพียง ส่วนใหญ่ใช้เหมือนเครื่องพิมพ์ดีดที่รัน pandoc ได้เวลางานหนังสือค้าง และมีสิ่งรบกวนน้อย

    • เห็นด้วยเต็มที่ว่าคอมพิวเตอร์ที่มีสิ่งรบกวนน้อยที่สุดเหมาะกับการเขียน ผมใช้ WordPerfect 5.1 บน PS/2 386SX เพื่อจุดประสงค์นั้น
      ผมชอบ EEE เพราะพกพาสะดวกมาก แต่คิดว่าคีย์บอร์ดเล็กเกินไปสำหรับการพิมพ์จริงจัง
    • ถ้าใช้งานโดยแทบไม่มีเว็บหรือแอปสมัยใหม่ Haiku OS อาจเป็นกรณีใช้งานที่น่าสนใจ
      ผมเคยลองบน PC แล้ว ถึงซอฟต์แวร์ที่ใช้ได้จะน้อยเกินไปอย่างชัดเจนสำหรับการเป็นระบบปฏิบัติการใช้งานประจำวันจริง ๆ แต่สำหรับงานที่ต้องการการเชื่อมต่อน้อยอย่างเครื่องพิมพ์ดีดกับเมล มันให้ความรู้สึกเหมือนเป็น OS ที่น่าใช้มาก
      ชอบความรู้สึกที่สอดคล้องกันตั้งแต่ UI, ซอฟต์แวร์พื้นฐาน ไปจนถึงระบบไฟล์ ถ้าผมเข้าใจถูก ระบบไฟล์คือการแทนข้อมูลทั้งหมด และ “ไฟล์” สามารถมีเมทาดาทาตามอำเภอใจได้ อีกทั้งทำได้แทบทุกอย่างจากตัวจัดการไฟล์ ทั้งระบบไฟล์เหมือนฐานข้อมูล NoSQL และแอปต่าง ๆ ก็รับแนวคิดนั้นไปใช้อย่างเป็นธรรมชาติ เช่น รายชื่อผู้ติดต่อเป็น “ไฟล์” ในโฟลเดอร์ เมลก็เป็น “ไฟล์” ในโฟลเดอร์เช่นกัน
      ตอนนั้นผมไม่เคยลอง BeOS แต่ในยุค 90 ที่การเชื่อมต่อยังต่ำ พาราไดม์นี้น่าจะเข้ากันได้ดีทีเดียว เช่น เขียน “ไฟล์” เมลโดยไม่มีอินเทอร์เน็ต ลากไปใส่ฟลอปปีดิสก์ แล้วส่งผ่านอินเทอร์เน็ตจากคอมพิวเตอร์อีกเครื่อง โดยจัดการทุกขั้นตอนผ่านตัวจัดการไฟล์เท่านั้น ซึ่งสอดคล้องกันอย่างน่าประหลาด
      น่าเสียดายที่ทันทีที่ต้องทำงานร่วมกับคอมพิวเตอร์อื่นที่ไม่เข้ากันกับระบบไฟล์ของ BeOS/Haiku ประโยชน์ของพาราไดม์นี้ก็ลดลง เพราะในเชิงสถิติแล้วคอมพิวเตอร์แทบทั้งหมดเป็นแบบนั้น
      แต่ถ้าเป็นเครื่องสำหรับใช้แทนเครื่องพิมพ์ดีด ก็น่าสนใจได้
    • เท่าที่ทราบ Debian จะถอดการรองรับ 32-bit x86 ในรีลีสถัดไป
    • ผมเคยมี 1215B แต่เสียไปเมื่อปีที่แล้ว และตอนนี้แท็บเล็ต Android มาแทนแล้ว
      ดูเหมือนว่าแท็บเล็ตจะกวาดตลาดช่วงเน็ตบุ๊กไปหมดแล้ว อัลตร้าพอร์ตเทเบิลหรือ 2-in-1 ยังมีอยู่ แต่ก็ใกล้กับอีกขั้วหนึ่งของช่วงราคามากกว่า

  • ชื่อเรื่องทำให้สับสนนิดหน่อย
    ถึงอย่างนั้น ทุกครั้งที่ได้อ่านว่า Windows ที่อิง DOS รุ่นเก่า ๆ ทำงานภายในอย่างไร ก็รู้สึกทึ่งเสมอ ทุกอย่างเหมือนถูกแปะด้วยเทปผ้าซอฟต์แวร์ แต่ somehow ก็ทำงานได้

    • ลองฟังที่ Casey Muratori พูดก็ได้ เขาบอกว่าสร้างกอง abstraction ขนาดมหึมาไว้ แต่จริง ๆ ไม่จำเป็น และมีแต่ทำให้ประสิทธิภาพแย่ลง

  • จำได้ว่าตอนที่ ET4000H ออกมา Windows 3.1 ยังไม่รองรับ โทรไปฝ่ายซัพพอร์ตเทคนิคของ MS แล้วเขาส่งดิสก์ไดรเวอร์มาให้ ถึงหลังจากนั้น 8 ชั่วโมง
    เป็นบริการซัพพอร์ตที่ดีที่สุดที่เคยได้รับสำหรับผลิตภัณฑ์เถื่อน

    • พูดให้แม่นคือ ET4000H เหมือนกับ ET4000ax ที่ Windows 3.0 และ 3.1 รองรับอยู่แล้ว แต่เป็นรุ่นที่มี HiDAC หรือก็คือทรูคัลเลอร์ 15/16 บิต แทน DAC 256 สี
      ความทรงจำเลือนราง แต่เหมือนว่าไดรเวอร์พื้นฐานจะทำงานในโหมด 16 สีได้ ส่วน 256 สีขึ้นไปไม่ได้ และตัวเลือกความละเอียดก็อาจจำกัดด้วย
      ตามข้อมูลของ MS ไดรเวอร์ที่รองรับ HiDAC ออกมาในสัปดาห์ที่สามของเดือนเมษายน 1992 ซึ่งช้ากว่าช่วงเวลาที่ผมจำได้ 1–2 สัปดาห์ เลยดูเหมือนจะตรงกันโดยรวม

  • น่าสนุกดี ผมมี EEEPC 701 รุ่นเล็กอยู่ และมันยังทำงานได้ แต่ไม่เคยคิดจะใช้เล่นเกมเรโทรเลย
    เครื่องของผมก็แค่ฝุ่นจับอยู่เฉย ๆ ถ้าลองทำอะไรแบบนี้น่าจะสนุกดี

    • น่าจะหมายถึง 701 นะ 207g ไม่ใช่ชื่อรุ่นของ Eee PC

  • ลองเทียบหมายเหตุเล็ก ๆ แบบไม่ตั้งใจดู ก็เห็นการเปลี่ยนสถานะถัดไปที่เจ้าตัวน่าจะจ้องจนถึงขั้นความหมายล้นไปแล้ว
    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
    ตามแพตเทิร์น DOS ที่พังกับ GUI ที่พังจะเป็น 200 หรือ 250 ส่วนที่ปกติเป็น 100 หรือ 050 ที่อยู่นั้นคืออะไรนะ?
    GUI ที่พังอยู่ใน โหมด M_VGA ไม่ใช่ LIN8 ด้วยเหตุผลบางอย่าง มันเกิดขึ้นได้อย่างไรและทำไม และจะเกี่ยวกับสาเหตุที่กลายเป็น 400x600 ซึ่งเป็นครึ่งหนึ่งของแนวนอน 800x600 หรือเปล่า? “โหมดข้อความ” จริง ๆ คือ 720x400 อย่างที่เห็นในโหมด DOS ทั้งสอง

  • ไม่รู้ว่าผู้เขียนจะเห็นไหม แต่ผมแจ้งเรื่องบทความนี้ให้ ผู้เขียนแพตช์ ทราบแล้ว
    https://www.bttr-software.de/forum/board_entry.php?id=22124#...