Software-update: Wine 7.17

Er is met versienummer 7.17 een nieuwe ontwikkelbuild van Wine verschenen. Wine is een opensource-implementatie van de Windows-api en maakt het mogelijk om DOS- en Windows-programma's op Linux, FreeBSD, Solaris en macOS te draaien. Een grote groep ontwikkelaars draagt bij aan Wine en er is voor gekozen om elke twee weken een nieuwe zogeheten ontwikkelversie uit te brengen in plaats van te wachten tot er een aantal nieuwe functies klaar is. Een paar keer per jaar verschijnt er een stabiele uitgave. De database met applicaties die onder Wine werken, al dan niet met behulp van kleine aanpassingen, bevat op het moment van schrijven 28.626 titels wat er 17 meer zijn dan verleden week. In deze uitgave zijn de volgende veranderingen en verbeteringen aangebracht:

What's new in this release:

• High Unicode planes support in DirectWrite.
• Some work towards Wow64 support in the Vulkan driver.

Bugs fixed in 7.17 (total 18):

• #11999: Endless Online game window appears as white texture
• #27243: Wiggles: All renderers are unsupported
• #34744: Earth 2150 fails to play .mp2 music (MPEG-1 Audio Decoder Filter needed, CLSID '{4a2286e0-7bef-11ce-9bd9-0000e202599c}')
• #37019: Multiple games fail to start due to D3D7 devices reporting unsupported HWTRANSFORMANDLIGHT capability (Summoner, Battle Realms: Zen Edition)
• #48986: Riot Vanguard (Riot Games) 'vgk.sys' crashes on unimplemented function ntoskrnl.exe.KeAreAllApcsDisabled
• #51939: Riot Vanguard (Riot Games) v1.0.x.x 'vgk.sys' crashes on unimplemented function ntoskrnl.exe.IoCreateFileEx
• #52449: Liar-soft Visual Novel's not displaying video (audio plays fine)
• #52457: CNG Encryption Failure (BCryptEncrypt)
• #52709: Visual Studio Community 2022 installer crashes when trying to open it
• #53032: winedevice.exe segfaults on exit when built with GCC
• #53337: Ice Cream Calculator: unusually slow scrolling
• #53427: BioShock needs D3DX10PreprocessShaderFromMemory implementation
• #53486: foobar2000.exe with foo_out_upnp breaks sending audio stream to another upnp renderer after a short period of time
• #53544: msys2 block device fstat function depends on NtQueryVolumeInformationFile FileFsFullSizeInformation
• #53547: msys2 installer fails to check disk space: "harddisk_query_volume Unsupported volume query 3"
• #53560: Wizard101 fails to load in 7.15
• #53581: Construction Set Extender crashes
• #53601: UI rendering broken for multiple applications (7-Zip, WinRAR, foobar2000, built-in apps) in Wine 7.16 at a non-default DPI

Versienummer	7.17
Releasestatus	Unstable
Besturingssystemen	Linux, BSD, macOS, Solaris
Website	Wine HQ
Download	https://www.winehq.org/download
Licentietype	GPL

Reacties (73)

[JosSchaars]

Proton vs Wine: https://embeddedinventor....ne-differences-explained/

[Sicos]

Ik denk bij Wine altijd, als je dan echt een spel wilt spelen dat er alleen voor Windows is maak dan gewoon een dual boot en speel het gewoon onder Windows. Zo duur is een Windows licentie nu ook weer niet als je het gewoon legaal wilt doen.

[Magic Power]

Vroeger had ik óf een dualboot, óf twee computers (een Linux laptop en een Windows desktop). Dat was nog in de tijd dat er niet veel (direct) op Linux werkte, en ik heb vooral aan het uitproberen was. Toendertijd heb ik inderdaad de meeste Windows spellen gewoon via Windows (XP,7) gespeeld. Het was toen teveel werk en gekloot om spellen via Linux proberen te draaien.

Sinds een paar jaar geleden zijn er echter een paar veranderingen, die alles (voor mij) erg anders maakt. Op dit moment werken bijna alle Windows spellen die ik op Linux wil spelen 'gewoon'. Ik hoef geen moeilijke files aan te maken, of code te compilen. Alle Windows spellen via Steam is letterlijk klik->Play, je merkt niet eens een verschil dat je een Windows spel gaat spelen, of aan het spelen bent, op een Linux systeem. En voor niet-Steam Windows spellen heb ik Lutris. Alhoewel je de omgeving ervoor klaar moet zetten, is het daarna ook dubbelklik 'Setup.exe', en klik op 'Play'. En alle Linux spellen werken ook gewoon door Klik en Play. Ik heb geen noodzaak meer voor een Windows omgeving, alles werkt gewoon makkelijk in de Linux omgeving.

En de tweede grotere verandering die is gekomen, is dat Windows je steeds meer probeert in hun richting, en denkwijze te duwen. De vrijheid die je had in Windows XP en 7 is (voor mij i.e.g.) duidelijk minder geworden. Waar ik voorheen wel redelijk tevreden was met Windows XP en Windows 7, ben ik helemaal niet tevreden met Windows 8, 10 en 11. Daarentegen ben ik veel meer tevreden met mijn huidige Linux omgeving. Alles werkt zoals ik wil, ik kan het ook aanpassen zoals ik wil, het zit niet zo in de weg als het bij Windows zit/zat (voor mij). Daarom ben ik nu een fulltime Linux gebruiker, en is Windows voor mij alleen nog een legacy omgeving, waar ik niet echt meer hoef te zijn.

--

