Linux için Windows 9x Alt Sistemi

 (social.hails.org)
12 puan yazan GN⁺ 7 일 전 | 2 yorum | WhatsApp'ta paylaş
  • İki işletim sisteminin tüm özelliklerinden aynı anda yararlanmayı mümkün kılmak için modern Linux çekirdeğini (6.19) Windows 9x çekirdeği içinde işbirlikçi olarak çalıştıran deneysel bir proje
  • WSL'den farklı olarak donanım sanallaştırması kullanmadığı için 486'da bile çalışabiliyor
  • Sayfalama, bellek koruması, preemptive zamanlama gibi modern OS özelliklerini Windows 9x ortamında kullanmayı sağlıyor ve yeniden başlatmadan uygulamaları yan yana çalıştırmayı destekliyor
  • Yamalanmış Linux çekirdeği, VxD sürücüsü, wsl.com istemcisi olmak üzere üç bileşenden oluşuyor; User-Mode Linux, Win9x çekirdek API çağrılarına uyarlanmış
  • Sistem çağrıları, Win9x'in kısa kesme tanımlayıcı tablosu sınırlaması nedeniyle int 0x80 yerine genel koruma hatası (GPF) işleyicisi üzerinden dispatch ediliyor
  • "AI olmadan gururla yazıldı (Proudly written without AI)", GPL-3 lisansı

WSL9x - codeberg.org/hails/wsl9x

Genel Bakış

  • WSL9x, modern Linux çekirdeğini (yazım anında 6.19) Windows 9x çekirdeğinin içinde işbirlikçi biçimde çalıştıran bir Windows 9x için Linux alt sistemi
  • Sayfalama, bellek koruması, preemptive zamanlama gibi her iki işletim sisteminin tüm özelliklerinden aynı anda yararlanmayı sağlıyor
  • Yeniden başlatmadan iki OS'nin uygulamalarını yan yana çalıştırabiliyor
  • AI olmadan elde yazılmış

Teknik Yapı

  • WSL9x üç bileşenden oluşuyor
    • Yamalanmış Linux çekirdeği (win9x-um-6.19 dalı)
    • VxD sürücüsü
    • wsl.com istemci programı

VxD sürücüsü

  • WSL9x'in başlatılmasından sorumlu; giriş noktası vxd/wsl9x.asm
  • Çekirdek kodunun ilk eşlemesini kuruyor ve DOS kesmeleri üzerinden vmlinux.elf dosyasını diskten yüklüyor (vxd/loader.c, vxd/fs.asm)
  • Çekirdek sabit taban adresi 0xd0000000 ile derleniyor
  • System VM içinde yeni bir iş parçacığı başlatıyor ve Linux'a giriş için kullanmak üzere 16 KiB yığın ayırıyor
  • Sonrasında çekirdeğe giriş, IRQ dispatch'i, kullanıcı alanına dönüş ve boşta durumunu işleyen olay döngüsüne giriyor (vxd/entry.c)

Sistem çağrıları ve sayfa hatası işleme

  • Sürücü, çekirdeğe dispatch edilmesi gereken kullanıcı alanı olayları olan sayfa hataları ve sistem çağrılarını işliyor
  • Sistem çağrıları genel koruma hatası (GPF) işleyicisi üzerinden işleniyor
    • Win9x'in kesme tanımlayıcı tablosu, Linux i386 sistem çağrısı kesmesi int 0x80 için düzgün bir işleyici kuracak kadar uzun değil
    • GPF işleyicisi hataya neden olan komutu inceleyip bunun int 0x80 olduğunu görürse, sanki kesme başarılı olmuş gibi komut işaretçisini ilerletiyor ve Linux sistem çağrısına dispatch ediyor (vxd/fault.c)

Linux çekirdeğindeki değişiklikler

  • User-mode Linux tabanlı, ancak POSIX API yerine Windows 9x çekirdek API'sini çağıracak şekilde değiştirilmiş
  • Kullanıcı modu (ring 3) yerine ring 0 (süpervizör/çekirdek modu) içinde çalışıyor
  • Bağlam değiştirme dahil Win9x çekirdeğiyle entegrasyonun önemli bir bölümü Linux çekirdeği tarafında bulunuyor
    • Ana kod konumu: linux/arch/um/os-Win95
    • Giriş noktası: main.c içindeki _start, başlıca dosyalar process.c, mmu.c

