Bir Köpek ile Windows 3.1 Grafik Yığını Karşı Karşıya

• 2008 model Asus Eee PC 1000H üzerinde Windows 3.11’i 1024x600 ekrana uyacak şekilde kullanmaya çalışırken, varsayılan VGA’nın ve Microsoft’un 256 renkli Super VGA sürücüsünün sınırları ortaya çıktı
• Windows 3.x’in Super VGA desteği ortak bir standart yerine kartlara özel tescilli genişletmelere göre tasarlanmıştı; Eee PC’nin Intel GMA 950’si de desteklenenler arasında değildi
• SVGAPatch, Microsoft svga256.drv dosyasını VBE çağrılarını temel alacak şekilde değiştirerek yüksek çözünürlüklü 256 renkli çıkışı mümkün kılıyor; ancak DOS ekran geçişinden sonra GUI’nin bozulması sorunu devam ediyordu
• Tersine analiz sonucunda ilk mod ayarının VBE’ye çevrildiği, fakat ekran geçişi sırasında yeniden ayarlama yolunun hâlâ Tseng ET4000 için mod 30h’yi ve text mode durumunda VBE scan line ayarını çağırdığı görüldü
• Ek yamayla tam ekran DOS oturumundan GUI’ye dönerken oluşan bozulma azaltıldı; ancak bank switching durumu tamamen çözülemediği için gerçek Eee PC’de GUI’nin ve pencereli modun kurtarılabildiği bir seviyede kaldı

---

Eee PC’de Windows 3.11 grafiklerini hayata döndürmek

• Hedef cihaz, 2008’de satın alınan Asus Eee PC 1000H; x86_64 desteği olmadığından güncel Linux dağıtımlarının çoğunu çalıştırmakta da zorlanıyor
• Amaç, bu netbook üzerinde Windows 3.11 for Workgroups’u daha iyi bir video çıkışıyla çalıştırmaktı
• Varsayılan çıkış VGA 640x480 16 renk olduğundan 1024x600 ekranda iyi görünmüyor ve en-boy oranı da uymuyor
• Windows 3.11 kurulum programı eski video bağdaştırıcıları için sürücüler içeriyor, ancak Eee PC’nin Intel GMA 950’sini desteklemiyor
• Dahil edilen Super VGA sürücüsü en fazla 1024x768 256 renk destekliyor gibi görünse de bu ortamda hata veriyor ve Windows başlamıyor

VGA, SVGA ve VBE arasındaki fark

• VGA, 1980’lerde IBM’in tasarladığı belirli bir video denetleyicisidir; yalnızca mavi analog konnektör ya da 640x480 çözünürlük anlamına gelmez
• SVGA bir standart olmaktan çok “temel VGA’dan gelişmiş olanlar”ı topluca ifade eden bir terime yakındı ve yazılımların her kartın tescilli genişletmelerini doğrudan desteklemesi gerekiyordu
• Microsoft’un 256 renkli SVGA sürücüsü destek listesinde şu aileler yer alıyordu
  • 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 dışındaki işlevlerin ortak bir arayüzle ele alınmasını sağlar; ancak Windows 3.x doğrudan bir VBE sürücüsü içermez
• BearWindows’un VBE9x ve VBEMP sürücüleri sırasıyla Windows 9x ve NT’de VBE kullanılmasını sağlar, fakat Windows 3.x sürümü yoktur

SVGAPatch’in çözdükleri ve geride bıraktıkları

• SVGAPatch, Microsoft’un 256 renkli Super VGA sürücüsünü VBE kullanacak şekilde yamalar
• Yamalanmış sürücü 1024x600 gibi ekranları doğru gösterebilir, ancak DOS uyumluluğunda çakışma yaşanır
• Windows 3.1 Enhanced Mode, grafik Windows uygulamalarıyla DOS uygulamalarını birlikte çalıştırabilir; DOS prompt’u da pencere içinde veya tam ekran açılabilir
• SVGAPatch uygulandıktan sonra şu sorunlar yeniden üretildi
  • Tam ekran DOS moduna girip Windows GUI’ye dönüldüğünde ekran bozuluyor
  • Bazı durumlarda yalnızca pencereli DOS prompt’u açmak bile ekranı bozuyor
  • DOSBox, 86Box ve gerçek Eee PC’de hepsinde yeniden üretilebiliyor, ancak bozulma biçimi biraz farklı
• Ayrı bir yeni sürücü olan PluMGMK/vbesvga.drv true color modlara kadar destek veriyor; ancak burada analiz, Microsoft kodunu ve SVGAPatch’i düzeltme yönünde ilerledi

Windows 3.x grafik yığınının yapısı

