Software-update: Wine 7.11

Er is met versienummer 7.11 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.524 titels. In deze uitgave zijn de volgende veranderingen en verbeteringen aangebracht:

What's new in this release:

• Android driver converted to PE.
• Zero-copy support with GStreamer.
• High Unicode planes support in case mappings.

Bugs fixed in 7.11 (total 34):

• 33381: Mayhem Triple renders too small
• 33383: Foobar2000 crashes on Alt-H
• 34176: Kernel32:CompareStringW strange behavior ?
• 35027: Euphoria needs CreateProcessInternalW function
• 36720: LCMapString with the parameter NORM_IGNORENONSPACE does not remove diacritics
• 39144: SpinTires tech demo wrong rendering after changing screen resolution
• 39298: kernel32 does not support custom nls installation.
• 45634: enabling CSMT ruins performance for rFactor 1.255
• 46281: Multiple Windows 7+ apiset-aware applications fail due to Wine loader lacking support for resolving virtual dlls via 'kernel32.GetModuleHandle' (Archicad 22)
• 46782: CompareStringEx does not support SORT_DIGITSASNUMBERS flag
• 49210: Mafia and Mafia II: Definitive Edition Launcher crashes with Wine-Mono
• 49232: Saints Row The Third Remastered shows floating black rectangles
• 50941: Multiple applications crash on unimplemented function WS2_32.dll.WSAConnectByName (TIP-Integral, EasyMiniGW)
• 50948: taskmgr.exe: wrong memory usage unit (GB => MB)
• 51243: In Wine dinput:keyboard fails if the keyboard layout does not match the display language
• 52663: Civilization 4: no text in main menu
• 52752: Rich Edit Control does not support drawing OLE objects
• 52795: Multiple applications crash in Mesa due to syscall stack overflow (Cyberpunk 2077, Stranger of Paradise, Doom Eternal with ray tracing)
• 52831: Kernel32::GetSystemPowerStatus returns invalid data if /sys/class/power_supply/BAT0 is missing
• 52841: Leverless arcade controller SOCD cleaning does not work
• 52885: Adobe Lightroom Classic 11.1 crash in user32
• 52893: GreedFall crashes on launch
• 52993: msi:action - test_publish() fails on date change
• 52995: shell32:shelllink crashes in Wine cause shell32:shellpath's test_PathResolve() to fail (test.bat file)
• 52998: xaudio2_7:xaudio2 fails on Windows 1909+
• 53029: Clipboard cut/paste partially broken in wine 7.8.1.2
• 53035: Displaying Out-GridView in Powershell Core crashes with WinVer > Win7
• 53038: Epic Games Launcher crashes on start
• 53076: Kvaser CanKing needs ntoskrnl.exe.KfRaiseIrql and ntoskrnl.exe.KeLowerIrql
• 53082: "explorer: Create clipboard manager thread when creating a desktop." causes hangs on wine startup
• 53102: Ubisoft Connect fails to connect to server
• 53112: winegstreamer build error
• 53136: crypt32:cert - testVerifyRevocation() fails in Wine
• 53138: crypt32:chain - testGetCertChain() fails in Wine

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

Reacties (35)

[idef1x]

Leuk zo'n database, maar dat zegt ook niet alles...probeer al tijden trackmania werkend te krijgen. Heeft platina status en toch lukt het niet met gewoon wine...via playonlinux, via lutris en via steam....geen van allen werkt bij mij. Een howto is niet op winhq te vinden, dus zou toch piece of cake moeten zijn...

[TheVivaldi]

Welke distributie gebruik je? En welke Wine-versie? En wat precies werkt er niet: installeert niet, start niet? En welke foutmeldingen krijg je precies?

[idef1x]

Kan ik nu even niet zien, maar laatste ubuntu LTS (22.04)...installeert wel, maar blijft een wit scherm tonen..bij steam ook en als steam het niet kan... ;-)

[beerse]