Je hebt gelijk, als je zegt dat het beter is om software te draaien in de omgeving waarvoor het gemaakt is. Maar op het moment dat Windows steeds verder van mij af staat, en Linux steeds fijner en makkelijker is, en emulatie erg eenvoudig en laagdrempelig gedaan kan worden, kies ik voor een Linux omgeving, met een emulatielaag voor de Windows spellen die ik wil spelen.

[Uruk-Hai]

Alle Windows spellen via Steam is letterlijk klik->Play, je merkt niet eens een verschil dat je een Windows spel gaat spelen, of aan het spelen bent, op een Linux systeem.

Dat is niet mijn ervaring. Afhankelijk van het spel zijn er wel degelijk verschillen met Windows en ik denk ook dat specifiek je eigen hardware verschil maakt. Ik kon van Halo (eerste deel) met Proton alleen het eerste level uitspelen met alle settings op low en tijdens het tweede level had ik al heel gauw voortdurend vastlopers.

Op Windows heb ik op dezelfde hardware de complete Halo: The Master Chief Collection uitgespeeld zonder een vergelijkbare hoeveelheid aan dergelijke vastlopers en alle settings op medium.

Dus nee, Linux, Steam en Proton zijn wat mij betreft nog niet zo algemeen geschikt voor de gamende massa als jij stelt. Ik vind het mooi dat het bestaat en wat het allemaal al kan, maar ik hoop wel dat het nog veel beter wordt dan het nu al is.

[Reactie gewijzigd door Uruk-Hai op 24 juli 2024 14:33]

[rbr320]

Ik kon van Halo (eerste deel) met Proton alleen het eerste level uitspelen met alle settings op low en tijdens het tweede level had ik al heel gauw voortdurend vastlopers.

Vervelend maar dat is dan weer niet mijn ervaring. Ik heb Halo: CE uit de MCC zonder problemen kunnen spelen op Linux, ook de co-op campaign. In Halo 2 had wel een aantal crashes tijdens co-op, maar die waren allemaal gerelateerd aan de cutscenes en na wat zoeken online blijken ook Windows gebruikers hier last van te hebben. De campaign van Halo 3 doet het ook prima, ik heb nog geen co-op geprobeerd.

Hardware: een core i5 8400 en een NVidia 1070 in een systeem met 16GB geheugen. Ik speel de spellen op 1440p op medium tot high settings.

[Reactie gewijzigd door rbr320 op 24 juli 2024 14:33]

[Uruk-Hai]

Ja, ik heb al eerder gemerkt dat mijn eigen ervaringen afwijken van die van veel andere Tweakers, maar wat ik bedoel is dat als Proton/Wine echt reeds zo zaligmakend is, iedereen (dus ik ook) zonder veel problemen goed Windows games moet kunnen spelen op Linux en dat is gewoon nog steeds niet zo.

Mijn eigen hardware is een Core i7 3770 met 8GB RAM en twee NVidia Geforce GTX 660 Ti videokaarten in SLI opstelling. Aan dat laatste heb ik in Linux volgens mij helemaal niks. Ik heb in elk geval op basis van de GUI van de grafische NVidia driver voor Linux niet de indruk dat die SLI ondersteund.

Anyway, ik raak er steeds meer van overtuigd dat ik gewoon pech heb met mijn hardware, ook omdat de Steam Deck mijn geconstateerde problemen niet heeft.

[Reactie gewijzigd door Uruk-Hai op 24 juli 2024 14:33]

[Bulkzooi]

Anyway, ik raak er steeds meer van overtuigd dat ik gewoon pech heb met mijn hardware, ook omdat de Steam Deck mijn geconstateerde problemen niet heeft.

SLI is van Nvidia dus dan zit die pech gewoon ingebakken in Steam Deck (lees: Proton).

@Hydranet Die Anti-cheat is DRM; dat mis je niet maar zit al heel lang in Linux. Wat je bedoelt met root-kit snap ik niet. Ik game (en meer) prima op VAAPI + Radeon drivers, ook al sinds de oude GNU/Linux kvm/dri infrastructur. VDPAU + nouveau van Nvidia lijkt me aardig afgeschreven; wellicht nog in gebruik in een museum of zo. Maar met hun closed-sourced driver kan je volgens mij prima SLI gebruiken. Klassiek gezien was dat zelfs altijd de beste GPU game-driver op GNU/Linux.

Maar goede links van Codeweaver! thnx. Weet je nog welke games ze allemaal ondersteunden?

We invented CrossOver software - a unique approach to cross-platform compatibility that does not require dual-boot or another OS license. We launched PortJump to help app and game developers broaden their market beyond Windows® users. And we launched ExecMode to help organizations solve really ugly technical challenges.

De implementaties van DirectX 11 en 12 zijn gebaseerd op Vulkan, waarbij respectievelijk DXVK en vkd3d compatibiliteit bieden met Direct3D 11 en 12.

cc: @Luminair

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[Hydranet]

Wat je bedoelt met root-kit snap ik niet.

Anti-cheat software die op kernel niveau zit dus dat die alles op je systeem kan uitlezen. Easy-Anticheat en Battle-Eye zijn daar volgens mij de twee meest bekende van.

Maar goede links van Codeweaver! thnx. Weet je nog welke games ze allemaal ondersteunden?

Je zou dan in de compatibiliteit lijst moeten zoeken die ik eerder linkte want ik zou het niet meer weten, sinds Proton zo goed voor mij werkt gebruik ik het eigenlijk nooit meer en soms gebruik ik wel is Lutris, heb het al dus jaren niet meer gebruikt.