• Windows 3.x Enhanced Mode, 32 bit korumalı moddaki Virtual Machine Manager’ın birden fazla VM oluşturduğu ve ilk VM içinde Standard mode Windows’un çalıştığı bir yapıya sahiptir
• Windows Setup’ta bir video bağdaştırıcısı seçildiğinde tek bir sürücü değil, birden fazla bileşen birlikte kurulur
  • Grabber: Pencereli DOS uygulamalarının render edilmesinden sorumlu olduğu anlaşılıyor
  • Display Driver: Ana Windows VM içinde donanım başlatma ve GUI render işlemlerinden sorumludur; Windows 3.x’te GDI’nin önemli bir kısmını da kendi içinde uygular
  • Virtual Display Device(VDD): Virtual Machine Manager’ın bir parçası olarak çalışır ve DOS uygulamaları ile gerçek VGA donanımı arasını çoklar
• 256 renkli SVGA girdileri aynı sürücüyü kullanır; SYSTEM.INI içindeki çözünürlük ve DPI ayarlarıyla ayrılır
• SVGAPatch yalnızca Display Driver’ı değiştirir, SVGA VDD’ye dokunmaz
• Sonuçta ekran bozulmasının nedenini daraltmak için Display Driver, VDD ve SVGAPatch’in yaptığı özel değişiklikleri birlikte anlamak gerekti

Tersine analizde kullanılan kaynaklar ve araçlar

• Referans olarak Windows 3.x VDDVGA ve Windows 3.1 DDK kullanıldı
• Windows 3.1 DDK şu kaynakları içeriyor
  • VGA, IBM 8514, Video 7, 16 renkli SVGA Display Driver kaynak kodları
  • VGA, IBM 8514, Video 7, 16 renkli SVGA VDD kaynak kodları
  • Neredeyse tüm Grabber kaynak kodları
  • Çok az dokümantasyon
• Asıl gereken 256 renkli SVGA Display Driver ve ilgili VDD kaynak kodları ise dahil değil
• svga256.drv ve vddsvga.386 analizinde IDA ve Ghidra kullanıldı
• Ghidra .drv dosyasını okuyabiliyordu; ancak VDD bir VxD olduğu için ayrı bir LX loader gerekiyordu ve 32 bit kod ile 16 bit kodun karışık olduğu dosyalarla çalışmada kısıtları vardı

svga256.drv iç analizi

• svga256.drv içinde GETCHARWIDTH, STRETCHBLT, VIDEOINIT_ATI gibi export fonksiyonları vardı; bunlar DDK kaynaklarıyla karşılaştırılabiliyordu
• Bazı fonksiyonlar VGA sürücü kaynaklarıyla neredeyse aynıydı; ancak GETCHARWIDTH gibi bold font genişliği düzeltme işlevi eksik olan farklar da vardı
• REALIZEOBJECT içinde VGA sürücüsü ile Video 7 sürücüsünün kodları karışmış gibi görünen farklılıklar vardı; renk işleme mantığı da farklıydı
• Yalnızca GDI fonksiyonlarıyla video bağdaştırıcısı etkileşimini açıklamak zor olduğundan analiz, başlatma yolu olan physical_enable üzerine devam etti

physical_enable ve Microsoft SVGA sürücüsünün yöntemi

• Windows Setup’ta “Super VGA (800x600, 256 colours, small fonts)” seçildiğinde SYSTEM.INI içine şu değerler girer
  • dpi=96
  • resolution=2
• Yamalanmış sürücü, önyüklemeden sonra ek olarak şu değerleri yazar
  • svgamode=48
  • ChipSet=Tseng ET4000
  • LatchCapable=No
• physical_enable, video modunu ayarlayan ve desteklenen mod listesini tarayarak çalışan yonga setine özel modu bulan temel başlatma fonksiyonudur
• Microsoft’un özgün mantığı, çözünürlüklere göre desteklenen mod tabloları tutar ve her modu SetAndValidateMode ile dener
• Başarılı olursa yonga setine özel başlatma fonksiyonunu, bank ayarlama fonksiyonunu vb. bulup çağırır; palet ayarı, framebuffer başlatma ve VDD adres ayarına kadar ilerler

SVGAPatch’in gerçek değişiklikleri

• SVGAPatch, üç çözünürlük listesindeki ilk yonga seti girdisinin fonksiyon ID’sini 2000 olarak değiştirir ve SetAndValidateMode ile bazı yonga setine özel fonksiyonların üzerine yazar
• Temel değişiklikler şunlardır
  • SetAndValidateMode: Mevcut VGA BIOS tabanlı mod ayarı yerine VBE 4F02h ile genişletilmiş video modu ister
  • SETBANK_TRIDENT: Trident’e özel register yazmak yerine VBE 4F05h ile video belleği penceresini taşır
  • VIDEOINIT_TRIDENT: VGA CRTC Offset Register yazmak yerine VBE 4F06h ile scan line uzunluğunu ayarlar
