Subsistem Windows 9x untuk Linux

 (social.hails.org)
12 poin oleh GN⁺ 2026-04-23 | 2 komentar | Bagikan ke WhatsApp
  • Proyek eksperimental yang menjalankan kernel Linux terbaru (6.19) secara kooperatif di dalam kernel Windows 9x, sehingga seluruh kemampuan kedua sistem operasi bisa dimanfaatkan secara bersamaan
  • Berbeda dari WSL, proyek ini tidak menggunakan virtualisasi perangkat keras, sehingga bisa berjalan bahkan pada 486
  • Fitur OS modern seperti paging, proteksi memori, dan penjadwalan preemptif dapat digunakan di lingkungan Windows 9x, serta mendukung menjalankan aplikasi berdampingan tanpa reboot
  • Terdiri dari tiga komponen: kernel Linux yang telah dipatch, driver VxD, dan klien wsl.com, dengan User-Mode Linux yang dimodifikasi agar memanggil API kernel Win9x
  • System call didispatch melalui handler General Protection Fault (GPF) alih-alih int 0x80, karena keterbatasan tabel deskriptor interupsi Win9x yang pendek
  • "Ditulis dengan bangga tanpa AI (Proudly written without AI)", berlisensi GPL-3

WSL9x - codeberg.org/hails/wsl9x

Gambaran umum

  • WSL9x adalah subsistem Linux untuk Windows 9x yang menjalankan kernel Linux terbaru (6.19 pada saat penulisan) secara kooperatif di dalam kernel Windows 9x
  • Seluruh kemampuan kedua sistem operasi dapat dimanfaatkan sekaligus, termasuk paging, proteksi memori, dan penjadwalan preemptif
  • Aplikasi dari kedua OS dapat dijalankan berdampingan tanpa reboot
  • Ditulis langsung tanpa AI

Struktur teknis

  • WSL9x terdiri dari tiga komponen
    • Kernel Linux yang telah dipatch (win9x-um-6.19 branch)
    • Driver VxD
    • Program klien wsl.com
Iklan

Driver VxD

  • Menangani inisialisasi WSL9x, dengan entry point di vxd/wsl9x.asm
  • Menyiapkan pemetaan awal kode kernel dan memuat vmlinux.elf dari disk melalui interupsi DOS (vxd/loader.c, vxd/fs.asm)
  • Kernel dikompilasi dengan alamat basis tetap 0xd0000000
  • Memulai thread baru di dalam System VM dan mengalokasikan stack 16 KiB untuk digunakan saat masuk ke Linux
  • Setelah itu masuk ke kernel dan ke event loop yang menangani dispatch IRQ, kembali ke userspace, dan keadaan idle (vxd/entry.c)

Penanganan system call dan page fault

  • Driver menangani page fault dan system call, yaitu event userspace yang harus didispatch ke kernel
  • System call diproses melalui handler General Protection Fault (GPF)
    • Win9x tidak memiliki tabel deskriptor interupsi yang cukup panjang untuk memasang handler yang layak bagi interupsi system call Linux i386 int 0x80
    • Handler GPF memeriksa instruksi yang menyebabkan fault; jika itu int 0x80, pointer instruksi dimajukan seolah interupsi berhasil, lalu didispatch ke system call Linux (vxd/fault.c)

Modifikasi kernel Linux

  • Berbasis User-mode Linux, tetapi dimodifikasi agar memanggil API kernel Windows 9x alih-alih API POSIX
  • Berjalan di ring 0 (mode supervisor/kernel), bukan mode pengguna (ring 3)
  • Sebagian besar integrasi kernel Win9x, termasuk context switching, berada di sisi kernel Linux
    • Lokasi kode utama: linux/arch/um/os-Win95
    • Entry point: _start di main.c, dengan file penting process.c, mmu.c
    Iklan

Klien wsl.com

  • Merupakan program DOS 16-bit yang diimplementasikan di wsl/wsl.asm
  • Memungkinkan prompt MS-DOS digunakan sebagai jendela TTY tanpa implementasi TTY terpisah
  • Saat dijalankan, program memanggil WSL9x V86 API (vxd/v86_api.asm) untuk memperoleh konsol yang tidak terpakai, lalu memberi tahu agar output konsol tersebut didispatch kepadanya
  • Setelah itu masuk ke event loop yang menunggu IRQ dan mencoba membaca keyboard saat interupsi terjadi
  • Juga berfungsi sebagai titik sinkronisasi untuk driver konsol (vxd/console.c)
    • Saat output Linux siap, event dijadwalkan, lalu int 0x29 dijalankan dalam konteks MS-DOS VM untuk menampilkan karakter ke jendela DOS
    • Interupsi ini juga merupakan titik tempat driver ANSI untuk DOS seperti NNANSI mencegat output terminal guna mengimplementasikan kode escape ANSI