[Luminair]

Ik snap de reden voor de CC niet helemaal, maar dank voor de info, interessant.

[Bulkzooi]

@Luminair je maakte interessante comments dus ik nam maar aan dat je het wel een leuke comment zou vinden.

Thnx @Hydranet Maar SLI werkt gewoon met de closed-sourced driver van Nvidia. Klassiek gezien was dat zelfs altijd de beste GPU game-driver op GNU/Linux. AMD Radeon is de beste FOSS GPU driver, in ieder geval totdat ARM Mali Panfrost volwassen werd.

Die Anti-cheat is DRM; dat mis je niet maar zit al heel lang in Linux. Wat je bedoelt met root-kit snap ik niet.

Anti-cheat software die op kernel niveau zit dus dat die alles op je systeem kan uitlezen. Easy-Anticheat en Battle-Eye zijn daar volgens mij de twee meest bekende van.

ah, zo. Ik begreep dat je het over rootkit op mobieltjes had maar je bedoelt met kernel niveau waarschijnlijk een UEFI BIOS feature. Maar anit-cheat software (Easy-Anticheat en Battle-Eye) betreft dus een gaming specific feature zo te zien, en niet zoiets als dvdccs, ARccOS, AACS, BD+, en BD-ROM Mark. Dit betreft de categorie content-beveiliging, aka DRM Scrambling.

En de Lutris Gamecliënt is wel cool! Python / PyGObject met een lekkere simpele buildfile voor Meson.

The client, an emulation bundle, can connect with existing services like Humble Bundle, GOG and Steam to make your game libraries easily available. Game downloads and installations are automated and can be modified through user made scripts. Setting-up your workstations means making sure your graphics drivers are installed and up to date, that Vulkan is installed and that the 32bit libraries for OpenGL / Vulkan are present.

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[Hydranet]

Ik denk dat jij gewoon pech hebt of zo, want ik game al op Linux sinds voor Proton er was. Ik gebruikte in die tijd Crossover Linux(Een grafische schil voor Wine die iets gelikter is) i.c.m Steam en soms gewoon een spel zonder Steam. Daarbij speelde ik vaak spellen die genoeg sterren hadden in de compatibiliteit's lijst. Daar had ik meestal dat de spellen met genoeg sterren prima werkte met soms wat mankementen maar de spellen met geen of minder als 3 sterren hoefde je echt niet te proberen. Ik heb sinds de beschikbaarheid van Proton, die Valve samen heeft ontwikkeld met Codeweavers, eigenlijk bijna nooit meer dat ik een spel niet kan spelen of dat ik tegen iets aanloop tenzij er een vorm van Anti-cheat in zit. Met lagere specs hardware en nu met ook betere specs hardware, ik zou alleen niet meer weten welke hardware dat was maar dat was de laatste keer voordat ik mijn oude pc van 6 jaar had vervangen voor een game laptop die ik nu weer heb vervangen voor een normale pc.

[Reactie gewijzigd door Hydranet op 24 juli 2024 14:33]

[Luminair]

Dus nee, Linux, Steam en Proton zijn wat mij betreft nog niet zo algemeen geschikt voor de gamende massa als jij stelt. Ik vind het mooi dat het bestaat en wat het allemaal al kan, maar ik hoop wel dat het nog veel beter wordt dan het nu al is.

Ik denk dat dat maar net is wat je als referentiekader gebruikt. De SteamDeck van Valve gaat als hete broodjes over de toonbank, en is bijna niet aan te slepen. Mensen zijn er lovend over, ondanks dat het SteamOS draait -- en dat gebruikt onder de motorkap gewoon Proton/Wine om windows games te draaien. Veel mensen vinden het klaarblijkelijk dus genoeg om geld uit te geven aan een machine die hoofdzakelijk Linux draait; ik heb nog niet eens gehoord van een van mijn vrienden dat ze windows er op (willen) draaien.

[danoam]

Same, draaide voorheen ook dual boot. Had Windows zelfs fysiek op een andere SSD en nog steeds had deze het lef om de eerste SSD met daarop Linux aan te raken en bij een update bootloader bestanden te plaatsen.

Tegenwoordig draai ik Windows alleen nog maar in een virtual machine met VFIO waar je fysiek je hardware aan kan doorgeven, zo hoef je nooit te rebooten en heb je nog steeds near native performance voor het select aantal spellen die niet lekker draaien onder Linux.

In mijn geval ben ik nog geen game tegengekomen die niet te spelen valt, maar zodra je mods of 3rd party tools wil gebruiken voor je game kan het vervelend zijn om met wine prefixes te kloten. En voor League of Legends bijvoorbeeld moet je telkens abi.vsyscall32=0 gebruiken om het te kunnen spelen. Ook had ik een keer een probleempje toen ik met een maat Borderlands wou spelen, ik had de native Linux versie en deze zat op een andere versie dan de Windows versie die m'n maat draaide.

Dus meeste games op Linux en daarnaast een Windows VM met VFIO puur voor het gemak, heb je het beste van beide werelden! Voor mensen die geinteresseerd zijn in de performance van zo'n VM:

https://www.youtube.com/watch?v=w473rRf9aYA
https://www.youtube.com/watch?v=Ol9O3Jow740

[Reactie gewijzigd door danoam op 24 juli 2024 14:33]

[scholtnp]

