Wine 9.0 met experimentele Wayland-driver en nieuwe WoW64-modus is uit

Wine 9.0 is uit. De niet-emulator voor Linux telt meer dan 7000 wijzigingen ten opzichte van de grote release van een jaar geleden. Een van de grootste veranderingen is een experimentele driver voor displayserver Wayland en WoW64-ondersteuning.

Wine 9.0 is de grootste nieuwe release sinds Wine 8.0, dat een jaar geleden uitkwam. De makers schrijven in de releasenotes dat de tool meer dan 7000 kleine veranderingen bevat. Een belangrijke daarvan is dat Wine 9 een experimentele Wayland-driver bevat. Die staat niet standaard aan, maar kan via de registry worden ingeschakeld. De ontwikkelaars zeggen nog verder te werken aan de displayserver, maar de driver ondersteunt op dit moment al vensterbeheer, meer dan één monitor en dpi-scaling, en heeft ondersteuning voor Vulkan. De toevoeging in Wine is een nieuwe stap in de toenemende adoptie van Wayland, een displaydriver die in steeds meer distro's wordt ondersteund en op termijn drivers als Xorg zou kunnen vervangen.

Nieuw in Wine 9.0 is ook de verbeterde WoW64-modus. In Wine 8.0 werd die modus voor het eerst toegevoegd. Dat maakte het mogelijk om 32bit-applicaties te draaien zonder dat er 32bit-library's nodig zijn. De oude modus had echter de beperking dat die apps altijd in een 32bit-Unix-load draaiden. De makers hebben nu een nieuwe modus toegevoegd waarmee het mogelijk is 32bit-applicaties op een volledig 64bit-besturingssysteem te installeren. Dat is volgens de makers nog geen standaard, maar gebruikers kunnen het handmatig inschakelen. Dat moet werken voor de meeste applicaties, maar de ontwikkelaars waarschuwen dat er ook nog beperkingen aan de experimentele feature zitten.

Andere opvallende verbeteringen binnen Wine 9.0 zijn betere ondersteuning voor Direct3D, waaronder efficiënter energiegebruik en betere ondersteuning van de Vulkan-driver. Wine 9.0 is een stable release.

Reacties (57)

[MulMonkey]

Wederom een goede stap in de goede richting voor Linux. En ook voor Linux gaming. Er worden nu echt veel stappen gezet om Wayland eindelijk de nieuwe standaard te maken.

[lasharor]

Wat is het voordeel van die Wayland driver vergeleken met bestaande drivers?

[nvaert1986]

Wayland is het nieuwe grafische platform (de vervanger van X11). Het is niet een 1:1 vervanger, omdat dit technisch gezien alleen maar een referentie implementatie is. Een aantal van deze referentie van deze implementatie zijn Weston en Sway, maar ook KDE en Gnome hebben hun eigen implementatie.

Het originele / oude platform X11 stamt nog steeds uit 1987 (ontwikkelt door Xerox). Bijna niemand begrijpt de code meer en is erg omslachtig om te beheren en zit vol met beveiligingsgaten. Daarnaast draait dit vaak als root (Administrator) en is dit nooit met beveiliging in acht ontwikkelt. Ook bevat X11 nog steeds veel legacy waarvan er bij sommige stukken niemand goed weet wat het doet of waarom het erin zit. Daarom gaan de grotere bedrijven X11 (X.org) uitfaseren en stoppen met ondersteuning.

Om applicaties op Wayland te draaien, dienen ze daarmee compatible te zijn. Standaard kunnen X11 applicaties niet op Wayland draaien. Daar wordt xwayland als compatibiliteitslaag gebruikt. Dit is echter ook niet ideaal en gaat niet altijd goed (voornamelijk met scaling en font weergave gaat dit nogal eens mis). Door dit native in wayland aan te spreken haal je xwayland (de compatibiliteitslaag) er tussenuit en heb je dus ook minder kans op problemen zoals zonet omschreven. Daarom heeft Wine deze driver ontwikkelt.

Steeds meer applicaties gaan Wayland ondersteuning bieden en dit gaat uiteindelijk de toekomst van de Linux grafische interface worden.

Zo wat duidelijker voor je?

[Hydranet]

Het probleem nu met Wayland is wel dat veel functionaliteit gemist word die wel in X11 zit waar veel mensen of forums and Reddit over klagen. En KDE Plasma, Gnome en tig andere Window Managers lijken nu toch wel allemaal hun eigen implementatie van Wayland te doen waardoor er toch wel verschillen gaan ontstaan wat je op de ene Desktop Environment of Window Manager wel of niet kan.

https://www.youtube.com/watch?v=5bjUJihNY7o
https://www.youtube.com/watch?v=UW3nYiK3nd0
https://www.youtube.com/watch?v=-16wFcJzeH0

En zo lang de Steam client nog geen Native Wayland support(maar via Xwayland gaat) heeft ga ik niet over naar Wayland omdat met een Nvidia kaart wanneer ik Steam open en mijn muis beweeg Steam erg gaat glitchen, daar mee bedoel dat de Steam client af en te verdwijnt wanneer je je muis beweegt.

[Reactie gewijzigd door Hydranet op 22 juli 2024 22:28]

[D0ubleD0uble]

Er is wel meer dat de Steam client mist naast native Wayland, zoals een volledige 64-bit versie, IPv6 ondersteuning (de steam client maakt gebruik van hardcoded IPv4 adressen in plaats van DNS) en Valve lijkt op deze punten geen haast te hebben helaas.

