Seekor Anjing Melawan Stack Grafis Windows 3.1

 (wuffs.org)
2 poin oleh GN⁺ 2025-01-06 | 1 komentar | Bagikan ke WhatsApp
  • Saat mencoba menggunakan Windows 3.11 pada Asus Eee PC 1000H keluaran 2008 dengan layar 1024x600, keterbatasan VGA bawaan dan driver Super VGA 256 warna dari Microsoft menjadi terlihat
  • Dukungan Super VGA di Windows 3.x bukanlah standar umum, melainkan struktur yang disesuaikan dengan ekstensi proprietari per kartu, dan Intel GMA 950 pada Eee PC bukan termasuk perangkat yang didukung
  • SVGAPatch mengubah Microsoft svga256.drv agar berbasis pemanggilan VBE, sehingga memungkinkan output 256 warna beresolusi tinggi, tetapi masalah GUI yang rusak setelah berpindah dari layar DOS masih tersisa
  • Hasil reverse analysis menunjukkan bahwa pengaturan mode awal sudah berubah ke VBE, tetapi jalur reset saat perpindahan layar masih memanggil mode 30h untuk Tseng ET4000 dan pengaturan VBE scan line dalam keadaan text mode
  • Patch tambahan mengurangi kerusakan saat kembali dari sesi DOS layar penuh ke GUI, tetapi belum sepenuhnya menyelesaikan status bank switching, sehingga pada Eee PC nyata hasilnya sebatas GUI dan pemulihan mode jendela bisa berfungsi

Menghidupkan kembali grafis Windows 3.11 di Eee PC

  • Perangkat target adalah Asus Eee PC 1000H yang dibeli pada 2008; karena tidak mendukung x86_64, sebagian besar distribusi Linux modern pun sulit dijalankan
  • Tujuannya adalah menjalankan Windows 3.11 for Workgroups di netbook ini dengan output video yang lebih baik
  • Output bawaan adalah VGA 640x480 16 warna, sehingga pada layar 1024x600 tampilannya kurang bagus dan rasio aspeknya juga tidak cocok
  • Installer Windows 3.11 menyertakan driver untuk adaptor video lama, tetapi Intel GMA 950 pada Eee PC tidak didukung
  • Driver Super VGA yang disertakan tampaknya mendukung hingga 1024x768 256 warna, tetapi pada lingkungan ini terjadi error dan Windows tidak bisa mulai

Perbedaan VGA, SVGA, dan VBE

  • VGA adalah video controller spesifik yang dirancang IBM pada 1980-an, bukan sekadar konektor analog biru atau resolusi 640x480
  • SVGA lebih merupakan istilah untuk mengelompokkan “yang lebih maju dari VGA dasar” ketimbang sebuah standar, dan perangkat lunak harus mendukung langsung ekstensi proprietari masing-masing kartu
  • Daftar dukungan driver SVGA 256 warna Microsoft mencakup seri berikut
    • 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) memungkinkan fungsi di luar VGA ditangani lewat antarmuka umum, tetapi Windows 3.x tidak menyertakan driver VBE langsung
  • VBE9x dan VBEMP dari BearWindows masing-masing memungkinkan penggunaan VBE di Windows 9x dan NT, tetapi tidak ada versi untuk Windows 3.x

Hal yang diselesaikan SVGAPatch dan yang tersisa

  • SVGAPatch mem-patch driver Super VGA 256 warna Microsoft agar menggunakan VBE
  • Driver yang sudah di-patch dapat menampilkan layar seperti 1024x600 dengan benar, tetapi terjadi konflik pada kompatibilitas DOS
  • Windows 3.1 Enhanced Mode dapat menjalankan aplikasi Windows grafis dan aplikasi DOS secara bersamaan, dan DOS prompt juga dapat ditampilkan dalam jendela atau layar penuh
  • Setelah SVGAPatch diterapkan, masalah berikut dapat direproduksi
    • Setelah masuk ke mode DOS layar penuh lalu kembali ke GUI Windows, layar menjadi rusak
    • Dalam beberapa kasus, layar rusak hanya dengan membuka DOS prompt dalam mode jendela
    • Semuanya dapat direproduksi di DOSBox, 86Box, dan Eee PC nyata, tetapi bentuk kerusakannya sedikit berbeda
  • PluMGMK/vbesvga.drv, driver baru terpisah, bahkan mendukung mode true color, tetapi di sini analisis dilakukan dengan arah memperbaiki kode Microsoft dan SVGAPatch