Persyaratan build dan eksekusi

  • Memerlukan cross toolchain untuk target i386-linux-musl (disarankan memakai musl-cross-make)
  • Memerlukan toolchain Open Watcom v2 untuk membangun komponen Windows
  • Perlu membangun kernel Linux yang telah dipatch dari branch win9x-um-6.19
  • Setel variabel lingkungan WATCOM dan LINUX dengan benar (lihat contoh di .envrc.example)
  • Memerlukan image hard disk hdd.base.img dengan Windows 9x yang sudah terpasang sebelumnya
  • Menjalankan make akan menghasilkan hdd.img yang telah disiapkan dengan WSL9x
  • Dari prompt MS-DOS, jalankan wsl untuk membuka pty; jika ingin memakai warna ANSI, disarankan memuat driver seperti nnansi.com terlebih dahulu

Lisensi

  • GPL-3

Bacaan terkait

2 komentar

 
GN⁺ 2026-04-23
Komentar Hacker News
  • Sebelum WSL, cara yang paling representatif untuk menjalankan binary Linux yang tidak dimodifikasi di dalam Windows adalah CoLinux dan flinux
    http://www.colinux.org/
    https://github.com/wishstudio/flinux
    flinux pada dasarnya lebih dekat ke arsitektur WSL1, sementara CoLinux terasa lebih seperti WSL2 karena membawa kernel Linux berdampingan
    Secara teknis, rasanya Cygwin lebih ortodoks. Alih-alih memaksa menyisipkan plumbing Linux eksternal, pendekatannya adalah menjalankan binary POSIX native di atas Windows, dan saya juga menyukai fakta bahwa itu selesai hanya dengan link DLL ringan tanpa menyentuh ring 0
    Namun saat itu kenyamanan package manager CLI masih kurang, dan ketika benar-benar bekerja di Windows, saya cukup terpikat dengan CoLinux
    • Seingat saya Cygwin jauh lebih tua daripada CoLinux. CoLinux rilis pada 2004, sedangkan Cygwin pada 1995
      Masalah utamanya yang saya ingat adalah DLL hell. Misalnya, kalau port OpenSSH untuk Windows membawa cygwin1.dll versinya sendiri, bentrok versi sering terjadi
      Meski begitu, di masa ketika RAM kecil dan swapping berat, rendahnya overhead tetap berarti
      Pada masa itu aplikasi native lebih dominan daripada Web 2.0 atau NodeJS, dan Java juga tidak punya reputasi bagus
      Pada akhirnya, seperti biasa, rasanya seperti maju dua langkah lalu mundur satu langkah
    • Ungkapan bahwa Cygwin itu pendekatan yang ortodoks mungkin benar menurut sebagian ukuran, tapi bagi saya itu terlihat sebagai pendekatan yang cukup ganjil
      Berlawanan dengan nuansa bahwa ia tidak lambat, kenyataannya lambat, kompatibilitasnya juga lebih rendah daripada cara lain, perlu recompile, dan sepanjang sebagian besar umurnya bukan alat yang dicintai luas
      Di dalam cygwin1.dll terjadi banyak sekali sulap kompatibilitas, dan pada akhirnya menurut saya itu sama saja dengan menarik plumbing Linux eksternal ke dalam proses. Terutama kalau mengingat cara mereka mengimplementasikan fork() tanpa dukungan sistem
      Cygwin sama sekali tidak berjalan di dalam isolasi Windows AppContainer. MSYS2 pun sampai sekarang memakai fondasi ini, jadi binary MSYS2 tidak bisa dijalankan di AppContainer
      Karena itu, untuk sandboxing Claude Code kami harus menempuh jalan yang sepenuhnya berbeda. Claude Code menginginkan Git for Windows, dan Git for Windows mendistribusikan bash.exe dan lainnya yang dibangun dengan MSYS2
      Sebaliknya, build Windows yang benar-benar native tidak punya hacking aneh semacam yang diminta cygwin1.dll, jadi build non-MSYS2 yang saya temukan berjalan baik di AppContainer
    • Sekarang MSYS2 tampaknya menyediakan package manager sambil tetap bergantung pada cygwin secara internal
      Karena bisa memakai pacman milik Arch Linux, mengelola binary POSIX native di Windows jadi cukup ramah bahkan tanpa VM Linux
    • Dari pengalaman pengembangan nyata, bekerja di atas Cygwin benar-benar menyakitkan
      Jika versi Cygwin yang sudah dibangun sebelumnya untuk pustaka C yang ingin dipakai tidak ada, Anda harus menjalankan seluruh pohon dependensi sendiri dengan configure dan make
      Selain itu, seingat saya sekitar dua pertiga kemungkinan Anda harus memperbaiki sesuatu sendiri, karena POSIX-nya tidak sepenuhnya cocok
    • Pada dasarnya Cygwin mengimplementasikan API POSIX di atas Win32, lalu mencampurkan sebagian panggilan Nt untuk meningkatkan kompatibilitas
      Namun untuk mendapatkan semantik yang benar, diperlukan segala macam jalan memutar dan hack; misalnya fork bukan copy-on-write
      Saya memakai Cygwin dari sekitar 1999 sampai 2022, sempat juga memakai WSL2 sedikit, dan masih memakainya di laptop
      Tapi untuk desktop, sejak tahun lalu saya sudah sepenuhnya pindah ke Linux
  • Ini terasa cukup menyenangkan karena seolah versi pre-NT Windows dari colinux
    Dulu saat masih memakai Windows di era XP, saya pernah menjalankan Colinux, dan itu alat yang benar-benar luar biasa
    Jauh lebih mudah menyiapkan stack LAMP di sisi Linux, dan dengan tetap mengedit memakai editor Windows saya bisa membangun lingkungan pengembangan lokal yang cukup bagus
    Bahkan bisa bereksperimen menjalankan desktop Linux di atasnya dengan memasang server X11 untuk Windows
    Saat melihat diri sendiri makin lama makin menumpuk lingkungan mirip Unix di atas Windows seperti itu, akhirnya saya pindah ke macOS
    Di luar nilai hacking murni, kalau memikirkan kegunaan nyata, saya juga merasa mesin kelas 486 akan cepat menabrak batas memori
    http://colinux.org/
    • Menurut saya Colinux benar-benar sebuah pencapaian teknis
      Hanya saja, rasanya tidak banyak orang yang menyadari itu
  • Orang yang membuat ini terasa hampir seperti penyihir
    Bagi saya ini tampak seperti pekerjaan yang nyaris mustahil
    Tapi saya jadi penasaran bagaimana ini terlihat di mata orang yang memahami arsitekturnya
    Jadi saya teringat lelucon tentang dua matematikawan yang bilang suatu teorema itu sepele, lalu baru setelah menjelaskan selama dua jam mereka mengakui bahwa itu memang sepele
    • Saya juga pernah saat jadi mahasiswa tahun pertama CS, berdiri di depan papan tulis saat kelas teori himpunan, lalu karena benar-benar tidak bisa melihat satu bagiannya, saya lewatkan begitu saja sebagai sepele
      Profesor pun bilang iya dan kami langsung lanjut ke bagian berikutnya
    • Saya biasanya cukup paham arsitektur, dan ini tidak terlihat seperti sihir bagi saya
      Yang justru sangat mengagumkan adalah bahwa penulisnya berhasil mengidentifikasi satu per satu daftar panjang detail setebal kitab yang memungkinkan semua ini
    • Peran inti sistem operasi modern, setahu saya, adalah membuat banyak program bisa berjalan bersamaan tanpa saling mengganggu
      Karena itu, tiap program hanya bisa membaca sebagian memorinya sendiri, dan CPU juga hanya dipakai dalam waktu terbatas sebelum diberikan ke program berikutnya
      Windows mulai memakai fungsi-fungsi seperti ini secara serius sejak Windows NT, dan XP juga berasal dari garis itu
      Sebaliknya, sampai Windows 98, program nyaris bisa melakukan apa saja, dan fitur proteksi perangkat keras semacam itu praktis menganggur
      Windows pada masa itu terasa lebih seperti sekumpulan pustaka fungsional untuk menampilkan UI dan berbicara dengan periferal ketimbang sebuah sistem operasi
      CPU punya perangkat keras khusus untuk membatasi akses memori dan waktu pemrosesan, tetapi Windows 9x tidak memanfaatkannya sepenuhnya
      Jadi saya rasa ada celah bagi subsistem Linux untuk Windows 9x ini untuk berpura-pura menjadi sistem operasinya sendiri, mengambil alih perangkat keras itu, lalu menjalankan sistem operasi modern
    • Kalau melihat halaman proyeknya, rasanya penjelasannya cukup bagus
      Menurut saya bagian tersulit dari pekerjaan seperti ini adalah memahami API driver Microsoft
      Dokumentasi era 9x tidak cukup rinci dan juga tidak mudah diakses, dan sampai sekarang pun ini bukan wilayah yang menyenangkan
    • Kernel win9x memang terkenal karena tidak melakukan terlalu banyak hal
      Jadi justru tampaknya ada cukup ruang untuk memindahkan sebagian fungsi level rendah Linux ke dalamnya
  • Menyenangkan melihat tulisan seperti ini muncul di front page pada hari yang sama
    Di satu sisi ada pembahasan bahwa Show HN makin banyak sampai tiga kali lipat dan dipenuhi aplikasi dengan nuansa vibe coding yang mirip, sementara di sisi lain ada seseorang yang selama 6 tahun membongkar isi Win9x dan menjalankan kernel Linux modern di dalamnya
    Dibandingkan thread yang dipenuhi aplikasi hasil prompt 20 menit, posting seperti ini terasa benar-benar membahagiakan
    • Saya lihat di README proyek tertulis Proudly written without AI
      Rasanya cukup menyenangkan bisa melihat kalimat seperti itu
    • Bahkan prompt-nya sendiri kemungkinan besar dibuat AI
      Alih-alih create me an owl app, sekarang umum meminta dibuatkan prompt komprehensif untuk membuat owl app, lalu menempelkannya ke sesi AI berikutnya
  • Ungkapan README > Proudly written with zero AI terasa agak ambigu
    Karena ada juga produk bernama Zero AI, jadi bisa terbaca seperti itu
    • Sekarang tampaknya sudah diperjelas menjadi > Proudly written without AI
      Ungkapannya jauh lebih jelas, dan proyeknya sendiri juga benar-benar menakjubkan
    • Di sini perbedaan huruf besar-kecil menurut saya penting
  • Saya tinggalkan tautan langsung tanpa perantara media sosial
    https://codeberg.org/hails/wsl9x
  • Saya penasaran apa referensi yang bagus untuk menjelaskan arsitektur Windows 3.x dan 9x dengan baik
    Saya tahu potongan informasi seperti adanya VM Monitor dan adanya dukungan semacam ini, tapi rasanya penjelasan detailnya tersebar di mana-mana
    Banyak orang merangkum Windows seolah hanya berjalan di atas DOS, tapi jelas itu tidak akurat
    Tentu ini berbeda dari virtual machine dalam arti modern, tetapi di dalamnya ada struktur teknis yang cukup menarik dan kebanyakan materi tampaknya hanya membahasnya secara dangkal
    Saya juga penasaran seberapa mirip proyek ini dengan BSD on Windows
    Dan saya juga tahu Architecture of Windows 9x, tetapi bagi selera saya rasanya kurang dalam
  • Kalau mengikuti gaya penamaan Microsoft, bukankah ini seharusnya bukan Windows Subsystem for Linux melainkan Linux Subsystem for Windows?
    • Saya rasa tidak juga
      Karena WSL berarti Linux on Windows, ini tampaknya dibaca sebagai W9xSL dalam arti Linux di atas Windows 9x
    • Saya juga sudah lama merasa nama ini tidak intuitif
    • Saya juga setuju
      Saya tidak bisa langsung memberi dasar pastinya, tetapi saya ingat pernah membaca bahwa ini terkait masalah merek dagang
      Katanya mereka awalnya ingin menyebutnya Linux Subsystem for Windows, tetapi pihak Linux foundation tidak mengizinkan proyek yang tidak diotorisasi memakai nama yang diawali Linux
  • Saya menduga ini mungkin lebih mudah daripada https://github.com/haileys/doslinux
    • Tapi saya tetap ingin bilang bahwa untuk melangkah ke tahap berikutnya saja butuh 6 tahun
  • Saya memahami bahwa kernel NT, dari NT 3.1 ke 2000 dan XP lalu sebagian garis keturunannya berlanjut sampai WSL di Windows 10/11, sejak 1993 memang dirancang dengan subsistem POSIX dalam pikiran
    Filsafat intinya adalah memiliki beberapa personality, lalu menerjemahkan system call dari tiap lingkungan ke panggilan kernel NT
    Karena itu, WSL1 pada 2016 pada dasarnya bisa dianggap mengulangi trik yang sama untuk Linux
    Sebaliknya, Windows 9x berasal dari garis DOS, jadi untuk menjalankan Linux di dalamnya mungkin dibutuhkan hack yang jauh lebih kotor dan secara mendasar berbeda
    Mungkin itulah juga alasan tak seorang pun melakukannya saat itu
    Jadi fakta bahwa ini benar-benar berjalan terasa menunjukkan betapa majunya arsitektur NT pada zamannya
    Untuk kegunaan praktis, saya teringat lingkungan yang masih terikat ke Windows 98, seperti perangkat lunak medis atau industri lama
    Namun jika pada 2026 Anda memegang 486, kemungkinan besar akan jauh lebih berguna menjalankan Linux native saja daripada menanamkan Linux ke dalam turunan DOS berusia 30 tahun
 
plumpmath 2026-04-24

Wah, coLinux haha -_- nama yang menyenangkan untuk didengar. Haha. Tapi sekarang pun saya tidak pakai meski ada WSL, namun win95+linux ini cukup menggoda.