Wine 11, Linux’in Windows oyunlarını çalıştırma biçimini çekirdek düzeyinde yeniden yazarak büyük ölçekli performans artışı sağladı

• Linux’te Windows oyunlarını çalıştırma mimarisi çekirdek düzeyinde baştan tasarlandı ve önceki wineserver tabanlı senkronizasyon darboğazı ortadan kaldırıldı
• Yeni NTSYNC sürücüsü, NT senkronizasyon nesnelerini doğrudan çekirdekte işliyor ve FPS’te 8 kata varan artışlar sağlıyor
• WoW64’ün tamamlanması sayesinde 64 bit Linux’te 32 bit Windows uygulamaları ek kütüphane olmadan çalıştırılabiliyor
• Wayland sürücüsünün güçlendirilmesi, Vulkan 1.4 desteği, Bluetooth ve force feedback iyileştirmeleri gibi değişikliklerle grafik ve giriş/çıkış uyumluluğu genişletildi
• Proton, SteamOS, Lutris gibi Wine tabanlı ekosistemin genelinde performans ve kararlılık artışı etkisi yayılıyor

---

Wine 11’in temel değişiklikleri

• Wine 11 yalnızca yıllık bir güncelleme değil; Linux’te Windows oyunlarını çalıştırma biçimini çekirdek düzeyinde yeniden yazan büyük çaplı bir revizyon

  • Yıllar içinde biriken hata düzeltmeleri ve performans iyileştirmelerine ek olarak NTSYNC desteği, WoW64’ün tamamlanması, Wayland sürücüsünün güçlendirilmesi gibi yapısal değişiklikler içeriyor
  • Proton, SteamOS gibi Wine tabanlı projelerin geneline performans kazanımları yayılıyor

Mevcut sınırlamalar ve geçici çözümler

• Geçmişte Wine, Windows’un NT senkronizasyon primitiflerini (mutex, semaphore, event vb.) Linux üzerinde eksiksiz biçimde uygulayamıyordu
  • İş parçacıkları arasındaki senkronizasyon için her seferinde wineserver üzerinden RPC çağrısı yapılıyor, saniyede binlerce çağrı kare gecikmesine ve düzensiz zamanlamaya yol açıyordu
• Esync, eventfd kullanarak wineserver çağrılarını azalttı ancak dosya tanımlayıcı sınırı sorununu ortaya çıkardı
• Fsync, futex tabanlı olduğu için daha hızlıydı; ancak çekirdek dışı yamalar gerektirdiğinden genel dağıtımlarda kullanımı zordu
  • Linux 5.16’daki futex_waitv, Fsync’in özgün biçiminden farklı ve tam bir ikame değil
• Her iki yöntem de geçici çözüm niteliğindeydi; bazı NT API’leri (ör. NtPulseEvent, NtWaitForMultipleObjects içindeki wait-for-all modu) doğru biçimde uygulanamıyordu

NTSYNC — çekirdek düzeyinde senkronizasyonun yeniden tasarımı

• NTSYNC, Linux çekirdeğine yeni bir /dev/ntsync aygıt sürücüsü ekleyerek Windows NT senkronizasyon nesnelerini doğrudan modelliyor
  • Senkronizasyon artık kullanıcı alanında değil, doğrudan çekirdeğin içinde işleniyor; böylece wineserver’a gidiş-dönüş çağrıları ortadan kalkıyor
  • Kuyruk yönetimi, event anlambilimi ve atomik işlemleri doğrudan çekirdek yürütüyor
• Geliştiricisi, Esync ve Fsync’i yaratan Elizabeth Figura; çözüm 2023 Linux Plumbers Conference’ta tanıtıldıktan sonra Linux 6.14’e dahil edildi

• Performans artışı verileri

  • Dirt 3: 110.6 → 860.7 FPS (%678 artış)
  • Resident Evil 2: 26 → 77 FPS
  • Call of Juarez: 99.8 → 224.1 FPS
  • Tiny Tina’s Wonderlands: 130 → 360 FPS
  • Call of Duty: Black Ops I artık tamamen oynanabilir durumda

