एक कुत्ते बनाम Windows 3.1 ग्राफ़िक्स स्टैक की टक्कर

 (wuffs.org)
2 पॉइंट द्वारा GN⁺ 2025-01-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2008 के Asus Eee PC 1000H पर Windows 3.11 को 1024x600 स्क्रीन के हिसाब से चलाने की कोशिश में, बेसिक VGA और Microsoft 256-कलर Super VGA ड्राइवर की सीमाएँ सामने आईं
  • Windows 3.x का Super VGA सपोर्ट किसी साझा standard पर नहीं, बल्कि हर कार्ड की proprietary extensions के हिसाब से बना था, और Eee PC का Intel GMA 950 सपोर्टेड नहीं था
  • SVGAPatch Microsoft svga256.drv को VBE calls आधारित बनाकर high-resolution 256-कलर output संभव करता है, लेकिन DOS स्क्रीन switching के बाद GUI टूटने की समस्या बची रहती थी
  • reverse analysis से पता चला कि initial mode setting तो VBE में बदल गई थी, लेकिन स्क्रीन switching के समय reset path अब भी Tseng ET4000 के mode 30h और text mode state में VBE scan line setting को call कर रहा था
  • अतिरिक्त patch से fullscreen DOS session से GUI पर लौटते समय corruption कम हुआ, लेकिन bank switching state तक पूरी तरह हल नहीं हुई; वास्तविक Eee PC पर यह GUI और windowed mode recovery संभव होने के स्तर तक ही पहुँचा

Eee PC पर Windows 3.11 graphics को फिर से चलाने लायक बनाना

  • target device 2008 में खरीदा गया Asus Eee PC 1000H है, जो x86_64 support न होने के कारण अधिकतर आधुनिक Linux distributions भी चलाने में कठिन स्थिति में है
  • लक्ष्य इस netbook पर Windows 3.11 for Workgroups को बेहतर video output के साथ चलाना था
  • default output VGA 640x480 16-color है, इसलिए 1024x600 स्क्रीन पर यह अच्छा नहीं दिखता और aspect ratio भी match नहीं करता
  • Windows 3.11 installer में पुराने video adapters के लिए drivers शामिल हैं, लेकिन Eee PC का Intel GMA 950 सपोर्ट नहीं करता
  • bundled Super VGA driver अधिकतम 1024x768 256-color support करता हुआ दिखता है, लेकिन इस environment में error देता है और Windows start नहीं होता

VGA, SVGA और VBE में फर्क

  • VGA 1980s में IBM द्वारा design किया गया एक specific video controller है; इसका मतलब सिर्फ blue analog connector या 640x480 resolution नहीं है
  • SVGA किसी standard से ज़्यादा “basic VGA से आगे की चीज़” को साथ में पुकारने वाला शब्द था, और software को हर card की proprietary extensions को सीधे support करना पड़ता था
  • Microsoft के 256-color SVGA driver support list में ये series शामिल हैं
    • 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 के बाहर की functionalities को common interface से handle करने देता है, लेकिन Windows 3.x में direct VBE driver शामिल नहीं था
  • BearWindows के VBE9x और VBEMP क्रमशः Windows 9x और NT में VBE इस्तेमाल करने देते हैं, लेकिन Windows 3.x version नहीं है

SVGAPatch ने क्या हल किया और क्या छोड़ा

  • SVGAPatch Microsoft के 256-color Super VGA driver को patch करके VBE इस्तेमाल करवाता है
  • patched driver 1024x600 जैसी screen को सही तरह display कर सकता है, लेकिन DOS compatibility में conflict आता है
  • Windows 3.1 Enhanced Mode graphical Windows apps और DOS applications को साथ-साथ चला सकता है, और DOS prompt को window या fullscreen में भी खोल सकता है
  • SVGAPatch लगाने के बाद ये समस्याएँ reproduce हुईं
    • fullscreen DOS mode में जाकर Windows GUI पर लौटने पर screen corrupt हो जाती है
    • कुछ मामलों में सिर्फ windowed DOS prompt खोलने से भी screen corrupt हो जाती है
    • DOSBox, 86Box और वास्तविक Eee PC—तीनों में reproduce होता है, लेकिन corruption का तरीका थोड़ा-थोड़ा अलग है
  • अलग नए driver PluMGMK/vbesvga.drv में true color modes तक support हैं, लेकिन यहाँ analysis Microsoft code और SVGAPatch को सुधारने की दिशा में किया गया

