Bagaimana Wine Bekerja 101

• Wine adalah lapisan kompatibilitas yang memungkinkan program Windows berjalan di OS yang kompatibel dengan POSIX (Linux, macOS, BSD)
  • Steam Deck dari Valve juga menggunakan solusi berbasis Wine

WINE = Wine Is Not an Emulator

• Pendekatan emulator lambat, dan sebenarnya Linux/macOS dapat menjalankan biner Windows secara native (jika sedikit dibantu)
• Penjelasan rinci tentang bagaimana biner Linux/Windows bekerja melalui debugger

Hello, Wine!

• Pada dasarnya, Wine adalah "Dynamic Loader" untuk executable Windows
• Ia adalah biner Linux native dan tahu cara menangani EXE maupun DLL
• Wine memuat executable Windows ke memori, lalu mem-parsing-nya untuk mengetahui dependensi, dan melompat ke kode yang harus dijalankan
• Hanya dengan ini saja biner Windows pada dasarnya sudah bisa dijalankan, tetapi ada pengecualian

System Calls

• system call, atau syscall, adalah hal yang membuat Wine menjadi rumit
• syscall diimplementasikan oleh OS, bukan berada di dalam executable atau library
• syscall yang disediakan OS adalah API OS
  • Linux: read, write, open, brk, getpid,..
  • Windows: NtReadFile, NtCreateProcess, NtCreateMutant,..
• System call berbeda dari pemanggilan fungsi biasa di dalam kode. Misalnya, membuka file harus ditangani kernel karena perlu melacak file descriptor
• Karena itu, kode aplikasi membutuhkan cara untuk melakukan "interrupt" sendiri dan menyerahkan kontrol ke kernel ("Context Switch")
• Kumpulan fungsi dan cara pemanggilannya yang disediakan OS berbeda-beda untuk tiap OS
  • Di Linux, saat memanggil fungsi read(), file descriptor harus ditempatkan di register %rdi, pointer buffer di %rsi, dan jumlah byte yang akan dibaca di %rdx
  • Namun di Windows, tidak ada fungsi read() di kernel
• Jika kode yang sama untuk mencetak "Hello World!" dijalankan di Linux/Windows
  • Linux memanggil puts dari libc.so, sedangkan Windows memanggil printf dari ucrtbase.dll
  • Di Linux modern, biasanya ini di-link statis sehingga implementasi puts disertakan di dalam biner dan libc.so tidak dipakai saat runtime
• Di Windows, setidaknya sampai beberapa waktu lalu, "hanya malware yang menggunakan system call secara langsung"
  • Aplikasi biasa selalu bergantung pada kernel32.dll/kernelbase.dll/ntdll.dll agar tidak berkomunikasi langsung dengan kernel

Runtime translation of Syscalls

• Bagaimana jika syscall diintersep?
  Saat aplikasi memanggil NtWriteFile(), bagaimana jika kita menyela, memanggil write(), lalu mengembalikan hasilnya dalam format yang diinginkan biner?
• Ini mungkin jika kita menyediakan versi kustom dari ucrtbase.dll, tetapi akan menimbulkan masalah yang rumit
• Sebagai gantinya, yang dimodifikasi adalah ntdll.dll yang berada di antara biner dan kernel
• Versi Wine terbaru terdiri dari ntdll.dll (biner PE) dan ntdll.so (biner ELF)
  • DLL adalah lapisan tipis yang hanya mengalihkan panggilan ke sisi ELF
  • ELF memiliki fungsi khusus bernama __wine_syscall_dispatcher, yang melakukan keajaiban mengubah stack saat ini dari Windows ke Linux, atau sebaliknya
• syscall dispatcher ini adalah jembatan yang menghubungkan dunia Windows dan dunia Linux
  • Ia menangani calling convention, mengalokasikan ruang stack, memindahkan register, dan sebagainya
  • Setelah eksekusi masuk ke ntdll.so dan berpindah ke biner Linux, kita dapat menggunakan semua API Linux

Apakah hanya itu?

• Kedengarannya sangat mudah, tetapi..
  • API Windows jumlahnya sangat banyak, tidak terdokumentasi dengan baik, memiliki bug yang diketahui/tidak diketahui, dan semuanya harus dipertahankan apa adanya. Sebagian besar kode Wine adalah implementasi dari berbagai DLL Windows
  • Ada berbagai cara untuk memanggil syscall, dan secara teknis tidak ada cara untuk mencegah aplikasi memanggil syscall secara langsung
    (ingat bahwa game Windows melakukan segala macam hal gila)
    Kernel Linux punya mekanisme khusus untuk menangani ini, dan tentu saja hal itu menambah kompleksitas
  • Masalah 32bit vs 64bit juga absurd. Ada sangat banyak game 32-bit, dan mereka tidak akan dirilis ulang lagi dalam versi 64-bit. Wine mendukung keduanya, jadi ini juga menambah kompleksitas
  • wine-server bahkan belum dibahas. Ini adalah proses terpisah yang dibuat Wine untuk mempertahankan "state" kernel (file descriptor, mutex, dan sebagainya)
  • Ingin menjalankan game? Anda harus menangani DirectX, PulseAudio, perangkat input, dan banyak lagi, jadi pekerjaannya sangat besar