• Yamadan sonra desteklenen mod listesinin ilk girdisi başarılı olur ve fonksiyon ID 2000’e bağlı yeniden yazılmış fonksiyonlar kullanılır
• SYSTEM.INI içine Tseng ET4000 değerinin yazılmasının nedeni, değer fiilen kullanılmasa bile listedeki ilk girdinin adının aynen kaydedilmesidir

VDD ve DspDrvr_Addresses

• VDD, DOS programlarının gerçek donanımı tek başına kullandığını varsaydığı durumları sanallaştırmayla ele alır
• Her VM, VDD_CB_Struc yapısının bir örneğine sahiptir; bu yapı flag’leri, VGA denetleyici durum aynasını ve VM’ye özel video belleği ayırma bilgilerini içerir
• VDD içinde belirli VGA bağdaştırıcılarını algılayan ve belirli register’ları kaydetme, geri yükleme ve simüle etme yöntemlerini değiştiren üreticiye özel kodlar bulunur
• DspDrvr_Addresses, Display Driver’ın VDD’ye adres bilgilerini aktardığı servistir; yorumlara göre DX ayrılmış alandır ve 0 olmalıdır, ancak gerçek VGA VDD kodunda DX 0 olmadığında özel bir davranış vardır
• SVGA VDD’de DX == 2 olduğunda yeni bir yol bulunur ve SVGA256.DRV bu fonksiyonu şu değerlerle çağırır
  • BX = 0xFFFF
  • DX = 2
  • DS:SI, shadow memory status baytını gösterir

DOSBox-X ile nedeni daraltmak

• DOSBox-X’in Video debug overlay özelliği ve hata ayıklayıcısı kullanılarak tam ekran DOS prompt geçişi öncesi ve sonrası VGA durumları karşılaştırıldı
• Normal GUI, normal DOS, bozuk GUI ve bozuk DOS durumlarında görünen mod açıklamaları ve register durumları farklıydı
• Vendor-specific VDD flag’inin yanlışlıkla açılıp açılmadığını kontrol etmek için DOSBox-X değiştirilerek fiziksel bellek döküldü, ancak DOSBox’ta bu flag açılmamıştı
• VGA register’ları karşılaştırıldığında DOSBox içindeki scan_len değerinin normal ve bozuk durumlarda farklı olduğu görüldü
  • Normal DOS’ta 40
  • Bozuk DOS’ta 296
  • Normal GUI’de 128
  • Bozuk GUI’de 256
• DOSBox’un VESA Scan Line API uygulaması, geçerli video modunu yorumlamasına göre scan_len değerini farklı hesaplıyordu; şüphe bu noktada yoğunlaştı

Belirleyici ipucu: text mode’da VBE scan line ayarı

• DOSBox-X’e VESA scan line ayarı günlüğü eklendiğinde şu çağrı yakalandı
  • VESA_ScanLineLength(subcall=2, val=1024, bytes=2, pixels=1024, lines=4768)
  • Geçerli mod M_TEXT
• Display Driver VBE 4F06h ile scan line uzunluğunu 1024 bayt olarak ayarlıyor; ancak DOSBox geçerli durumu text mode olarak gördüğünden iç durum yanlış hesaplanıyor
• Windows başlangıcında 800x600 SVGA ve M_LIN8 durumunda scan line ayarı normal şekilde gerçekleşiyor
• Tam ekran DOS prompt açıldıktan sonra Alt+Enter ile GUI’ye dönüldüğünde şu akış oluşuyor
  • Bir kod mod 30h’ye, yani onluk 48’e geçiş istiyor
  • patched display driver, text mode durumundayken scan line uzunluğunu ayarlıyor
  • DOSBox iç durumu ile VGA register tabanlı durum birbirinden sapıyor
• Mod 30h, SVGAPatch’in ele geçirdiği Tseng ET4000’ün 800x600 için kullandığı mod değeriydi

Eksik kalan ekran geçiş yolu

• Windows 3.1 Display Driver, ekran geçiş komutlarını almak için INT 2Fh’yi hook eder
• VGA sürücüsü aşağıdaki dört komutu işler, ancak SVGA256 sürücüsü yalnızca SCREEN_SWITCH_OUT ve SCREEN_SWITCH_IN komutlarını destekler
  • SCREEN_SWITCH_OUT
  • SCREEN_SWITCH_IN
  • SAVE_DEV_REGS
  • RES_DEV_REGS