Windows 3.x graphics stack की संरचना

  • Windows 3.x Enhanced Mode में 32-bit protected mode का Virtual Machine Manager कई VMs बनाता है, और पहली VM के अंदर Standard mode Windows चलता है
  • Windows Setup में video adapter चुनने पर कोई single driver नहीं, बल्कि कई components साथ install होते हैं
    • Grabber: समझा गया कि यह windowed DOS apps rendering संभालता है
    • Display Driver: main Windows VM के अंदर hardware initialization और GUI rendering संभालता है, और Windows 3.x में GDI का काफी हिस्सा खुद implement करता है
    • Virtual Display Device(VDD): Virtual Machine Manager के हिस्से के रूप में चलता है और DOS apps व वास्तविक VGA hardware के बीच multiplexing करता है
  • 256-color SVGA entries वही driver इस्तेमाल करती हैं, और SYSTEM.INI की resolution व DPI settings से अलग होती हैं
  • SVGAPatch सिर्फ Display Driver modify करता है, SVGA VDD को नहीं छूता
  • आखिरकार screen corruption का कारण narrow down करने के लिए Display Driver, VDD और SVGAPatch द्वारा किए गए private changes को साथ समझना पड़ा

reverse analysis में इस्तेमाल material और tools

  • reference material के रूप में Windows 3.x VDDVGA और Windows 3.1 DDK इस्तेमाल किए गए
  • Windows 3.1 DDK में ये sources शामिल हैं
    • VGA, IBM 8514, Video 7, 16-color SVGA Display Driver source
    • VGA, IBM 8514, Video 7, 16-color SVGA VDD source
    • लगभग सारे Grabber sources
    • बहुत कम documentation
  • असल में ज़रूरी 256-color SVGA Display Driver और संबंधित VDD source शामिल नहीं हैं
  • svga256.drv और vddsvga.386 के analysis के लिए IDA और Ghidra इस्तेमाल किए गए
  • Ghidra .drv पढ़ सकता था, लेकिन VDD एक VxD था इसलिए अलग LX loader चाहिए था, और 32-bit code व 16-bit code मिले-जुले file को handle करने में limitations थीं

svga256.drv के अंदर का analysis

  • svga256.drv में GETCHARWIDTH, STRETCHBLT, VIDEOINIT_ATI जैसी export functions हैं, जिन्हें DDK source से compare किया जा सकता था
  • कुछ functions VGA driver source से लगभग समान थे, लेकिन GETCHARWIDTH में bold font width adjustment capability न होने जैसा अंतर भी था
  • REALIZEOBJECT में VGA driver और Video 7 driver के code के मिले-जुले होने जैसा अंतर दिखा, और color handling logic भी अलग था
  • सिर्फ GDI functions से video adapter interaction explain करना कठिन था, इसलिए initialization path physical_enable के analysis तक बात पहुँची

physical_enable और Microsoft SVGA driver का तरीका

  • Windows Setup में “Super VGA (800x600, 256 colours, small fonts)” चुनने पर SYSTEM.INI में ये values आती हैं
    • dpi=96
    • resolution=2
  • patched driver boot के बाद अतिरिक्त रूप से ये values लिखता है
    • svgamode=48
    • ChipSet=Tseng ET4000
    • LatchCapable=No
  • physical_enable video mode set करता है और supported mode list scan करके chipset-specific working mode ढूँढने वाला core initialization function है
  • Microsoft की original logic में resolution-wise supported mode tables हैं, और SetAndValidateMode से हर mode test किया जाता है
  • सफल होने पर यह chipset-specific initialization function और bank setting function आदि ढूँढकर call करता है, और palette setting, framebuffer initialization, VDD address setting तक आगे बढ़ता है

SVGAPatch में असल changes

  • SVGAPatch तीन resolution lists में पहले chipset entry की function ID को 2000 में बदलता है, और SetAndValidateMode व कुछ chipset-specific functions overwrite करता है
  • core changes ये हैं
    • SetAndValidateMode: मौजूदा VGA BIOS आधारित mode setting के बजाय VBE 4F02h से extended video mode request करता है
    • SETBANK_TRIDENT: Trident-specific register writes के बजाय VBE 4F05h से video memory window move करता है
    • VIDEOINIT_TRIDENT: VGA CRTC Offset Register write के बजाय VBE 4F06h से scan line length set करता है
  • patch के बाद supported mode list की पहली entry सफल होती है, और function ID 2000 से जुड़ी rewritten functions इस्तेमाल होती हैं
  • SYSTEM.INI में Tseng ET4000 value लिखे जाने की वजह यह है कि भले ही value वास्तव में इस्तेमाल न हो, list की पहली entry का नाम वैसे ही save हो जाता है