De prijs van de licentie is vaak niet het probleem. Er zijn genoeg verhalen geweest dat zo'n dual boot bij een Windows update alsnog weer verminkt werd waardoor de andere partitie niet neer werkte.
Gek genoeg gebruik ik Wine nu vooral om Windows executables te testen: Rust code crosscompileren op Linux, en vervolgens testen met Wine. Kunnen mijn software gebruikers gewoon op Windows blijven en ben ik tevreden en effectief met mijn Linux workflow.

[Magic Power]

Daarom had ik mijn dual-boot destijds ingesteld door GPT partitioning en UEFI boot te gebruiken. Dan kan Windows de linux bootloader niet overschrijven met zijn eigen bootloader. Dat werkt, alleen heb ik wel meegemaakt dat Windows zonder te vragen de UEFI bootloader volgorde aanpaste, en opeens Windows als eerste gestart werd, terwijl altijd Linux als eerste werd opgestart. Gelukkig is dat in het BIOS simpel aan te passen door de volgorde aan te passen.

Via Linux opstarten is beter, want zelfs dan kun je makkelijk een keuzescherm toevoegen waarin je alsnog simpel Windows kunt opstarten, dus het wisselen is dan zeer makkelijk.

[Hydranet]

Sommige mensen willen gewoon geen Windows draaien, Wine/Proton werken tegenwoordig prima met de meeste spellen met uitzondering als er Anti-Cheat(root-kit) software word gebruikt met het spel.

[eprillios]

Omgekeerd kan een dual boot-installatie en een aparte Windows-licentie te veel van het goede zijn, als je slechts een programma wil draaien die niet beschikbaar is op Linux, macOS, etc. Voor veel zaken werkt Wine meer dan prima, zonder dat het je geld of extra moeite kost. Voor elk wat wils dus.

[DamirB]

Naja je verliest dat ook veel resources aan je VM, zo niet.

[jimshatt]

Welke VM? Bij dual boot draai je geen VM (meestal)

[Uruk-Hai]

Dualboot OS'en zijn voor de meeste mensen teveel van het goede.

Bovendien is dualboot op steeds meer systemen niet meer zo makkelijk of helemaal niet meer te realiseren als vroeger.

[psychicist]

Wine is een legale implementatie van de Windows API's op POSIX-compatibele besturingssystemen die Windows systeemcalls vertaalt naar de POSIX equivalenten en volledig legaal is. Het gaat niet om de kosten, maar om het feit dat je geen Windows hoeft te draaien om toch al je applicaties te kunnen gebruiken en je spellen te kunnen spelen.

Aangezien Wine en het daarop gebaseerde Proton steeds beter worden, wordt de noodzaak voor Windows ook steeds minder. ReactOS maakt trouwens ook gebruik van Wine en heeft als doel een Windows-compatibel besturingssysteem te zijn.

[Bulkzooi]

@psychicist

Wine is een legale implementatie van de Windows API's op POSIX-compatibele besturingssystemen die Windows systeemcalls vertaalt naar de POSIX equivalenten. "Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly"

ReactOS maakt trouwens ook gebruik van Wine en heeft als doel een Windows-compatibel besturingssysteem te zijn.

{Win32 API <> posix API} <> Windows NT primitives

Heb je toevallig een linkje naar de API calls van Wine en/of ReactOS? En weet je hoe het staat het met de sdk's van ReactOS? Ik ben groot fan van ReactOS, persoonlijke top 3 van Windows-like distro's, maar ik zit er niet continue bovenop.

Maar Wine verschrompeld idd totdat Proton overblijft voor gaming op Android via Vulkan.

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[crazyboy01]

Ik denk bij Wine niet eens aan games.

[Jack Flushell]

.

[Reactie gewijzigd door Jack Flushell op 24 juli 2024 14:33]

[PrimusIP]

Ik heb een MacBook met ARM architectuur die niet dual boot ondersteunt. Het dual booten daarop instellen (en dan de ARM Windows moeten gebruiken voor gamen) kost me meer gedoe dan Wine gebruiken.

[davince72]

Volgens mij gaat het om gemak en niet om geld (en het is ook niet illegaal oid). Ik heb wel eens wat games gekocht op steam die ik draai op een mac....wellicht zitten daar games tussen die via wine draaien. Geen idee en hoef ik ook niet te weten.

[TheVivaldi]

Wine is niet alleen voor spellen. Ik gebruik het voor een ander programma dat ik tussen mijn werkzaamheden door gebruik. Dan is opnieuw opstarten geen doen en een tweede pc vind ik zeer overbodig. Het programma werkt al jaren prima onder Wine, incl. updates, dus ik zie niet in waarom ik dan een andere oplossing zou moeten kiezen.

Daarbij is Wine volledig legaal.

[Reactie gewijzigd door TheVivaldi op 24 juli 2024 14:33]

[jvelite]

"legaal" ? Dit is niet illegaal.

Plus; als we met z'n allen de-facto dus Windows zouden moeten gebruiken moedig je alleen maar monopolistengedrag aan. Laten we dat niet doen?

Het is ook precies de ontwikkeling van dit stukje software wat projecten als de Steam Deck mogelijk maakt.

[ejabberd]

Je vergeet dat Wine cruciaal is voor de Steam Deck. Als je gelooft dat de Steam Deck een mooie toekomst tegemoet gaat, zo ook Wine.

En hobbyproject? Ik denk dat je het niveau van de code van Wine eerder moet vergelijken met die van Apache, MySQL, Drupal,...

[patchii]

Er staat toch wel vrij duidelijk op de gelinkte wikipedia pagina van Proton dat het gebruikt maakt van Wine.

"It is a collection of software and libraries combined with a patched version of Wine to improve performance and compatibility with Windows games."