• Sorunlu fonksiyon, Windows GUI’ye dönüldüğünde çağrılan dev_to_foreground idi
• SVGA256’nin dev_to_foreground fonksiyonu şu akışla çalışır
  • farsetmode çağrısı
  • farsetmode mod 48’i ayarlar
  • Yonga setine özel VideoInit çağrısı
  • enabled_flag değerini 0xFF yapar
  • Windows API SetPalette çağrısı
• SVGAPatch ilk başlatmadaki mod ayarı yolunu VBE’ye çevirmişti, ancak ekran geçişi sırasında modu yeniden ayarlayan yolu değiştirmemişti

Ek yamayla GUI kurtarmayı iyileştirmek

• Özgün setmode kodu, wGraphicsMode değerini ax içine koyup INT 10h çağırdıktan sonra ptr_videoinit çağıran kısa bir yapıdaydı
• SVGAPatch’in kısalttığı SetAndValidateMode sonrasında kalan boşluğa yeni kod eklendi
  • CurrentHeight değerinden 1 çıkarılan değer cx içine kondu
  • SetAndValidateMode çağrıldı
  • ptr_videoinit çağrıldı
• setmode içindeki ilk komut yeni koda atlayacak şekilde değiştirildi; böylece ekran geçişinde de VBE tabanlı mod ayarı yolu kullanılmaya başlandı
• Bu düzeltmeden sonra tam ekran DOS oturumuna girip GUI’ye dönüldüğünde ekran artık bozulmadı
• Ancak pencereli moddan tam ekrana geçerken noktaların yeniden belirmesi sorunu devam etti

Kalan bank switching sorunu

• DOSBox hata ayıklayıcısında B8000 VGA belleğine bakıldığında metin içeriği vardı, ancak ekranda görünmüyordu
• Şüpheli nokta, sürücünün daha fazla video belleğine erişmek için kullandığı bank switching idi
• DOSBox-X’e SVGA bank durumunu yazdıran bir komut eklendiğinde, tam ekrana dönülürken VGA bağdaştırıcısının yanlış bank’te kaldığı doğrulandı
• dev_to_background içine bank’i 0’a döndürmeye çalışan yeni bir rutin eklendi, ancak sorun düzelmedi
• DOSBox’un VBE 4F05h uygulaması VGA CRTC register 0x6A’ya yazma şeklindeydi ve dev_to_background çağrıldığında VDD zaten yazmaları trap ettiği bir durumda olduğundan çok geçti

Özgün sürücü ve yamalı sürücüyle deney sonuçları

• 86Box üzerinde Microsoft’un özgün SVGA 256 renk sürücüsü çeşitli emüle kartlarla denendiğinde, destek listesi içinde bile sonuçlar tutarlı değildi
  • Cirrus Logic GD5420 (ISA): çalışıyor
  • Tseng Labs ET4000AX: çalışıyor
  • Oak OTI-077: pencereli DOS prompt’u ilk açıldığında ekran bozuluyor, tam ekranda dikey çizgiler oluşuyor
  • Trident TVGA 8900D: tam ekran DOS prompt’ta ekran bozuluyor, pencereli mod normal
  • ATI VGA Wonder XL, Paradise PVGA1A, Video 7 VGA 1024i için bazı çözünürlüklerde Windows başlamıyor
• 86Box’ın birebir aynı kartları sunmadığı ve emülasyon doğruluğunun da kesin olmadığı notu var
• Değiştirilen SVGAPatch tabanlı sürücü daha yeni kartlarla denendiğinde de sonuçlar kartlara göre değişti
  • Matrox Millennium II: çok yavaş; pencereli DOS çalışıyor ama tam ekran bozuluyor
  • 3dfx Voodoo Banshee: pencereli DOS açıldığında GUI bozuluyor, ancak tam ekran geçişi çalışıyor
  • S3 Trio3D/2X: Windows başlangıcında bozuk ekran görünüyor; ancak DOS prompt’tan sonra tam ekrandan çıkınca 1024x768 normal görünüyor
  • 3dfx Voodoo3 3500 SI: Banshee’ye benziyor, ancak tam ekran yalnızca bir kez çalışıyor

Eee PC’deki son durum

• Gerçek Eee PC’de GUI normal çalışıyor
• Tam ekran DOS prompt geçişi hâlâ bozuluyor, ancak DOSBox’tan farklı bir şekilde ortaya çıkıyor
• DOSBox’ta çok sayıda bozuk karakter içeren text mode görünürken, Eee PC’de bazı renkleri kaybolmuş bozuk bir GUI görülüyor
• Pencereli moda yeniden geçildiğinde kurtarma mümkün
• Özgün SVGAPatch yalnızca pencereli prompt açıldığında bile tüm GUI’yi bozuyor ve işletim sistemini yeniden başlatmayı gerektiriyordu; değiştirilmiş sürücü bununla kıyaslandığında büyük ölçüde iyileşmiş durumda
• Daha iyi bir çözüm olarak aktif biçimde geliştirilen PluMGMK/vbesvga.drv projesini izlemeye devam etme yolu seçildi