Is dit deze fameuze Linux Desktop release waar het op slack over ging? Wine en WSL kunnen beter samengaan. Of krijgen we straks een rebranding naar Visual Wine of zo? Ik bedoel, SteamOS 3 groeit harder dan hun allebei bij elkaar.

Nope, dit is niet de fameuze linux desktop release.
Wine is een library/toolset/omgeving om onder linux te installeren zodat daar msWIndows gebaseerde programma's kunnen draaien.

wsl is onder msWindows tegenwoordig een geminimaliseerd virtueel systeem waar een bijgewerkte linux distributie in kan worden geïnstalleerd om daar binnen zonder problemen linux applicaties te draaien op msWindows systeem.

Het heeft geen toegevoegde waarde om in een wsl omgeving een keer wine te installeren. Als je wsl gebruikt draai je al een msWindows systeem, dan hoeft linux dat niet na te doen.
Andersom, een wsl in wine heeft ook geen toegevoegde waarde.

[Bulkzooi]

@beerse Ik draai nog altijd Win 7 en heb nooit Wine nodig gehad; enkel de directx9c runtime voor gaming, en nog enkele .dll's, o.a. voor surround sound.

De toegevoegde waarde ligt eraan waar je vandaan komt. Dus als je Windows 10 of 11 met WSL assumed, dan heb je gelijk. Maar kan Wine dan games spelen uit de Windows Store of zo? Xbox Live? Playstation PSN? Apple iTunes? Hoe zie je dat Wine de concurrentie aangaat met SteamOS wat betreft installbase op Linux Desktop? Die supporten al een zillion games en Steam Deck support ook al iets van de helft.

Ik zie eigenlijk alleen maar meer moeilijkheden voor Wine, met ook de browsers die steeds meer games gaan supporten. Van de games die in DOS draaien, draaien tegenwoordig de meesten ook in de browser. En waarom zou je in een moderne Linux Distro, dus met GBM/MESA, nog eens Wine installeren? Ook lijkt Retro Arch me beter qua backward compatilibity met oude games op Linux.

Overigens, snap ik je punt niet in relatie tot mijn post:

in een wsl omgeving een keer wine te installeren heeft geen toegevoegde waarde
..
Andersom, een wsl in wine heeft ook geen toegevoegde waarde.

Say what? Bedoel je inelkaar compileren of zo? Je kan software niet in elkaar installeren. lol, dan krijg je gegarandeerd conflicten. Maar het is allemaal wel in C geschreven, behalve wat fancy stuff dat op de GPU draait.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 17:22]

[beerse]

@beerse Ik draai nog altijd Win 7 en heb nooit Wine nodig gehad; enkel de directx9c runtime voor gaming, en nog enkele .dll's, o.a. voor surround sound.

De toegevoegde waarde ligt eraan waar je vandaan komt. Dus als je Windows 10 of 11 met WSL assumed, dan heb je gelijk. Maar kan Wine dan games spelen uit de Windows Store of zo? Xbox Live? Playstation PSN? Apple iTunes? Hoe zie je dat Wine de concurrentie aangaat met SteamOS wat betreft installbase op Linux Desktop? Die supporten al een zillion games en Steam Deck support ook al iets van de helft.

Ik zie eigenlijk alleen maar meer moeilijkheden voor Wine, met ook de browsers die steeds meer games gaan supporten. Van de games die in DOS draaien, draaien tegenwoordig de meesten ook in de browser. En waarom zou je in een moderne Linux Distro, dus met GBM/MESA, nog eens Wine installeren? Ook lijkt Retro Arch me beter qua backward compatilibity met oude games op Linux.

Overigens, snap ik je punt niet in relatie tot mijn post:

Volgens mij heb jij het product 'wine' niet helemaal juist op je netvlies.

Wine is niet voor msWindows systemen. Wine is voor linux systemen zodat ze daar msWindows programma's kunnen draaien.

