Linux के लिए Windows 9x सबसिस्टम

 (social.hails.org)
12 पॉइंट द्वारा GN⁺ 9 일 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • एक प्रायोगिक प्रोजेक्ट जो Windows 9x kernel के अंदर आधुनिक Linux kernel (6.19) को cooperative तरीके से चलाता है, ताकि दोनों operating systems की पूरी क्षमताओं का एक साथ उपयोग किया जा सके
  • WSL के विपरीत, यह hardware virtualization का उपयोग नहीं करता, इसलिए 486 पर भी चल सकता है
  • paging, memory protection, preemptive scheduling जैसी आधुनिक OS सुविधाएँ Windows 9x वातावरण में उपलब्ध कराता है, और reboot के बिना applications को साथ-साथ चलाने देता है
  • यह patched Linux kernel, VxD driver, और wsl.com client इन तीन components से मिलकर बना है, और User-Mode Linux को Win9x kernel API calls के लिए अनुकूलित किया गया है
  • system calls को Win9x की छोटी interrupt descriptor table की सीमा के कारण int 0x80 के बजाय general protection fault (GPF) handler के माध्यम से dispatch किया जाता है
  • "Proudly written without AI", GPL-3 license

WSL9x - codeberg.org/hails/wsl9x

अवलोकन

  • WSL9x, Windows 9x kernel के भीतर आधुनिक Linux kernel (लिखे जाने के समय 6.19) को cooperative तरीके से चलाने वाला Windows 9x के लिए Linux subsystem है
  • paging, memory protection, preemptive scheduling जैसी दोनों operating systems की पूरी सुविधाओं का एक साथ उपयोग संभव बनाता है
  • reboot के बिना दोनों OS के applications को साथ-साथ चलाया जा सकता है
  • इसे AI के बिना सीधे लिखा गया है

तकनीकी संरचना

  • WSL9x तीन components से बना है
    • patched Linux kernel (win9x-um-6.19 branch)
    • VxD driver
    • wsl.com client program

VxD driver

  • यह WSL9x की initialization संभालता है, और इसका entry point vxd/wsl9x.asm है
  • यह kernel code की शुरुआती mapping सेट करता है और DOS interrupts के जरिए vmlinux.elf को disk से लोड करता है (vxd/loader.c, vxd/fs.asm)
  • kernel को fixed base address 0xd0000000 पर compile किया गया है
  • यह System VM के भीतर एक नया thread शुरू करता है और Linux entry के लिए 16 KiB stack आवंटित करता है
  • इसके बाद यह एक event loop में प्रवेश करता है जो kernel entry, IRQ dispatch, userspace में वापसी, और idle state को संभालता है (vxd/entry.c)

system call और page fault handling

  • driver उन userspace events को संभालता है जिन्हें kernel तक dispatch करना होता है: page faults और system calls
  • system calls को general protection fault (GPF) handler के जरिए संभाला जाता है
    • Win9x की interrupt descriptor table इतनी लंबी नहीं है कि वह Linux i386 system call interrupt int 0x80 के लिए सही handler स्थापित कर सके
    • GPF handler fault पैदा करने वाले instruction की जाँच करता है, और यदि वह int 0x80 हो तो instruction pointer को ऐसे आगे बढ़ाता है जैसे interrupt सफल रहा हो, फिर उसे Linux system call के रूप में dispatch करता है (vxd/fault.c)

Linux kernel में बदलाव

  • यह User-mode Linux पर आधारित है, लेकिन POSIX API के बजाय Windows 9x kernel API को call करने के लिए संशोधित किया गया है
  • यह user mode (ring 3) में नहीं, बल्कि ring 0 (supervisor/kernel mode) में चलता है
  • Win9x kernel integration का बड़ा हिस्सा, जिसमें context switching भी शामिल है, Linux kernel पक्ष में मौजूद है
    • मुख्य code location: linux/arch/um/os-Win95
    • entry point: main.c का _start, और मुख्य files process.c, mmu.c

