Wine 11 ने kernel स्तर पर Linux में Windows गेम चलाने के तरीके को फिर से लिखा, बड़े पैमाने पर performance gains हासिल किए

• Linux में Windows गेम चलाने की संरचना को kernel स्तर पर पूरी तरह फिर से डिज़ाइन किया गया, जिससे पुराने wineserver-आधारित synchronization bottleneck हट गए
• नया NTSYNC driver NT synchronization objects को सीधे kernel में संभालता है, और अधिकतम 8 गुना से भी ज़्यादा FPS सुधार दर्ज किया गया
• WoW64 पूरा होने से 64-bit Linux पर अब 32-bit Windows apps को अलग libraries के बिना चलाया जा सकता है
• Wayland driver को मज़बूत किया गया, Vulkan 1.4 support, Bluetooth·Force feedback improvements सहित graphics और input/output compatibility का दायरा बढ़ा
• Proton, SteamOS, Lutris जैसे पूरे Wine-आधारित ecosystem में performance और stability improvements का असर फैल रहा है

---

Wine 11 के मुख्य बदलाव

• Wine 11** सिर्फ एक साधारण वार्षिक अपडेट नहीं है, बल्कि** Linux में Windows गेम चलाने के तरीके को kernel स्तर पर फिर से लिखने वाला बड़ा पुनर्गठन संस्करण है

  • कई वर्षों से जमा bug fixes और performance improvements के अलावा NTSYNC support, WoW64 completion, Wayland driver enhancements जैसे संरचनात्मक बदलाव शामिल हैं
  • Proton, SteamOS जैसे Wine-आधारित प्रोजेक्ट्स में performance gains का असर फैल रहा है

पुरानी सीमाएँ और अस्थायी उपाय

• पहले Wine, Windows के NT synchronization primitives (mutex, semaphore, event आदि) को Linux पर पूरी तरह लागू नहीं कर पाता था
  • threads के बीच synchronization के लिए हर बार wineserver को RPC call करनी पड़ती थी, और प्रति सेकंड हज़ारों calls frame delay और अनियमित timing पैदा करती थीं
• Esync ने eventfd का उपयोग कर wineserver calls कम कीं, लेकिन file descriptor limit की समस्या आई
• Fsync futex-आधारित होने के कारण अधिक तेज़ था, लेकिन kernel के बाहर patch की ज़रूरत पड़ती थी, इसलिए सामान्य distributions में इसका उपयोग कठिन था
  • Linux 5.16 का futex_waitv, Fsync के मूल रूप से अलग है और उसका पूरा विकल्प नहीं है
• दोनों तरीके अस्थायी समाधान ही थे, और कुछ NT APIs (जैसे NtPulseEvent, NtWaitForMultipleObjects का wait-for-all mode) को सटीक रूप से लागू नहीं किया जा सकता था

NTSYNC — kernel स्तर पर synchronization का पुनर्रचना

• NTSYNC Linux kernel में नया /dev/ntsync device driver जोड़ता है, जो Windows NT synchronization objects को सीधे मॉडल करता है
  • synchronization अब user space की बजाय सीधे kernel के भीतर संभाला जाता है, जिससे wineserver round-trip calls हट जाती हैं
  • queue management, event semantics और atomic operations सभी kernel सीधे संभालता है
• इसे Esync और Fsync बनाने वाली Elizabeth Figura ने विकसित किया, 2023 Linux Plumbers Conference में प्रस्तुत किया गया और बाद में Linux 6.14 में merge हुआ

• performance improvement के आँकड़े

  • Dirt 3: 110.6 → 860.7 FPS (678% improvement)
  • 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 अब पूरी तरह playable है

• fsync की तुलना में अंतर

  • fsync users के लिए सुधार सीमित हो सकता है, लेकिन जिन games में multithreaded bottleneck था उनमें नाटकीय सुधार दिखता है
  • mainline kernel में शामिल होने से अलग patch की ज़रूरत नहीं, Fedora 42·Ubuntu 25.04 जैसी नई distributions में तुरंत उपयोग संभव
  • SteamOS 3.7.20 beta में यह default रूप से शामिल है, और Proton GE में भी सक्रिय है
  • NTSYNC, Wine के इतिहास में पहली बार kernel स्तर पर सटीक synchronization implementation हासिल करने का उदाहरण है