Kijk bij de specificaties hier boven, het is alleen maar beschikbaar voor unix en linux. Het is er niet voor msWindows en zal er ook voor msWindows nooit komen.

[Bulkzooi]

je reageert op dat ik zeg dat Wine en WSL beter kunnen samengaan. Het is dan nogal kortzichtig om enkel van één van beide OS'en uit te gaan. Dan zeg je iets over inelkaar installeren en dan raak je me helemaal kwijt.

Die specs waar je het over hebt, die zijn er al en die staan los van Wine; da's gewoon een software implementatie in C. En die staan ook los van Powershell trouwens. Die specs, het zijn er meerdere, gaan meer over interoperabiliteit en portabiliteit zoals POSIX bijvoorbeeld.

SteamOS en ook het nieuwe Nest OS van Google (eerst bekent onder Fuchsia OS) zijn goede voorbeelden van hoe het ook kan. Ook Retro Arch is erg inspirerend.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 17:22]

[TheVivaldi]

Huh? Wine en WSL zijn twee volledig verschillende producten.

[TheVivaldi]

Maar Wine en WSL doen totaal verschillende dingen, dus ik snap niet helemaal wat je bedoelt? Het is net alsof je zegt dat Fiat en Vespa één carroserie moeten gaan aanbieden omdat ze toevallig allebei iets met gemotoriseerde voertuigen doen. Maar je kunt niet een autocarrosserie gebruiken om een Vespa te bouwen. Het zal me dan ook een worst wezen op welke OS'en Wine en WSL draaien, het gaat er om dat ze zó verschillend zijn dat ze nooit van hun leven samen kunnen gaan. Auto vs brommer, dus.

[Chris_147]

Ik lees je reacties, maar begrijp totaal niet wat je nu eigenlijk wilt.
Wine en WSL samenwerken, hoe dan?
Wine in WSL draaien? Dan draai je dus Windows applicaties op de Wine compatibiliteitslaag op Linux dat in WSL op Windows draait. Dan kan je beter gewoon Windows applicaties op Windows draaien, want dat heb je toch al draaien
WSL in Wine draaien? Dan draai je Linux op Windows compatibiliteitslaag in Linux. Lijkt me ook niet efficiënt.
Dus kan je eens duidelijk toelichten wat je wil?

Daarnaast begrijp ik niet wat het probleem zou zijn met SteamOS. Zelfde voor Fuchsia.

[Drumar]

Ik werk al een kleine 20 jaar met wine, pakweg 10 jaar langer met Linux... Een ik volg je totaal niet.

Wine is een implementatie van de Windows API zodat je daarmee Windows applicaties op een posix systeem kan draaien. WSL is een container waarbinnen een Linux omgeving direct met de Windows kernel kan praten. Dat is echt heel anders, ik vrees dat hij degene bent die zaken door elkaar haalt

StreamOS is, wat kort door de bocht, een Linux met wine er op. Wel een aanpassing op de standaard wine, met nadruk op gaming.

[xFeverr]

Volgens mij begrijp je niet helemaal wat Wine is -of- begrijpt niemand hier wat je zegt.

Grappig dat je het ook over Steam en SteamOS hebt. Die gebruiken dus ook veelvuldig Wine om het voor elkaar te krijgen Windows-games op Linux te kunnen gebruiken. En dat noemen ze Proton.

Proton is a tool for use with the Steam client which allows games which are exclusive to Windows to run on the Linux operating system. It uses Wine to facilitate this.

(Bron)

[Reactie gewijzigd door xFeverr op 22 juli 2024 17:22]

[Xander2]

Ik gebruik geen OpenBox maar ik verwacht dat elke professional in 2D/3D een compositing window manager gebruikt i.p.v. Win3.1 style stacking, voor het tekenen wil je de GPU hanteren, niet de archaische aan elkaar geknoopte X11 protocollen die de CPU belasten.