Struktur stack grafis Windows 3.x

  • Windows 3.x Enhanced Mode memiliki struktur di mana Virtual Machine Manager dalam protected mode 32-bit membuat beberapa VM, dan Standard mode Windows berjalan di dalam VM pertama
  • Saat memilih adaptor video di Windows Setup, yang dipasang bukan satu driver tunggal, melainkan beberapa komponen bersama
    • Grabber: dipahami bertanggung jawab atas rendering aplikasi DOS dalam mode jendela
    • Display Driver: bertanggung jawab atas inisialisasi hardware dan rendering GUI di dalam VM Windows utama; pada Windows 3.x, sebagian besar GDI juga diimplementasikan sendiri di sini
    • Virtual Display Device(VDD): berjalan sebagai bagian dari Virtual Machine Manager dan melakukan multiplexing antara aplikasi DOS dan hardware VGA nyata
  • Item SVGA 256 warna menggunakan driver yang sama, dan dibedakan lewat pengaturan resolusi dan DPI di SYSTEM.INI
  • SVGAPatch hanya memodifikasi Display Driver dan tidak menyentuh SVGA VDD
  • Pada akhirnya, penyebab kerusakan layar baru bisa dipersempit dengan memahami bersama Display Driver, VDD, dan perubahan privat yang dibuat SVGAPatch

Materi dan alat yang digunakan untuk reverse analysis

  • Sebagai referensi digunakan Windows 3.x VDDVGA dan Windows 3.1 DDK
  • Windows 3.1 DDK menyertakan source berikut
    • Source Display Driver untuk VGA, IBM 8514, Video 7, dan SVGA 16 warna
    • Source VDD untuk VGA, IBM 8514, Video 7, dan SVGA 16 warna
    • Hampir semua source Grabber
    • Dokumentasi yang sangat sedikit
  • Justru Display Driver SVGA 256 warna yang dibutuhkan dan source VDD terkait tidak disertakan
  • IDA dan Ghidra digunakan untuk menganalisis svga256.drv dan vddsvga.386
  • Ghidra dapat membaca .drv, tetapi VDD adalah VxD sehingga memerlukan LX loader terpisah, dan ada keterbatasan dalam menangani file yang mencampur kode 32-bit dan 16-bit

Analisis internal svga256.drv

  • svga256.drv memiliki fungsi export seperti GETCHARWIDTH, STRETCHBLT, dan VIDEOINIT_ATI, sehingga bisa dibandingkan dengan source DDK
  • Sebagian fungsi hampir sama dengan source driver VGA, tetapi ada juga perbedaan seperti hilangnya fitur koreksi lebar bold font pada GETCHARWIDTH
  • Pada REALIZEOBJECT, tampak ada perbedaan seperti campuran kode dari driver VGA dan driver Video 7, dan logika pemrosesan warnanya juga berbeda
  • Karena interaksi adaptor video sulit dijelaskan hanya dengan fungsi GDI, analisis berlanjut ke jalur inisialisasi physical_enable

physical_enable dan cara kerja driver SVGA Microsoft

  • Jika “Super VGA (800x600, 256 colours, small fonts)” dipilih di Windows Setup, nilai berikut masuk ke SYSTEM.INI
    • dpi=96
    • resolution=2
  • Setelah boot, driver yang sudah di-patch juga mencatat nilai berikut
    • svgamode=48
    • ChipSet=Tseng ET4000
    • LatchCapable=No
  • physical_enable adalah fungsi inisialisasi inti yang mengatur mode video dan menelusuri daftar mode yang didukung untuk menemukan mode per chipset yang berfungsi
  • Logika asli Microsoft memiliki tabel mode dukungan per resolusi dan menguji tiap mode dengan SetAndValidateMode
  • Jika berhasil, fungsi inisialisasi per chipset, fungsi pengaturan bank, dan lainnya ditemukan lalu dipanggil; setelah itu dilakukan pengaturan palet, inisialisasi framebuffer, hingga pengaturan alamat VDD