Inmiddels zit al die functionaliteit echt wel in Wayland, alleen HDR en global hotkeys, en dat laatste zit al een tijd in KDE. Wayland is volwassen en het is Nvidia die de boel heeft tegengehouden. Welke distro/driver/DE gebruik je? Toen ik een Nvidia kaart had werkte alles prima onder KDE Wayland, op wat kleine dingetjes na (inmiddels ook gefixt onder Plasma 6)

[Hydranet]

Een 64 bit versie van de Steam client gaat nog wel even duren verwacht ik. Ik gebruik geen KDE Plasma maar Gnome met de 545 driver onder Arch Linux.

[MornixRS]

Exact mijn situatie (Manjaro) en dat werkt perfect onder X11. Ik vrees dat het nog wel een jaar of twee gaat duren voordat Wayland in deze configuratie een serieuze optie wordt.

[nvaert1986]

Het klopt inderdaad dat Wayland bepaalde functionaliteit mist. Zo draait mijn laptop ook nog op X11, simpelweg omdat de NVIDIA grafische drivers niet goed werken met externe schermen op mijn laptop. Dit is een bekende GNOME / KDE bug. Ze zijn er echter wel hard mee bezig deze ontbrekende functionaliteiten aan Wayland toe te voegen. Het protocol heeft inderdaad nog wat gebrekkige kanten.

Desondanks ben ik er van overtuigd dat dit goed komt. Dit zie ik als een soortgelijk debacle dat Microsoft Windows Vista had bij het omschakelen naar WDDM drivers die in het begin zeer veel problemen gaven en er pas in Microsoft Windows 7 met recente drivers allemaal uitgehaald is.

De functionaliteit treft primair (er zijn uitzonderingen) een beperkte groep mensen, welke exotische zaken kunnen gebruiken. De doorsnee gebruiker gaat geen problemen ondervinden met Wayland, zo heb ik een standaard simpel Dell laptopje met Intel CPU en integrated graphics en dit werkt prima onder Wayland. Tevens kan ik op mijn gaming PC (wel met AMD GPU, maar dit werkt meestal beter onder Linux net zoals Intel i.v.m. open source drivers) melden dat Wayland beter werkt dan X11. Dit gaat goedkomen, maar is simpelweg een kwestie van tijd

Daarnaast zijn er ook een aantal functionaliteit die enkel goed werken in Wayland in sommige gevallen (zoals VRR; FreeSync in mijn geval). Dit werkte voor mij totaal niet goed op X11, terwijl ik op Wayland geen problemen ervaar.

Het klopt tevens dat Steam nog geen native Wayland client heeft en via XWayland loopt, zelf heb ik hier echter nog geen problemen mee ervaren.

Tenslotte vind ik wel dat Red Hat / Fedora en Ubuntu erg snel de stekker uit X11 trekken en dat ze hier best nog wel eens een jaar of 2 mee hadden mogen wachten, gezien Wayland echt nog maar net volwassen is en nog een paar jaar ontwikkeld tijd nodig heeft voordat het echt mature is in mijn optiek; De native Wayland driver van Wine is daar een voorbeeld van (welke nog niet af is). Plasma 6 is nog niet uit (momenteel in RC status) waar veel van de huidige beperkingen en problemen in zijn opgelost en zo nog een aantal zaken dat ik het wel echt allemaal korte termijn vind.

[Hydranet]

Ik geloof ook wel dat het goed komt maar er moeten nog een hoop applicaties omgeschreven worden zodat ze Wayland compatible zijn of dat de Wayland alternatieven meer bekend worden qua naam van de tools.

Ik heb een Steam Deck en daar ben ik wel erg blij mee dat, ik voor sommige spellen HDR heb, ik wil misschien ooit nog wel een AMD gpu kopen maar voor mijn PC ik ben verder helemaal tevreden met met Nvidia RTX 3090 gpu. Want nu ook sinds kort werkt is dat wanneer ik via een Gnome wayland sessie ben ingelogd mijn scherm kan delen via Teams, wat voor heen een hele tijd stuk was.

[Reactie gewijzigd door Hydranet op 22 juli 2024 22:28]

[kozue]

Ik snap niet dat mensen Wayland zo volwassen vinden. In de praktijk is het nauwelijks bruikbaar als je iets meer wilt dan een browser en de standaard utilities van je desktop. Ik heb het vorig jaar eens geprobeerd. Ik was klaar met die nvidia driver en had eindelijk de oude Geforce (een 9-serie ofzo? ja, best een oud ding) uit m'n computer gehaald, en ben naar de onboard Intel chip overgestapt. Qua performance in games ontloopt het elkaar niet veel. Maar ik ben ook geen PC gamer. Ik speel voornamelijk op de console en als ik al iets op de PC speel zijn het vooral oude spellen.

Dus toen ik van die nvidia driver af was, kreeg ik van Fedora automatisch een Wayland desktop voorgeschoteld. Ik had nooit expliciet Xorg gekozen, dat kreeg ik automatisch door de legacy binary nvidia driver die Wayland niet ondersteunde. Maar ik had allerlei problemen, die ik me grotendeels niet meer kon herinneren, maar waarvoor ik wel ging duckducken voor een oplossing. Toen kwam ik er achter dat ik op Wayland zat, en dat de oplossing was om gewoon weer Xorg te gaan draaien. Van wat ik me herinner: multi-monitor werkte niet zoals ik het wilde, X11 applicaties hadden een lelijke window decorator (ik hou van consistentie), en volgens mij zelfs applicaties die helemaal niet wilde werken. Het gros van de grafische software is tenslotte X11 gebaseerd en blijft dat voorlopig nog wel even. Dus binnen een dag was ik weer terug op Xorg.