Da's een beetje de insteek van de door jouw verfoeide Wayland, het woud aan knip-, plak- en hackwerk van protocollen van een bejaard ontwerp als X11, d.w.z. toen 3D, shared libraries vrijwel niet bestonden en elke drawing primitive in CPU werd gedaan, bij het vuil zetten, sterk versimpelen en aan te passen aan nieuwere hardware mogelijkheden. Zelfde route die MacOSX en Windows ook hebben genomen.

En de Linux Desktop is voor mij al minstens een decennium een succes en ik heb geen enkele behoefte om een gedrocht als Win32 API met dependencies en hacks naar binnen te hengelen, laat staan moeite te doen om anderen te overtuigen Windows te vervangen als ik daar geen last van heb.

Wine is puur een oplossing voor binaries alleen voor Windows gecompileerd zonder gelijkwaardig alternatief wat het meest naar voren komt in games, vandaar SteamOS. En dat is het doel, Win binaries draaien, niet iedereen Linux voor desktop te laten gebruiken of overgang te vergemakkelijken.

Verder, de gemiddelde linux desktop gebruiker heeft geen behoefte aan Wine of Windows applicaties gezien de belabberde staat van Wine in menig populaire distro en popularity contest over de jaren en een minimalistische setup biedt ook niet de meest efficiente of geavanceerde workflow; je zit met name jezelf nogal in de weg als je in een DOS schermpje blijft steken.

[Drumar]

Ik draai dus al zo'n 30 jaar GNU/Linux, in die applicaties die enkel beschikbaar zijn voor Windows toch te kunnen gebruiken, geen ik dus wine 🍷, de implementatie van de Windows API op posix

Ziehier de workflow.
Overigens waren het veelal games die ik op deze manier speelde, juist daarvoor is vaak helaas geen goed Linux alternatief beschikbaar, alhoewel dat een beetje lijkt te veranderen

[xFeverr]

woooow... wat? Dat gaming op Linux niet zo best is dat klopt wel. En dat Linux op de desktop uberhaupt niet zo'n succes is klopt ook. De rest van het verhaal is echt heel lastig te begrijpen. Ik snap er echt geen fluit van, en met mij iedereen hier volgens mij.

Ik ben overigens geen Linux fanboy. In de verste verte niet, mijn dagelijks werk en expertise ligt bij de Microsoft stack. Dus daar kun je mij in ieder geval niet van betichten. (Als dat is wat je doet, want nogmaals... begrijp er weinig van)

Daarnaast: Chocolatey is niet van Microsoft dus die oplossing hebben ze niet zelf gemaakt. Ze hebben wel iets dat WinGet heet en vergelijkbaar is. Maar Chocolatey is niet van MS. Ik gebruik ze beide overigens niet.

En als laatste:

Vóór WSL syncte ik vanaf Windows weleens projecten naar een remote Bitbucket met een Mercurial CVS of met TortoiseSVN naar Apache Subversion CVS,

WAT? Vóór WSL is vóór augustus 2016 btw. Maar wat staat er nu? Bitbucket icm Mercurial, Subversion en SVN? HUH!? En dan nu zeggen dat dat obsolete is sinds Github, terwijl Bitbucket zelf al Git is? Heb je nu gewoon 4 versiebeheersystemen achter elkaar gezet zonder enige samenhang? Of snap je er echt he-le-maal niks van? Nee toch? dit doe je expres?

Ik vind het knap dat je keer op keer een enorme nietszeggende onsamenhangende woordenbrij kunt neerpleuren die niemand hier begrijpt en waar geen hout van klopt. Mijn (dubieuze) complimenten daarvoor.

[Reactie gewijzigd door xFeverr op 22 juli 2024 17:22]

[Bulkzooi]

@xFeverr. Heb je überhaupt ooit weleens aan lokaal versiebeheer in een shared repository gedaan? Anders vertel ff welke tools je gebruikt en hoe jullie toen bv. je vertalingsprojecten managen over meerdere teams en meerdere operating systems met verschillende locales en verschillende tijdzones.