WoW64 पूरा — 32-bit compatibility का एकीकरण

• WoW64(Windows 32-bit on Windows 64-bit) architecture implementation Wine 11 में पूरा हुआ
  • 64-bit Linux systems पर 32-bit Windows apps चलाने के लिए अब अलग 32-bit libraries install करने की ज़रूरत नहीं
  • एक single binary executable की bitness को अपने-आप पहचानकर संभाल लेती है
• इसमें OpenGL memory mapping, SCSI passthrough, और 16-bit application support भी शामिल है
  • यानी 1990 के दशक के पुराने Windows software भी चलाए जा सकते हैं
• पहले distributions के multilib configuration differences के कारण चलाना कठिन था, लेकिन अब Wine इसे अंदरूनी रूप से संभालता है

Wayland और अन्य प्रमुख सुधार

• Wayland driver

  • clipboard के लिए दो-तरफ़ा copy, drag and drop support, और resolution switching के समय compositor scaling से पुराने games की compatibility बेहतर हुई
  • X11 से Wayland में शिफ्ट होने पर Wine compatibility की ज़्यादातर समस्याएँ दूर हो गईं

• graphics और media

  • X11 पर EGL अब OpenGL का default backend है, जिसने GLX को replace किया
  • Vulkan 1.4 support, और Vulkan Video-आधारित H.264 hardware-accelerated decoding जोड़ी गई

• input/output और peripherals

  • Force feedback सुधार से racing wheel और flight stick support बेहतर हुआ

  • Bluetooth BLE services और pairing support**,** MIDI soundfont processing में सुधार

    • Zip64 compression, Unicode 17.0.0, TWAIN 2.0 scanning(64-bit), IPv6 ping features जोड़े गए

• performance और platform विस्तार

  • Linux·macOS पर thread priority management में सुधार से multithread performance बेहतर हुई
  • ARM64 पर 4K page size simulation support जोड़ी गई, जिससे ARM-आधारित Linux devices के साथ compatibility मिली

game compatibility और bug fixes

• Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI, Battle.net जैसे प्रमुख titles की compatibility बेहतर हुई
• सैकड़ों bug fixes शामिल हैं, जिससे overall stability और performance में सुधार हुआ

समग्र मूल्यांकन

• NTSYNC, WoW64 completion, Wayland improvements, और large-scale bug fixes के संयोजन के साथ Wine 11, Proton के बाद की सबसे महत्वपूर्ण release है
• Proton, Lutris, Bottles जैसे सभी Wine-आधारित projects की performance और compatibility बेहतर होती है
• Linux पर gaming करने वालों के लिए Wine 11 एक ऐसा version है जिसे ज़रूर आज़माना चाहिए

[kh0324]

निष्कर्ष तो यही निकलेगा कि फिर से कई साल पुराने गेम खेलने पड़ेंगे, और backward compatibility भी टूट जाएगी..

लगता है यह कोई trade-off है

[GN⁺]

Hacker News की राय