Ik ben niet van plan om het de komende tijd nog eens te proberen. En dat hoeft gelukkig ook niet. Want jouw opmerking dat ze "snel de stekker uit X11 trekken" klopt niet. Iedere distro die ik gebruik heeft gewoon nog X11, die je simpel kunt kiezen vanuit het loginscherm. En die Intel chip bevalt overigens uitstekend, dus ik ben wel blij om van Nvidia af te zijn

[Xander2]

Het originele / oude platform X11 stamt nog steeds uit 1987 (ontwikkelt door Xerox). Bijna niemand begrijpt de code meer en is erg omslachtig om te beheren en zit vol met beveiligingsgaten. Daarnaast draait dit vaak als root (Administrator) en is dit nooit met beveiliging in acht ontwikkelt. Ook bevat X11 nog steeds veel legacy waarvan er bij sommige stukken niemand goed weet wat het doet of waarom het erin zit. Daarom gaan de grotere bedrijven X11 (X.org) uitfaseren en stoppen met ondersteuning.

Dat valt mee, xorg is een aardige verbetering en heeft het pad geeffend naar transitie.

Het ontwerp en protocol van X11 is volledig achterhaald met het idee dat grafische/monitor/input drivers geregeld worden door een display manager gebaseerd op hardware (en software; geen dynamische libraries) uit de jaren 80 (blitting/primitieven), waarvan support wel door het protocol vereist wordt.

Dat laatste, en volledig gebrek van inachtname van 3D hardware wat toen niet bestond, maakt ontwikkeling en optimalisatie enorm complex en tijdrovend.

Het is niet eenvoudig nieuwe hardware features in te passen en alle apparaten moet je zowel in kernel als X11 configureren.

Beetje OT, maar ter aanvulling.

[GhostShinigami]

in heel simpele termen: wayland is nieuw geschreven (ook al weer even geleden) maar het vervangt X.11 dat nog dateerd uit de jaren 90 ofzo, en nog hele slechte code is, die nooit gebouwd is met security enz in gedachte. en steeds lastiger te onderhouden word wegens het zulke oude (en slechte) code is. Dus is daar wayland voor in de plaats gekomen. Maar een groot nieuw systeem dat tussen je pc en je scherm in zit, leverd nogal wat changes overal en voor iedereen (veelal developers) dus de adoptie er van is wat traag.. maar begint nu erg goed op stoom te komen gelukkig

[Superstoned]

Kleine toevoeging. Wayland en X zijn niet alleen een kwestie van 'het was nodig om opnieuw te beginnen omdat de code oud was', al speelde dat een rol. Een tweede, misschien belangrijkere factor, is dat de hardware/software interactie gewoon heel anders is vandaag.

Een simpel voorbeeld. X was ontwikkeld met het idee dat je als applicatie opdrachten geeft om individuele lijntjes en tekst karakters te schrijven. Dus wil je een 1 pixel dikke, horizontale lijn die 50 pixels lang is? Dan zeg je dat tegen X. Die geeft dat dan weer aan de video kaart, want video kaarten hebben 2D acceleratie om lijntjes te tekenen.

Je snapt dat dat voor een 1993-achtige computer interface inderdaad goed werkt. En het gaat ook lekker efficiënt over een netwerk! Maar je tekent er geen mooi half-transparant bubble-knopje met anti-aliased tekst mee. Een moderne video kaart heeft dit 2D gedeelte nog, maar alles gaat in 3D en met pixmaps, waarbij een applicatie direct met de video kaart moet praten om een knopje, tekst en de rest van het venster te renderen, en dit daarna als plaatje aan de display server geeft, die dat dan weer met de andere vensters samenvoegt en weer terug geeft aan de video kaart om te renderen en weer te geven. X is daar totaal niet voor geschreven, het is een compleet andere manier van werken. Wayland heeft niets van dit 'vertel me waar ik een pixel neer moet zetten', die zegt gewoon, "hey, hier heb je toegang tot de video kaart, laat het ff weten als je klaar bent en waar je de pixmap van je venster dan hebt, dan vertel ik de video kaart hoe ie het moet samenvoegen met de rest van de apps".

Dus minder heen en weer kopieren (die pixmap kan in het video kaart geheugen blijven ipv terug naar X op de CPU en dan weer terug naar de GPU) en een veel simpeler protocol, wat het natuurlijk ook veel sneller maakt.

Maar het heeft heel lang geduurd, en dat was niet omdat dit niet werkte, maar omdat een display server VEEL meer doet dan beeld weergeven. Het team wilde eigenlijk af van die andere zaken. Denk aan dingen als tekst weergeven, maar ook communicatie tussen vensters en het klipboard, hoe je screen recording doet, het positioneren van vensters, focus handling etc etc. Het gevolg was dat Wayland veel en veel te simpel was in het begin.

Eigenlijk een tikje jammer, iedereen (KDE, GNOME, etc) moest ontzettend veel zelf doen en synchroniseren met andere teams zodat je kunt kopiëren in een KDE app en plakken in een GNOME app enzo. Dat was niet echt handig, daar die communicatie tussen projecten niet altijd goed werkt - mede omdat ze soms dingen totaal anders willen doen en hun design ideeën niet compatibel zijn. Dus dat vertraagde de implementatie gigantisch. Dat had beter gekund, maar de meeste van deze dingen zijn nu zo'n beetje wel opgelost.