Maar ik heb aangepast dat Chocolatery niet van Microsoft is. Overigens gebruikte ik TortoiseHg om te syncen naar een Mercurial repo op de Bitbucket service zonder dat ik Wine nodig had. My bad.

Maar waarom get erbij halen? Dat heeft helemaal niks met versiebeheer te maken.

lol, en waarom denk je dat Linus zelf git ging schrijven? Omdat hij zo happy was met de mogelijkheden op GNU/Linux? git is van 7 April 2005 btw.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 17:22]

[Drumar]

Ik ken alle termen die je noemt, en lees ook prima. Je verhaal raakt alleen kant noch wal.

Gaming suckte altijd al bigtime op GNU/Linux en de Linux Desktop is al 3x mislukt. Vanwaar die weerstand? En dan nog wel terwijl nu ook Google Chrome FlexOS, wat ondertussen op de meest gangbare architecturen draait, nu net de install-base écht gaat laten groeien.

Het is ongetwijfeld zelfs vaker dan dat mislukt. Dat hangt in grote mate ook af van wat andere zaken:
- Aanbod A-rating games
- De Linux desktop is niet voor iedereen weggelegd, daar zaten nog best wat drempels voordat een leek dingen opgestart kreeg.

Maar zoals gezegd: ik draai dus al pakweg 20 jaar die A-rating games die enkel voor windows (en mac, toegegeven) aangeboden worden gewoon via Wine. Dat is me al die tijd prima gelukt, vaak met betere fps en andere performance dan onder Windows. (dit gevalideerd doordat ik indertijd nog een dual boot opstelling had)

Dat X11 niet de meest efficiente oplossing is, maar lang wel de enige oplossing was, is inmiddels wel duidelijk geworden.

maarrrr... je haalt een hele hoop zaken door elkaar en je spreekt jezelf nogal tegen, dat maakt het wat lastig te uit te vogelen wat je punt is.

En dat heeft niks met een OS te maken maar meer met terminolgy en wat verschillen tussen OS'en, talen en het historisch verloop daarvan.

... heeft het nou wel of niet met een OS te maken? ;-)

De lijst van dependencies van wine is eigenlijk heel beperkt. Alleen... op het moment van compileren bepaal je welke zaken er in moeten komen. En daardoor wordt de lijst met dependencies wat groot. Gezien ik Wine al net zo lang zelf compileer als dat ik het gebruik heb ik daar wel een redelijk beeld van ;-) Stel dat je LDAP zaken met wine wilt kunnen doen, dan wordt libldap een dependency. Dat zal je merken bij package managers: daar is het vooraf gecompileerd, met een zo groot mogelijke doelgroep, dus ook met een heel breed scala aan dependencies. Dat ligt niet zozeer aan wine zelf; Zeker door de implementatie van de windows API... In zekere mate zou je iets vergelijkbaars kunnen zeggen over de Linux kernel. Heb je wel eens naar de opties gekeken die daar allemaal in zitten? Grote kans dat de kernel die jij hebt draaien een hele hoop dingen kan die je nooit of te nimmer zal gebruiken. Maar de packager wil niet voor iedere aparte workflow een aparte kernel compileren. Zelfde geldt dus voor Wine. Maar omdat ze niet de LDAP stack (ik neem die maar als voorbeeld) zelf opnieuw uitvinden en in de code zetten, laten ze die implementatie over aan een welbekende library. Dependencies zijn dus niet per-se slecht.

Tegenwoordig (ik ben kwijt sinds wanneer, maar het is al ruim een jaar) ondersteunt wine ook Wayland. Dus de hele rant over X11 snap ik niet. Dat wine flakey is: het is niet perfect; verre van... maar mijn respect heeft het zeker: zoveel windows versies die al goed ondersteund worden (beter dan de ondersteuning van Microsoft voor oude versies van windows) en steeds meer zaken die gewoon heel goed werken. Bloated is het zeker niet. Wel groot. Maar dat is inherent aan het product: de implementatie van een bloated product is zelf net zo bloated ;-) Als ik de eiffeltoren exact na probeer te bouwen (1 op 1) moet je niet gek opkijken dat er een heel groot gevaarte komt te staan.