[GN⁺]

Hacker News yorumları

• SVGA desteği bir yana, güncel standartları destekleyen bir PC’ye Windows 3.x kurduğunuzda temel VGA hemen çalışıyor; modern Linux/BSD’de ise doğru sürücü ve elle hazırlanmış yapılandırma dosyaları olmadan Xorg/Wayland üzerinde temel yazılımsal hızlandırmalı VGA framebuffer’ını bile kolayca kullanamamak her zaman şaşırtıcı geliyor.
  Ölmüş XFree86 projesi bu “tak çalışsın” durumuna en çok yaklaşan girişimdi, ama önünde daha çok yol vardı ve bu yaklaşım Xorg fork’unda korunmamış gibi görünüyor.

  • XFree86 de burada Xorg’dan farklı bir şey yapmıyordu.
    Modern bir PC’de CSM ile boot ederseniz, tavsiye edilecek bir şey olmasa da Xorg’un x86emu ile video BIOS’unu çalıştırıp VBE backend ile açılması gerekir; EFI ile boot ederseniz de firmware ve bootloader’ın bıraktığı mod üzerinde efifb tabanlı modesetting’in açılması gerekir.
    Ancak bu, 16 bit ya da 32 bit işletim sistemleri için daha kolay bir iştir. VESA mod ayarı gerçek modda 16 bit çağrılar gerektirir; standardın ilerleyen kısımlarında kağıt üzerinde 32 bit giriş noktası olsa da bunu düzgün uygulayan neredeyse yoktur. 64 bit moda geçtiğinizde vm86 kullanılamadığı için kullanıcı alanından 16 bit kod çağıramazsınız; bu yüzden video BIOS kodunu okuyup bir x86 emülatöründe çalıştıran x86emu gerekir, ama bu her zaman kusursuz değildir.
  • Linux’ta vgafb/vesafb var; dağıtım uygun şekilde yapılandırılmışsa bu mümkün.
    Ancak genellikle performansı ve kalitesi düşük bir deneyim olur ve kullanıcı bunun nedenini bilemeyebilir; bu yüzden bazı ya da çoğu dağıtımın bunu varsayılan olarak açmadığı anlaşılıyor. Bugünlerde neredeyse tüm GPU’lar yerel olarak desteklendiğinden, “hızlandırmasız VGA/VESA kullanıyorsunuz, düzeltin” diye bir açılır uyarı yapma motivasyonu da olmamış olabilir.
  • Çok eski bir mesele ama X’te “tak çalışır” bir genel VGA sürücüsü olduğunu hatırlıyorum. Artık bunun olmadığı mı söyleniyor?
  • X11’de çok uzun zamandır VESA sürücüsü vardı, fakat işlenecek piksel sayısı çözünürlükle birlikte hızla arttığı için performans ölçeklenmesi kötü.
    İşte kullandığım boot edilebilir Linux dağıtımları, ağırlıkla GRML ve Clonezilla, KMS desteği sayesinde boot sırasında ekranın ya da sanal KVM’nin doğal çözünürlüğüne otomatik uyum sağlıyor ve oldukça iyi çalışıyor. Anaconda, yani RedHat ailesi kurucusu, ve Debian kurucusu da boot sırasında doğal çözünürlüğe ayarlanıyor.
    GUI kurucuları X11 üzerinde VESA’yı doğrudan kullanıyor.
    Xorg fork’u da çok uzun zamandır “yapılandırma dosyasız boot” desteğine sahip. Çok uzun süredir yapılandırma dosyası yönetmiyorum ve bu çok daha memnun edici. Bkz. https://www.xkcd.com/963/.
  • Xorg’u, build sistemleri temizlenmiş XFree86’ya yakın görüyorum.