Het is nog steeds zo dat veel meer werk richting de desktop projecten is gepushed, het is allemaal een beetje te 'Linux' gegaan, waarbij niemand echt aan het hele plaatje dacht, maar de Wayland mensen alleen aan Wayland dachten, en elk van de desktops aan hun eigen stukje. Maar goed, we zijn nu wat, 15 jaar bezig, en we komen er langzaam

Al zijn we de netwerk transparantie wel kwijt. Maar dat is ook wel logisch - X deed dat door de 'draw commands' over het netwerk te sturen. Die gebruiken we al jaren niet meer, dus stuurde X tegenwoordig pixmaps over het netwerk - en niet echt efficiënt. De ontwikkelaars vonden dat dat door een aparte tool zou moeten worden gedaan, die er echt voor gebouwd is. Op zich redelijk, maar ja we zijn wel het gemak van bijna-geen-configuratie-nodig netwerk transparantie van apps kwijt. Uncool.

(Ik gebruik zelf Wayland nog steeds niet. Zucht)

EDIT: sorry, dit was geen 'kleine toevoeging' maar een essay.
EDIT2: verhaal liep niet echt, ietsje gefixed, plus iets over netwerk transparantie

[Reactie gewijzigd door Superstoned op 22 juli 2024 22:28]

[Sandor_Clegane]

Het feit dat X11 gewoon over het netwerk werkt maakt X11 fijn om mee te werken.

Xming op je Windows machine en je kan gewoon applicaties starten vanaf je Linux machine zonder dat deze een Xserver hoeft te hebben. Ik vind het nog steeds een stuk eleganter dan andere opties waarbij je een complete desktop over moet nemen.

[Reactie gewijzigd door Sandor_Clegane op 22 juli 2024 22:28]

[Superstoned]

Jup, da's een slachtoffer. Technisch geen gekke beslissing, maar in de praktijk wel erg jammer.

[luxebenen]

Dat kan nog steeds, maar je hebt daar losse software voor nodig: https://gitlab.freedesktop.org/mstoeckl/waypipe/

[Nivve]

Veel diepgaande reacties al, wat ik nooit zou kunnen. Echter voor gebruikers zijn er een aantal heel praktische zaken in Wayland. Voor mij is er eigenlijk 1: Multi-monitor met verschillende refresh rates is op xorg praktisch onmogelijk (als normale user).

Onder Xorg is het niet mogelijk om twee verschillende refresh rates te weergeven, gezien de twee schermen voor Xorg gewoon als een enkel groot scherm met een rare resolutie gezien wordt. Xorg is namelijk nooit ontworpen om met meerdere schermen om te gaan.
Dus gezien mijn tweede scherm 60hz is, wordt mijn eerste scherm ook 60hz, ook al kan deze tot 165hz aan.
Wayland is gemaakt om wel met meerdere schermen om te gaan en dus kan ik vrolijk wel mijn hoofdscherm op 165hz zetten, terwijk mijn tweede scherm 60hz blijft.

Zo zijn er meerdere zaken als HiDPI, HDR, etc, waar Xorg nooit voor gebouwd is en Wayland wel. Al heb ik daar met mijn apparatuur nog geen ervaring mee.

[MacGyverNL]

Dus gezien mijn tweede scherm 60hz is, wordt mijn eerste scherm ook 60hz, ook al kan deze tot 165hz aan.

Huh. That's weird. Ik heb m'n schermen op een AMD-kaart side-by-side in 60Hz en 144Hz draaien. Nou configureer ik die altijd al direct met xrandr, misschien is dat wat je met "praktisch onmogelijk als normale user" bedoelt? Maar 't zou zo simpel moeten zijn als een `--rate` aan de resolutie-selectie van elk scherm meegeven. Ervan uitgaande dat die optie uberhaupt wordt opgepikt, I guess.

[Nivve]

Het is al een tijd geleden dat ik Xorg heb gebruikt. Dus ik heb het voor de zekerheid maar nog eens getest, want wie weet heb ik ongelijk.
Ik test dit overigens op Fedora Gnome (Bazzite) en net als jij met een AMD GPU.

De settings geven idd een optie om refresh rate in te stellen op beide schermen (respectievelijk dus 165 en 60) als ik inlog onder Xorg. Dus qua instellen van de opties heb je gelijk en kan dit gewoon wanneer je Xorg gebruikt.

Echter ik wil volledig zijn, dus ik heb ook even getest of Xorg zich aan de settings houdt. Dus ik ga naar mijn vertrouwde tester toe, testufo.com, want framerate testen is anders zo placebo-gevoelig.
Ik gebruik dan deze test, want het wel of niet kunnen lezen van text is nog een beetje objectief: https://www.testufo.com/f...mpare=2&showfps=1&kiosk=1

Voor beiden test cases hieronder ben ik ingelogd onder Xorg.
In de eerste test staat mijn tweede scherm aangesloten, maar uitgeschakeld in de Display Settings. De ufotest lijkt helemaal correct, waar de 165fps sectie goed te lezen is en de 60fps sectie praktisch onleesbaar.
Voor de tweede test zet ik het tweede scherm weer aan (wederom in de Display Settings) en op het moment dat ik op Apply druk wordt het 165fps gedeelte net zo blurry en onleesbaar als in het 60fps gedeelte variant, alsof beiden op dat moment 60 fps genereren. Verwarrend genoeg zeggen de Display Settings nog steeds 165/60, alsof het systeem zelf niet doorheeft dat dit gebeurd.