• मुझे Wine प्रोजेक्ट के लिए लगभग असीम सम्मान है
  30 साल तक Windows के documented/undocumented व्यवहार को ज्यों का त्यों दोहराने की कोशिश करना उबाऊ और कम इनाम वाला काम लगता है, लेकिन इसी वजह से Wine सचमुच उपयोगी प्रोडक्ट बना है
  खासकर जब पुराने गेम Windows से भी बेहतर चलते दिखते हैं, तो उसकी बारीकी और दर्द सहने की क्षमता कमाल की लगती है

  • पहले मुझे लगता था कि Wine ठीक से काम कर ही नहीं सकता, इसलिए मैं Linux पर गेमिंग से बचता था
    कभी-कभी कोई साधारण गेम चलाकर लगता था, “अरे, यह तो चल गया?”, लेकिन मुझे नहीं लगता था कि इस पर भरोसा किया जा सकता है
    अब मानता हूँ कि वह आकलन पूरी तरह गलत था
  • इतने शानदार प्रोजेक्ट के बावजूद, Word, Excel, Outlook जैसे business apps अब भी अच्छी तरह नहीं चलते, यह अफसोस की बात है
    कहा जाता है कि Excel 2010 आखिरी version था जिसे Platinum grade मिला था
    यह दिलचस्प है कि गेम्स की तुलना में ऐसे apps ज़्यादा कठिन क्यों हैं
  • Wine कई platforms पर compatibility tests अपने-आप चलाता है
    test results page देखने पर समझ आता है कि ऐसी व्यवस्थित जांच ही ऊँची compatibility की कुंजी है
  • ReactOS का ज़िक्र भी बनता है
    उस प्रोजेक्ट से मिली बहुत-सी जानकारी Wine development में आई है
  • 90 के दशक में जब मैं OS/2 इस्तेमाल करता था, तब Windows apps चलाने के लिए पूरा Windows boot करना पड़ता था
    उस समय मैं Wine जैसा कुछ खुद बनाना चाहता था, लेकिन मेरे पास पर्याप्त जानकारी नहीं थी
    अब मैं Linux सिर्फ server के लिए इस्तेमाल करता हूँ, इसलिए इसकी ज़रूरत नहीं पड़ती, और सुना है Mac के लिए भी Wine है, लेकिन कोई ऐसा Windows app नहीं है जिसे मैं खास तौर पर चलाना चाहूँ

• Proton की वजह से गेम frame rates में इतना बड़ा उछाल देखकर हैरानी हुई
  Dirt 3 का 110FPS से 860FPS और Resident Evil 2 का 26FPS से 77FPS जाना यकीन करना मुश्किल है
  लगता है Valve ने इसमें खूब पैसा लगाया है

  • हालांकि ये आँकड़े Wine+ntsync और Wine के basic version की तुलना के हैं, इसलिए इनमें कुछ बढ़ा-चढ़ाकर दिखने वाली बात है
    मौजूदा fsync-आधारित Wine से तुलना करें तो सुधार सिर्फ कुछ प्रतिशत का है
    फिर भी ntsync साफ़ तौर पर एक सुधार है
    ntsync docs देखें तो यह Linux पर Windows की synchronization संरचना को अधिक सटीक ढंग से लागू करने के लिए kernel driver है
  • यह भी ध्यान रखना चाहिए कि तुलना “जब esync या fsync इस्तेमाल न किया गया हो” उससे की गई है
  • Proton और Wine का रिश्ता क्या है, यह जानने की जिज्ञासा है — Proton क्या Valve/SteamOS के लिए नाम है, या अलग प्रोजेक्ट है?

• कुछ लोगों की राय है कि ntsync performance gains को लेकर ज़्यादा उत्साहित नहीं होना चाहिए
  ज़्यादातर मामलों में performance improvement single-digit percent तक ही है, और कुछ गेम्स में उल्टा थोड़ा slowdown भी हो सकता है

  • अगर कोई fsync patch के बिना kernel चला रहा हो, तो बात अलग हो सकती है
  • Wayland और X11 के performance difference की तुलना भी दिलचस्प होगी

• ऐसी low-level तकनीकी बातें देखकर कभी-कभी शर्म आती है कि मैं तो सिर्फ CRUD apps बनाता हूँ

  • लेकिन CRUD भी मूल्यवान है, और मानसिक स्वास्थ्य के लिए अच्छा है
    मैंने एक किस्सा सुना था कि एक प्रतिभाशाली developer बेहद कठिन deadlines से टूटकर आखिरकार साधारण VB CRUD काम में चला गया और उसे “paid vacation” जैसा बताया
  • मैं भी Outlook में “यहाँ क्लिक करो, वहाँ क्लिक करो” जैसे साधारण कामों में मदद करता हूँ, लेकिन यह भी ज़रूरी काम है
  • दूसरी तरफ, low-level developers भी high-level systems संभालते समय खुद को कमतर महसूस करते हैं
  • मैं compiler बनाता हूँ, फिर भी personal projects के लिए CRUD app कई बार बनाने की कोशिश करके असफल हुआ हूँ
    Rails, Phoenix, Django सब आज़मा चुका हूँ, लेकिन आसान नहीं था
    हाल में Claude की मदद से थोड़ी प्रगति हुई है
  • CRUD apps भी आसान नहीं होते
    enterprise requirements इतने जटिल होते हैं कि architecture आसानी से टूट सकती है

