Subsistem Windows 9x untuk Linux

 (social.hails.org)
8 poin oleh GN⁺ 7 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Struktur yang mendukung menjalankan aplikasi Windows 9x dan Linux secara bersamaan, dengan kernel Linux modern berjalan secara kooperatif dengan kernel Windows di ring 0
  • Dengan asumsi tanpa menggunakan virtualisasi perangkat keras, sehingga disebut dapat berjalan bahkan di 486
  • Disebutkan bahwa cakupan modifikasi pada Windows 95 VMM tidak sebesar yang diperkirakan, serta penggunaan pemanggilan layanan VMM dan layanan terkait konteks memori seperti VMMCreateThread
  • Untuk jaringan, belum dicoba, dan dijawab bahwa sepertinya cukup dengan menulis driver jaringan untuk masing-masing sisi
  • Disebutkan bahwa gagasan ini dirapikan dan diwujudkan setelah doslinux, tanpa garis keturunan langsung, sambil memperlihatkan perbedaan pendekatan serta konteks dirilis sebelum dukungan 486 dihapus

Implementasi inti

  • Tautan proyek codeberg.org/hails/wsl9x juga disertakan
  • Dalam komentar tambahan juga disebutkan bahwa ini dirilis agar sesuai dengan waktu sebelum Linux menghapus dukungan 486

Keterangan tambahan tentang cara kerja

  • Menjawab pertanyaan tentang seberapa banyak Windows 95 VMM dimodifikasi, dijelaskan bahwa jumlahnya tidak sebanyak yang diduga
    • Disebutkan penggunaan beberapa pemanggilan layanan VMM
    • Contohnya VMMCreateThread dan layanan terkait konteks memori
    • Disebutkan juga bahwa ada item yang menurut dokumentasi bersifat internal dan tidak seharusnya dipanggil, tetapi tetap digunakan; namun dijawab bahwa campur tangan terhadap implementasi internal pada umumnya hanya sampai di situ
  • Menjawab pertanyaan apakah implementasi jaringan sudah dicoba, dijawab belum dicoba
    • Disebutkan bahwa tampaknya cukup menulis driver jaringan untuk masing-masing sisi

Hubungan dengan doslinux

  • Dijelaskan bahwa ia ingin membuat wsl9x sejak setelah doslinux
  • Disebutkan bahwa butuh 6 tahun untuk merapikan gagasan hingga metode implementasinya
  • Ditegaskan bahwa tidak ada garis keturunan langsung antara kedua proyek
    • Disebutkan bahwa pendekatannya sangat berbeda
    • Namun, pembelajaran dan pengalaman yang diperoleh dari doslinux tetap berlanjut

Reaksi dan perbandingan

  • Dalam berbagai tanggapan, berulang kali muncul reaksi bahwa ini mirip coLinux
    • Termasuk ungkapan bahwa ini seperti coLinux untuk Win9x
    • Ada juga tanggapan yang mengingatkan pengalaman menggunakan coLinux pada era XP
  • Ada pula tanggapan yang membandingkannya dengan Cygwin atau mengenangnya sebagai alternatif lama
  • Mengenai kemungkinan menjalankan aplikasi Windows, nama aplikasi spesifik seperti Winamp, Command & Conquer, Foobar2000 with Wine disebut dalam komentar, tetapi dukungan aktualnya tidak dikonfirmasi dalam isi utama
  • Berbagai pertanyaan dan candaan tentang kecepatan, menjalankan X server, kemungkinan Wayland compositor, apakah BSOD terjadi, dan lain-lain terus muncul, tetapi sebagian besar tidak ada informasi tambahan yang terkonfirmasi

Konteks rilis

  • Ini diperkenalkan dengan ungkapan bahwa secara pribadi mungkin ini salah satu hacking terbesar yang pernah ada
  • Ada tanggapan bahwa ini merupakan cara untuk memperpanjang umur pakai praktis komputer lama, tetapi tidak disertai penjelasan teknis tambahan yang mendukungnya
  • Isi utama postingan sangat singkat, dan fakta inti berfokus pada eksekusi bersamaan, eksekusi kooperatif di ring 0, tanpa virtualisasi, dan kemungkinan berjalan di 486

Bacaan terkait

1 komentar

 
GN⁺ 7 jam lalu
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