Wine nasıl çalışır 101

xguru · 2022-10-25T10:43:22+09:00

Wine, POSIX uyumlu işletim sistemlerinde (Linux, macOS, BSD) Windows programlarını çalıştırmayı sağlayan bir uyumluluk katmanıdır Valve'ın Steam Deck'i de Wine tabanlı bir çözüm kullanıyor WINE = Wine Is Not an Emulator Emülatör yaklaşımı yavaştır ve aslında Linux/macOS, Windows ikililerini yerel olarak çalıştırabilir (biraz yardım edilirse) Yazı, debugger üzerinden Linux/Windows ikililerinin nasıl çalıştığını ayrıntılı olarak açıklıyor Hello, Wine! Temelde Wine, Windows çalıştırılabilir dosyaları için bir "Dynamic Loader"dır Yerel bir Linux ikilisidir ve EXE ya da DLL'lerin nasıl işlenmesi gerektiğini bilir Wine, Windows çalıştırılabilir dosyasını belleğe yükledikten sonra ayrıştırır, bağımlılıklarını belirler ve çalıştırılması gereken koda sıçrar Yalnızca bununla bile Windows ikililerini çalıştırmak mümkündür, ancak istisnalar vardır System Calls syscall olarak adlandırılan sistem çağrıları, Wine'ı karmaşık hale getirir syscalllar işletim sisteminde uygulanır; çalıştırılabilir dosyanın veya kütüphanenin içinde yer almaz İşletim sisteminin sunduğu syscalllar, işletim sistemi API'sidir Linux: read, write, open, brk, getpid,.. Windows: NtReadFile, NtCreateProcess, NtCreateMutant,.. Sistem çağrıları, koddaki sıradan fonksiyon çağrılarından farklıdır. Örneğin bir dosya açma işlemi, File Descriptor takibini gerektirdiği için çekirdek tarafından ele alınmalıdır Bu yüzden uygulama kodunun kendi kendini "interrupt" edip denetimi çekirdeğe vermesinin bir yolu olmalıdır ("Context Switch") İşletim sisteminin sunduğu fonksiyon kümesi ve bunların çağrılma biçimi, her işletim sisteminde farklıdır Linux'ta read() fonksiyonunu çağırırken dosya tanımlayıcısını %rdi, arabellek işaretçisini %rsi, okunacak bayt sayısını ise %rdx register'ına koymak gerekir Ancak Windows'ta çekirdekte read() diye bir fonksiyon yoktur Aynı "Hello World!" yazdırma kodu Linux/Windows'ta çalıştırıldığında Linux, libc.so içindeki puts'u; Windows ise ucrtbase.dll içindeki printf'i çağırır Günümüz Linux'unda genelde statik linkleme yapıldığından puts implementasyonu ikilinin içine dahil edilir ve çalışma anında libc.so kullanılmaz Windows'ta en azından yakın zamana kadar "yalnızca kötü amaçlı yazılımlar sistem çağrılarını doğrudan kullanıyordu" Sıradan uygulamalar her zaman kernel32.dll/kernelbase.dll/ntdll.dll'e bağımlıdır; böylece çekirdekle doğrudan iletişim kurmazlar Runtime translation of Syscalls Peki syscall'ları yakalarsak ne olur? Uygulama NtWriteFile() çağırdığında araya girip write() çağırdıktan sonra sonucu ikilinin beklediği formatta geri döndürsek? Özel bir ucrtbase.dll sürümü sağlanırsa bu mümkün olabilir, ancak karmaşık sorunlar ortaya çıkar Bunun yerine ikili ile çekirdek arasında duran ntdll.dll değiştirilir Wine'ın yeni sürümleri ntdll.dll (PE ikilisi) ve ntdll.so (ELF ikilisi) bileşenlerinden oluşur DLL, çağrıları yalnızca ELF tarafına yönlendiren ince bir katmandır ELF tarafında __wine_syscall_dispatcher adlı özel bir fonksiyon bulunur; bu fonksiyon mevcut stack'i Windows'tan Linux'a ya da tersine çevirmek gibi sihirli işler yapar Bu syscall dispatcher, Windows dünyası ile Linux dünyasını bağlayan köprüdür Calling convention'ları işler, stack alanı ayırır, register'ları taşır ve benzeri işleri yapar Çalışma ntdll.so'ya gelip Linux ikilisine geçtiğinde artık tüm Linux API'lerini kullanabiliriz Hepsi bu mu? Kulağa çok kolay gibi geliyor ama... Windows API'leri son derece fazladır, iyi belgelenmemiştir, bilinen/bilinmeyen hatalar içerir ve bunların olduğu gibi korunması gerekir. Wine kodunun büyük bölümü, çeşitli Windows DLL'lerinin implementasyonlarından oluşur syscall çağırmanın farklı yolları vardır ve teknik olarak uygulamaların syscallları doğrudan çağırmasını engellemenin bir yolu yoktur (Windows oyunlarının akla gelebilecek her türlü çılgınlığı yaptığını unutmayın) Linux çekirdeğinin bunu işlemek için özel mekanizmaları vardır ve elbette bu da karmaşıklığı artırır 32 bit ve 64 bit meselesi de başlı başına saçmalıktır. Sayısız 32 bit oyun vardır ve bunlar yeniden 64 bit olarak yayımlanmayacaktır. Wine her ikisini de desteklediği için bu da karmaşıklığı artırır Burada wine-serverdan hiç söz etmedik. Bu, Wine'ın oluşturduğu ayrı bir süreçtir ve çekirdeğin "durumunu" (dosya tanımlayıcıları, mutex'ler vb.) korur Oyun çalıştırmak mı istiyorsunuz? DirectX, PulseAudio, giriş aygıtları ve daha fazlasını ele almak gerekir; yani yapılacak iş çoktur Wine uzun yıllardır geliştiriliyor ve çok yol kat etti. Bugün Cyberpunk 2077 ya da Elden Ring gibi modern oyunları sorunsuz çalıştırabiliyor Bazen Wine'ın Windows'tan daha iyi performans gösterdiği bile oluyor

(werat.dev)

34 puan yazan xguru 2022-10-25 | 11 yorum | WhatsApp'ta paylaş

Wine, POSIX uyumlu işletim sistemlerinde (Linux, macOS, BSD) Windows programlarını çalıştırmayı sağlayan bir uyumluluk katmanıdır
- Valve'ın Steam Deck'i de Wine tabanlı bir çözüm kullanıyor

WINE = Wine Is Not an Emulator

Emülatör yaklaşımı yavaştır ve aslında Linux/macOS, Windows ikililerini yerel olarak çalıştırabilir (biraz yardım edilirse)
Yazı, debugger üzerinden Linux/Windows ikililerinin nasıl çalıştığını ayrıntılı olarak açıklıyor

Hello, Wine!

Temelde Wine, Windows çalıştırılabilir dosyaları için bir "Dynamic Loader"dır
Yerel bir Linux ikilisidir ve EXE ya da DLL'lerin nasıl işlenmesi gerektiğini bilir
Wine, Windows çalıştırılabilir dosyasını belleğe yükledikten sonra ayrıştırır, bağımlılıklarını belirler ve çalıştırılması gereken koda sıçrar
Yalnızca bununla bile Windows ikililerini çalıştırmak mümkündür, ancak istisnalar vardır

System Calls

syscall olarak adlandırılan sistem çağrıları, Wine'ı karmaşık hale getirir
syscalllar işletim sisteminde uygulanır; çalıştırılabilir dosyanın veya kütüphanenin içinde yer almaz
İşletim sisteminin sunduğu syscalllar, işletim sistemi API'sidir
- Linux: read, write, open, brk, getpid,..
- Windows: NtReadFile, NtCreateProcess, NtCreateMutant,..
Sistem çağrıları, koddaki sıradan fonksiyon çağrılarından farklıdır. Örneğin bir dosya açma işlemi, File Descriptor takibini gerektirdiği için çekirdek tarafından ele alınmalıdır
Bu yüzden uygulama kodunun kendi kendini "interrupt" edip denetimi çekirdeğe vermesinin bir yolu olmalıdır ("Context Switch")
İşletim sisteminin sunduğu fonksiyon kümesi ve bunların çağrılma biçimi, her işletim sisteminde farklıdır
- Linux'ta read() fonksiyonunu çağırırken dosya tanımlayıcısını %rdi, arabellek işaretçisini %rsi, okunacak bayt sayısını ise %rdx register'ına koymak gerekir
- Ancak Windows'ta çekirdekte read() diye bir fonksiyon yoktur
Aynı "Hello World!" yazdırma kodu Linux/Windows'ta çalıştırıldığında
- Linux, libc.so içindeki puts'u; Windows ise ucrtbase.dll içindeki printf'i çağırır
- Günümüz Linux'unda genelde statik linkleme yapıldığından puts implementasyonu ikilinin içine dahil edilir ve çalışma anında libc.so kullanılmaz
Windows'ta en azından yakın zamana kadar "yalnızca kötü amaçlı yazılımlar sistem çağrılarını doğrudan kullanıyordu"
- Sıradan uygulamalar her zaman kernel32.dll/kernelbase.dll/ntdll.dll'e bağımlıdır; böylece çekirdekle doğrudan iletişim kurmazlar

Runtime translation of Syscalls

Peki syscall'ları yakalarsak ne olur?
Uygulama NtWriteFile() çağırdığında araya girip write() çağırdıktan sonra sonucu ikilinin beklediği formatta geri döndürsek?
Özel bir ucrtbase.dll sürümü sağlanırsa bu mümkün olabilir, ancak karmaşık sorunlar ortaya çıkar
Bunun yerine ikili ile çekirdek arasında duran ntdll.dll değiştirilir
Wine'ın yeni sürümleri ntdll.dll (PE ikilisi) ve ntdll.so (ELF ikilisi) bileşenlerinden oluşur
- DLL, çağrıları yalnızca ELF tarafına yönlendiren ince bir katmandır
- ELF tarafında __wine_syscall_dispatcher adlı özel bir fonksiyon bulunur; bu fonksiyon mevcut stack'i Windows'tan Linux'a ya da tersine çevirmek gibi sihirli işler yapar
Bu syscall dispatcher, Windows dünyası ile Linux dünyasını bağlayan köprüdür
- Calling convention'ları işler, stack alanı ayırır, register'ları taşır ve benzeri işleri yapar
- Çalışma ntdll.so'ya gelip Linux ikilisine geçtiğinde artık tüm Linux API'lerini kullanabiliriz

Hepsi bu mu?

Kulağa çok kolay gibi geliyor ama...
- Windows API'leri son derece fazladır, iyi belgelenmemiştir, bilinen/bilinmeyen hatalar içerir ve bunların olduğu gibi korunması gerekir. Wine kodunun büyük bölümü, çeşitli Windows DLL'lerinin implementasyonlarından oluşur
- syscall çağırmanın farklı yolları vardır ve teknik olarak uygulamaların syscallları doğrudan çağırmasını engellemenin bir yolu yoktur
  (Windows oyunlarının akla gelebilecek her türlü çılgınlığı yaptığını unutmayın)
  Linux çekirdeğinin bunu işlemek için özel mekanizmaları vardır ve elbette bu da karmaşıklığı artırır
- 32 bit ve 64 bit meselesi de başlı başına saçmalıktır. Sayısız 32 bit oyun vardır ve bunlar yeniden 64 bit olarak yayımlanmayacaktır. Wine her ikisini de desteklediği için bu da karmaşıklığı artırır
- Burada wine-serverdan hiç söz etmedik. Bu, Wine'ın oluşturduğu ayrı bir süreçtir ve çekirdeğin "durumunu" (dosya tanımlayıcıları, mutex'ler vb.) korur
- Oyun çalıştırmak mı istiyorsunuz? DirectX, PulseAudio, giriş aygıtları ve daha fazlasını ele almak gerekir; yani yapılacak iş çoktur
Wine uzun yıllardır geliştiriliyor ve çok yol kat etti. Bugün Cyberpunk 2077 ya da Elden Ring gibi modern oyunları sorunsuz çalıştırabiliyor
Bazen Wine'ın Windows'tan daha iyi performans gösterdiği bile oluyor