Dus ja, in de settings is het prima in te stellen. Maar in de praktijk lijkt het er op mijn systeem op dat het toch echt niet werkt en Xorg zich zal aanpassen naar de laagste van de twee. Dat de settings dit niet correct weergeven is erg verwarrend...

[Reactie gewijzigd door Nivve op 22 juli 2024 22:28]

[MacGyverNL]

Huh, interesting.

Jouw test reproducerend zie ik dat die site (met een framerate van 144 ingesteld) op het 144Hz-scherm een framerate van niet meer dan 65fps bereikt, terwijl mijn scherm (deze ASUS heeft een OSD framerate counter + graph) op 144Hz gedreven wordt. Overigens geeft de site geen refresh rate aan, en zegt ie "UNSUPPORTED: VSYNC is not available on the Linux platform". Maar dat lijkt hij ook allemaal te doen als ik alléén het 144Hz-scherm aan heb staan -- ook dan bereikt hij niet meer dan 65 FPS.

Misschien dat de RX550 waarop deze schermen in Linux draaien gewoon niet sneller kan renderen; het gaat me op het moment even te ver om te rebooten met Xorg op de RX6900XT. Maar ik kan me voorstellen dat de Xorg render speed de lowest common denominator is, terwijl het scherm wel op de gewenste snelheid draait. Wat onwenselijk is, want 60 is geen deler van 144 dus dan heb je bijna per definitie aliasing of stotteren, en kan ik 'm beter op 120 of 60 draaien... Bedankt hiervoor, iets om verder uit te zoeken als ik tijd heb.

Ik ben een oen, ik was vergeten dat ik ook nog een beamer over DisplayPort heb aangesloten en m'n xrandr-commando's schakelden die output niet uit. Ik zie inderdaad hetzelfde als jij: met alle schermen aan is de maximale render speed de lowest common denominator, met alleen het 144Hz-scherm aan rendert ie op 144Hz. Tijd om die op 120Hz te configureren, I guess; of een 3D-game te proberen en te kijken wat dat doet.

In ieder geval duidelijk genoeg dat 't niet simpel is.

[Reactie gewijzigd door MacGyverNL op 22 juli 2024 22:28]

[Nivve]

Ha, dat laatste sluit ik me helemaal bij aan!

Daarom vind ik het zo jammer dat de settings blijkbaar geen indicatie geven dat dit gebeurd, zou al veel debugging schelen.

[Verwijderd]

Het grote voordeel van Wayland is dat de codebase niet 1 grote legacy puinhoop is, en er daardoor sneller en met minder bugs gebouwd kan worden. Daarnaast zijn er wat leuke minor features maar ook enkele minor tekortkomingen.

[kdekker]

Wine is een Windows emulator, dus het kan nooit over (native) Linux gaming gaan, maar op z'n best een meer praktisch gebruik van een Linux systeem, waar je (sommige) Windows games kunt spelen.

Ik snap het gebruik, c.q. de voorkeur voor Linux of afkeer van Windows (of Microsoft), maar heel veel meer bestaansrecht creert Wine niet voor Linux systemen in een zakelijke omgeving als kantoor PC (of laptop). Wine is toch meer leuk voor in de prive sfeer, niet zakelijk. Veel plezier ermee. Wellicht dat ik zelf ook ooit de overstap maak op een Linux systeem, maar op dit moment is dat meer werk dan de (kleine) ergernissen die Windows 10 geeft (en persoonlijk vind ik Windows 11 nog wat onhandiger/meer/diepere menus).

[Remzi1993]

Wine doet niet aan emulatie maar aan vertaling. Het vertaalt Windows besturingssysteem API aanroepen naar Linux besturingssysteem API aanroepen. Je kan het vergelijken met als je bijvoorbeeld naar een bestand moet schrijven dan wordt Windows.schrijf naar Linux.schrijf vertaald (voorbeeld).

Emulatie is wel iets anders.

[Reactie gewijzigd door Remzi1993 op 22 juli 2024 22:28]

[MadEgg]

Hoe is emulatie anders dan? Wine doet zich naar de software voor als Windows. Het implementeert Windows APIs zodat software die op Linux oid kan aanroepen. Het interpreteert Windows binaries die je anders niet eens zou kunnen opstarten.

In mijn boekje is dat wat een emulator doet. Wine is niet een virtuele machine, maar het emuleert Windows door een laag aan te bieden die lijkt op de Windows APIs.

[The Zep Man]

In mijn boekje is dat wat een emulator doet. Wine is niet een virtuele machine, maar het emuleert Windows door een laag aan te bieden die lijkt op de Windows APIs.

Volgens mij is Wine een herimplementatie van Windows API's. Dat maakt het geen emulator, net als dat Vaultwarden server geen emulator is van Bitwarden server.

Ook uitgelegd door WineHQ:

Wine (originally an acronym for "Wine Is Not an Emulator") is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.

Het doel is dus niet om onderdelen van Windows te simuleren, maar enkel om API's beschikbaar te stellen om applicaties gemaakt voor Windows te kunnen draaien. Het enige dat overeenkomt met Windows is de API interface (voor compatibiliteit met applicaties). De code daarachter simuleert niets van Windows, maar doet zijn eigen ding.