• Wine telah dikembangkan sejak lama dan sudah menempuh perjalanan jauh. Saat ini, game modern seperti Cyberpunk 2077 atau Elden Ring dapat dijalankan tanpa masalah
  Bahkan terkadang Wine dapat menunjukkan performa yang lebih baik daripada Windows

[roxie]

Selain isinya, kualitas ringkasannya juga benar-benar luar biasa. Terima kasih.

[minho2da]

Saya menggunakan yes24 dan Kyobo Book Centre yang menyediakan layanan membaca berbasis langganan.

Setelah mengubah lingkungan PC rumah saya ke Ubuntu, saya mencoba menjalankan YES24 dan Kyobo Book Centre dengan Wine.

Keduanya memakai DRM terpisah, jadi saya sempat bertanya-tanya apakah bisa dijalankan. Namun YES24, yang saya tahu dibuat dengan QT, berjalan dengan baik, sedangkan EBOOK Kyobo Book Centre tidak bisa dijalankan. (UI berjalan, DRM tidak berjalan)

Saya tahu keduanya sama-sama memakai DRM, jadi saya sempat berpikir apa yang membuat yang satu bisa berjalan dan yang satu lagi tidak. Tapi setelah melihat tulisan di atas, rasanya saya jadi kurang lebih paham (meme "aku benar-benar paham" secara garis besar)

[bbulbum]

Sejak wine5.0, KakaoTalk bisa berjalan tanpa pengaturan apa pun, jadi saya senang. (Terlepas dari saya sebenarnya tidak ingin memakai KakaoTalk..)
Memang ada beberapa masalah pada tampilan layar, tetapi fitur seperti pengiriman gambar lewat clipboard bekerja dengan mulus.
Sepertinya Wine pada umumnya fokus pada menjalankan game, tetapi saya suka karena berbagai aplikasi juga bisa dijalankan dengan baik.
Meski ada pembicaraan tentang penerapan Linux di lembaga publik, mereka bahkan tidak terpikir membuat KakaoTalk versi Linux, itu agak... sangat mengecewakan..
Versi Mac malah dibuat dengan cepat..

[bbulbum]

Saya kira saya sudah tahu garis besarnya, tapi menarik juga melihat penjelasan tentang Wine sedetail ini .. wkwk

[kayws426]

Karena Wine umumnya bisa menjalankan program Windows dengan baik, apakah mungkin juga membayangkan membuat aplikasi lintas platform menggunakan Wine? (khusus desktop)

[ganadist]

Seingat saya, pada zaman dulu HWP dari Hancom juga pernah di-porting dan dirilis untuk Linux berbasis Wine. (R4 memakai layer library kompatibilitas win32 terpisah, dan saya agak lupa apakah yang memakai Wine itu R5 atau 2002.)
Karena itu, pada satu masa sempat ada candaan bahwa berkat Wine, win32 adalah API lintas platform yang paling populer dan paling sukses.
Tapi sekarang sudah zamannya electron/wasm;;

[jinseokim]

Ini sedikit cerita yang berbeda, tetapi jika Anda ingin melakukannya seperti itu -- karena lisensi Wine adalah LGPL, bergantung pada cara Anda menulis kodenya, Anda mungkin harus membuka sebagian atau seluruh kode sumber.

[kunggom]

Seperti dijelaskan juga di artikel aslinya, alasan Wine bukan emulator adalah karena ia menggunakan instruksi CPU apa adanya. Artinya, perangkat lunak yang pada dasarnya bisa dijalankan dengan Wine adalah perangkat lunak Windows yang berjalan di CPU x86 atau x86-64.

Pada titik saat ini, ketika Apple sudah memindahkan seluruh lini Mac ke arsitektur ARM dan Microsoft juga telah merilis kit pengembangan berbasis ARM, rasanya agak sulit menyebut perangkat lunak yang hanya berjalan di CPU berbasis x86(-64) sebagai “dukungan lintas platform”.

[kayws426]

Ya. Benar seperti yang Anda katakan... sepertinya tanpa sadar saya membatasinya hanya pada mesin keluarga x86.

[jjpark78]

Karena ada Electron atau Tauri, sepertinya ini bukan pilihan yang bagus jika harus membuat sesuatu yang lintas platform dari awal. Jika ada kendala khusus yang membuat teknologi berbasis web browser tidak bisa digunakan, mungkin akan lebih baik memakai library seperti Qt yang mendukung cross-compiling dengan baik..

[iceflower01]

222