11 yorum

roxie 2022-10-29

İçerik de içerik ama özetin kalitesi gerçekten inanılmaz. Teşekkürler.

minho2da 2022-10-25

Abonelik tabanlı okuma hizmeti sunan yes24 ve Kyobo Book Centre kullanıyorum.

Evdeki PC ortamını Ubuntu’ya çevirdikten sonra Wine kullanarak YES24 ve Kyobo Book Centre’i çalıştırmayı denedim.

İkisi de ayrı bir DRM kullandığı için çalışıp çalışmayacağından emin değildim ama bildiğim kadarıyla QT ile yapılmış olan YES24 sorunsuz çalıştı; Kyobo Book Centre EBOOK ise çalışmadı. (UI çalışıyor, DRM çalışmıyor X)

İkisinde de DRM uygulandığını biliyorum, bu yüzden neden birinin çalışıp diğerinin çalışmadığını düşünüyordum; ama yukarıdaki yazıyı görünce kabaca anlayabildim sanırım (kabaca tamamen anladım görseli).

bbulbum 2022-10-25

wine5.0'dan beri KakaoTalk hiçbir ayar gerektirmeden çalıştığı için mutluyum. (KakaoTalk kullanmak istemem ayrı mesele olsa da..)
Ekran gösteriminde birkaç sorun var ama panoya kopyalanan görselleri gönderme gibi işlevler sorunsuz çalışıyor.
Genel olarak Wine sanki oyun çalıştırmaya odaklanıyor gibi görünüyor ama çeşitli uygulamaları da iyi çalıştırdığı için güzel.
Kamu kurumlarında Linux kullanımına geçiş konuşulsa bile Linux sürümü KakaoTalk'u akıllarına bile getirmemeleri biraz... bayağı kötü aslında..
Mac sürümünü hemen yapıvermişlerdi oysa..