• fsync ile farkları

  • fsync kullanıcıları için artış sınırlı olabilir; ancak çok iş parçacıklı darboğaz yaşayan oyunlarda iyileşme dramatik
  • Ana çekirdeğe dahil edildiği için ek yama gerekmiyor; Fedora 42, Ubuntu 25.04 gibi güncel dağıtımlarda hemen kullanılabiliyor
  • SteamOS 3.7.20 beta sürümünde varsayılan olarak geliyor, Proton GE içinde de etkinleştirildi
  • NTSYNC, Wine tarihinde ilk kez çekirdek düzeyinde doğru senkronizasyon uygulamasının sağlandığı örnek oldu

WoW64 tamamlandı — 32 bit uyumluluğun birleşmesi

• WoW64 (Windows 32-bit on Windows 64-bit) mimarisinin uygulanması Wine 11 ile tamamlandı
  • 64 bit Linux sistemlerde 32 bit Windows uygulamalarını çalıştırmak için ayrı 32 bit kütüphane kurmak gerekmiyor
  • Tek bir ikili dosya, çalıştırılabilir dosyanın bit düzeyini otomatik algılayıp işliyor
• OpenGL bellek eşleme, SCSI pass-through ve 16 bit uygulama desteği de buna dahil
  • Böylece 1990’lardan kalma eski Windows yazılımları da çalıştırılabiliyor
• Eskiden dağıtıma göre değişen multilib yapılandırmaları nedeniyle çalıştırma zordu; artık bunu Wine kendi içinde ele alıyor

Wayland ve diğer önemli iyileştirmeler

• Wayland sürücüsü

  • Çift yönlü pano kopyalama, sürükle-bırak desteği ve çözünürlük değişiminde compositor ölçeklemesi ile eski oyunların uyumluluğu arttı
  • X11’den Wayland’a geçişte yaşanan Wine uyumluluk sorunlarının büyük kısmı giderildi

• Grafik ve medya

  • X11 üzerinde EGL, OpenGL için varsayılan arka uç haline getirildi ve GLX’in yerini aldı
  • Vulkan 1.4 desteği ile Vulkan Video tabanlı H.264 donanımsal hızlandırmalı çözme eklendi

• Giriş/çıkış ve çevre birimleri

  • Force feedback iyileştirmeleri sayesinde yarış direksiyonları ve flight stick desteği güçlendirildi

  • Bluetooth BLE hizmetleri ve eşleştirme desteği, MIDI soundfont işleme iyileştirildi

    • Zip64 sıkıştırma, Unicode 17.0.0, TWAIN 2.0 tarama (64 bit) ve IPv6 ping özellikleri eklendi

• Performans ve platform genişlemesi

  • Linux ve macOS’ta iş parçacığı önceliği yönetimi iyileştirildi, çok iş parçacıklı performans arttı
  • ARM64 üzerinde 4K sayfa boyutu simülasyonu desteği eklenerek ARM tabanlı Linux cihazlarla uyumluluk sağlandı

Oyun uyumluluğu ve hata düzeltmeleri

• Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI, Battle.net gibi önemli yapımlarda uyumluluk iyileştirildi
• Yüzlerce hata düzeltmesiyle genel kararlılık ve performans artırıldı

Genel değerlendirme

• NTSYNC, WoW64’ün tamamlanması, Wayland iyileştirmeleri ve geniş kapsamlı hata düzeltmeleri bir araya gelerek Wine 11’i Proton’dan sonraki en önemli sürüm haline getiriyor
• Proton, Lutris, Bottles gibi Wine tabanlı tüm projelerde performans ve uyumluluk iyileşiyor
• Linux’te oyun oynayan kullanıcılar için Wine 11 kesinlikle denemeye değer bir sürüm

[kh0324]

Sonuçta birkaç yıllık eski oyunda yine geriye dönük uyumluluk bozulacak gibi görünüyor..

Demek ki bu da eşdeğer bir takasmış.

[GN⁺]

Hacker News yorumları