wsl.com istemcisi

  • wsl/wsl.asm içinde uygulanmış 16 bitlik bir DOS programı
  • Ayrı bir TTY uygulaması olmadan MS-DOS komut istemini TTY penceresi olarak kullanmayı sağlıyor
  • Çalıştırıldığında WSL9x V86 API'sini (vxd/v86_api.asm) çağırarak kullanılmayan bir konsol ayırıyor ve bu konsolun çıktısının kendisine dispatch edilmesini bildiriyor
  • Sonrasında IRQ beklerken kesme oluştuğunda klavye okumayı deneyen bir olay döngüsüne giriyor
  • Ayrıca konsol sürücüsü (vxd/console.c) için bir senkronizasyon noktası işlevi görüyor
    • Linux çıktısı hazır olduğunda bir olay zamanlanıyor ve MS-DOS VM bağlamında int 0x29 çalıştırılarak DOS penceresine karakter yazdırılıyor
    • Bu kesme aynı zamanda NNANSI gibi DOS için ANSI sürücülerinin ANSI kaçış kodlarını uygulamak üzere terminal çıktısını yakaladığı nokta

Derleme ve çalıştırma gereksinimleri

  • i386-linux-musl hedefi için bir cross toolchain gerekli (musl-cross-make öneriliyor)
  • Windows bileşenlerini derlemek için Open Watcom v2 toolchain gerekli
  • win9x-um-6.19 dalındaki yamalanmış Linux çekirdeğinin derlenmesi gerekli
  • WATCOM ve LINUX ortam değişkenleri uygun şekilde ayarlanmalı (örnek için .envrc.example dosyasına bakın)
  • Windows 9x önceden kurulmuş hdd.base.img sabit disk imajı gerekli
  • make çalıştırıldığında WSL9x hazırlanmış hdd.img oluşturuluyor
  • MS-DOS komut isteminde wsl çalıştırılarak pty açılıyor; ANSI renk kullanımı için nnansi.com gibi bir sürücünün önceden yüklenmesi öneriliyor

Lisans

  • GPL-3

İlgili okumalar