wsl.com client

  • यह wsl/wsl.asm में implement किया गया 16-bit DOS program है
  • अलग TTY implementation के बिना MS-DOS prompt को TTY window की तरह उपयोग करने देता है
  • चलने पर यह WSL9x V86 API (vxd/v86_api.asm) को call करके एक unused console आवंटित कराता है, और सूचित करता है कि उस console का output इसी तक dispatch किया जाए
  • इसके बाद यह एक event loop में प्रवेश करता है, IRQ का इंतज़ार करता है और interrupt होने पर keyboard read की कोशिश करता है
  • यह console driver (vxd/console.c) के लिए synchronization point की भूमिका भी निभाता है
    • जब Linux output तैयार होता है, तो यह event schedule करता है और MS-DOS VM context में int 0x29 चलाकर DOS window में characters output करता है
    • यही वह interrupt है जहाँ NNANSI जैसे DOS ANSI drivers, ANSI escape codes लागू करने के लिए terminal output को intercept करते हैं

build और run आवश्यकताएँ

  • i386-linux-musl target के लिए cross toolchain आवश्यक है (musl-cross-make की सिफारिश)
  • Windows components के build के लिए Open Watcom v2 toolchain आवश्यक है
  • win9x-um-6.19 branch से patched Linux kernel build करना आवश्यक है
  • WATCOM और LINUX environment variables को सही तरह सेट करना होगा (उदाहरण के लिए .envrc.example देखें)
  • Windows 9x पहले से इंस्टॉल की गई hard disk image hdd.base.img आवश्यक है
  • make चलाने पर WSL9x तैयार की गई hdd.img बनती है
  • MS-DOS prompt में wsl चलाकर pty खोलें; ANSI colors के लिए nnansi.com जैसे driver को पहले से लोड करने की सिफारिश है

license

  • GPL-3

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