Enkel een overeenkomende API-interface (buitenschil) maakt geen emulator. Bij een emulator denk ik aan iets dat van binnen probeert hetzelfde te doen als iets anders. Daar is bij Wine geen sprake van.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 22:28]

[kdekker]

Dat doet iedere emulator ook ;-). Gekkigheid: dit lijkt meer op een semantische discussie.
En uiteraard: in de open source gemeenschap zijn er wel meer grapjannussen: v.g.l. yacc en bison (allebei grote runderen). Ik kan die grappen wel waarderen en twijfel een beetje of de naam Wine niet een grap uit dezelfde categorie is.

Effectief is het verschil van een communicatielaag die iets omzet en een emulator natuurlijk ongeveer nul. Beide doen runtime iets omzetten.

Overigens noemde HPE Aries een emulatie laag om PA-RISC binaries op een Itanium chip op HP-UX te draaien. Zoiets lijkt me vrij goed te vergelijken met Wine. Kenmerk ook: het kost extra PK's t.o.v. native draaien (op Windows in dit geval). En ook die kosten van PKs is waar voor Wine. Ik heb er verder geen moeite mee dat Wine zichzelf geen emulator noemt. Het gedraagt zich zo, het ziet er uit alsof, en we noemen het iets anders.

[Reactie gewijzigd door kdekker op 22 juli 2024 22:28]

[koboy]

En hier zit dus de misvatting: het draaien van Windows applicaties met wine kost geen pk's. Door de bank genomen draaien Windows applicaties met zo snel met wine als met Windows als besturingssysteem.

Kenmerk van een emulator is dat er hardware wordt nagedaan. Dosemu kan bijvoorbeeld een hele rits grafische kaarten en geluidskaarten nadoen, en emuleert ook de CPU. Dit kost (om in jouw termen te blijven) pk's.
Wat het wine team heeft gedaan is de dll's opnieuw schrijven zodat die niet de Windows drivers aanspreken maar de Linux drivers. Hierdoor is het ook zo snel. Tegenwoordig is deze klus dusdanig compleet dat alleen heel specifieke stukken Windows code niet meer werken, en dan moet je vooral denken aan de anti cheat en rootkit achtige zaken.

[TheVivaldi]

En hier zit dus de misvatting: het draaien van Windows applicaties met wine kost geen pk's. Door de bank genomen draaien Windows applicaties met zo snel met wine als met Windows als besturingssysteem.

Klopt. Ik draai al jaren één programma onder Wine (ook steeds weer een nieuwe versie ervan) en de snelheid is top. Alleen bij een koude start (dus als de computer een keer opnieuw opgestart is geweest) is het opstarten van het programma ietsje trager dan op Windows/als het native was geweest, maar niet dusdanig traag dat het hinderlijk is (oftewel: niet traag genoeg om tussendoor koffie te kunnen zetten ). En eenmaal opgestart zijn de prestaties top en bij een warme start start ie supersnel op.

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 22:28]

[kdekker]

Ok, emulatie = hardware emulatie en dit is dan wat anders om windows API spul te vervangen. Ik volg je.
Overigens: het kost wel degelijk PKs, omdat elke CPU instructie PK's kost. Alleen weet je niet of het meer of minder PK's zijn dan op Windows zelf met een andere onderliggende API.

Maar al met al is de discussie toch een beetje semantisch: Windows heeft ook een HAL achtige laag (bijvoorbeeld DirectX, maar ook andere zaken) om de GUI te presenteren (en andere Windows specifieke dingen als registry, MSI databases, (roaming) user profiles etc). Microsoft schrijft hardware fabriakenten bepaalde dingen voor (driver model oid), wat Linux op een andere manier doet en Wine voor je 'vertaalt' naar een Linux equivalent. Xorg c.q. Wayland (dat kende ik zelf niet; lang geleden dat ik iets deed met Xorg) is daar een voorbeeld van. De overgang van emulatie van echte hardware (in jouw termen: echte emulatie) naar HAL tussenlagen (dat jij geen emulatie noemt, maar ik eigenlijk ook wel emulatie vind) en software lagen (wat idd meer simulatie is).

Ik geloof niet dat we van mening verschillen.

[xfj]

Inderdaad. Ik schreef er hier 2 jaar geleden al over: xfj in 'Wine 7.2'

Tot en met versie 981108 stond er nog “This is release 981108 of Wine, the MS Windows emulator”, de volgende versie schreef “This is release 981211 of Wine, a free implementation of Windows on Unix”. Hoewel je ook kunt stellen dat Wine meer is dan een emulator omdat je met Winelib ook Windows bronbestanden kunt compileren voor Linux. De jaren ’90 FAQ had dan ook “The word Wine stands for one of two things: WINdows Emulator, or Wine Is Not an Emulator. Both are right. Use whichever one you like best”.

[Remzi1993]

Een emulatielaag kost ook heel veel CPU maar een vertaling, zoals een compatibiliteitslaag, kost stukken minder CPU rekenkracht en is dus veel efficiënter dan dingen emuleren.

Praktisch heb je dus gelijk, beide hebben tot doel om ervoor te zorgen dat iets op een andere platform werkt, maar technisch implementeren ze dat dus op een andere manier. Je kan het vergelijken met de auto of een racewagen naar je werkt te gaan, beide hebben dezelfde doel de ander is sneller.