Dan je verhaal over CVS / SVN / Git.
Dit zijn drie verschillende manieren om projecten met meerdere mensen tegelijk te delen. CVS is de oudste (zover ik weet), maar liep al snel tegen beperkingen aan; SVN heeft geprobeerd deze op te lossen... maar volgens Linus Torvalds wel op een verkeerde manier. En zo werd Git geboren. Het zijn alle drie vormen van een concurrent versioning systeem; Je opmerkingen over Mercurial en Tortoise doen me vermoeden dat je zelf vooral op de windows stack werkt. Dat is prima, dat doen meer mensen...

[Bulkzooi]

Je forceert me om te herhalen..

1> Het aanbod van games; De uitgevers waren niet het probleem. GNU/Linux was het probleem.
2> Het heeft met de verschillen tussen OS'en te maken. Niet met karakteristieken van een specifiek OS. Nogmaals, da's heel het punt van mijn opmerking en betreft dus interoperabiliteit. Da's nu de 4e keer dat ik hetzelfde tegen je zeg maar je leest continue verkeerd. Da's al een hele prestatie op zich.
3> X11 en MiR/Wayland zijn belangrijk voor Wine en Gaming, maar qua Linux Desktop zit het al een eeuw in de weg en in textmode is het totaal overbodig; een composite manger zoals xrandr is voldoende. Kijk enkel maar naar de distrohoppers die switchen vanwege window managers. Het zelfde geldt overigens voor package managers.
4> Je mist compleet de moeilijkheid van versiebeheer. Maar de problemen zitten hem mn. tussen een lokaal systeem om sourcecode te onderhouden, en het syncen met een remote systeem, evt. met meerdere teams, tijdzones, etc.. Tegenwoordig wordt ook Gitea en/of Gitlab ingezet om elementen van de workflow en het process te managen.

Anyway, je blijft dezelfde fouten maken. Dus je bent niet eens bekent met een latex workflow, noch met de commando's en tools om effectief een systeem te beheren. Je mist alle praktische ervaring en je praat als een Wine gebruiker die het allemaal beter weet. lol, een winegebruiker die het beter weet.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 17:22]

[Drumar]

Je reactie laat al het een en ander blijken.... De lol maakt het af ;-)

1> Dat de Unreal engine native prima werk levert op Linux maakt duidelijk dat het probleem niet in het OS zit. Daar lees _jij_ dan weer steeds overheen.
2> Gezien meer mensen in deze thread ongeveer hetzelfde zeggen, dat je verhaal kant noch wal raakt, zou weleens kunnen betekenen dat het probleem niet alleen bij de ontvanger zit, maar wellicht ook bij de zender?
3> X11 en Wayland zijn geen window managers; Wayland schurkt er een beetje tegenaan, daar zit volgens mij standaard een soort van window manager bij. Bij X11 zit dit heel expliciet niet. Daar heb je dus perse een window manager bij nodig, en daar heb je nogal wat van. Van tiling tot compositing window managers. Je hoeft niet van distro te switchen als je een andere window manager wilt. De een zweert bij Gnome, de ander bij KDE weer een ander wil TWM of NextStep... Ook voor je package manager hoef je doorgaans niet over te stappen, tenzij je Suse draait... De meeste package managers tegenwoordig (apt, dnf en yum) doen vrij behoorlijk hun werk. Ik ben geen fan, maar het is voor mij geen blocking ding. Gezien ik al ruim 30 jaar Slackware draai, kan ik best uit de voeten met het zelf compileren van de packages die ik nodig heb.
4> Versie beheer is moeilijk; ik weet er alles van. Je maakt van een applicatie die van een standaard gebruik maakt meteen een product. Gitlab is een product dat git gebruikt, net als github ... Zowel gitlab als github komen met een sloot meer producten om de workflow verder te optimaliseren.