Perubahan nyata dari SVGAPatch

  • SVGAPatch mengubah ID fungsi pada item chipset pertama di tiga daftar resolusi menjadi 2000, lalu menimpa SetAndValidateMode dan beberapa fungsi per chipset
  • Perubahan intinya sebagai berikut
    • SetAndValidateMode: alih-alih pengaturan mode berbasis VGA BIOS lama, meminta mode video extended lewat VBE 4F02h
    • SETBANK_TRIDENT: alih-alih menulis register khusus Trident, memindahkan jendela memori video lewat VBE 4F05h
    • VIDEOINIT_TRIDENT: alih-alih menulis VGA CRTC Offset Register, menetapkan panjang scan line lewat VBE 4F06h
  • Setelah patch, item pertama di daftar mode yang didukung berhasil, dan fungsi yang ditulis ulang yang terhubung ke ID fungsi 2000 digunakan
  • Alasan nilai Tseng ET4000 tercatat di SYSTEM.INI adalah karena nama item pertama dalam daftar disimpan apa adanya, meskipun nilainya tidak benar-benar dipakai

VDD dan DspDrvr_Addresses

  • VDD menangani situasi ketika program DOS mengharapkan kendali eksklusif atas hardware nyata lewat virtualisasi
  • Setiap VM memiliki instance struktur VDD_CB_Struc, yang berisi flag, mirror status controller VGA, dan informasi alokasi memori video per VM
  • Di dalam VDD terdapat kode per vendor yang mendeteksi adaptor VGA tertentu dan mengubah cara penyimpanan, pemulihan, serta simulasi register tertentu
  • DspDrvr_Addresses adalah layanan tempat Display Driver meneruskan informasi alamat ke VDD; menurut komentar, DX adalah field cadangan dan harus 0, tetapi pada kode VGA VDD nyata ada perilaku khusus saat DX bukan 0
  • Pada SVGA VDD terdapat jalur baru saat DX == 2, dan SVGA256.DRV memanggil fungsi ini dengan nilai berikut
    • BX = 0xFFFF
    • DX = 2
    • DS:SI menunjuk ke byte status shadow memory

Mempersempit penyebab dengan DOSBox-X

  • Video debug overlay dan debugger DOSBox-X digunakan untuk membandingkan status VGA sebelum dan sesudah peralihan DOS prompt layar penuh
  • Komentar mode dan status register yang ditampilkan berbeda antara kondisi GUI normal, DOS normal, GUI rusak, dan DOS rusak
  • Untuk memeriksa apakah flag VDD vendor-specific salah aktif, DOSBox-X dimodifikasi agar melakukan dump memori fisik, tetapi di DOSBox flag tersebut tidak aktif
  • Saat register VGA dibandingkan, nilai scan_len internal DOSBox berbeda antara kondisi normal dan rusak
    • Pada DOS normal: 40
    • Pada DOS rusak: 296
    • Pada GUI normal: 128
    • Pada GUI rusak: 256
  • Implementasi VESA Scan Line API di DOSBox menghitung scan_len secara berbeda tergantung mode video saat ini, dan titik ini dipersempit sebagai tersangka utama

Petunjuk penentu: pengaturan VBE scan line dalam text mode

  • Setelah log pengaturan VESA scan line ditambahkan ke DOSBox-X, panggilan berikut tertangkap
    • VESA_ScanLineLength(subcall=2, val=1024, bytes=2, pixels=1024, lines=4768)
    • Mode saat ini adalah M_TEXT
  • Display Driver menetapkan panjang scan line menjadi 1024 byte lewat VBE 4F06h, tetapi DOSBox menganggap keadaan saat ini sebagai text mode, sehingga status internal dihitung keliru
  • Saat Windows mulai, pengaturan scan line berjalan normal dalam status SVGA 800x600 dan M_LIN8
  • Setelah membuka DOS prompt layar penuh lalu kembali ke GUI dengan Alt+Enter, alur berikut terjadi
    • Sebuah kode meminta peralihan ke mode 30h, yaitu 48 dalam desimal
    • patched display driver menetapkan panjang scan line dalam keadaan text mode
    • Status internal DOSBox dan status berbasis register VGA menjadi tidak sinkron
  • Mode 30h adalah nilai mode untuk 800x600 pada Tseng ET4000 yang di-hijack oleh SVGAPatch