• Eski Windows 3.1 GUI günümüzdekilerden çok daha sezgisel, verimli ve kullanışlı görünüyor.
  https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...
  Metindeki gibi düşük çözünürlüklü bir ekranda Win11 acaba nasıl görünürdü? Win11 Başlat menüsü, bir anahtar kelime yazıp devrelere dua etmek dışında neredeyse kullanılamaz halde.
  Saf bir varsayımla, Windows NT ve 2000 en iyi noktaydı; ondan sonra ürün yöneticileri sihir yapıp durdu gibi. KDE ve Gnome pek değişmedi ama zaman geçtikçe daha çekici görünüyorlar :)

  • Son “iyi” sürümün Windows 7 olduğunu düşünüyorum. NT/2000’e benziyordu ama grafik donanımındaki gelişmeler sayesinde daha güzeldi; ondan önceki XP de öyleydi. Vista’nın UI’ı da aslında fena değildi, kusurları başka yerdeydi.
    Windows 8 her şeyi bozdu ve Windows toparlanamadı. Bunun iki nedeni olduğunu düşünüyorum: mobil platformların yükselişi ve Microsoft’un tembelliği.
    Artık birçok uygulamanın ayrı masaüstü ve mobil sürümleri olması gibi çözmesi zor bir sorun var. Biri büyük ekran ve klavye-fare, diğeri küçük dokunmatik ekran; bu yüzden iyi bir masaüstü uygulamasıyla iyi bir mobil uygulamanın tamamen farklı olması gerekir. Ama kullanıcıya iki sürümün de tanıdık gelmesini istersiniz; bu nedenle en iyi çabayla bile ödünler oluşur.
    Microsoft yine de bunu makul şekilde yapabilirdi, ama yapmadı. Denetim Masası’na bakınca bu açık. Yeni Denetim Masası olan Ayarlar, Windows 8’den beri, yani 12 yıldır var; buna rağmen eski Denetim Masası’ndaki tüm işlevleri hâlâ taşıyamadı ve ikisine de ihtiyaç var. Birkaç ay önce tamamen geçiş yapmayı deneyeceklerdi ama hazır değildi; gelecekte hazır olup olmayacağı da belirsiz. Üstelik popüler özelleştirme seçeneklerini sık sık kaldırıyorlar ve paket uygulamalar arasında stil de tutarlı değil. Bu tartışmalı olmanın ötesinde, nesnel olarak kötü.
    Yalnızca Microsoft’u ve Windows’u suçlayamayacağımız bir başka etken de uygulama geliştiricilerinin işletim sistemi entegrasyonu yerine markalaşmayı ve kendi iç tutarlılıklarını önceliklendirmesi. Birçok modern UI, Electron gibi tarayıcı motorlarıyla render edilen web sayfalarından ibaret; yerel işletim sistemi kontrollerini kullanmıyor, temaları yok sayıyor ve pencere süslemelerini de kendisi çiziyor. İşletim sistemi tutarsız olabilir, ama uygulama geliştiricileri de yardımcı olmuyor.
  • Flat design sektör için neredeyse bir felaketti. Skeuomorphism de aslında üzerine resim yapıştırılmış flat design olduğundan o da epey kötüydü.
    Windows Forms birçok şeyi doğru yaptı; eksik bir gösterge seçmem gerekirse “etkin ama düzenlenemez” gibi bir durum olurdu.
  • Anlatılanlara göre Windows 11, aslında telefonlar ve tabletler için de geliştirilen Windows 10X’miş. Başlat menüsünde yüklü olan her şeyi düz bir şekilde göstermesi ve aramaya daha fazla yönlendirmesi, Android etkisini oldukça hissettiriyor.
    Yine de katılıyorum. Win10 betasında kutucuklarla Windows 7 tarzı listeyi karıştıran bir biçim vardı; bu Windows 2000’e kadar uzanan yaklaşımdı ve bence zirve oydu. İkisinin de iyi yanlarına sahip olabilirdi. Bildirim alanı her zaman zayıftı, Ayarlar paneli ise Denetim Masası’na kıyasla berbat. Elbette Denetim Masası da dağınık ve karmaşıktı; en iyisi olup olmadığı tartışılabilir.

• Yazar, DOS istemini pencere modunda açarken ekranın bozulduğunu söylemiş; bu, DOS isteminin ayrı bir VM’de, yani V86 modunda çalışması ve INT 10h ile VGA ROM BIOS’unu çağırması nedeniyle olabilir.
  Bu cihazın VGA ROM BIOS’u muhtemelen VBE üzerinde bir sarmalayıcıdır; yani VBE I/O portları olan 0x1CE ve 0x1CF’ye erişen IN/OUT komutları içeriyor olabilir. DOS VM’de gerçekleşen bu tür okuma ve yazmalar, VMM sanallaştırmazsa varsayılan olarak gerçek donanıma kadar ulaşır.
  Bu, Windows 3.x/9x görüntü sürücüsü yazarlarının ele almak zorunda kaldığı yaygın bir sorundu; ancak sanallaştırılması gereken I/O port numaraları grafik bağdaştırıcısına göre değişirdi. Win95 DDK’da, VMM hizmetleri olan Install_IO_Handler ve Enable/Disable_Global_Trapping ile I/O port tuzakları kurmayı ve tuzak işleyicisi içinde VDD_Get_VM_Info ile mevcut CRTC’ye hangi VM’in sahip olduğunu belirlemeyi gösteren bir örnek var. Böylece tuzak işleyicisi I/O’yu donanıma gönderip göndermeyeceğine veya nasıl sanallaştıracağına karar verebilir. Başlangıç için iyi bir sanallaştırma politikası, CRTC sahibi olmayan VM’lerden gelen yazmaları basitçe yok saymaktır; gereken karmaşıklık daha sonra eklenebilir.