Een ander onderdeel van Proton is inderdaad ook een layer om van Direct3D naar Vulkan te gaan. Maar het hele plaatje werkt niet zonder het Wine gedeelte. Uiteindelijk is het ook gewoon een fork van Wine.

[patchii]

Wine is juist nog nooit zo levend geweest. Proton is de backbone van de hele steamdeck en dat ding is nu flink populair. Zonder Wine heb je ook geen Proton.

[Bulkzooi]

Wine is juist nog nooit zo levend geweest. Proton is de backbone van de hele steamdeck en dat ding is nu flink populair. Zonder Wine heb je ook geen Proton.

Op GNU/Linux heb je geen Wine of Proton nodig. Iedereen gebruikt QT / GTK voor de Gui en MESA voor games, evt. met GPU-acceleratie.

Wellicht dat er nog een handjevol devs publiceren naar Chocolatey, maar dan houdt het wel op. Maar ook dat is een dood spoor, nu met het succes van Steam en de volwassenheid van MAME, RetroArch, OpenDos & browser gaming.

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[patchii]

Op GNU/Linux heb je zeker geen Wine of Proton nodig, het is geen verplichting. Proton wordt gebruikt om bijvoorbeeld games die voor Windows zijn gemaakt te runnen op een GNU/Linux machine.

Nee dit is zeker geen verplichting of een vereiste. Maar in de markt willen mensen de allernieuwste games spelen en deze worden vaak alleen voor Windows gepublished. Het is juist een mooie zet dat iets zoals Proton (wat dus gebruikt maakt van Wine) zo populair is geworden en goed werkt dat ze ervoor hebben kunnen kiezen om dit te gebruiken op de steam deck.

Het is een entertainment markt en niet een development markt waar Proton op gericht is.

[Bulkzooi]

Op GNU/Linux heb je zeker geen Wine of Proton nodig, het is geen verplichting. Proton wordt gebruikt om bijvoorbeeld games die voor Windows zijn gemaakt te runnen op een GNU/Linux machine.

Nee dit is zeker geen verplichting of een vereiste. Maar in de markt willen mensen de allernieuwste games spelen en deze worden vaak alleen voor Windows gepublished.

Ken je Mesa? En 99% van de oudere games draaien al op GNU/Linux.

Heb je een voorbeeld van een game die beter draait op Wine dan op de gangbare alternatieven?

Proton is een project onder invloed van Steam Deck om wat mobiele calls te absorberen.

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[patchii]

Ik wens je veel succes om bijvoorbeeld Witcher 3, Horizon Zero Dawn, Arma 3, noem het maar op, te draaien op GNU/Linux zonder het gebruik van Wine of Proton. Wat voor "gangbare alternatieven" zijn er dan ook?

[patchii]

Hoezo zijn dit slechte voorbeelden? En waar haalt jij uit dan Wine zich richt op oude games op GNU/Linux? Ik geef je zeker gelijk dat je oude games beter via OpenDos, Mame, RetroArch kan gebruiken. Nu vind ik het wel komisch dat je Steam benoemt want het zou best wel is kunnen dat je de game dan via Proton speelt.

Het klopt ook zeker wel dat als een game afhankelijk is van DirectX dat dit dankzij de dev studio is. Maar dat is dus de hele reden dat Wine en dus ook Proton bijvoorbeeld bestaat. Nu kan je dus toch nog de games spelen op je GNU/Linux machine.

Ik herhaal, het is een entertainment markt en niet een development markt waar Proton op gericht is.

De eindgebruiker wil gewoon zijn triple A games kunnen spelen op zijn GNU/Linux machine.

[Bulkzooi]

Hoezo zijn dit slechte voorbeelden? En waar haalt jij uit dan Wine zich richt op oude games op GNU/Linux? Ik geef je zeker gelijk dat je oude games beter via OpenDos, Mame, RetroArch kan gebruiken. Nu vind ik het wel komisch dat je Steam benoemt want het zou best wel is kunnen dat je de game dan via Proton speelt.

Het klopt ook zeker wel dat als een game afhankelijk is van DirectX dat dit dankzij de dev studio is. Maar dat is dus de hele reden dat Wine en dus ook Proton bijvoorbeeld bestaat. Nu kan je dus toch nog de games spelen op je GNU/Linux machine.

Ik herhaal, het is een entertainment markt en niet een development markt waar Proton op gericht is.

Yes, dus waarom Wine? Omdat game studio's zich niet op GNU/Linux focusten.

Dit topic gaat ook over Wine; dat een afgeleid subproject zoals Proton wat dingen verbeterd, da's logisch. Mag ook wel, want iedereen gaat mobiel gamen en de concurrentie qua Linux gaming streeft Wine aan alle kanten voorbij.

Zelfs een doorsnee GNU/Linux distro met een moderne browser vangt al 95% af van de historische use cases van Wine.

En Steam heeft toch zeker geen Proton nodig? Mesa met evt. Gpu acceleratie moet voldoende zijn.

Qua entertainment kan je beter op Android gamen. Maar gpu-versnelde games of games met DirectX9c afhankelijkheid kan je beter op Windows willen gamen. Dan kan je gewoon Steam desgewenst ff installeren.

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[patchii]

Ja dat is dus inderdaad de reden dat iets als Wine moet bestaan. Is daar dan zo veel mis mee. Ik ben het mee eens dat het probleem bij de studios liggen. Wees blij dat dan dit project bestaat om het probleem op te lossen. Er zijn echt nog wel use cases voor Wine. Zelf gebruik ik dit om ExactAudioCopy te draaien op mijn GNU/Linux machine.