Dat ik de LaTeX flow wel of niet ken, lijkt mij irrelevant. Dat ik niet bekend zou zijn met de tools en commando's om effectief een systeem te beheren.. mwah. dat durf ik wel te betwijfelen Waar je dat nu precies uit opmaakt, ontgaat me totaal. Lijkt me een gevalletje onnodig en ongefundeerd zwartmaken.

Je mist alle praktische ervaring en je praat als een Wine gebruiker die het allemaal beter weet. lol, een winegebruiker die het beter weet.

Vertel. Welke practische ervaring mis ik zoal?

[Bulkzooi]

Heel simpel @Drumar Lees mijn eerst post nog eens, probeer mijn antwoorden nog eens te lezen, en lees dan jouw posts nog eens.

Wat betreft die commando's om te beheren. Daar zit je verwarring in; die zijn niet statisch geweest sindsdien. Maar je beantwoordt niks, voegt allemaal irrelevante anekdotes over jou game ervaringen in, maar dat voegt echt niks toe. Dus dan kan je wel Slackware gebruiken en zo, maar het gaat dus over commando's zoals install, upgrade, update, merge, emerge, en nog duizenden oplossingen.

Die LaTeX workflow voegt wel iets toe, want het gaat over textmode users, als subgroep in de linux desktop gebruikers. Jij begint nou weer over X11, terwijl alleen xrandr de composite manager relevant is voor de workflows die we bespreken.

Github gaf toen maar 1 repo en dat was voor mij de belangrijkste reden om voor bitbucket te kiezen. Maar uiteindelijk wil je het vooral lokaal op orde hebben, met ook sync mogelijkheden. Bovendien zijn dus de lokale mogelijkheden enorm gegroeid met gitea en gitlab. Maar denk dan meer aan issues, projectmanagement, teams, etc. en ook CI automation heeft veel toegevoegd. Overigens, ook een m2m workflow die textgebaseerd is. Alleen die flow groeit al harder dan dat Linux desktop ooit gedaan heeft of ooit zal doen.

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 17:22]

[Drumar]

Dit is een topic over Wine. Dat ik dus mijn anekdotische ervaringen over _mijn_ gebruik van Wine deel, is on-topic en draagt daarin bij. Wat ik allemaal nog meer met Linux doe was enkel om te illustreren dat het zich niet beperkt tot alleen gaming on linux. Ik gaf dus enkel aan dat ik dat wel doe, en dat dat prima werkt. Overigens is dat ongeveer de enige manier en plek waar ik zelf Wine gebruik. Voor de rest heb ik waardige alternatieven die native goed op Linux werken.

Ik pak je eerste post er even bij:

Is dit deze fameuze Linux Desktop release waar het op slack over ging? Wine en WSL kunnen beter samengaan. Of krijgen we straks een rebranding naar Visual Wine of zo? Ik bedoel, SteamOS 3 groeit harder dan hun allebei bij elkaar.

Intussen hebben meerdere mensen een poging gedaan je te vertellen dat Wine en WSL combineren een beetje absurd is. Er is inmiddels ook verteld over SteamOS wat in feite een Linux distributie met een van de flavours van Wine er op (uit mijn hoofd Proton)

Ik raad je af werk te zoeken in de kerkklokken business... want klokken en klepels kunnen wat verwarrend overkomen.

[THETCR]

De Windows API is precies het gene wat Wine afvangt en met thunks omzet naar de juiste Linux calls.

Voor de rest roep je maar wat namen die verder niks te maken hebben met het Wine en WSL concept en trek je scheve vergelijkingen en classificeer je producten verkeerd omdat je volgens mij maar een globaal idee hebt van wat het allemaal doet.

[Drumar]

Zou het gewoon een troll zijn

[THETCR]

