Wine कैसे काम करता है 101

• Wine एक compatibility layer है जो POSIX-संगत OS (Linux, macOS, BSD) पर Windows प्रोग्राम चलाने योग्य बनाती है
  • Valve का Steam Deck भी Wine-आधारित solution इस्तेमाल करता है

WINE = Wine Is Not an Emulator

• emulator तरीका धीमा होता है, और वास्तव में Linux/macOS native रूप से Windows binaries चला सकते हैं (अगर थोड़ी मदद दी जाए)
• debugger के ज़रिये Linux/Windows binaries कैसे काम करती हैं, इसका विस्तार से वर्णन

Hello, Wine!

• मूल रूप से Wine, Windows executable files के लिए एक "Dynamic Loader" है
• यह एक native Linux binary है, और जानता है कि EXE या DLL को कैसे संभालना है
• Wine, Windows executable file को memory में लोड करता है, उसे parse करके dependencies पहचानता है, और फिर जिस code को चलाना है वहाँ jump करता है
• सिर्फ इससे भी Windows binary चल सकती है, लेकिन कुछ exceptions हैं

System Calls

• system calls, जिन्हें syscalls भी कहा जाता है, Wine को जटिल बनाते हैं
• syscalls OS में implement होते हैं, executable या library के अंदर नहीं होते
• OS द्वारा दिए गए syscalls ही OS API होते हैं
  • Linux : read, write, open, brk, getpid,..
  • Windows : NtReadFile, NtCreateProcess, NtCreateMutant,..
• system call, code के सामान्य function call से अलग होता है. उदाहरण के लिए, file open जैसी चीज़ kernel में ही संभाली जानी चाहिए क्योंकि वही File Descriptor को track करता है
• इसलिए application code को खुद को "interrupt" करके kernel को control देने का तरीका चाहिए ("Context Switch")
• OS द्वारा दी जाने वाली functions की सूची और उन्हें call करने का तरीका हर OS में अलग होता है
  • Linux में read() function को call करते समय file descriptor को register %rdi, buffer pointer को %rsi, और पढ़े जाने वाले bytes की संख्या को %rdx में रखना होता है
  • लेकिन Windows में kernel के अंदर read() function होता ही नहीं
• जब एक ही "Hello World!" प्रिंट करने वाला code Linux/Windows पर चलाया जाता है
  • Linux, libc.so के puts को call करता है, जबकि Windows, ucrtbase.dll के printf को call करता है
  • आजकल Linux में static linking आम है, इसलिए puts implementation को binary के अंदर ही शामिल कर दिया जाता है और runtime पर libc.so का इस्तेमाल नहीं होता
• Windows में कम से कम हाल तक "सिर्फ malware ही system calls का सीधे इस्तेमाल करता था"
  • सामान्य applications हमेशा kernel32.dll/kernelbase.dll/ntdll.dll पर निर्भर रहती हैं ताकि वे kernel से सीधे बात न करें

Runtime translation of Syscalls

• अगर syscall को intercept किया जाए तो?
  जब application NtWriteFile() को call करे, उसी समय बीच में आकर write() call किया जाए, और फिर binary जिस format में result चाहता है उसी format में return कर दिया जाए?
• custom version का ucrtbase.dll देकर यह संभव हो सकता है, लेकिन इससे जटिल समस्याएँ पैदा होती हैं
• इसकी जगह binary और kernel के बीच मौजूद ntdll.dll को modify किया जाता है
• Wine के हाल के versions, ntdll.dll (PE binary) और ntdll.so (ELF binary) से बने होते हैं
  • dll एक पतली layer है जो बस calls को ELF side की ओर redirect करती है
  • ELF में __wine_syscall_dispatcher नाम का एक special function होता है, जो current stack को Windows से Linux, या उल्टा, बदलने का जादू करता है
• यही syscall dispatcher Windows की दुनिया और Linux की दुनिया के बीच पुल है
  • यह calling convention संभालता है, stack space allocate करता है, registers को move करता है, वगैरह
  • जब execution ntdll.so तक आकर Linux binary side पर पहुँच जाता है, तब हम सभी Linux API का इस्तेमाल कर सकते हैं

क्या बस इतना ही?

• सुनने में बहुत आसान लगता है, लेकिन...
  • Windows API की संख्या बहुत विशाल है, documentation अच्छी नहीं है, ज्ञात/अज्ञात bugs मौजूद हैं, और उन्हें जैसा है वैसा ही preserve करना पड़ता है. Wine का ज़्यादातर code अलग-अलग Windows DLLs के implementations से बना है
  • syscall को call करने के कई तरीके हैं, और तकनीकी रूप से applications को syscall सीधे call करने से रोकने का कोई तरीका नहीं है
    (याद रखें कि Windows games हर तरह की पागल हरकतें करते हैं)
    Linux kernel में इसे संभालने के लिए special mechanism हैं, और स्वाभाविक रूप से इससे जटिलता और बढ़ती है
  • 32bit vs 64bit का मुद्दा भी बेतुका है. बहुत सारे 32-bit games मौजूद हैं, और उन्हें दोबारा 64-bit में release नहीं किया जाएगा. Wine दोनों को support करता है, इसलिए इससे भी जटिलता बढ़ती है
  • यहाँ wine-server का अभी ज़िक्र भी नहीं किया गया है. यह Wine द्वारा बनाया गया एक अलग process है, जो kernel की "state" (file descriptors, mutexes आदि) को बनाए रखता है
  • अगर games चलाने हैं, तो DirectX, PulseAudio, input devices आदि को भी संभालना पड़ता है, इसलिए काम बहुत बढ़ जाता है