Jalur perpindahan layar yang terlewat

  • Display Driver Windows 3.1 meng-hook INT 2Fh untuk menerima perintah perpindahan layar
  • Driver VGA menangani empat perintah berikut, tetapi driver SVGA256 hanya mendukung SCREEN_SWITCH_OUT dan SCREEN_SWITCH_IN
    • SCREEN_SWITCH_OUT
    • SCREEN_SWITCH_IN
    • SAVE_DEV_REGS
    • RES_DEV_REGS
  • Fungsi bermasalahnya adalah dev_to_foreground, yang dipanggil saat kembali ke GUI Windows
  • dev_to_foreground pada SVGA256 berjalan dengan alur berikut
    • Memanggil farsetmode
    • farsetmode menetapkan mode 48
    • Memanggil VideoInit per chipset
    • Menetapkan enabled_flag ke 0xFF
    • Memanggil Windows API SetPalette
  • SVGAPatch mengubah jalur pengaturan mode saat inisialisasi ke VBE, tetapi jalur yang mengatur ulang mode saat perpindahan layar tidak diubah

Perbaikan pemulihan GUI lewat patch tambahan

  • Kode setmode asli memiliki struktur pendek: memasukkan wGraphicsMode ke ax, memanggil INT 10h, lalu memanggil ptr_videoinit
  • Kode baru disisipkan ke ruang tersisa setelah SetAndValidateMode yang dipendekkan oleh SVGAPatch
    • Memasukkan nilai CurrentHeight dikurangi 1 ke cx
    • Memanggil SetAndValidateMode
    • Memanggil ptr_videoinit
  • Instruksi pertama setmode diubah agar melompat ke kode baru, sehingga jalur pengaturan mode berbasis VBE juga dipakai saat perpindahan layar
  • Setelah perbaikan ini, layar tidak lagi rusak saat masuk ke sesi DOS layar penuh lalu kembali ke GUI
  • Namun, masalah titik-titik yang muncul lagi saat berpindah dari mode jendela ke layar penuh masih tersisa

Masalah bank switching yang tersisa

  • Saat memeriksa memori VGA B8000 di debugger DOSBox, isi teks memang ada tetapi tidak terlihat di layar
  • Titik yang dicurigai adalah bank switching yang digunakan driver untuk mengakses lebih banyak memori video
  • Setelah perintah untuk menampilkan status bank SVGA ditambahkan ke DOSBox-X, terlihat bahwa adaptor VGA tetap berada di bank yang salah saat kembali ke layar penuh
  • Rutinitas baru untuk mengembalikan bank ke 0 dimasukkan ke dev_to_background, tetapi masalahnya tidak teratasi
  • Implementasi VBE 4F05h di DOSBox dilakukan dengan menulis ke register VGA CRTC 0x6A, dan saat dev_to_background dipanggil, VDD sudah berada dalam kondisi menjebak penulisan, sehingga sudah terlambat

Hasil eksperimen driver asli dan driver patch

  • Hasil pengujian driver SVGA 256 warna asli Microsoft pada beberapa kartu emulasi di 86Box tidak konsisten bahkan dalam daftar dukungan
    • Cirrus Logic GD5420 (ISA): berfungsi
    • Tseng Labs ET4000AX: berfungsi
    • Oak OTI-077: layar rusak saat pertama membuka DOS prompt mode jendela, muncul garis vertikal pada layar penuh
    • Trident TVGA 8900D: layar rusak pada DOS prompt layar penuh, mode jendela normal
    • Beberapa resolusi ATI VGA Wonder XL, Paradise PVGA1A, dan Video 7 VGA 1024i gagal memulai Windows
  • Ada catatan bahwa 86Box tidak menyediakan kartu yang persis sama dan akurasi emulasinya juga belum pasti
  • Hasil pengujian driver berbasis SVGAPatch yang sudah dimodifikasi pada kartu-kartu yang lebih baru juga berbeda-beda per kartu
    • Matrox Millennium II: sangat lambat; DOS mode jendela berfungsi tetapi layar penuh rusak
    • 3dfx Voodoo Banshee: GUI rusak saat membuka DOS mode jendela, tetapi perpindahan layar penuh berfungsi
    • S3 Trio3D/2X: layar rusak saat Windows mulai, tetapi setelah DOS prompt lalu keluar dari layar penuh, 1024x768 tampil normal
    • 3dfx Voodoo3 3500 SI: mirip Banshee, tetapi layar penuh hanya berfungsi sekali

Status akhir di Eee PC

  • Pada Eee PC nyata, GUI berjalan normal
  • Perpindahan DOS prompt layar penuh masih rusak, tetapi tampil dengan cara berbeda dari DOSBox
  • Di DOSBox, muncul text mode dengan banyak karakter rusak, sedangkan di Eee PC terlihat GUI rusak dengan sebagian warna menghilang
  • Jika berpindah kembali ke mode jendela, pemulihan bisa dilakukan
  • SVGAPatch asli membuat seluruh GUI rusak hanya dengan membuka prompt mode jendela sehingga OS perlu direstart, tetapi driver yang dimodifikasi jauh lebih baik daripada itu
  • Untuk solusi yang lebih baik, dipilih untuk terus memantau PluMGMK/vbesvga.drv, yang sedang aktif dikembangkan