bbulbum 2022-10-25

Kabaca nasıl çalıştığını biliyordum ama Wine'ı bu kadar ayrıntılı anlatmaları gerçekten ilginçmiş .. haha

kayws426 2022-10-25

Wine çoğunlukla Windows programlarını iyi çalıştırdığına göre, Wine kullanarak çapraz platform bir uygulama geliştirme fikri de mümkün olabilir mi? (yalnızca masaüstü)

ganadist 2022-10-26

Çok eskiden Hancom’un HWP’sinin de Wine tabanlı olarak Linux için port edilip yayımlandığını biliyorum. (R4’e ayrı bir win32 uyumluluk kütüphane katmanı eklenmişti; Wine’ın kullanıldığı sürümün R5 mi yoksa 2002 mi olduğu konusunda ise hafızam bulanık.)
Bu yüzden bir dönem, Wine sayesinde win32’nin en yaygın ve en başarılı çapraz platform API’si olduğu esprisi de yapılırdı.
Ama artık electron/wasm çağı;;

jinseokim 2022-10-25

Biraz farklı bir konu ama, eğer bunu yapacaksanız -- Wine'ın lisansı LGPL olduğu için, kodu nasıl yazdığınıza bağlı olarak kaynak kodunun bir kısmını veya tamamını açıklamak zorunda kalabilirsiniz.