[Reactie gewijzigd door Remzi1993 op 22 juli 2024 22:28]

[batjes]

Emulatie gaat niet om de gebruikte techniek, maar om het doel. Het emuleren houdt in dat je het ene systeem in het andere systeem nabootst. Hoe je dat bereikt doet er niet toe. Dit kan zoals WINE door gewoon de aangesproken API te vertalen. Dit kan zoals een NES of GBA emulator door alle instructies te vertalen naar X86 of ARM. Dit kan door middel van virtualisatie zoals Xbox dat (deels) doet.

Dat WINE voor Wine is not an emulator staat, is een grap. Dat was juist _de_ grap.

[Verwijderd]

Is juist geen semantiek. Wine probeert geen windows te zijn en dingen niet volgens de windows manier/implementatie te doen, maar calls met zo min mogelijk grote overhead richting de kernel/drivers/systeem te krijgen.

Een emulator probeert juist alles zo exact mogelijk als hetgeen wat het simuleert te doen, met alle quirks, bugs en slechte implentaties die daar bij horen.

technisch heeft het raakvlakken maar qua uitgangspunt is het volledig anders.

[batjes]

Ze mogen wel heel hard roepen dat WINE geen emulator is, veranderd er niets aan.

Het vertalen van platform X naar platform Y is emulatie. Want heel simpel: Het draait niet native zonder de "compatibility laag".

Er zijn game emulators die op exact dezelfde wijze werken, er zijn emulators die anders werken (meer virtueel machine achtig bv). Het repliceert de Win32 API tot zelfs al zijn quirks en uitzonderingen. Raad eens wat een oude (S)NES emulator doet? Calls omtoveren naar een ander platform, inclusief alle quirks en uitzonderingen, zodat een game 1 op 1 werkt zoals het zou moeten werken.

WINE emuleert Windows op Linux, iets anders kan je er niet van maken. Dat WINE staat voor Wine is Not an Emulator was juist de grap. Dat het vandaag de dag iedereen /r/wooshed, tja.

[Reactie gewijzigd door batjes op 22 juli 2024 22:28]

[TheVivaldi]

En ReactOS? Technisch gezien gebruiken ze ook Wine, maar aan de andere kant kun je alleen Windows-apps installeren, dus het is niet echt een compatibiliteitslaag in hun geval.

[learn_more]

We gebruiken een aantal userspace libraries van wine, maar een groot gedeelte van de applicaties en de gehele kernel en de laag daar direct bovenop (ntdll etc) hebben niks met wine te maken.

[batjes]

Ook ReactOS is emulatie. Het emuleert Windows.

2x ongewenst lol (niet naar jou per sé), maar kom op:
https://en.wikipedia.org/wiki/Emulator

In computing, an emulator is hardware or software that enables one computer system (called the host) to behave like another computer system (called the guest).

De intro is toch afdoende? Wine en ReactOS emuleren beide Win32.

[Xander2]

Enkel een overeenkomende API-interface (buitenschil) maakt geen emulator. Bij een emulator denk ik aan iets dat van binnen probeert hetzelfde te doen als iets anders. Daar is bij Wine geen sprake van.

Sja, een library geport naar een platform is geen emulator maar de WINE libraries tesamen hebben toch wel degelijk het doel een Windows omgeving te emuleren.

Of je nou op instructie-niveau vertaald of op API-niveau, het komt uiteindelijk op hetzelfde neer.

[veltnet]

Je hebt helemaal gelijk, emulatie is technisch gezien iets anders

Maar je kunt er ook anders naar kijken (minder technisch):
Emuleren betekent imiteren of namaken.
Emulatie is een manier om een andere platform te imiteren. Dit kan op meerdere manieren. Op machine nivo (via een emulator) of op library nivo (zoals Wine). Via beide methodes wordt er nog steeds een ander platform geimiteerd/nagemaakt, alleen op een verschillend abstractienivo.

WINE betekent "Wine Is Not a Emulator". En dat zorgt er natuurlijk ook voor dat je het geen emulator mag noemen want ze zeggen zelf dat ze het niet zijn. Maar stiekum zijn ze het toch wel een beetje, want er zijn een aantal windows libraries geimiteerd of nagemaakt (of hoe je het dan ook wilt noemen)

[Reactie gewijzigd door veltnet op 22 juli 2024 22:28]

[ultimate-tester]

Kleine correctie, Wine Is Not an Emulator. Het is een compatibiliteitslaag die methode-aanroepen van Windows API functies opvangt en vervolgens vergelijkbare Linux functies (of custom implementaties) aanroept om het juiste resultaat terug te kunnen geven op die Windows oproep.

[Reactie gewijzigd door ultimate-tester op 22 juli 2024 22:28]

[bzuidgeest]

Wine is een windows API implementatie, niet niet een emulator. Het herimplementeert de Windows api's. Als het achterliggende OS/ Framework en code sneller zijn dan Windows zelf kan wine prima sneller zijn dan Windows.
Met alle mankracht achter en optimalisatie van Windows is dat wellicht onwaarschijnlijk, maar het is zeker niet onmogelijk. Of de windows API nou draait op een windows kernel of een linux kernel hoeft niet uit te maken. Alleen de output van de functies maakt uit.

[bcome]

.

[Reactie gewijzigd door bcome op 22 juli 2024 22:28]

[Verwijderd]