Bacaan terkait

1 komentar

 
GN⁺ 2025-01-06
Opini Hacker News

  • Terlepas dari dukungan SVGA, yang selalu mengejutkan adalah ketika Windows 3.x dipasang di PC yang mendukung standar modern, VGA dasar langsung berfungsi, sementara di Linux/BSD modern, bahkan framebuffer VGA dengan akselerasi perangkat lunak dasar pun tidak mudah dipakai di Xorg/Wayland tanpa driver yang cocok dan berkas konfigurasi manual
    Proyek XFree86 yang sudah mati mungkin merupakan upaya yang paling mendekati “langsung jalan” seperti ini, tetapi jalannya masih panjang, dan pendekatan itu tampaknya tidak dipertahankan dalam fork Xorg

    • XFree86 juga tidak melakukan hal yang berbeda dari Xorg dalam hal ini
      Jika PC modern di-boot dengan CSM, meski bukan sesuatu yang direkomendasikan, Xorg seharusnya menjalankan video BIOS dengan x86emu lalu naik lewat backend VBE; jika di-boot dengan EFI, modesetting berbasis efifb seharusnya berjalan di atas mode yang ditinggalkan oleh firmware dan bootloader
      Namun ini lebih mudah untuk sistem operasi 16-bit atau 32-bit. Pengaturan mode VESA memerlukan panggilan 16-bit real mode, dan meski di bagian akhir standar secara nominal ada entry point 32-bit, hampir tidak ada yang mengimplementasikannya dengan benar. Begitu masuk ke mode 64-bit, vm86 tidak bisa dipakai sehingga kode 16-bit tidak dapat dipanggil dari user space; karena itu diperlukan x86emu, yang membaca kode video BIOS dan menjalankannya di emulator x86, tetapi ini tidak selalu sempurna
    • Di Linux ada vgafb/vesafb, jadi jika distribusinya dikonfigurasi dengan tepat, hal itu memungkinkan
      Namun biasanya pengalaman yang dihasilkan berkinerja dan berkualitas rendah, dan pengguna mungkin tidak tahu penyebabnya, jadi tampaknya sebagian atau sebagian besar distribusi tidak mengaktifkannya secara default. Sekarang hampir semua GPU didukung secara native, mungkin juga tidak ada motivasi untuk membuat pop-up yang berkata “Anda sedang memakai VGA/VESA tanpa akselerasi, perbaiki ini”
    • Ini sudah lama sekali, tetapi saya ingat X pernah punya driver VGA generik yang “langsung jalan”. Apakah maksudnya sekarang itu sudah tidak ada?
    • X11 sudah lama punya driver VESA, tetapi jumlah piksel yang harus diproses bertambah cepat seiring resolusi, sehingga skalabilitas kinerjanya buruk
      Distribusi Linux bootable yang saya pakai untuk pekerjaan, terutama GRML dan Clonezilla, otomatis menyesuaikan ke resolusi native layar atau KVM virtual saat boot berkat dukungan KMS, dan bekerja cukup baik. Anaconda, yaitu installer keluarga RedHat, serta installer Debian juga menyesuaikan ke resolusi native saat boot
      Installer GUI menggunakan VESA secara langsung di atas X11
      Fork Xorg juga sudah lama mendukung “boot tanpa berkas konfigurasi”. Saya sudah sangat lama tidak mengelola berkas konfigurasi, dan itu jauh lebih memuaskan. Lihat https://www.xkcd.com/963/
    • Saya menganggap Xorg kurang lebih sebagai XFree86 yang sistem build-nya dirapikan

  • GUI Windows 3.1 lama terlihat jauh lebih intuitif, efisien, dan enak dipakai dibanding yang sekarang
    https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...
    Di layar beresolusi rendah seperti dalam artikel, seperti apa jadinya Win11? Menu Start Win11 hampir tidak bisa dipakai selain mengetik kata kunci lalu berdoa kepada rangkaiannya
    Hipotesis polos saya: Windows NT dan 2000 adalah titik optimalnya, lalu setelah itu para product manager mulai melakukan sihir. KDE dan Gnome tidak banyak berubah, tetapi seiring waktu justru terlihat makin menarik :)

    • Menurut saya versi “bagus” terakhir adalah Windows 7. Mirip NT/2000, tetapi lebih cantik berkat peningkatan hardware grafis, begitu juga XP sebelumnya. Vista sendiri UI-nya baik-baik saja; cacatnya ada di tempat lain
      Windows 8 merusak semuanya dan Windows tidak pernah pulih. Menurut saya alasannya ada dua: kebangkitan platform mobile dan kemalasan Microsoft
      Kini muncul masalah sulit: banyak aplikasi punya versi desktop dan versi mobile terpisah. Yang satu untuk layar besar plus keyboard dan mouse, yang lain untuk layar sentuh kecil, sehingga aplikasi desktop yang baik dan aplikasi mobile yang baik harus benar-benar berbeda. Namun karena mereka ingin kedua versi terasa familier bagi pengguna, kompromi tetap muncul meski sudah berusaha sebaik mungkin
      Microsoft sebenarnya bisa saja menanganinya dengan cukup baik, tetapi tidak melakukannya. Lihat saja Control Panel. Settings, Control Panel baru, sudah ada sejak Windows 8, 12 tahun lalu, tetapi masih belum bisa memindahkan semua fungsi dari Control Panel lama sehingga keduanya tetap diperlukan. Beberapa bulan lalu mereka mencoba melakukan peralihan penuh, tetapi ternyata belum siap, dan entah apakah akan pernah siap. Selain itu, mereka sering menghapus opsi kustomisasi yang populer, dan gaya antar aplikasi bawaan juga tidak konsisten. Ini bukan sekadar kontroversial, melainkan secara objektif buruk
      Faktor lain yang tidak bisa semata-mata ditimpakan pada Microsoft dan Windows adalah para pengembang aplikasi lebih memprioritaskan branding dan konsistensi internal daripada integrasi dengan sistem operasi. Banyak UI modern hanyalah halaman web yang dirender dengan engine browser seperti Electron, tidak memakai kontrol native sistem operasi, mengabaikan tema, dan menggambar sendiri dekorasi jendela. Sistem operasi memang bisa saja tidak konsisten, tetapi pengembang aplikasi juga tidak membantu
    • Flat design nyaris menjadi bencana bagi industri. Skeuomorphism pun sebenarnya cukup buruk, karena pada dasarnya hanya flat design yang ditempeli gambar
      Windows Forms melakukan banyak hal dengan benar, dan kalau harus menyebut satu isyarat yang hilang, mungkin “aktif tetapi tidak bisa diedit”
    • Menurut cerita yang beredar, Windows 11 awalnya adalah Windows 10X yang juga dibuat untuk ponsel dan tablet. Menu Start-nya tampak cukup dipengaruhi Android: menampilkan semua yang terpasang secara datar dan lebih mendorong penggunaan pencarian
      Meski begitu, saya setuju. Beta Win10 pernah memiliki bentuk yang mencampur tile dengan daftar ala Windows 7, dan karena itu merupakan pendekatan yang berlanjut sampai Windows 2000, saya rasa itulah puncaknya. Kita bisa saja mendapatkan kelebihan dari keduanya. Area notifikasi memang selalu lemah, dan panel Settings buruk dibanding Control Panel. Tentu saja Control Panel juga berantakan dan rumit, jadi apakah itu yang terbaik masih bisa diperdebatkan

  • Penulis mengatakan layar menjadi rusak saat membuka prompt DOS dalam mode jendela; ini bisa terjadi karena prompt DOS berjalan di VM terpisah, yaitu mode V86, dan memanggil VGA ROM BIOS melalui INT 10h
    VGA ROM BIOS pada perangkat ini kemungkinan besar adalah wrapper di atas VBE, artinya mungkin berisi instruksi IN/OUT yang mengakses port I/O VBE, yaitu 0x1CE dan 0x1CF. Pembacaan dan penulisan seperti ini yang terjadi di VM DOS pada dasarnya akan sampai ke hardware nyata jika tidak divirtualisasi oleh VMM
    Ini adalah masalah umum yang harus ditangani para penulis driver display Windows 3.x/9x, tetapi nomor port I/O yang perlu divirtualisasi berbeda-beda untuk tiap adapter grafis. Win95 DDK memiliki contoh yang mengatur trap port I/O dengan layanan VMM Install_IO_Handler dan Enable/Disable_Global_Trapping, lalu di dalam handler trap memakai VDD_Get_VM_Info untuk menentukan VM mana yang saat ini memiliki CRTC. Dengan ini, handler trap bisa memutuskan apakah I/O akan diteruskan ke hardware, atau divirtualisasi dengan cara apa. Kebijakan virtualisasi yang bagus sebagai titik awal adalah membuang begitu saja penulisan dari VM yang bukan pemilik CRTC, lalu menambahkan kompleksitas yang diperlukan belakangan

  • Virtual Display Device(VDD) berjalan sebagai bagian dari manajer mesin virtual dasar, dan bertindak seperti multiplexer untuk hardware video. Jika aplikasi DOS berjalan fullscreen, perintahnya diteruskan langsung ke adapter VGA “asli”, dan jika tidak, VDD mengemulasikannya
    Menarik melihat orang lain menemukan kembali struktur seperti ini. Secara pribadi, saya menganggapnya struktur yang cukup mendahului zamannya, bahkan lebih dulu daripada hypervisor modern dengan hardware passthrough. GUI Windows 3.x sendiri, termasuk proses multitasking preemptive, pada dasarnya berjalan sebagai proses DOS protected mode yang diperluas di dalam VM tempat DOS berjalan, sementara VMM32, kernel hypervisor, melakukan multiplexing antara itu dan VM proses DOS lain. Jadi satu bagian driver display berinteraksi dengan “hardware” di bawah GDI, dan bagian lain memvirtualisasikan hardware di ring 0 serta melakukan multiplexing dengan VM lain
    Ini mungkin bisa diperbaiki di DOSBox, tetapi perbaikan itu akan terikat pada adapter video tertentu yang diemulasikan DOSBox. Yang diinginkan bukan itu, melainkan membuat patch VBE generik bekerja lebih baik
    Saya pernah menulis driver framebuffer VESA Win9x untuk Intel GMA950 dan menambahkan akselerasi dasar, yaitu perintah blitter dan fill, dan pada dasarnya mengalami masalah yang sama sehingga menyadari mengapa Win9x tidak punya driver VESA generik. VDD harus tahu cara menyimpan dan memulihkan status GPU, dan detail itu tentu bergantung pada vendor. Saya juga sempat memikirkan ide yang bisa dibuat generik. Misalnya mengemulasikan atau menelusuri VBIOS untuk melihat port dan MMIO apa saja yang disentuh pada setiap pergantian mode, tetapi tidak sampai mengimplementasikannya
    Di DOSBox muncul mode teks dengan banyak karakter rusak, dan di Eee PC muncul GUI rusak dengan sebagian warna hilang
    Ini terlihat seperti register palet tidak disimpan dan dipulihkan dengan benar. Selain itu, kerusakan di bagian atas layar bisa dihindari dengan memindahkan plane tampilan resolusi tinggi ke atas 256K, sehingga 256K pertama VRAM tersisa untuk plane VGA dan emulasi VGA. Untungnya Intel GMA memiliki cukup banyak dokumentasi publik. Bukan dokumen 900 dan 950, melainkan dokumen 810/815 dan 965 ke atas, tetapi sebagian besar register dan perintah tidak berubah sehingga bisa dijadikan referensi untuk detailnya

  • Katanya “karena tidak ada dukungan x86_64, sebagian besar distro Linux modern pun tidak bisa dijalankan”, tetapi Eee saya masih bertahan dengan Debian 32-bit
    Firefox terlalu berat sehingga nyaris tersendat-sendat, tetapi streaming video dengan mpv masih cukup lancar. Saya terutama memakainya seperti mesin tik dengan sedikit distraksi, yang bisa menjalankan pandoc saat pekerjaan buku menumpuk

    • Saya sepenuhnya setuju bahwa komputer dengan distraksi minimal bagus untuk menulis. Untuk tujuan itu saya memakai WordPerfect 5.1 di PS/2 386SX
      Saya menyukai EEE karena sangat portabel, tetapi menurut saya keyboard-nya terlalu kecil untuk mengetik serius
    • Jika dipakai tanpa web atau aplikasi modern, ini bisa menjadi use case menarik untuk sesuatu seperti Haiku OS
      Saya pernah mencobanya di PC, dan memang jelas kekurangan software yang bisa dipakai untuk menjadi sistem operasi harian sungguhan, tetapi untuk penggunaan dengan konektivitas rendah seperti mesin tik dan email, rasanya seperti OS yang sangat menyenangkan
      Saya suka kesan konsisten dari UI, software bawaan, hingga filesystem-nya. Jika saya memahaminya dengan benar, filesystem adalah representasi semua data, “file” bisa memiliki metadata arbitrer, dan hampir semuanya bisa dilakukan dari file manager. Seluruh filesystem terasa seperti database NoSQL, dan aplikasi-aplikasinya menerima struktur itu secara alami. Kontak adalah “file” di dalam folder, email juga “file” di dalam folder, dan seterusnya
      Saat itu saya belum pernah mencoba BeOS, tetapi pada era 90-an ketika konektivitas masih rendah, paradigma ini tampaknya cukup cocok. Menulis “file” email tanpa internet, menyeretnya ke floppy drive, lalu mengirimkannya lewat internet dari komputer lain—semua dilakukan hanya dengan file manager—terasa sangat konsisten, sampai mengejutkan
      Sayangnya, begitu harus beroperasi dengan komputer lain yang tidak kompatibel dengan filesystem BeOS/Haiku, kegunaan paradigma ini berkurang. Secara statistik, hampir semua komputer memang seperti itu
      Namun untuk perangkat yang dipakai sebagai mesin tik, ini bisa menarik
    • Setahu saya Debian akan menghapus dukungan 32-bit x86 pada rilis berikutnya
    • Saya dulu punya 1215B, tetapi mati tahun lalu, dan sekarang posisinya digantikan tablet Android
      Tablet tampaknya telah menyapu segmen pasar netbook. Ultraportable atau 2-in-1 memang masih ada, tetapi itu lebih dekat ke sisi harga yang berlawanan

  • Judulnya agak membingungkan
    Meski begitu, setiap kali membaca bagaimana Windows berbasis DOS lama bekerja di dalamnya, saya selalu merasa kagum. Semuanya seperti ditempel dengan duct tape software, tetapi entah bagaimana tetap berjalan

    • Coba dengarkan cerita Casey Muratori. Intinya, mereka membangun tumpukan abstraksi raksasa yang sebenarnya tidak diperlukan, dan hanya membuat performa memburuk

  • Saya ingat ketika ET4000H keluar, saat itu belum didukung di Windows 3.1. Saya menelepon dukungan teknis MS, lalu mereka mengirimkan disket driver, dan tiba 8 jam kemudian
    Itu dukungan terbaik yang pernah saya dapatkan untuk produk bajakan

    • Tepatnya, ET4000H sama dengan ET4000ax yang sudah didukung di Windows 3.0 dan 3.1, tetapi alih-alih DAC 256 warna, produk itu memiliki HiDAC, yaitu true color 15/16-bit
      Ingatan saya samar, tetapi sepertinya mode 16 warna berfungsi dengan driver bawaan, sementara 256 warna atau lebih tidak bisa, dan pilihan resolusinya mungkin juga terbatas
      Menurut MS, driver yang mendukung HiDAC keluar pada minggu ketiga April 1992, 1–2 minggu setelah waktu yang saya ingat, jadi secara umum tampaknya cocok

  • Menarik. Saya punya EEEPC 701 yang kecil, dan masih berfungsi, tetapi belum pernah terpikir untuk memakainya buat game retro
    Punya saya hanya menumpuk debu, tapi sepertinya seru kalau mencoba hal-hal seperti ini

    • Sepertinya yang dimaksud 701. 207g bukan nama model Eee PC

  • Ketika saya iseng membandingkan catatan-catatan kecilnya, terlihat perubahan status berikutnya yang mungkin sudah ditatap sampai mengalami kejenuhan makna
    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
    Dari polanya, DOS yang rusak dan GUI yang rusak bernilai 200 atau 250, sedangkan yang normal 100 atau 050. Alamat itu apa?
    GUI yang rusak entah bagaimana berada di mode M_VGA, bukan LIN8. Bagaimana dan mengapa bisa begitu, dan apakah ada hubungannya dengan alasan ia menjadi 400x600, setengah lebar horizontal dari 800x600? “Mode teks” sebenarnya adalah 720x400 seperti terlihat pada kedua mode DOS

  • Saya tidak tahu apakah penulisnya akan melihat, tetapi saya sudah memberi tahu pembuat patch tentang tulisan ini
    https://www.bttr-software.de/forum/board_entry.php?id=22124#...