2 yorum

 
GN⁺ 7 일 전
Hacker News yorumları
  • WSL'den önce, Windows içinde değiştirilmemiş Linux ikililerini çalıştırmanın başlıca yolları olarak CoLinux ve flinux vardı diye düşünüyorum.
    http://www.colinux.org/
    https://github.com/wishstudio/flinux
    flinux aslında yapı olarak WSL1'e daha yakındı; CoLinux ise Linux çekirdeğini yanına yüklemesi açısından daha çok WSL2 hissi veriyordu.
    Teknik olarak Cygwin bana daha klasik, daha düzgün bir yaklaşım gibi gelirdi. Dışarıdan Linux tesisatını zorla eklemek yerine Windows üzerinde yerel POSIX ikilileri çalıştırıyordu ve yalnızca hafif bir DLL bağlantısıyla işi bitirip ring 0'a dokunmaması da hoşuma gidiyordu.
    Yine de o dönemde CLI paket yöneticilerinin sunduğu rahatlık yoktu ve pratikte Windows'ta çalışırken CoLinux'a epey bağlanmıştım.
    • Cygwin'in CoLinux'tan çok daha eski olduğunu hatırlıyorum. CoLinux 2004'te, Cygwin ise 1995'te yayımlandı.
      Benim hatırladığım temel sorun DLL cehennemi idi. Örneğin Windows için OpenSSH portu kendi cygwin1.dll dosyasıyla gelirse sürüm çakışmaları sık yaşanırdı.
      Yine de RAM'in az, swap'in ağır olduğu zamanlarda düşük ek yük önemliydi.
      O dönemde Web 2.0 ya da NodeJS gibi şeylerden çok yerel uygulamalar merkezdeydi ve Java'nın da itibarı iyi değildi.
      Sonuçta her zamanki gibi iki adım ileri bir adım geri giden bir akış gibiydi.
    • Cygwin'in "doğru" yaklaşım olduğu sözü bazı ölçütlere göre doğru olabilir ama bana oldukça tuhaf bir yaklaşım gibi geliyordu.
      Yavaş olmadığı ima edilse de pratikte yavaştı, diğer yöntemlerden daha az uyumluydu, yeniden derleme gerektiriyordu ve ömrünün büyük bölümünde de yaygın olarak sevilen bir araç değildi.
      cygwin1.dll içinde muazzam bir uyumluluk sihri dönüyordu ve sonuçta dışarıdaki Linux tesisatını sürecin içine taşımış oluyordunuz. Özellikle sistem desteği olmadan fork()'u nasıl uyguladığını düşününce bu daha da belirginleşiyordu.
      Cygwin, Windows AppContainer yalıtımı içinde hiç çalışmıyor. MSYS2 de hâlâ bu temele dayandığı için MSYS2 ikilileri AppContainer içinde çalışamıyor.
      Bu yüzden Claude Code sandboxing'de tamamen farklı bir yol izlemek zorunda kaldık. Çünkü Claude Code Git for Windows istiyor ve Git for Windows, MSYS2 ile derlenmiş bash.exe gibi araçları dağıtıyor.
      Buna karşılık gerçekten yerel Windows derlemeleri, cygwin1.dll'in istediği o tuhaf hack'leri gerektirmediğinden, bulduğum non-MSYS2 derlemeler AppContainer içinde sorunsuz çalıştı.
    • Bugünlerde MSYS2'nin içeride Cygwin'e dayanırken bir yandan da paket yöneticisi sunduğunu düşünüyorum.
      Arch Linux'un pacman aracını kullanabildiğiniz için, Linux VM olmadan da Windows'ta yerel POSIX ikilileriyle oldukça kullanışlı şekilde çalışılabiliyor.
    • Gerçek geliştirme deneyimimde Cygwin üzerinde çalışmak gerçekten acı vericiydi.
      Kullanmak istediğiniz C kütüphanesinin önceden derlenmiş bir Cygwin sürümü yoksa, bağımlılık ağacının tamamını configure ve make ile elinizle döndürmeniz gerekiyordu.
      Üstelik hatırladığım kadarıyla yaklaşık üçte iki ihtimalle bir şeyleri elle düzeltmeniz gerekirdi, çünkü POSIX uyumu tam kusursuz değildi.
    • Cygwin temelde Win32 üzerinde POSIX API'sini uyguluyordu ve uyumluluğu artırmak için bazı Nt çağrılarını da karıştırıyordu.
      Ama doğru anlamı yakalamak için her türlü dolambaç ve hack gerekiyordu; örneğin fork copy-on-write değildi.
      Ben Cygwin'i yaklaşık 1999'dan 2022'ye kadar kullandım, WSL2'yi de biraz denedim ve dizüstünde hâlâ onu kullanıyorum.
      Ama masaüstünde geçen yıldan beri tamamen Linux'a geçtim.
  • Bunun colinux'un pre-NT Windows sürümü gibi bir şey olması fikri beni oldukça sevindirdi.
    Eskiden XP döneminde Windows kullanırken Colinux çalıştırmıştım; gerçekten büyüleyici bir araçtı.
    Linux tarafında LAMP yığınını kurmak çok daha kolaydı ve düzenlemeyi Windows editörleriyle yaparken yerel geliştirme ortamını oldukça iyi hale getirebiliyordunuz.
    Windows için bir X11 sunucusu ekleyip üstünde Linux masaüstü açmayı denemek de mümkündü.
    Windows üzerinde giderek daha Unix benzeri bir ortam kurduğumu fark edip sonunda macOS'a geçmiştim.
    Saf hack değeri dışında pratik kullanımı düşününce, 486 sınıfı makinelerde hızla bellek sınırına çarpılacağı da aklıma geliyor.
    http://colinux.org/
    • Colinux gerçekten bir teknik başarı idi.
      Sadece bunu fark eden insan sayısı azdı.
  • Bunu yapan kişi bana neredeyse bir büyücü gibi geldi.
    Benim gözümde neredeyse imkânsız görünen bir işti.
    Ama yapıyı anlayan insanların buna nasıl baktığını merak ettim.
    Bu da bana iki matematikçinin bir teoremi önemsiz diye nitelemesi ve iki saatlik açıklamadan sonra gerçekten önemsiz olduğuna ikna olunmasıyla ilgili şakayı hatırlattı.
    • Ben de CS birinci sınıfta kümeler kuramı dersinde tahtaya çıkıp bir ispat yaparken, bir türlü gösteremediğim kısmı önemsiz deyip geçiştirmiştim.
      Hoca da kabul edip bir sonrakine geçmişti.
    • Ben genelde yapıyı anlayan taraftayım ve bu bana sihir gibi görünmüyor.
      Ama yazarı, bunu mümkün kılan uzun vizyon belgesi gibi ayrıntı listesini tek tek keşfetmiş olması açısından çok etkileyici buluyorum.
    • Modern işletim sistemlerinin temel rolünü, birçok programın birbirine karışmadan aynı anda çalışmasını sağlamak olarak anlıyorum.
      Bu yüzden her program belleğin yalnızca kendine ayrılan kısmını okuyabilir ve CPU'yu da sınırlı bir süre kullanıp ardından diğer programa bırakır.
      Windows bu özellikleri asıl olarak Windows NT ile ciddi biçimde kullanmaya başladı; XP de o ailedendir.
      Buna karşılık Windows 98'e kadar programlar neredeyse her şeyi yapabiliyordu ve donanımın sunduğu bu koruma özellikleri büyük ölçüde boşta kalıyordu.
      O dönemin Windows'u bana bir işletim sisteminden çok, bir arayüz gösteren ve çevre birimleriyle konuşan işlev kütüphaneleri paketi gibi geliyordu.
      CPU'da bellek erişimini ve işlem süresini sınırlayan özel donanım var ama Windows 9x bunu yeterince kullanmıyordu.
      Bu yüzden Windows 9x için bir Linux alt sistemi, kendisi işletim sistemiymiş gibi davranıp bu donanımı kullanarak modern bir işletim sistemi çalıştırabilecek bir boşluk bulabiliyor.
    • Proje sayfasına bakınca açıklamanın epey iyi yapıldığını düşündüm.
      Bana göre bu tür işlerde en zor kısım Microsoft sürücü API'sini çözüp anlamaktır.
      9x döneminin belgeleri ne yeterince ayrıntılıydı ne de erişimi kolaydı; bugün bile pek keyifli bir alan sayılmaz.
    • win9x çekirdeği, aslında pek fazla iş yapmadığı ile meşhurdu.
      Bu yüzden Linux'un bazı düşük seviye özelliklerini içine taşımak için epey alan bırakıyor gibi görünüyordu.
  • Böyle bir yazının aynı gün ön sayfaya çıkması hoşuma gitti.
    Bir tarafta Show HN'in üç katına çıktığından ve benzer vibe coding uygulamalarından söz edilirken, diğer tarafta birisi 6 yıl boyunca Win9x'in içini eşeleyip modern bir Linux çekirdeğini onun içinde çalıştırıyordu.
    20 dakikalık prompt'larla üretilmiş uygulamalarla dolu başlıklarla kıyaslayınca, böyle gönderiler gerçekten mutluluk veriyor.
    • Projenin README dosyasında Proudly written without AI yazdığını gördüm.
      Böyle bir ifade görmek oldukça hoşuma gitti.
    • Hatta prompt'un kendisinin bile muhtemelen AI tarafından yazıldığını düşünüyorum.
      create me an owl app demek yerine, owl app üretmek için kapsamlı bir prompt yazdırıp onu sonraki AI oturumuna yapıştırmak artık yaygınlaştı.
  • README'deki > Proudly written with zero AI ifadesi bana biraz muğlak gelmişti.
    Çünkü gerçekten Zero AI adlı bir ürün var, bu yüzden öyle de okunabilir diye düşündüm.
    • Şimdi bunu > Proudly written without AI olarak değiştirip daha açık hale getirmiş gibi görünüyor.
      İfade çok daha net olmuş ve projenin kendisi de gerçekten etkileyici.
    • Burada büyük/küçük harf farkı önemli bence.
  • Sosyal ağ üzerinden gitmeyen doğrudan bağlantıyı bırakıyorum.
    https://codeberg.org/hails/wsl9x
  • Windows 3.x ve 9x mimarisini iyi anlatan iyi kaynaklar neler olabilir diye merak ediyorum.
    VM Monitor diye bir şey olduğunu ve bu tür desteğin bulunduğunu parça parça biliyorum ama ayrıntılı açıklamaların dağınık halde olduğunu hissediyorum.
    Pek çok kişi Windows'u basitçe DOS üzerinde çalışan bir şey diye özetliyor ama bunun açıkça doğru olmadığını düşünüyorum.
    Elbette bugünkü anlamda bir sanal makine değil ama içinde oldukça ilginç teknik yapılar vardı ve çoğu kaynak bunları sadece yüzeysel geçiyor gibi.
    Ayrıca bu projenin BSD on Windows ile ne kadar benzer olduğunu da merak ediyorum.
    Architecture of Windows 9x sayfasını da biliyorum ama bana göre yeterince derin değil.
  • Microsoft tarzı adlandırma mantığıyla bakarsak bunun Windows Subsystem for Linux değil, Linux Subsystem for Windows olması gerekmez mi diye düşündüm.
    • Bence şart değil.
      WSL, Linux on Windows anlamına geliyorsa bu da Windows 9x üzerindeki Linux anlamında W9xSL diye okunuyor gibi.
    • Ben de bu ismi uzun zamandır pek sezgisel bulmuyorum.
    • Ben de katılıyorum.
      Şu an hemen dayanak gösteremem ama bir yerde bunun ticari marka meselesiyle ilgili olduğunu okuduğumu hatırlıyorum.
      Aslında Linux Subsystem for Windows demek istiyorlardı ama Linux Foundation tarafı, yetkisiz projelerin Linux ile başlayan adlar kullanmasına izin vermiyordu gibi bir hikâyeydi.
  • https://github.com/haileys/doslinux yerine bunun daha kolay olduğunu tahmin ediyorum.
    • Yine de bir sonraki aşamaya gelmek 6 yıl sürdü demek isterim.
  • NT çekirdeğinin NT 3.1'den 2000 ve XP'ye, oradan da daha sonra Windows 10/11 içindeki WSL'ye uzanan bir soy taşıdığını ve daha 1993'te en başından POSIX alt sistemi düşünülerek tasarlandığını anlıyorum.
    Temel felsefe, birden fazla personality barındırıp her ortamın sistem çağrılarını NT çekirdek çağrılarına çevirmekti.
    Bu yüzden WSL1 de 2016'da aslında aynı numaranın Linux için yeniden uygulanmış hali gibi görünüyor.
    Buna karşılık Windows 9x DOS soyundan geldiği için, içinde Linux çalıştırmak çok daha dağınık ve temelden farklı hack'ler gerektiriyor olmalıydı.
    Muhtemelen o dönemde kimsenin bunu yapmamış olmasının sebebi de buydu.
    Dolayısıyla bunun gerçekten çalışıyor olması bile NT mimarisinin ne kadar zamanının ötesinde olduğunu gösteriyor gibi geliyor.
    Pratik kullanım tarafında aklıma, Windows 98'e bağlı kalmış eski tıbbi ya da endüstriyel yazılımlar geliyor.
    Ama 2026'da elinizde bir 486 varsa, 30 yıllık bir DOS türevinin içine Linux yerleştirmeye çalışmak yerine doğrudan yerel Linux çalıştırmak muhtemelen çok daha faydalı olur.
 
plumpmath 6 일 전

Vay coLinux haha -_- tanıdık bir isim. hehe Ama şu an WSL olsa da kullanmıyorum, win95+linux ise cezbedici geliyor.