Ik gebruik een linux systeem met wine zakelijk. Onze vlaggenschip applicatie is een windows applicatie. Ik ontwikkel er zelf niet aan, maar gebruik het wel.

[Cageman1984]

Nu maar wachten op 'echte' HDR op Linux... Dan ga ik waarschijnlijk echt over op Linux!

[Remzi1993]

HDR is nog in de kinderschoenen. Echt HDR heb je alleen als je Dolby Vision of hdr10+ met meer dan 1000 nits, anders heb je gewoon fake HDR.

Na 5 tot 10 jaar gaat HDR pas betaald worden voor de gemiddelde consument.

[Cageman1984]

Maar dan is de HDR in Windows 11 dus eigenlijk ook fake?

[Remzi1993]

Ja, dat is het dus ook 😂🤣

Het juiste woord is eigenlijk: Gimmick

[Reactie gewijzigd door Remzi1993 op 22 juli 2024 22:28]

[Cageman1984]

Ja, dat is het dus ook

Oke, voor jou waarschijnlijk logisch, maar voor mij even een openbaring...

Goed, dan twee vragen.

1) als ik HDR in Windows aan zet, zie ik wel een verschil. Bijvoorbeeld in horizon zero dawn werden de kleuren er een stuk minder overbelicht en oranje door. Wat zie ik precies met HDR aan in Windows ten opzichte van HDR uit?

2) zou ik dan bij wijze van spreken vandaag maar overstappen naar Linux? Ik heb na een periode Ubuntu eens nobara geprobeerd. Het viel me echt mee met hoeveel spellen het prima werkte. Met relatief weinig klooien. En goede performance. Alleen HDR moest ik via gamescopesessies aan de gang krijgen en dat werkte niet goed. Daarom besloten te wachten tot HDR echt out-of-the-box geïmplementeerd was.

[Remzi1993]

Hetzelfde met HD ready en Full HD. Het is wel iets beter dan SD (Standard Defeinition) maar 720p is niet echt HD. Dit heb je dus hetzelfde met HDR. Maar binnen 5 tot 10 jaar heeft iedereen "echte" HDR.

Wat betreft je vraag over Linux: Het gaat er om wat voor jou belangrijk is. Voor mij is dat FPS en minimaal HD of 1440p en dat het tussen de 120 en 144hz werkt en op mijn Steam Deck vind ik resolutie niet belangrijk en tussen 30 en 60 fps is goed genoeg. Voor de rest vind ik HDR en resoluties boven de 1440p niet alleen geldverspilling maar zorgt dat niet echt voor betere ervaring qua geld en kwaliteit.

Je kan beter een 1440p monitor met minimaal 144hz kopen dan een dure 4K monitor met dure HDR specificaties. Ze zijn nog te duur daarvoor en niet alle games ondersteunen het of halen hier het beste eruit.

Dus het gaat erom wat voor jou belangrijk is.

[Reactie gewijzigd door Remzi1993 op 22 juli 2024 22:28]

[Remzi1993]

HDR is nog in de kinderschoenen. Echt HDR heb je alleen als je Dolby Vision of hdr10+ met meer dan 1000 nits, anders heb je gewoon fake HDR.

Na 5 tot 10 jaar gaat HDR pas betaald worden voor de gemiddelde consument.

PS: Typefout: betaald = betaalbaar

[shady61]

Ik ben benieuwd of sommige DE’s of window managers zullen stoppen met bestaan omdat ze de overgang niet kunnen maken naar Wayland.

Ik gebruik Wayland in Gnome (desktop) en Sway (laptop). In Gnome gaan sommige programma’s vanzelf half uit beeld na bijv. een slaapstand, waarschijnlijk omdat Wayland de posities niet onthoudt. In Kde vond ik Wayland best een drama. Ik ben daarom overgestapt naar Gnome omdat X11 qua beveiliging niet ideaal is en het de vraag blijft hoe lang Kde er over gaat doen om alle features werkend te krijgen.

[nvaert1986]

Het is afhankelijk van je doel en je hardware combinatie, maar tegenwoordig is dat al een stuk beter in 5.27.10 en vermoed dat veel van de problemen compleet opgelost zijn in 6.0. Ik heb Wayland zelf ieder jaar opnieuw geprobeerd en ben pas afgelopen December permanent naar Wayland geschakeld.

[Reactie gewijzigd door nvaert1986 op 22 juli 2024 22:28]

[Guus...]

Er zullen zeker een aantal DE's en WM's afvallen maar er worden ook weer nieuwe gemaakt zoals Hyperland. Wat ik een positief teken vind is dat Linux Mint met Cinnamon in Juli 2023 bezig was met Wayland en nu al een goed werkende alpha heeft kunnen produceren. Omdat de tools zoals Kwin, Mutter, wlroots en smithey nu al redelijk ver zijn verwacht ik dat een aantal DE's en WM's daarmee het komende jaar nog niet te laat zijn om ook te beginnen met de overstap.

[learn_more]

Heeft er iemand toevallig een mooi artikeltje dat iets meer de diepte ingaat over de wow64 implementatie van wine?

[teapot]

Wat me helaas nog steeds niet gelukt is in wine is een programma compileren en linken in borland c++ builder 6. Uitgerekend in de laatste stap als de linker zowat klaar is krijg ik een memory error (LME, linker memory error). Ik heb ze wel eens gevraagd maar ik zou een debug build van wine moeten gaan bouwen en daar heb ik nou net even de puf niet voor. Maar ik ga het weer eens proberen met deze versie.