VDD और DspDrvr_Addresses

  • VDD उस स्थिति को virtualization से handle करता है जहाँ DOS program actual hardware पर exclusive control की उम्मीद करता है
  • हर VM में VDD_CB_Struc structure instance होता है, और इस structure में flags, VGA controller state mirror, और VM-specific video memory allocation info होता है
  • VDD में particular VGA adapter detect करने और specific register save/restore/simulation methods बदलने वाला vendor-specific code मौजूद है
  • DspDrvr_Addresses वह service है जिससे Display Driver VDD को address info देता है; comments के अनुसार DX reserved field है और 0 होना चाहिए, लेकिन actual VGA VDD code में DX non-zero होने पर special behavior है
  • SVGA VDD में DX == 2 होने पर नया path है, और SVGA256.DRV इस function को इन values से call करता है
    • BX = 0xFFFF
    • DX = 2
    • DS:SI shadow memory status byte को point करता है

DOSBox-X से कारण narrow down करना

  • DOSBox-X के Video debug overlay और debugger का इस्तेमाल करके fullscreen DOS prompt switching से पहले और बाद की VGA state compare की गई
  • normal GUI, normal DOS, corrupt GUI, corrupt DOS states में दिखने वाली mode annotations और register states अलग थीं
  • vendor-specific VDD flag गलती से on हो रहा है या नहीं, यह check करने के लिए DOSBox-X modify करके physical memory dump किया गया, लेकिन DOSBox में वह flag on नहीं था
  • VGA registers compare करने पर DOSBox के अंदर scan_len value normal state और corrupt state में अलग थी
    • normal DOS में 40
    • corrupt DOS में 296
    • normal GUI में 128
    • corrupt GUI में 256
  • DOSBox की VESA Scan Line API implementation current video mode decision के आधार पर scan_len अलग calculate करती थी, और यह point main suspect के रूप में narrow down हुआ

निर्णायक clue: text mode में VBE scan line setting

  • DOSBox-X में VESA scan line setting log add करने पर ये call पकड़ा गया
    • VESA_ScanLineLength(subcall=2, val=1024, bytes=2, pixels=1024, lines=4768)
    • current mode M_TEXT है
  • Display Driver VBE 4F06h से scan line length को 1024 bytes पर set करता है, लेकिन DOSBox current state को text mode मान रहा है, जिससे internal state गलत calculate हो जाती है
  • Windows start के समय 800x600 SVGA और M_LIN8 state में scan line setting सही तरह होती है
  • fullscreen DOS prompt खोलने के बाद Alt+Enter से GUI पर लौटते समय यह flow होता है
    • कोई code mode 30h, यानी decimal 48, पर switch request करता है
    • patched display driver text mode state में scan line length set करता है
    • DOSBox internal state और VGA register-based state में mismatch हो जाता है
  • mode 30h SVGAPatch द्वारा hijack किया गया Tseng ET4000 का 800x600 mode value था

छूटा हुआ screen switching path

  • Windows 3.1 Display Driver INT 2Fh को hook करके screen switching commands receive करता है
  • VGA driver ये चार commands handle करता है, लेकिन SVGA256 driver सिर्फ SCREEN_SWITCH_OUT और SCREEN_SWITCH_IN support करता है
    • SCREEN_SWITCH_OUT
    • SCREEN_SWITCH_IN
    • SAVE_DEV_REGS
    • RES_DEV_REGS
  • समस्या वाला function dev_to_foreground था, जो Windows GUI पर लौटते समय call होता है
  • SVGA256 का dev_to_foreground इस flow से चलता है
    • farsetmode call
    • farsetmode mode 48 set करता है
    • chipset-specific VideoInit call
    • enabled_flag को 0xFF पर set
    • Windows API SetPalette call
  • SVGAPatch ने initialization के समय mode setting path को VBE में बदल दिया था, लेकिन screen switching के समय दोबारा mode set करने वाला path नहीं बदला था