• Wine projesine neredeyse sonsuz bir saygı duyuyorum
  30 yıl boyunca Windows’un belgelenmiş/belgelenmemiş davranışlarını birebir yeniden üretmeye çalışmak sıkıcı ve ödülü az bir iş gibi geliyor, ama Wine’ın gerçekten kullanılabilir bir ürün hâline gelmesini sağlayan da bu oldu
  Özellikle eski oyunların Windows’tan daha iyi çalıştığını görünce, ayrıntılara verilen özen ve acıya karşı sabır gerçekten etkileyici geliyor

  • Eskiden Wine’ın düzgün çalışmasının mümkün olmadığını düşündüğüm için Linux’ta oyun oynamaktan kaçınırdım
    Arada basit oyunları çalıştırıp “bu gerçekten oluyor mu?” diye düşündüğüm olurdu, ama güvenilir olduğunu düşünmezdim
    Şimdi bunun tamamen yanlış bir değerlendirme olduğunu kabul ediyorum
  • Gerçekten harika bir proje olmasına rağmen, Word, Excel, Outlook gibi iş uygulamalarının hâlâ iyi çalışmaması üzücü
    Son Platinum derecesi alan sürümün Excel 2010 olduğu söyleniyor
    Bunun oyunlardan neden daha zor olduğu ilginç
  • Wine, farklı platformlarda uyumluluk testlerini otomatik olarak çalıştırıyor
    Test sonuçları sayfasına bakınca, bu tür sistematik doğrulamanın yüksek uyumluluğun anahtarı olduğu görülüyor
  • ReactOS da anılmayı hak ediyor
    O projede edinilen bilginin önemli bir kısmı Wine geliştirmesine aktı
  • 90’larda OS/2 kullandığımda, Windows uygulamalarını çalıştırmak için tüm Windows’u başlatmak gerekiyordu
    O zaman Wine gibi bir şeyi kendim yapmak istemiştim ama bilgim yetersizdi
    Şimdi Linux’u yalnızca sunucu için kullanıyorum, Mac için de Wine olduğunu duydum ama özellikle çalıştırmak istediğim bir Windows uygulaması yok

• Proton sayesinde oyun kare hızlarının inanılmaz derecede arttığını görmek şaşırtıcı
  Dirt 3’ün 110FPS’ten 860FPS’e, Resident Evil 2’nin ise 26FPS’ten 77FPS’e çıkması inanması güç
  Bunda Valve’ın ciddi para harcamış olmasının büyük payı olduğunu düşünüyorum

  • Yine de bu rakamlar Wine+ntsync ile Wine’ın varsayılan sürümünü karşılaştırıyor, bu yüzden biraz abartılı bir yönü var
    Mevcut fsync tabanlı Wine ile karşılaştırıldığında artış birkaç yüzde puan düzeyinde
    Buna rağmen ntsync açık bir iyileştirme
    ntsync belgelerine göre bu, Windows’un senkronizasyon yapısını Linux’ta daha doğru uygulamak için kullanılan bir kernel sürücüsü
  • Karşılaştırmanın “esync veya fsync kullanılmadığında” yapıldığına da dikkat etmek gerekiyor
  • Proton ile Wine arasındaki ilişkiyi merak ediyorum — Proton, Valve/SteamOS için kullanılan bir ad mı, yoksa ayrı bir proje mi?

• ntsync performans artışı konusunda fazla heyecanlanmamak gerektiğini söyleyenler de var
  Çoğu durumda performans artışı tek haneli yüzde seviyesinde, bazı oyunlar ise biraz daha yavaş bile olabilir

  • fsync yaması olmayan bir kernel kullananlar için durum farklı olabilir
  • Wayland ile X11 arasındaki performans farkını da karşılaştırmaya değer bulanlar var

• Bu tür düşük seviye teknoloji konularını görünce benim sadece CRUD uygulamaları yapıyor olmam utanç verici geliyor

  • Ama CRUD’un da değeri var ve ruh sağlığı için iyi
    Eskiden dâhi bir geliştiricinin aşırı yoğun takvimler altında ezildikten sonra basit bir VB CRUD işine geçip bunu “ücretli tatil gibi” diye anlattığı bir hikâye duymuştum
  • Ben de Outlook’ta “buraya tıkla, şuraya tıkla” gibi basit yardımlar yapıyorum ama bu da gerekli bir iş
  • Tersine, düşük seviye geliştiriciler de yüksek seviye sistemlerle uğraşırken kendilerini yetersiz hissedebiliyor
  • Derleyici yapan biri olarak ben bile kişisel projeler için CRUD uygulaması yapmayı defalarca denedim ve başarısız oldum
    Rails, Phoenix, Django hepsini denedim ama kolay değildi
    Son dönemde Claude’un yardımıyla biraz ilerleme kaydettim
  • CRUD uygulamaları da hiç hafife alınacak şeyler değil
    Kurumsal gereksinimler karmaşık olduğu için mimari kolayca çökecek hâle gelebiliyor