kunggom 2022-10-25

Orijinal metinde de açıklandığı gibi, Wine’ın bir emülatör olmamasının nedeni CPU komutlarını olduğu gibi kullanmasıdır. Bu da Wine ile çalıştırılabilecek yazılımın, temelde x86 ya da x86-64 CPU üzerinde çalışan Windows yazılımları olduğu anlamına gelir.

Apple tüm Mac serisini ARM mimarisine taşımışken ve MS de ARM tabanlı geliştirme kiti sunmuşken, yalnızca x86(-64) tabanlı CPU’larda çalışan yazılımları “çapraz platform desteği” olarak nitelendirmek biraz zor değil mi diye düşünüyorum.

kayws426 2022-10-27

Evet. Dediğiniz gibi... galiba fark etmeden bunu x86 ailesi makinelerle sınırlamışım.

jjpark78 2022-10-25

electron veya tauri varken, eğer en baştan çapraz platform bir şey geliştirmek gerekiyorsa bunun çok iyi bir tercih olmadığı anlaşılıyor.
Web tarayıcısı tabanlı teknolojilerin kullanılamadığı özel kısıtlar varsa,
çapraz derlemeyi iyi destekleyen Qt gibi bir kütüphane kullanmak daha iyi olabilir..

iceflower01 2022-10-25

222