अतिरिक्त patch से GUI recovery में सुधार

  • original setmode code में wGraphicsMode को ax में डालकर INT 10h call करने और फिर ptr_videoinit call करने की छोटी structure थी
  • SVGAPatch द्वारा छोटा बनाए गए SetAndValidateMode के बाद बची जगह में नया code insert किया गया
    • CurrentHeight से 1 घटाकर value cx में डाली
    • SetAndValidateMode call किया
    • ptr_videoinit call किया
  • setmode की पहली instruction को नए code पर jump करने के लिए बदला गया, ताकि screen switching के समय भी VBE-based mode setting path चले
  • इस modification के बाद fullscreen DOS session में जाकर GUI पर लौटने पर screen अब corrupt नहीं हुई
  • हालांकि windowed mode से fullscreen में जाते समय dots फिर से दिखने की समस्या बची रही

बचा हुआ bank switching issue

  • DOSBox debugger में B8000 VGA memory देखने पर text content मौजूद था, लेकिन screen पर दिखाई नहीं दे रहा था
  • suspect point bank switching था, जिसका इस्तेमाल driver अधिक video memory access करने के लिए करता है
  • DOSBox-X में SVGA bank state print करने वाला command add करने पर confirm हुआ कि fullscreen पर लौटते समय VGA adapter गलत bank में रुका हुआ था
  • dev_to_background में bank को 0 पर वापस लाने वाली नई routine डाली गई, लेकिन समस्या ठीक नहीं हुई
  • DOSBox का VBE 4F05h implementation VGA CRTC register 0x6A में write करने के तरीके पर था, और dev_to_background call होने तक VDD already writes को trap कर रहा था, इसलिए बहुत देर हो चुकी थी

original driver और patched driver के experiment results

  • 86Box में Microsoft original SVGA 256-color driver को कई emulated cards पर test करने पर support list के अंदर भी results consistent नहीं थे
    • Cirrus Logic GD5420 (ISA): काम करता है
    • Tseng Labs ET4000AX: काम करता है
    • Oak OTI-077: windowed DOS prompt पहली बार खोलते समय screen corruption, fullscreen में vertical lines
    • Trident TVGA 8900D: fullscreen DOS prompt में screen corruption, windowed mode normal
    • ATI VGA Wonder XL, Paradise PVGA1A, Video 7 VGA 1024i की कुछ resolutions में Windows start fail
  • यह caveat है कि 86Box exactly वही cards provide नहीं करता और emulation accuracy भी निश्चित नहीं है
  • modified SVGAPatch-based driver को और नए cards पर test करने के results भी card-wise अलग थे
    • Matrox Millennium II: बहुत धीमा, windowed DOS काम करता है लेकिन fullscreen corrupt होता है
    • 3dfx Voodoo Banshee: windowed DOS खोलने पर GUI corrupt हो जाता है, लेकिन fullscreen switching काम करती है
    • S3 Trio3D/2X: Windows start पर corrupt screen आता है, लेकिन DOS prompt के बाद fullscreen से निकलने पर 1024x768 normal display होता है
    • 3dfx Voodoo3 3500 SI: Banshee जैसा, लेकिन fullscreen सिर्फ एक बार काम करता है