• Virtual Display Device(VDD) temel sanal makine yöneticisinin bir parçası olarak çalışır ve video donanımı için bir çoklayıcı gibi davranır. DOS uygulaması tam ekrandaysa komutlar “gerçek” VGA bağdaştırıcısına doğrudan iletilir; değilse VDD bunları emüle eder.
  Başkalarının bu yapıyı yeniden keşfetmesi ilginç. Kişisel olarak bunun, donanım geçişi olan modern hipervizörlerden önce gelen ve döneminin oldukça ilerisinde bir yapı olduğunu düşünüyorum. Önalımlı çok görevli süreçleri de içeren Windows 3.x GUI’nin kendisi, aslında DOS’un çalıştığı bir VM içinde genişletilmiş korumalı mod DOS süreci olarak çalışır; hipervizör çekirdeği olan VMM32 de onu diğer DOS süreç VM’leriyle çoklar. Bu yüzden görüntü sürücüsünün bir bölümü GDI altında “donanım” ile etkileşirken, diğer bölümü ring 0’da donanımı sanallaştırıp diğer VM’lerle çoklar.
  Bu DOSBox’ta düzeltilebilir; ancak o düzeltme DOSBox’ın emüle ettiği belirli video bağdaştırıcısına bağlı olur. İstenen şey bu değil, genel amaçlı VBE yamasının daha iyi çalışmasını sağlamak.
  Intel GMA950 için bir Win9x VESA framebuffer sürücüsü yazmış ve temel hızlandırma, yani blitter ve doldurma komutlarını bile eklemiştim; aslında aynı sorunları yaşayarak Win9x’te neden genel amaçlı bir VESA sürücüsü olmadığını anladım. VDD’nin GPU durumunu nasıl kaydedip geri yükleyeceğini bilmesi gerekir; bu ayrıntılar da doğal olarak üreticiye bağımlıdır. Genel amaçlı yapılabilecek fikirler de düşündüm. Örneğin VBIOS’u emüle etmek ya da izleyip her mod değişiminde hangi portlara ve MMIO’ya dokunduğuna bakmak gibi; ama uygulamaya geçiremedim.
  DOSBox’ta bozuk karakterlerle dolu bir metin modu çıkıyor; Eee PC’de ise bazı renkleri kaybolmuş bozuk bir GUI görünüyor.
  Bu, palet kayıtlarının düzgün kaydedilip geri yüklenmediği izlenimini veriyor. Ayrıca ekranın üst kısmındaki bozulma, yüksek çözünürlüklü görüntü düzlemini 256K’nın üzerine taşıyıp VRAM’in ilk 256K’sını VGA düzlemi ve VGA emülasyonu için bırakarak önlenebilir. Neyse ki Intel GMA için oldukça fazla açık belge var. Bunlar 900 ve 950 belgeleri değil, 810/815 ve 965 sonrası belgeler; ama kayıtların ve komutların çoğu değişmediği için ayrıntılara bakılabilir.