• Wine का विकास लंबे समय से हो रहा है और यह बहुत आगे आ चुका है. आज यह Cyberpunk 2077 और Elden Ring जैसे आधुनिक games को भी बिना समस्या चला सकता है
  कभी-कभी तो Wine, Windows से भी बेहतर performance दिखाता है

[roxie]

कंटेंट तो अच्छा है ही, लेकिन सारांश की क्वालिटी वाकई कमाल की है। धन्यवाद।

[minho2da]

मैं yes24 और Kyobo Book Centre की subscription-based reading services का उपयोग कर रहा हूँ.

घर के PC environment को Ubuntu में बदलने के बाद मैंने Wine का इस्तेमाल करके YES24 और Kyobo Book Centre चलाने की कोशिश की.

दोनों अलग-अलग DRM इस्तेमाल करते हैं, इसलिए सोचा था कि शायद चलेंगे या नहीं, लेकिन YES24, जो मेरी जानकारी में QT से बना है, अच्छी तरह चल गया, जबकि Kyobo Book Centre EBOOK नहीं चला. (UI चला, DRM नहीं चला)

मुझे पता है कि दोनों पर DRM लागू है, इसलिए मैं सोच रहा था कि किस वजह से एक चलता है और दूसरा नहीं, लेकिन ऊपर का लेख देखकर लगता है कि अब लगभग समझ आ रहा है (वही वाला 'मैंने पूरी तरह समझ लिया' वाला meme).

[bbulbum]

wine5.0 के बाद से KakaoTalk बिना किसी सेटिंग के चल जाता है, इससे खुशी होती है। (हालाँकि KakaoTalk इस्तेमाल करना चाहता हूँ, ऐसा भी नहीं है..)
कुछ स्क्रीन डिस्प्ले में थोड़ी दिक्कत है, लेकिन clipboard image भेजने जैसी सुविधाएँ seamless तरीके से काम करती हैं।
लगता है कि Wine ज़्यादातर गेम चलाने पर फोकस कर रहा है, लेकिन यह तरह-तरह के apps भी अच्छी तरह चला देता है, यह अच्छी बात है।
सरकारी संस्थानों में Linux अपनाने की बात आती है, तब भी Linux version का KakaoTalk बनाने का खयाल तक नहीं करते, यह सच में काफ़ी खराब लगता है..
Mac version तो झटपट बना दिया था..

[bbulbum]

मुझे मोटे तौर पर पता था, लेकिन इस तरह इतनी विस्तार से Wine को समझाया गया है, यह काफ़ी दिलचस्प लगा .. हाहा

[kayws426]

कुल मिलाकर Wine Windows प्रोग्राम अच्छी तरह चला देता है, तो क्या Wine का इस्तेमाल करके cross-platform app बनाने की भी कल्पना की जा सकती है? (सिर्फ desktop तक सीमित)

[ganadist]

बहुत पहले, मुझे पता है कि Hancom का HWP भी Wine-आधारित तरीके से Linux के लिए port करके जारी किया गया था। (R4 में अलग win32 compatibility library layer थी, और Wine का इस्तेमाल R5 में था या 2002 में, यह थोड़ा धुंधला याद है।)
इसलिए, एक समय ऐसा भी था जब Wine की वजह से यह मज़ाक चलता था कि win32 सबसे लोकप्रिय और सबसे सफल cross-platform API है।
लेकिन अब Electron/wasm का ज़माना है;;

[jinseokim]

यह थोड़ा अलग मुद्दा है, लेकिन अगर आप ऐसा करना चाहते हैं -- Wine का लाइसेंस LGPL है, इसलिए कोड कैसे लिखा गया है उस पर निर्भर करते हुए आपको source code का कुछ हिस्सा या पूरा source code सार्वजनिक करना पड़ सकता है।

[kunggom]

जैसा कि मूल लेख में भी समझाया गया है, Wine emulator नहीं है क्योंकि यह CPU instructions को ज्यों का त्यों इस्तेमाल करता है। इसका मतलब यह है कि Wine पर चल सकने वाला software मूल रूप से x86 या x86-64 CPU पर चलने वाला Windows software होता है.

ऐसे समय में, जब Apple पूरे Mac ecosystem को ARM architecture पर शिफ्ट कर चुका है और MS भी ARM-based development kit पेश कर रहा है, x86(-64)-based CPU पर ही चलने वाले software को “cross-platform support” कहना शायद थोड़ा मुश्किल लगता है।

[kayws426]

हाँ। जैसा आपने कहा... लगता है कि मैंने भी अनजाने में इसे x86 सीरीज़ मशीनों तक सीमित कर दिया था।

[jjpark78]

चूँकि electron या tauri मौजूद हैं, इसलिए अगर शुरुआत से cross-platform बनाना हो तो यह शायद कोई अच्छा विकल्प नहीं लगता।
अगर web browser-आधारित तकनीकें इस्तेमाल नहीं की जा सकतीं, ऐसी कोई खास बाधा हो,
तो शायद Qt जैसी library का इस्तेमाल बेहतर हो सकता है, जो cross-compiling को अच्छी तरह support करती है..

[iceflower01]

222