2 टिप्पणियां

 
GN⁺ 9 일 전
Hacker News की टिप्पणियाँ
  • WSL से पहले Windows के अंदर बिना बदले हुए Linux binaries चलाने के प्रमुख तरीकों में CoLinux और flinux थे
    http://www.colinux.org/
    https://github.com/wishstudio/flinux
    flinux असल में WSL1 architecture के काफ़ी करीब था, और CoLinux का अंदाज़ WSL2 जैसा लगता था क्योंकि वह Linux kernel को साथ में लोड करता था
    तकनीकी रूप से Cygwin ज़्यादा canonical लगता था. बाहरी Linux plumbing को ज़बरदस्ती फिट करने के बजाय यह Windows पर native POSIX binaries चलाने का तरीका था, और सिर्फ़ हल्की DLL linking से काम हो जाता था, इसलिए ring 0 को छूना नहीं पड़ता था, यह बात अच्छी लगती थी
    हालांकि उस समय CLI package manager की सुविधा कमज़ोर थी, और असल में Windows पर काम करते समय मैं CoLinux का काफ़ी उपयोग करता था
    • याद है कि Cygwin, CoLinux से काफ़ी पुराना था. CoLinux 2004 का था, जबकि Cygwin 1995 में जारी हुआ था
      मेरी याद में मुख्य समस्या DLL hell थी. उदाहरण के लिए, अगर Windows के लिए OpenSSH port अपनी अलग cygwin1.dll लेकर आता, तो version conflicts अक्सर हो जाते थे
      फिर भी कम RAM और भारी swapping वाले दौर में इसका कम overhead मायने रखता था
      उस समय Web 2.0 या NodeJS जैसी चीज़ों से ज़्यादा native apps केंद्र में थे, और Java की भी अच्छी प्रतिष्ठा नहीं थी
      आख़िर में हमेशा की तरह यह दो कदम आगे, एक कदम पीछे वाली प्रगति जैसा लगता था
    • यह कहना कि Cygwin canonical था, कुछ मानकों पर सही हो सकता है, लेकिन मुझे यह काफ़ी अजीब approach लगा
      धीमा नहीं होने का जो संकेत दिया जाता है, उसके उलट यह वास्तव में धीमा था, compatibility भी दूसरे तरीकों से कम थी, recompilation भी चाहिए होती थी, और अपने लंबे जीवन के ज़्यादातर हिस्से में यह कोई बहुत प्रिय tool नहीं था
      cygwin1.dll के अंदर भारी compatibility wizardry चल रही थी, और अंत में यह बाहरी Linux plumbing को process के अंदर खींच लाने जैसा ही था. खासकर जब system support के बिना fork() लागू करने का तरीका याद आता है
      Cygwin Windows AppContainer isolation के अंदर चलता ही नहीं है. MSYS2 भी अब तक इसी नींव पर बना है, इसलिए MSYS2 binaries AppContainer में नहीं चलतीं
      इसी वजह से Claude Code sandboxing में पूरी तरह अलग रास्ता लेना पड़ा. Claude Code को Git for Windows चाहिए, और Git for Windows bash.exe जैसी चीज़ें MSYS2 से बनी हुई वितरित करता है
      दूसरी तरफ़ असली native Windows builds में cygwin1.dll जैसी अजीब hacks की ज़रूरत नहीं होती, इसलिए जो non-MSYS2 builds मुझे मिले वे AppContainer में ठीक चले
    • आजकल MSYS2 अंदर से cygwin पर निर्भर रहते हुए भी package manager देता है
      इसमें Arch Linux का pacman इस्तेमाल किया जा सकता है, इसलिए Linux VM के बिना भी Windows पर native POSIX binaries को काफ़ी friendly तरीके से संभाला जा सकता है
    • वास्तविक development experience में Cygwin पर काम करना सचमुच दर्दनाक था
      जिस C library का इस्तेमाल करना हो, अगर उसका पहले से बना हुआ Cygwin version न मिले, तो पूरी dependency tree को configure, make से खुद बनाना पड़ता था
      और मेरी याद में लगभग दो-तिहाई संभावना रहती थी कि कुछ न कुछ खुद ठीक करना पड़े, क्योंकि POSIX पूरी तरह सटीक मेल नहीं खाता था
    • Cygwin मूल रूप से Win32 के ऊपर POSIX API लागू करता था, और compatibility बढ़ाने के लिए कुछ Nt calls भी मिलाता था
      लेकिन सही semantics पाने के लिए तरह-तरह के workarounds और hacks चाहिए होते थे, उदाहरण के लिए fork copy-on-write नहीं था
      मैंने लगभग 1999 से 2022 तक Cygwin इस्तेमाल किया, WSL2 भी थोड़ा इस्तेमाल किया, और आज भी laptop पर वही इस्तेमाल करता हूँ
      लेकिन desktop पर पिछले साल से पूरी तरह Linux पर आ गया हूँ
  • यह colinux का pre-NT Windows version जैसा है क्या, यह सोचकर काफ़ी अच्छा लगा
    पहले XP के दौर में Windows इस्तेमाल करते समय Colinux चलाया था, और वह सचमुच कमाल का tool था
    Linux side पर LAMP stack लगाना कहीं आसान था, और editing Windows editor से करते हुए local development environment काफ़ी बढ़िया बनाया जा सकता था
    Windows के लिए X11 server जोड़कर ऊपर Linux desktop चलाने के प्रयोग भी किए जा सकते थे
    इस तरह Windows के ऊपर परत-दर-परत Unix जैसा environment बनाते-बनाते मैं आख़िरकार macOS पर चला गया
    शुद्ध hacking value से अलग, व्यावहारिक उपयोग सोचें तो 486-स्तर की मशीन में जल्दी ही memory limits आ जाएँगी, ऐसा भी लगता है
    http://colinux.org/
    • Colinux सचमुच एक तकनीकी उपलब्धि था
      बस इसे पहचानने वाले ज़्यादा लोग नहीं थे
  • इसे बनाने वाला व्यक्ति लगभग जादूगर जैसा लगा
    मेरी नज़र में यह लगभग असंभव काम था
    लेकिन जो लोग इसकी architecture समझते हैं, उनकी नज़र में यह कैसा दिखता होगा, यह जानने की जिज्ञासा हुई
    इसलिए वह मज़ाक याद आया जिसमें दो गणितज्ञ किसी theorem को trivial कहते हैं, और दो घंटे समझाने के बाद सामने वाला मान लेता है कि हाँ, यह सचमुच trivial था
    • मैंने भी CS के पहले साल में set theory की class में बोर्ड के सामने proof करते हुए, जो हिस्सा समझ नहीं आ रहा था उसे बस trivial कहकर टाल दिया था
      फिर professor ने भी मान लिया और हम बस आगे बढ़ गए, यह याद है
    • मैं आम तौर पर architecture समझ लेता हूँ, और यह मुझे जादू जैसा नहीं लगता
      बल्कि इस बात पर ज़्यादा हैरानी होती है कि इसे संभव बनाने वाली लंबी vision-document जैसी detail list लेखक ने एक-एक करके समझ ली
    • आधुनिक operating system की मुख्य भूमिका कई programs को एक साथ इस तरह चलाना है कि वे एक-दूसरे में दखल न दें
      इसलिए हर program अपनी memory का सिर्फ़ एक हिस्सा पढ़ सकता है, और CPU भी सीमित समय तक मिलता है, फिर अगले program को दे दिया जाता है
      Windows ने यह चीज़ें Windows NT से गंभीरता से अपनाईं, और XP भी उसी परिवार का था
      इसके उलट Windows 98 तक programs लगभग कुछ भी कर सकते थे, और hardware की वे सुरक्षा-क्षमताएँ लगभग बेकार पड़ी रहती थीं
      उस दौर का Windows किसी operating system से ज़्यादा UI दिखाने और peripherals से बात करने वाली functional libraries के bundle जैसा लगता था
      CPU में memory access और processing time सीमित करने के लिए विशेष hardware होता है, लेकिन Windows 9x इसका पूरा उपयोग नहीं करता था
      इसलिए Windows 9x के लिए Linux subsystem के पास खुद operating system होने का नाटक करके उस hardware का इस्तेमाल करते हुए एक आधुनिक operating system चलाने की गुंजाइश बन जाती है
    • project page देखें तो समझाना काफ़ी अच्छा किया गया है
      मेरी नज़र में ऐसे काम का सबसे कठिन हिस्सा Microsoft driver API को समझना है
      9x दौर का documentation न तो पर्याप्त विस्तार वाला था, न आसानी से उपलब्ध, और आज भी यह कोई सुखद क्षेत्र नहीं है
    • win9x kernel इस बात के लिए मशहूर था कि वह मूल रूप से बहुत कम काम करता है
      इसलिए शायद Linux की कुछ low-level capabilities उसमें जोड़ने की काफ़ी जगह बच जाती थी
  • अच्छा लगा कि ऐसी पोस्ट उसी दिन front page पर आई
    एक तरफ़ चर्चा थी कि Show HN तीन गुना बढ़ गया है और vibe-coding जैसे apps बहुत बढ़ गए हैं, और दूसरी तरफ़ कोई व्यक्ति 6 साल तक Win9x के अंदरूनी हिस्सों में घुसकर उसके भीतर आधुनिक Linux kernel चला रहा था
    20 मिनट के prompt से बने apps से भरे threads की तुलना में, ऐसी पोस्ट सचमुच खुशी देती है
    • project README में Proudly written without AI लिखा है
      यह देखकर काफ़ी अच्छा लगा
    • अब तो यह भी काफ़ी संभव लगता है कि prompt खुद AI ने बनाया हो
      create me an owl app कहने के बजाय, owl app बनाने के लिए एक comprehensive prompt बनवाकर उसे अगली AI session में paste करना अब आम हो गया है
  • README में > Proudly written with zero AI वाली अभिव्यक्ति थोड़ी अस्पष्ट लगी
    क्योंकि Zero AI नाम का एक product सचमुच मौजूद है, इसलिए इसे उस तरह भी पढ़ा जा सकता था
    • अब शायद इसे > Proudly written without AI कर दिया गया है, जो ज़्यादा स्पष्ट है
      अभिव्यक्ति भी कहीं साफ़ हो गई है, और project खुद भी सचमुच चौंकाने वाला है
    • यहाँ capitalization का फ़र्क महत्वपूर्ण है
  • social site के बिना सीधा link छोड़ रहा हूँ
    https://codeberg.org/hails/wsl9x
  • जानना चाहता हूँ कि Windows 3.x और 9x की architecture को अच्छी तरह समझाने वाले अच्छे resources कौन से हैं
    इतना तो पता है कि VM Monitor जैसी कोई चीज़ थी और इस तरह की support मौजूद थी, लेकिन विस्तृत व्याख्या बिखरी हुई लगती है
    बहुत से लोग Windows को बस DOS के ऊपर चलने वाली चीज़ कहकर समेट देते हैं, लेकिन वह स्पष्ट रूप से सही नहीं है
    बेशक यह आज के अर्थों वाली virtual machine जैसा नहीं था, लेकिन इसके अंदर काफ़ी दिलचस्प तकनीकी संरचना थी, और ज़्यादातर material उसे बहुत सतही तौर पर ही छूता है
    यह भी जानना चाहता हूँ कि यह project BSD on Windows से कितना मिलता-जुलता है
    और Architecture of Windows 9x भी जानता हूँ, लेकिन मेरे हिसाब से उसमें गहराई की कमी है
    • WinWorld से मिला DDK काफ़ी उपयोगी लगा, यह सिफ़ारिश करूँगा
      https://winworldpc.com/product/windows-sdk-ddk/windows-95-ddk
      documentation बहुत विस्तृत है और sample code भी भरपूर है, इसलिए सीधे गहराई में जाने के लिए अच्छा है
  • अगर Microsoft-style naming देखें, तो यह Windows Subsystem for Linux नहीं बल्कि Linux Subsystem for Windows होना चाहिए, ऐसा लगा
    • ज़रूरी नहीं
      WSL का अर्थ Linux on Windows है, इसलिए इसे भी Windows 9x पर Linux के अर्थ में W9xSL पढ़ा जा रहा होगा
    • मुझे भी यह नाम शुरू से intuitive नहीं लगा
    • मैं भी सहमत हूँ
      अभी तुरंत सबूत नहीं दे सकता, लेकिन याद है कि कभी पढ़ा था कि इसका संबंध trademark issue से था
      यानी वे इसे मूल रूप से Linux Subsystem for Windows कहना चाहते थे, लेकिन Linux foundation की तरफ़ से बिना अनुमति वाली परियोजनाओं को Linux से शुरू होने वाला नाम इस्तेमाल करने की अनुमति नहीं थी, कुछ ऐसा मामला था
  • https://github.com/haileys/doslinux की तुलना में यह वाला शायद आसान रहा होगा, ऐसा अंदाज़ा है
    • फिर भी उसके अगले चरण तक पहुँचने में 6 साल लगे, यह कहना चाहूँगा
  • मेरी समझ में NT kernel, NT 3.1 से 2000 और XP होते हुए बाद में Windows 10/11 के WSL तक कुछ lineage बनाए रखता है, और 1993 से ही इसे POSIX subsystem ध्यान में रखकर डिज़ाइन किया गया था
    इसका मूल दर्शन कई personalities रखना था, जहाँ हर environment की system calls को NT kernel calls में translate किया जाए
    इसलिए WSL1 को भी 2016 में Linux के लिए उसी ट्रिक का एक नया रूप मान सकते हैं
    दूसरी तरफ़ Windows 9x, DOS lineage का था, इसलिए उसके अंदर Linux चलाने के लिए कहीं ज़्यादा गंदे और मूल रूप से अलग hacks चाहिए रहे होंगे
    शायद उसी वजह से उस समय किसी ने यह नहीं किया
    इसलिए इसका सचमुच काम करना ही यह दिखाता है कि NT architecture कितना अपने समय से आगे था
    व्यावहारिक उपयोग के लिहाज़ से पुराने medical या industrial software जैसे ऐसे environments याद आते हैं जो Windows 98 से बंधे हुए हैं
    हालांकि अगर 2026 में आपके हाथ में 486 हो, तो 30 साल पुराने DOS derivative के अंदर Linux डालने से बेहतर सीधे native Linux चलाना शायद कहीं ज़्यादा उपयोगी होगा
 
plumpmath 8 일 전

अरे coLinux lol -_- कितना पुराना और प्यारा नाम है। lol लेकिन अभी तो WSL होने पर भी इस्तेमाल नहीं करता, फिर भी win95+linux वाला कॉम्बो काफ़ी लुभा रहा है।