Eee PC पर final state

  • वास्तविक Eee PC पर GUI normal काम करता है
  • fullscreen DOS prompt switching अभी भी corrupt होती है, लेकिन DOSBox से अलग तरीके से दिखती है
  • DOSBox में कई corrupt characters वाला text mode दिखा, जबकि Eee PC पर कुछ colors गायब हुए corrupt GUI दिखा
  • windowed mode में वापस switch करने पर recovery possible है
  • original SVGAPatch में सिर्फ windowed prompt खोलने पर भी पूरा GUI corrupt हो जाता था और OS restart की जरूरत पड़ती थी, लेकिन modified driver इससे काफी बेहतर है
  • बेहतर solution के तौर पर actively developed PluMGMK/vbesvga.drv पर नज़र बनाए रखने का विकल्प चुना गया

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-06
Hacker News टिप्पणियां

  • SVGA सपोर्ट को अलग रखें, तो हमेशा हैरानी होती है कि आधुनिक standards सपोर्ट करने वाले PC पर Windows 3.x डालने पर basic VGA तुरंत काम करने लगता है, जबकि modern Linux/BSD में सही driver और manual config files के बिना Xorg/Wayland में basic software-accelerated VGA framebuffer तक आसानी से इस्तेमाल नहीं हो पाता
    मर चुका XFree86 project ऐसी “बस चल जाए” वाली चीज़ के सबसे करीब आया था, लेकिन उसे अभी लंबा रास्ता तय करना था, और लगता है वह approach Xorg fork में सुरक्षित नहीं रही

    • XFree86 ने भी यहां Xorg से अलग कुछ नहीं किया था
      किसी modern PC पर CSM से boot करें तो—हालांकि यह recommend करने लायक नहीं है—Xorg को x86emu से video BIOS चलाकर VBE backend पर उठना चाहिए, और EFI से boot करें तो firmware और bootloader द्वारा छोड़े गए mode के ऊपर efifb-based modesetting उठनी चाहिए
      लेकिन यह 16-bit या 32-bit operating systems के लिए आसान काम है। VESA mode setting के लिए real-mode 16-bit call चाहिए, और standard के बाद के हिस्से में 32-bit entry point नाममात्र को था, पर उसे ठीक से implement करने वाली जगहें बहुत कम थीं। 64-bit mode में जाने पर vm86 इस्तेमाल नहीं कर सकते, इसलिए user space से 16-bit code call नहीं कर सकते, और इसी वजह से x86emu चाहिए, जो video BIOS code पढ़कर उसे x86 emulator में चलाता है, लेकिन यह हमेशा perfect नहीं होता
    • Linux में vgafb/vesafb है, इसलिए distribution अगर ठीक से configured हो तो यह संभव है
      हालांकि आम तौर पर experience performance और quality में कमतर होता है और user को वजह पता नहीं चल सकती, इसलिए लगता है कुछ या ज़्यादातर distributions इसे default में enable नहीं करते। आजकल लगभग हर GPU natively supported है, इसलिए “आप unaccelerated VGA/VESA इस्तेमाल कर रहे हैं, इसे ठीक करें” वाला popup बनाने की motivation भी शायद नहीं रही होगी
    • बहुत पुरानी बात है, लेकिन याद है कि X में एक generic VGA driver था जो “बस काम करता था।” क्या मतलब अब वह नहीं है?
    • X11 में बहुत पहले से VESA driver था, लेकिन resolution के साथ process करने वाले pixels की संख्या तेजी से बढ़ती है, इसलिए performance scaling खराब रहती है
      काम में इस्तेमाल होने वाले bootable Linux distributions, मुख्यतः GRML और Clonezilla, KMS support के साथ boot के दौरान screen या virtual KVM की native resolution पर अपने-आप fit हो जाते हैं और काफी अच्छी तरह काम करते हैं। Anaconda, यानी RedHat-family installer, और Debian installer भी boot के समय native resolution पर fit हो जाते हैं
      GUI installers X11 के ऊपर सीधे VESA इस्तेमाल करते हैं
      Xorg fork भी बहुत पहले से “बिना config file के boot” support करता है। मैं बहुत लंबे समय से config file manage नहीं कर रहा हूं, और यह कहीं ज़्यादा संतोषजनक है। https://www.xkcd.com/963/ देखें
    • Xorg मुझे XFree86 जैसा ही लगता है, बस build system साफ किया हुआ

  • पुराना Windows 3.1 GUI आजकल की चीज़ों से कहीं ज़्यादा intuitive, efficient और इस्तेमाल में अच्छा लगता है
    https://wuffs.org/user/pages/02.blog/windows-3x-graphics/640...
    लेख जैसी low-resolution screen पर Win11 आखिर कैसा दिखेगा? Win11 Start menu तो keyword type करने के बाद circuits से प्रार्थना करने के अलावा लगभग इस्तेमाल लायक नहीं है
    मेरी भोली-सी hypothesis है कि Windows NT और 2000 optimal point थे, और उसके बाद product managers ने जादू-टोना किया है। KDE और Gnome बहुत ज़्यादा नहीं बदले, लेकिन समय के साथ वे और आकर्षक लगने लगे हैं :)

    • मेरे हिसाब से आखिरी “अच्छा” version Windows 7 था। NT/2000 जैसा ही था, लेकिन graphics hardware improvements की वजह से ज्यादा सुंदर था, और उससे पहले XP भी ऐसा ही था। Vista का UI भी अपने-आप में ठीक था, खामियां कहीं और थीं
      Windows 8 ने सब कुछ खराब कर दिया और Windows कभी recover नहीं हुआ। मुझे लगता है वजहें दो थीं: mobile platforms का उभार और Microsoft की सुस्ती
      अब यह मुश्किल समस्या है कि कई apps के desktop और mobile versions अलग-अलग होते हैं। एक बड़े screen और keyboard-mouse के लिए है, दूसरा छोटे touchscreen के लिए, इसलिए अच्छा desktop app और अच्छा mobile app पूरी तरह अलग होना चाहिए। लेकिन आप चाहते हैं कि user को दोनों versions परिचित लगें, इसलिए best effort के बाद भी compromises आते हैं
      Microsoft फिर भी इसे ठीक-ठाक कर सकता था, लेकिन उसने नहीं किया। Control Panel देखें तो साफ है। नया Control Panel, यानी Settings, Windows 8 के समय से—12 साल पहले से—मौजूद है, फिर भी पुराने Control Panel की सारी functions अब तक shift नहीं कर पाया, इसलिए दोनों की जरूरत है। कुछ महीने पहले वे पूरी तरह switch करने की कोशिश करना चाहते थे, लेकिन ready नहीं था, और आगे कभी होगा भी या नहीं, पता नहीं। ऊपर से वे popular customization options अक्सर हटाते रहते हैं, और bundled apps के बीच style भी consistent नहीं है। यह सिर्फ विवादास्पद नहीं, objectively खराब है
      Microsoft और Windows को ही दोष न देने की एक और वजह यह है कि app developers operating system integration के बजाय branding और internal consistency को priority देते हैं। कई modern UI Electron जैसे browser engine से render की गई web page भर हैं, native operating system controls नहीं इस्तेमाल करते, theme ignore करते हैं और window decorations भी खुद draw करते हैं। Operating system inconsistent हो सकता है, लेकिन app developers भी मदद नहीं करते
    • Flat design industry के लिए लगभग disaster था। Skeuomorphism भी असल में तस्वीर चिपकाया हुआ flat design ही था, इसलिए वह भी काफी खराब था
      Windows Forms ने बहुत सारी चीज़ें सही की थीं, और अगर missing state में एक चीज़ चुननी हो तो शायद “active but not editable” होगी
    • सुनी-सुनाई बात के मुताबिक Windows 11 असल में Windows 10X था, जिसे phones और tablets के लिए भी बनाया जा रहा था। Start menu में Android का काफी असर दिखता है: installed सब कुछ flat तरीके से दिखाना और search को ज्यादा encourage करना
      फिर भी सहमत हूं। Win10 beta में tiles और Windows 7-style list को मिलाने वाला रूप था, जो Windows 2000 तक चली आ रही शैली से जुड़ा था; मेरे हिसाब से वही peak था। दोनों की खूबियां मिल सकती थीं। Notification area हमेशा कमजोर रहा, और Settings panel Control Panel के मुकाबले बहुत खराब है। बेशक Control Panel भी बिखरा और complex था, इसलिए वह best था या नहीं, इस पर बहस हो सकती है

  • लेखक ने कहा कि DOS prompt को window mode में खोलने पर स्क्रीन टूट जाती है; यह इसलिए हो सकता है क्योंकि DOS prompt अलग VM, यानी V86 mode में चलता है और INT 10h के जरिए VGA ROM BIOS को call करता है
    इस मशीन का VGA ROM BIOS शायद VBE के ऊपर एक wrapper रहा होगा, यानी इसमें VBE I/O ports 0x1CE और 0x1CF तक access करने वाले IN/OUT instructions शामिल रहे होंगे। DOS VM में होने वाली ऐसी reads और writes, अगर VMM उन्हें virtualize न करे, तो मूल रूप से असली hardware तक पहुँच जाती हैं
    यह एक आम समस्या थी जिसे Windows 3.x/9x display driver authors को संभालना पड़ता था, लेकिन virtualize किए जाने वाले I/O port numbers हर graphics adapter के लिए अलग होते थे। Win95 DDK में VMM service Install_IO_Handler और Enable/Disable_Global_Trapping से I/O port traps set करने और trap handler के अंदर VDD_Get_VM_Info से यह तय करने का example है कि अभी CRTC का मालिक कौन-सा VM है। इससे trap handler तय कर सकता है कि I/O को hardware तक भेजना है या किस तरह virtualize करना है। शुरुआत के लिए एक अच्छी virtualization policy यह है कि जो VM CRTC owner नहीं है उसकी writes को बस discard कर दिया जाए, और जरूरत की complexity बाद में जोड़ी जाए

  • Virtual Display Device(VDD) underlying virtual machine manager के हिस्से के रूप में चलता है और video hardware के लिए multiplexer की तरह काम करता है। अगर DOS app full screen में है तो commands सीधे “असली” VGA adapter तक भेजे जाते हैं, वरना VDD उन्हें emulate करता है
    दिलचस्प है कि लोग इस architecture को फिर से खोज रहे हैं। निजी तौर पर मुझे यह modern hypervisors with hardware passthrough से पहले का, अपने समय से काफी आगे का design लगता है। preemptive multitasking processes वाली Windows 3.x GUI खुद असल में DOS चलाने वाले VM के अंदर extended protected mode DOS process के रूप में चलती है, और hypervisor kernel VMM32 उसे और दूसरे DOS process VMs को multiplex करता है। इसलिए display driver का एक हिस्सा GDI के नीचे “hardware” से interact करता है, और दूसरा हिस्सा ring 0 में hardware को virtualize करके दूसरे VMs के साथ multiplex करता है
    इसे DOSBox में ठीक किया जा सकता है, लेकिन वह fix DOSBox द्वारा emulate किए जा रहे specific video adapter से बंध जाएगा। चाही गई चीज़ वह नहीं, बल्कि generic VBE patch को बेहतर ढंग से काम कराना है
    मैंने कभी Intel GMA950 के लिए Win9x VESA framebuffer driver लिखा था और basic acceleration, यानी blitter और fill commands तक जोड़े थे; तब लगभग यही समस्या झेलते हुए समझ आया कि Win9x में generic VESA driver क्यों नहीं था। VDD को GPU state को save और restore करना आना चाहिए, और वे details स्वाभाविक रूप से vendor-dependent हैं। मैंने generic तरीके से करने के ideas भी सोचे थे। उदाहरण के लिए VBIOS को emulate या trace करके देखना कि हर mode switch पर कौन-से ports और MMIO छुए जाते हैं, लेकिन implementation तक नहीं पहुँच पाया
    DOSBox में टूटे characters से भरा text mode दिखता है, और Eee PC पर कुछ रंग गायब हुए broken GUI दिखता है
    यह palette registers के ठीक से save/restore न होने जैसा लगता है। साथ ही स्क्रीन के ऊपर की corruption को high-resolution display plane को 256K से ऊपर ले जाकर टाला जा सकता है, जिससे VRAM का पहला 256K VGA planes और VGA emulation के लिए बचा रहे। अच्छी बात है कि Intel GMA के लिए काफी public documentation उपलब्ध है। 900 और 950 के docs नहीं, बल्कि 810/815 और 965 के बाद वाले docs हैं, लेकिन ज्यादातर registers और commands बदले नहीं हैं, इसलिए details के लिए उनका सहारा लिया जा सकता है

  • “x86_64 support नहीं है, इसलिए ज्यादातर modern Linux distros भी नहीं चल सकते,” लेकिन मेरा Eee 32-bit Debian पर ठीक-ठाक टिका हुआ है
    Firefox बहुत भारी है इसलिए लगभग अटकता है, लेकिन mpv से video streaming काफी अच्छी चल जाती है। मैं इसे मुख्य रूप से ऐसी typewriter की तरह इस्तेमाल करता हूँ जिसमें pandoc चला सकता हूँ जब book work pending हो और distractions कम हों

    • मैं पूरी तरह सहमत हूँ कि writing के लिए कम से कम distractions वाला computer अच्छा होता है। उस काम के लिए मैं PS/2 386SX पर WordPerfect 5.1 इस्तेमाल करता हूँ
      EEE मुझे बहुत portable होने की वजह से पसंद था, लेकिन serious typing के लिए उसका keyboard बहुत छोटा लगता है
    • अगर इसे web या modern apps के बिना इस्तेमाल करना है, तो Haiku OS जैसी किसी चीज़ के लिए यह interesting use case हो सकता है
      मैंने इसे PC पर इस्तेमाल किया था; usable software की कमी इसे सचमुच daily-use operating system बनने से रोकती थी, लेकिन typewriter और mail जैसे low-connectivity uses के लिए यह बहुत enjoyable OS लगा
      UI, default software और filesystem तक में consistent feel अच्छी लगी। अगर मैंने सही समझा, तो filesystem ही सारे data का representation है और “files” arbitrary metadata रख सकती हैं, और file manager में लगभग सब कुछ किया जा सकता है। पूरा filesystem NoSQL database जैसा है और apps भी उसे naturally अपनाती हैं। Contacts folder के अंदर “files” हैं, mail भी folder के अंदर “files” हैं, ऐसा ही structure है
      उस समय मैंने BeOS कभी नहीं छुआ था, लेकिन low-connectivity वाले 90s में यह paradigm काफी फिट बैठता होगा। बिना internet के mail “file” लिखना, उसे floppy drive पर drag-and-drop करना, फिर दूसरे computer से internet पर भेजना—यह सब file manager से ही करना आश्चर्यजनक रूप से consistent था
      अफसोस कि जैसे ही किसी ऐसे दूसरे computer के साथ interoperate करना पड़ता है जो BeOS/Haiku filesystem से compatible नहीं है, इस paradigm की उपयोगिता घट जाती है। statistically देखें तो लगभग सारे computers ऐसे ही हैं
      लेकिन typewriter-purpose device के लिए यह interesting हो सकता है
    • मेरी समझ से Debian अगले release में 32-bit x86 support हटाने वाला है
    • मेरे पास 1215B था, लेकिन पिछले साल मर गया, और अब उसकी जगह Android tablet ने ले ली है
      लगता है tablets ने netbook market segment को साफ कर दिया। ultraportables या 2-in-1 अभी भी हैं, लेकिन वे price range के लगभग opposite end पर हैं

  • title थोड़ा confusing था
    फिर भी पुराने DOS-based Windows के अंदरूनी कामकाज के बारे में जब भी पढ़ता हूँ, हमेशा विस्मय होता है। सब कुछ software duct tape से चिपका हुआ लगता है, लेकिन somehow काम कर जाता है

    • Casey Muratori की बात सुनिए। उनका कहना है कि हमने abstraction का विशाल ढेर बना दिया है, जबकि असल में उसकी जरूरत नहीं होती और वह सिर्फ performance खराब करता है

  • जब ET4000H आया था, तो याद है कि उस समय Windows 3.1 में इसका support नहीं था। MS tech support को फोन किया, तो उन्होंने driver disk भेज दी, और वह 8 घंटे बाद पहुँच गई
    pirated product पर मुझे मिला यह सबसे बेहतरीन support था

    • सटीक तौर पर कहें तो ET4000H, ET4000ax जैसा ही था जिसे Windows 3.0 और 3.1 पहले से support करते थे, लेकिन 256-color DAC की जगह इसमें HiDAC, यानी 15/16-bit truecolor लगा था
      याद थोड़ी धुंधली है, लेकिन शायद basic driver से 16-color mode चलता था और 256 colors से ऊपर नहीं चलता था; resolution selection भी सीमित रहा होगा
      MS के मुताबिक HiDAC को support करने वाला driver अप्रैल 1992 के तीसरे हफ्ते में आया था, जो मेरी याद वाले समय से 1–2 हफ्ते बाद है, इसलिए कुल मिलाकर बात सही लगती है

  • मजेदार है। मेरे पास छोटा model EEEPC 701 है और वह अभी भी चलता है, लेकिन retro gaming के लिए उसके बारे में कभी नहीं सोचा था
    मेरा तो बस धूल खा रहा है, पर ऐसी चीजें आजमाना मजेदार हो सकता है

    • लगता है 701 की बात कर रहे हैं। 207g कोई Eee PC model name नहीं है

  • छोटे annotations को यूं ही compare किया, तो शायद इतना घूरने के बाद कि semantic satiation हो जाए, अगला state change दिखता है
    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
    pattern के हिसाब से broken DOS और broken GUI 200 या 250 हैं, और normal 100 या 050। वह address क्या होगा?
    broken GUI somehow LIN8 नहीं बल्कि M_VGA mode में है। यह कैसे और क्यों हुआ, और क्या इसका 800x600 की आधी horizontal width यानी 400x600 बनने की वजह से कोई संबंध है? असली “text mode” तो दोनों DOS modes में दिखने की तरह 720x400 है

  • पता नहीं लेखक देख रहे होंगे या नहीं, लेकिन मैंने यह post patch author को बता दी है
    https://www.bttr-software.de/forum/board_entry.php?id=22124#...