• “x86_64 desteği olmadığı için çoğu güncel Linux dağıtımını da çalıştıramıyor” deniyor ama benim Eee’m 32 bit Debian ile gayet idare ediyor.
  Firefox fazla ağır olduğu için neredeyse takıla takıla çalışıyor, ama mpv ile video akışı izlemek yeterince mümkün. Ben onu çoğunlukla kitap işleri biriktiğinde pandoc çalıştırabileceğim ve dikkat dağıtıcı unsurları az olan bir daktilo gibi kullanıyorum.

  • Yazı yazarken dikkat dağıtıcı unsurları en aza indiren bir bilgisayarın iyi olduğu fikrine tamamen katılıyorum. Bu amaçla PS/2 386SX üzerinde WordPerfect 5.1 kullanıyorum.
    EEE’yi çok taşınabilir olduğu için seviyordum; ama ciddi yazı yazmak için klavyesinin fazla küçük olduğunu düşünüyorum.
  • Web ya da modern uygulamalar olmadan kullanılacaksa Haiku OS gibi bir şey için ilginç bir kullanım senaryosu olabilir.
    PC’de denedim; gerçekten günlük bir işletim sistemi olabilmesi için mevcut yazılımın kesinlikle yetersiz olduğunu gördüm, ama daktilo ve e-posta gibi düşük bağlantılı amaçlar için çok keyifli bir işletim sistemi gibi hissettirdi.
    Arayüzün, temel yazılımların ve dosya sisteminin tutarlı hissi hoşuma gitti. Doğru anladıysam dosya sistemi tüm verilerin temsili ve “dosyalar” rastgele meta veriler taşıyabiliyor; dosya yöneticisinden neredeyse her şeyi yapabiliyorsunuz. Tüm dosya sistemi NoSQL veritabanı gibi ve uygulamalar da bunu doğal biçimde benimsiyor. Kişiler bir klasör içindeki “dosyalar”, e-postalar da bir klasör içindeki “dosyalar” şeklinde.
    O dönemde BeOS’a hiç dokunmamıştım; ama bağlantının düşük olduğu 90’larda bu paradigmanın oldukça iyi uymuş olabileceğini düşünüyorum. İnternet olmadan e-posta “dosyası” yazıp disket sürücüsüne sürükleyip bırakmak, sonra başka bir bilgisayarda internet üzerinden göndermek gibi tüm süreci yalnızca dosya yöneticisiyle yapmak şaşırtıcı derecede tutarlıydı.
    Ne yazık ki BeOS/Haiku dosya sistemiyle uyumlu olmayan başka bilgisayarlarla birlikte çalışmanız gerektiği anda bu paradigmanın kullanışlılığı azalıyor. İstatistiksel olarak neredeyse tüm bilgisayarlar böyle olduğu için.
    Ama daktilo amaçlı bir cihaz için ilginç olabilir.
  • Bildiğim kadarıyla Debian bir sonraki sürümde 32 bit x86 desteğini kaldıracak.
  • 1215B’ye sahiptim ama geçen yıl öldü; artık yerini bir Android tablet aldı.
    Tabletler netbook pazar segmentini silip süpürmüş gibi görünüyor. Ultra taşınabilirler ya da 2’si 1 arada cihazlar hâlâ var, ama onlar fiyat skalasının daha çok diğer ucuna yakın.

• Başlık biraz kafa karıştırıcıydı.
  Yine de eski DOS tabanlı Windows’un içeride nasıl çalıştığını her okuduğumda hep hayranlık duyuyorum. Her şey yazılımsal koli bandıyla tutturulmuş gibi ama somehow çalışıyor.

  • Casey Muratori’nin anlattıklarını dinlemek yeterli. Devasa bir soyutlama yığını oluşturduklarını, ama bunun aslında gerekli olmadığını ve yalnızca performansı kötüleştirdiğini söylüyor.

• ET4000H çıktığında o dönemde Windows 3.1 tarafından desteklenmediğini hatırlıyorum. MS teknik desteği aradım; bana sürücü diski gönderdiler ve 8 saat sonra ulaştı.
  Korsan bir ürünle aldığım en iyi destekti.

  • Tam olarak söylersek ET4000H, Windows 3.0 ve 3.1’in zaten desteklediği ET4000ax ile aynıydı; ancak 256 renk DAC yerine HiDAC, yani 15/16 bit true color bulunan bir üründü.
    Hafızam bulanık ama temel sürücüyle 16 renk modu çalışıyordu, 256 renk ve üzeri olmuyordu sanırım; çözünürlük seçimi de sınırlı olmuş olabilir.
    MS’e göre HiDAC destekleyen sürücü 1992 Nisan’ının üçüncü haftasında çıkmış; benim hatırladığım zamandan 1-2 hafta sonrası olduğu için genel olarak uyuyor gibi.

• İlginç. Küçük model olan EEEPC 701 bende var ve hâlâ çalışıyor; ama retro oyun amaçlı kullanmayı hiç düşünmemiştim.
  Benimki sadece tozlanıyor, böyle şeyler denemek eğlenceli olabilir.

  • 701’den bahsediyor sanırım. 207g bir Eee PC model adı değil.

• Küçük notları gelişigüzel karşılaştırınca, muhtemelen anlam doygunluğu yaşayana kadar bakıldıktan sonra görülen şu durum değişimleri ortaya çıkıyor:
  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
  Desene göre bozuk DOS ve bozuk GUI 200 veya 250; düzgün olanlar ise 100 veya 050. Acaba o adres ne?
  Bozuk GUI bir şekilde LIN8 değil, M_VGA modunda. Bu nasıl ve neden oldu; 800x600’ün yatayda yarısı olan 400x600’e dönüşmesiyle bir ilgisi olabilir mi? Gerçek “metin modu”, iki DOS modunda görüldüğü gibi 720x400.

• Yazarı görür mü bilmiyorum ama bu yazıyı yama yazarına ilettim.
  https://www.bttr-software.de/forum/board_entry.php?id=22124#...