• Valve’a harcadığım binlerce doların sonunda Wine’ı iyileştirmeye gitmiş olması sevindirici
  Valve’ın bunun için kaç geliştirici ve yüklenici çalıştırdığını merak ediyorum

  • Wine geliştiricilerinin üçte ikisi CodeWeavers bünyesinde ve Valve ile Proton sözleşmeleri kapsamında çalışıyor
    Yani fonların büyük kısmı oraya akıyor

• Wine paradoksal biçimde kendini gereksiz kılan bir şey olabilir
  Linux’ta oyunlar iyi çalışırsa geliştiriciler doğrudan Linux sürümü çıkarır ve Wine’a ihtiyaç kalmayabilir

  • Ama Wine’ın API’si Linux’tan daha kararlı olduğu için, Wine tersine birinci sınıf hedef hâline gelebilir
  • Gerçekte bunun tersinin yaşandığını düşünüyorum
    Yerel sürüm olsa bile Windows sürümünü Proton ile çalıştırmak daha kararlı oluyor
    Windows API’si tanıdık ve değişmez olduğu için geliştiriciler geliştirmeyi hâlâ onun etrafında yapıyor
  • Günümüzde “Linux desteği” demek çoğu zaman Proton’da iyi çalışması anlamına geliyor
  • Bence bu “iyi bir sorun”
  • Ayrıca Wine oyun dışında da pek çok amaçla kullanılıyor; dolayısıyla yerel sürümler artsa bile talep sürecektir
    Windows ABI’si hâlâ daha kararlı olduğu için, performans farkı önemsiz kaldığı sürece yalnızca Windows derlemesini korumak daha verimli

• ntsync’in kullanıcı alanında paylaşımlı bellek ile uygulanıp uygulanamayacağını soranlar vardı
  Claude buna, “Oyunların %95’i için daha basit yaklaşım yeterli olduğundan karmaşık paylaşımlı bellek mantığını uygulama motivasyonu yoktu; doğruluk önemli hâle geldiğinde ise bunu kernel’e taşımak doğal oldu” diye açıklama getirmiş

  • Ama gerçekte Linux böyle bir kullanıcı alanı özelliği sunmadığı için bu mümkün değil
    ntsync basit bir API sarmalayıcısı değil, NT kernel’inin senkronizasyon davranışını yeniden üreten kernel düzeyinde bir adaptör
    Kaynak koduna bakıldığında kernel zamanlayıcısıyla sıkı biçimde entegre olduğu görülüyor
  • Kernel belgelerinde de “kullanıcı alanı uygulamasıyla Windows düzeyinde performans ve doğruluk sağlanamaz” ifadesi açıkça yer alıyor
    Belge bağlantısı

• Linux’un Windows’u yeniden uygularken onu geçmesi gerçekten şaşırtıcı
  Microsoft kendi yazılımlarını giderek daha rahatsız edici hâle getirirken, böyle bir başarı etkileyici

  • Özellikle 64 bit Windows’ta kaybolan 16 bit desteğini Wine’ın koruyor olması çok önemli
    Eski oyunların çoğu 16 bit temelli ve 32 bit oyunlarda bile kurulum programı bazen 16 bit olabiliyor

• Eğer bir Wine geliştiricisi bunu görürse, Carolina Code Conference 2026’da bununla ilgili bir sunum yapmasını isterim
  Konuşmacı başvuruları 31 Mart’a kadar açık

• macOS’ta da aynısını isteyenler bu depoya katkıda bulunabilir

  • Ama dürüst olmak gerekirse MacOS için oyun sayısı o kadar az ki, ilgilenen geliştirici sayısı da muhtemelen çok düşüktür
    Eskiden okulun Mac’lerinde Bolo tank oyununu oynadığımı hatırlıyorum ama Windows oyunlarının %1’i bile etmez gibi geliyor
  • Ama performans yüzünden kernel’e alınması gerekiyorsa, Linux’ta bunun neden kullanıcı alanında yapılmadığını merak ediyorum