Weet je überhaupt wel wat thunks zijn?

Mocht je Chocolatey bedoelen: dat is een package manager wat scripts uitvoert. Heeft hier niks mee te maken.

Zo lees ik wel meer incorrecte statements van je.

OpenGL is ook geen framework maar een interface en bevat geen Vulkan. Vulkan is namelijk de opvolger voor OpenGL.

QT is ook geen toolkit, maar een front-end framework wat cross platform compatible is.

Zit je toevallig meer aan de business kant van de IT?

[Reactie gewijzigd door THETCR op 22 juli 2024 17:22]

[Bulkzooi]

haha, nou aangezien je niet leest en niet antwoord:
het gaat over het weinige succes van de linux desktop, en versiebeheer is een essentieel vereiste daarin. En daar gebruikt men een package manager voor, en als het project groter wordt is het ook gebruikelijk om een versiebeheersysteem te gebruiken.

Tunks is een naam die een of andere gast van Wine gekozen heeft en wat enkel gerelateerd is aan het falen van GNU/Linux gaming. Aangezien er ook geen betere oplossingen waren op GNU/Linux is het ook niet moeilijke te verklaren waarom de Linux Desktop en GNU/Linux gaming nooit van de grond zijn gekomen, hoewel toolkits als GTK en QT desktop userspace wel wat dragelijker hebben gemaakt.

Vandaar mijn voorstel, en SteamOS toont aan met Proton goede bezig te zijn, en ook Google laat zien hoe het moet met Chrome OS Flex. Wine daarentegen is een totally bloated en buggy product en heeft zijn bruikbaarheid allang verloren. Helemaal nu je alternatieven hebt als virt-manager hebt.

[THETCR]

het gaat over het weinige succes van de linux desktop, en versiebeheer is een essentieel vereiste daarin. En daar gebruikt men een package manager voor, en als het project groter wordt is het ook gebruikelijk om een versiebeheersysteem te gebruiken.

Versie beheer zijn dingen zoals Git. Wat een op zichzelf staand iets en niks te maken heeft met package managers.
In projecten worden package managers gebruikt voor het beheren van dependencies.

Tunks is een naam die een of andere gast van Wine gekozen heeft en wat enkel gerelateerd is aan het falen van GNU/Linux gaming.

Thunks is een programmeer term voor het toevoegen van routine. Dit wordt veelvuldig gebruikt voor (backwards) compatibility, door een API call af te vangen, data te muteren waar nodig en vervolgens de juiste API aan te spreken. Microsoft doet dit bijvoorbeeld om de Win32 APIs wel te kunnen veranderen en oude applicaties wel blijven werken. Dat concept komt niet bij Wine vandaan.

hoewel toolkits als GTK en QT desktop userspace wel wat dragelijker hebben gemaakt.

QT is geen toolkit maar een front-end framework. En na mijn mening een verschrikkelijke één.

Vandaar mijn voorstel, en SteamOS toont aan met Proton goede bezig te zijn, en ook Google laat zien hoe het moet met Chrome OS Flex. Wine daarentegen is een totally bloated en buggy product en heeft zijn bruikbaarheid allang verloren.

Appels en peren. Je probeert een OS te vergelijken met een software applicatie.
Daarnaast is Proton een fork van Wine met wat toevoegingen van Valve.

[Bulkzooi]

ok, wat jullie tunks 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.

[THETCR]

WSL is voornamelijk bedoeld voor ontwikkelaars. De Linux images draaien in containers en bevatten aangepaste kernels zodat ze rechtstreeks gebruiken maken van de Windows NT primitives, in plaats van thunks om de Linux API calls af te vangen.

Wine is echter een Linux applicatie die thunks gebruikt om Windows/Direct3D calls etc. af te vangen en de juiste Linux API's aan te roepen.

Ook al vallen beide in de categorie "compatibility layer", zijn het twee compleet verschillende projecten en zou het totaal onlogisch zijn om ze samen te voegen.