Als jij een oplossing vindt om maar op Android te gamen of Windows te installeren om te gamen snap je gewoon het hele idee van Wine en voornamelijk Proton niet.

[patchii]

Dat je Proton een bagger product vindt is eerder je eigen probleem dan. Ik snap dat de codebase misschien helemaal uit de hand is gelopen, ik ben zelf geen software developer dus ik geef daar geen commentaar op.

Ik game überhaupt niet meer dus mij maakt het allemaal niet uit. Ik denk voornamelijk aan de markt naar wie bijvoorbeeld dus een steam deck gericht is. Mensen willen hier gewoon de nieuwste games op spelen.

Volgens mij heeft het geen nut om er verder over te praten want we komen er toch niet uit.

[Xander2]

Ken je Mesa? En 99% van de oudere games draaien al op GNU/Linux.

Ja, Mesa is een (E)GL stack. Daar draait misschien 1% van de games op, maar alle Windows games zeker niet. Die hebben een vertaalslag nodig als Wine, DirectX is niet alleen grafische calls, maar ook geluid etc. en niet compatibel met (E)GL.

[redtails]

Als niet-windows programmeur verbaast het mij altijd dat Wine eigenlijk nog steeds niet perfect werkt. Je zou toch denken dat de Windows API's allemaal gedocumenteerd zijn, en daarmee dus een-op-een over te nemen zijn? Wine heeft een lange historie die veel verder teruggaat dan de meeste console emulators (jaja ik weet het, Wine is geen emumator), maar toch is de relatieve compatibiliteit van Wine minder dan die van console emulators waar er vrijwel geen documentatie beschikbaar was

[Damic]

Het is niet omdat ze gedocumenteerd zijn dat ze al geport zijn, als voorbeeld

#51939: Riot Vanguard (Riot Games) v1.0.x.x 'vgk.sys' crashes on unimplemented function ntoskrnl.exe.IoCreateFileEx

en er staan er nog een paar in.

Vergeet niet Windows is groot in code base en heeft veel modules met daarin veel functies() die je allemaal moet porten en hopen dat alles goed gaat.
Je kan dan in dit geval beter wachten tot er veel programma's worden gemeld die niet werken/crashen en dan pas programmeer tijd aan besteden om die functie te porten naar Wine.

[batjes]

Er zitten bakken met uitzonderingen in de Win32 (en ook D3D) API's waar je u tegen zegt.

Jaren geleden hing ik nog wel eens op Freenode rond in o.a. het kanaal waar Wine devs samen kwamen. Het was heel interessant en ook vermakelijk om die mensen te horen over bepaalde Win32 API's. Dat er uitzonderingen in zitten voor enkel een bepaalde applicatie, soms alleen een bepaalde versie, die het totale gedrag van de hele API veranderd en dan kan in een enkele API call gewoon tientallen of zelfs honderden van dat soort uitzonderingen zitten. Afhankelijk van hoe het aangeroepen wordt, welke applicatie het aanroept, welke versie van de applicatie, welke versie van windows, welke compatibility layer uitzondering gebruikt wordt.

Zo zit er in D3D voor een bepaalde AAA titel een uitzondering in, die game 'vergat' gewoon de drawframe

Microsoft bakt zo ontzettend veel uitzonderingen in de Windows API's omdat de ontwikkelaars zelf niet lijken te weten waar ze mee bezig zijn. De Win32 API is een gigantische puinhoop aan uitzonderingen en daarvan is praktisch niets gedocumenteerd buiten Microsoft. Maar moeten de Wine developers de patch notes/blogs/kb door spitten of er zelf maar achter zien te komen door de boel te reverse engineeren.

[Bulkzooi]

Gek genoeg gebruik ik Wine nu vooral om Windows executables te testen: Rust code crosscompileren op Linux, en vervolgens testen met Wine. Kunnen mijn software gebruikers gewoon op Windows blijven en ben ik tevreden en effectief met mijn Linux workflow.

@scholtnp

Klinkt meer alsof je IDE outdated is. En het lijkt mij dat je meer Wine aan het testen bent. Kan je je test sets niet overhevelen naar GNU/Linux dan?Maar ik vindt het juist een goed idee van @Sicos ; Ik opt voor een Dual-boot met Windows XP erbij. Als er maar geen Libre Office en Firefox Browser op staan.

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[scholtnp]

Ik denk dat je me verkeerd begrijpt, ik wil een programma schrijven en zorgen dat het zowel onder Linux werkt alsook onder Windows (en eventueel Apple) met exact dezelfde code base. Verder gebruikt ik gewoon cargo en de command line, het type IDE heeft er niets mee van doen.

[Bulkzooi]

Nee, ik ben juist nieuwsgierig en vind portability cool. Alsmede interoperability. Vandaar dat ik tipte om je tests-sets op je native platform te schrijven en te onderhouden.

Rust Apps zijn gewoon native op GNU/Linux. Ik kan me geen enkele sustainable use-case met Wine voorstellen. Wellicht een ouderwetse manier om te pushen naar Chocolatery?

Of zit je op MacOS en is daar Rust niet native dan?

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[scholtnp]