• यह जानकर खुशी हुई कि मैंने Valve पर जो हज़ारों डॉलर खर्च किए, वे आखिरकार Wine को बेहतर बनाने में लगे
  जानना चाहूँगा कि Valve ने इसके लिए कितने developers और contractors रखे हैं

  • Wine developers के लगभग दो-तिहाई CodeWeavers से जुड़े हैं, और उनका Valve तथा Proton के साथ contract है
    यानी ज़्यादातर funding उधर जाती है

• विडंबना यह है कि Wine शायद आत्म-विनाशकारी भी हो सकता है
  अगर Linux पर गेम्स बहुत अच्छे चलने लगें, तो developers शायद सीधे Linux port बना देंगे और Wine की ज़रूरत नहीं रहेगी

  • लेकिन Wine का API Linux की तुलना में ज़्यादा स्थिर है, इसलिए संभव है कि वही first-class target बन जाए
  • मुझे लगता है कि हक़ीक़त उलटी है
    native port होने पर भी Windows version को Proton से चलाना ज़्यादा स्थिर होता है
    Windows API परिचित है और बदलता नहीं, इसलिए developers उसी को आधार बनाकर काम करते रहते हैं
  • आजकल “Linux support” का मतलब अक्सर Proton पर अच्छी तरह चलना होता है
  • मुझे यह “अच्छी समस्या” लगती है
  • और Wine का उपयोग सिर्फ गेम्स तक सीमित नहीं है, इसलिए native ports बढ़ने पर भी इसकी मांग बनी रहेगी
    Windows ABI अब भी ज़्यादा स्थिर है, इसलिए जब तक performance difference मामूली है, सिर्फ Windows build बनाए रखना अधिक व्यावहारिक है

• किसी ने पूछा कि क्या user space में shared memory से ntsync लागू नहीं किया जा सकता
  Claude ने समझाया कि “95% गेम्स के लिए साधारण तरीका काफी था, इसलिए जटिल shared-memory logic लागू करने की प्रेरणा नहीं थी, और जब accuracy महत्वपूर्ण हुई तो उसे kernel में डालना स्वाभाविक था”

  • लेकिन वास्तव में यह संभव नहीं है, क्योंकि Linux ऐसी user-space functionality देता ही नहीं
    ntsync सिर्फ साधारण API wrapper नहीं, बल्कि NT kernel के synchronization व्यवहार को दोहराने वाला kernel-level adapter है
    source code देखने पर पता चलता है कि यह kernel scheduler के साथ काफ़ी गहराई से जुड़ा है
  • kernel docs में भी साफ लिखा है कि “user-space implementation से Windows-स्तर की performance और accuracy हासिल नहीं की जा सकती”
    docs link

• Linux को Windows को दोबारा लागू करते हुए उससे भी बेहतर करते देखना हैरान करता है
  जब Microsoft अपना ही software लगातार ज़्यादा असुविधाजनक बनाता जा रहा है, तब यह उपलब्धि और भी प्रभावशाली लगती है

  • खासकर यह कि Wine ने 64-bit Windows में गायब हो चुके 16-bit support को बनाए रखा है, बहुत महत्वपूर्ण है
    कई पुराने गेम्स 16-bit आधारित हैं, और कई 32-bit गेम्स के installer भी 16-bit होते हैं

• अगर कोई Wine developer यह पढ़ रहा हो, तो उम्मीद है कि वह Carolina Code Conference 2026 में इस पर talk देगा
  speakers के लिए आवेदन 31 मार्च तक खुले हैं

• अगर आप macOS पर भी यही चाहते हैं, तो इस repository में योगदान दे सकते हैं

  • लेकिन सच कहें तो MacOS के लिए गेम्स बहुत कम हैं, इसलिए शायद इसमें दिलचस्पी रखने वाले developers भी बहुत कम होंगे
    स्कूल के Mac पर Bolo tank game खेलने की याद ज़रूर है, लेकिन संख्या शायद Windows games की 1% भी नहीं होगी
  • लेकिन अगर performance कारणों से इसे kernel में डालना पड़ा, तो फिर Linux में इसे user space में क्यों नहीं किया गया — यह सवाल अब भी दिलचस्प है