Nog wat verdere verheldering: Ik programmeer op een Ubuntu OS, met Rust (en cargo) via het rustup tool. Als je een simpele CLI programma schrijft is dat voldoende, want met cargo kun je parameters meegeven om te crosscompilen (wel even dus een andere target definiëren met rustup). Wil je ook nog een grafische interface dan heb je de keuze uit het aanroepen van een native interface of een geheel non-native. Omdat ik het ook belangrijk vond dat het zonder additionele library (*.dll of *.so) installatie kan werken heb ik nu de Rust bindings van FLTK gekozen. Dan kan ik in Ubuntu een *.exe maken die ik aan Windows gebruikers kan geven. En eerst test ik ze dus met Wine: omdat Wine een subset is van de Windows API gebruik ik dus nooit unsupported functies.

[Bulkzooi]

Thnx, zoiets stel ik me inderdaad voor.

Gebruik je dan een oude versie van Rust, die niet-native is (C++ builder daargelaten), om die grafische FLTK-bindings te testen?

Maar ik zie geen enkele use-case hier meer voor. Als je echt interoperable wil zijn kan je die test-sets beter migreren naar GNU/Linux. Of C++ in zijn geheel vermijden en C of Rust gebruiken.

Ik zie wat confusie rondom het Wine project in gebruikte terminology; win32 API & NT primitives. Wellicht dat je hier nog het e.e.a. moet abstraieeren en consolideren om dat stuk van de code beter te maken.

Maar grafische (Rust) Apps op GNU/Linux developpen met Wine heeft geen enkel voordeel, zo ver ik weet.

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[scholtnp]

Gebruik je dan een oude versie van Rust, die niet-native is (C++ builder daargelaten), om die grafische FLTK-bindings te testen?

rustc 1.63.0 (4b91a6ea7 2022-08-08)

Maar ik zie geen enkele use-case hier meer voor. Als je echt interoperable wil zijn kan je die test-sets beter migreren naar GNU/Linux. Of C++ in zijn geheel vermijden en C of Rust gebruiken.

De programma code staat al in GNU/Linux.... En voor zover ik weet kun je niet all C++ bindings met Rust automatisch genereren (met C dus wel). Ik lift verder mee op dat FLTK project, dus als programmeur zie ik de C of C++ interface niet.

Maar grafische (Rust) Apps op GNU/Linux developpen met Wine heeft geen enkel voordeel, zo ver ik weet.

Als het onder Linux werkt, kan ik daarna controleren of het ook op Windows zou werken. Dat is mijn use-case.

[Bulkzooi]

Als niet-windows programmeur verbaast het mij altijd dat Wine eigenlijk nog steeds niet perfect werkt. Je zou toch denken dat de Windows API's allemaal gedocumenteerd zijn, en daarmee dus een-op-een over te nemen zijn? Wine heeft een lange historie die veel verder teruggaat dan de meeste console emulators (jaja ik weet het, Wine is geen emumator), maar toch is de relatieve compatibiliteit van Wine minder dan die van console emulators waar er vrijwel geen documentatie beschikbaar was

De Win32 API is rock-solid; het zijn de grafische API's die continue iets hebben. Nou is het weer Proton, benodigd voor GNU/Linux gaming met Steam. Historisch gezien is Direct3D de basis, voordat DirectX het overnam.

Bovendien heb je toolkits als GTK en QT nodig om GNU/Linux desktop userspace te emuleren. Da's dus gewoon een moderne GNU/Linux distro met virt-manager en/of OpenBox.

cc: @THETCR Over die Windows NT primitives... Win32 API <> posix API. Juist om bloat te verwijderen is het nuttig en wenselijk, eigenlijk noodzakelijk, om één ABI te hebben.

De Linux images draaien in containers en bevatten aangepaste kernels zodat ze rechtstreeks gebruiken maken van de Windows NT primitives

• kernel-laag van Wine
• Wine system DLL's
• Assorti dll's (drivers, d3d, win32, alle userspace meuk zoals explorer.exe, etc.)
• Chocolatey App Store met custom Chromium & Firefox packages.

ok, wat jullie tunks uit de "compatibility layer" noemen zie ik gewoon als de else uit een if statement. Komt op mij eerder over als een tijdelijk concept met permanente debugging om uiteindelijk stateless interpreters te kunnen gebruiken.

lol, ook maakt het niks uit of je Qt een frontend, toolkit of framework noemt. Tegenwoordig wordt er sowiezo over projecten die in libraries zitten gepraat, juist vanwege al die verwarring die toch irrelevant is nadat er gecompileerd is.

En die toevoegingen van Valve aan Proton is exact het verschil waar ik in mijn eerste post op doelde.

Ik zou zeggen, kijk ook eens naar OpenGL en SDL (Simple DirectMedia Layer) framework vs. Microsoft DirectX multimedia framework (Direct3D). Dat eerste betreft dus de klassieke render infrastructuur van GNU/Linux, met ook nog KVM, DRI en evt. MESA en Vulkan. Dan laat ik X server en GUI toolkits zoals GTK/QT gemakshalve nog ff buiten beschouwing. Of libraries zoals systemd en wayland, die ook hardnekkig in de weg blijven zitten, wat betreft een efficiënte Linux Desktop.

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[switchboy]

Beetje van de klok en de klepel. Direct3d is een onderdeel van directX en met iedere paar nieuwe generaties grafische kaarten worden er nieuwe features ondersteund. Het is dus als het ware veel meer een bewegend doel dan de win 32 API

Proton wordt tegenwoordig gebruikt om direct3D api calls af te vangen en om te zetten naar vulkan api calls. Vulkan is een tegenhanger van direct3D. Een opvolger van openGL

[blorf]

Ik heb het jaren geleden geprobeerd. Volgens mij is het nu een project dat per Windows-programma een cross-reference probeert t op te bouwen die de vereiste versies van systeembestanden kent die het beste werken. Hiervoor bestaat geen heldere logica. Het is een MS-bouwwerk
Ze noemen het "geen emulator" om niet voor reverse-engineers door te gaan, want dan ontwikkel je tegen de runtime-data/program space van een closed-source sysreem aan, wat het systematisch ontrafelen daarvan vereist.

[Bulkzooi]

Ik heb het jaren geleden geprobeerd. Volgens mij is het nu een project dat per Windows-programma een cross-reference probeert t op te bouwen die de vereiste versies van systeembestanden kent die het beste werken. Hiervoor bestaat geen heldere logica. Het is een MS-bouwwerk
Ze noemen het "geen emulator" om niet voor reverse-engineers door te gaan, want dan ontwikkel je tegen de runtime-data/program space van een closed-source systeem aan, wat het systematisch ontrafelen daarvan vereist.

Ja, Microsoft is de drijvende kracht achter de overgang van C naar C++. En C++ heeft ander vereisten dan C.

Runtimes betreft het verschil tussen interpreteren en compileren. Het verschil in Wine is de C++ builder. De terminology in deze layers is niks anders dan vendor-speak.

Dat de logica niet helder is, dat is evident.

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[blorf]

Met runtime-data bedoel ik de aanwezige, reeds in RAM geladen systeem- en programma-code. Iets ontwikkelen en distribueren dat daar rechtsstreeks aan komt of binary onderdelen vervangt is waarschijnlijk illegaal

[Reactie gewijzigd door blorf op 24 juli 2024 14:33]

[blorf]

Geen idee hoe je dat voor Windoiws uitlegt maar ik denk in *nix-stijl. Een gestarte executable wordt naar het geheugen gekopieerd. Dat is de runtime-data. Ook wel program space, maar in het geval van OS-onderdelen is "program" niet helemaal de correcte term. "System space" ?

[Reactie gewijzigd door blorf op 24 juli 2024 14:33]

[Bulkzooi]

Geen idee hoe je dat voor Windoiws uitlegt maar ik denk in *nix-stijl. Een gestarte executable wordt naar het geheugen gekopieerd. Dat is de runtime-data. Ook wel program space, maar in het geval van OS-onderdelen is "program" niet helemaal de correcte term.

Ja, Da's dus die vendor-speak en dan kan je ook nog de hypervisors en emulators erbij halen.

Maar ik heb het met @scholtnp over een interoperable app die portable is en wat Wine in die development flow nou toch allemaal uitspookt.

Ik adviseer hem om zijn unit test naar GNU/Linux te verhuizen.

[blorf]

Ik hoop dat MS eens een keer echt overstag gaat met OSS. Het is een kwestie van gekozen strategie, maar ze hebben genoeg in huis om een uiterst concurrerend game-platform neer te zetten waar gebruikers ook aan kunnen bijdragen. Het zou betekenen dat ik 3 meter games uit het XP-tijdperk weer kan doen zonder een speciale computer daarvoor.

[Bulkzooi]

Ik hoop dat MS eens een keer echt overstag gaat met OSS. Het is een kwestie van gekozen strategie, maar ze hebben genoeg in huis om een uiterst concurrerend game-platform neer te zetten waar gebruikers ook aan kunnen bijdragen. Het zou betekenen dat ik 3 meter games uit het XP-tijdperk weer kan doen zonder een speciale computer daarvoor.

Je hebt WASM tegenwoordig; Microsoft heb je daarvoor niet echt nodig en die hebben een aardig game platform als je het mij vraagt, met de Xbox en Bethesda en zo.

Die oude Windows XP games moeten gewoon runnen op nieuwe hardware volgens mij. Anders heb je echt goede projecten zoals RetroArch en Mame daarvoor.

Weer anderen runnen die oudere games in een VM of met OpenDos of zo. Met WASM zelfs in de browser

Keuze zat; vandaar ook dat Wine op zijn laatste benen loopt totdat enkel nog Proton over is.

Dat Wine überhaupt nog devs heeft..

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[blorf]

Alles 8- en 16-bit is op geen enkel modern OS een probleem. Wat oude XP-games betreft is naar mijn idee ongeveer 25% van de 3d-accellerated games bruikbaar op een recente Windows-installatie. Persoonlijk zou ik als dit wordt verbeterd meer Windows gaan gebruiken en daar ook meer voor over hebben. Dat is het tegenovergestelde van de situatie nu. Aan de offline XP-machine die ik heb staan verdienen ze niks en er zit behoorlijk wat werk in om het draaiend te houden.

[Reactie gewijzigd door blorf op 24 juli 2024 14:33]

[Bulkzooi]

Alles 8- en 16-bit is op geen enkel modern OS een probleem. Wat oude XP-games betreft is naar mijn idee ongeveer 25% van de 3d-accellerated games bruikbaar op een recente Windows-installatie.

Dat zeg ik; kijk gewoon eens naar glide, wasm, RetroArch en MAME.

Die projecten zijn al jááren bezig met forward compatibility van 8- en 16 bit games.

De d3d calls zullen in ieder geval niet voor de problemen zorgen.

[Reactie gewijzigd door Bulkzooi op 24 juli 2024 14:33]

[switchboy]

Wat een onzin!
Ga je eerst eens inlezen voor je onzin plaatst


https://nl.wikipedia.org/wiki/Direct3D

https://nl.wikipedia.org/wiki/OpenGL#Vulkan

[Reactie gewijzigd door switchboy op 24 juli 2024 14:33]