Plannen voor Wine 1.0 gepresenteerd

In een speciale editie van de Wine Weekly Newsletter is door een van de medewerkers van het Wine-project geschetst hoe de toekomst van het programma er zal uitzien. Het is de bedoeling dat versie 1.0 van Wine tegen het einde van dit jaar het levenslicht ziet, voorafgaand daaraan zullen er twee maanden lang alleen maar bugs opgelost worden. Voordat het zover is, moet er nog het een en ander gebeuren. Zo zal het Wine-register nog enige veranderingen moeten ondergaan en is het de bedoeling dat de IDL-compiler featurecompleet zal zijn. Door middel van een IDL is het mogelijk om programma's met elkaar te laten communiceren, ook als ze niet in dezelfde 'taal' gebouwd zijn.

Wine HQ-logoVerder is het de bedoeling dat Wine 1.0 zal beschikken over functionaliteit om met kopieerbeveiligingen om te gaan. Een andere belangrijke feature die in deze eerste finale versie van Wine zijn opwachting zal maken, is de mogelijkheid om het overgrote deel van de Direct3D-applicaties te kunnen gebruiken. Ook aan andere DirectX-features, te weten DirectInput, DirectSound en DirectPlay, wordt hard gewerkt. Onder meer door de afwezigheid van documentatie is dat echter geen eenvoudige taak. Volledige compatibiliteit met Windows op dit gebied is geen vereiste voordat Wine 1.0 gereleased zal worden.

Volgens de Wine-developers zal het niet enorm veel werk zijn om Direct3D10, dat met Windows Vista zal worden meegeleverd, in Wine te gaan ondersteunen. Interessant hieraan is dat het mogelijk zou moeten zijn om de Wine-implementatie van Direct3D10 te porten naar Windows. Dat zou betekenen dat het toch mogelijk wordt om Direct3D10-games op eerdere Windows-versies dan Windows Vista te spelen. Microsoft zelf zal namelijk DirectX10 alleen beschikbaar stellen voor die Windows-release. In de nabije toekomst zullen in Wine verder bugs gefixed worden in het verwerken van RPC-calls over een TCP/IP-verbinding. Verder zal de support voor Visual Basic-applicaties vervolmaakt worden.

Een ander gebied waar door de Wine-ontwikkelaars de komende tijd veel aandacht aan geschonken zal worden, is het verder verbeteren van de Mac OS X-versie van de software. Die versie is namelijk vooralsnog gemiddeld drie keer zo langzaam als de Linux-versie van Wine. Verder zal er gewerkt worden aan het beter compatibel maken van de software met de Mac OS X-kernel. Dit is geen eenvoudige opgave, omdat de Wine-developers tegen verschillende problemen met de genoemde kernel aanlopen. Dit wordt waarschijnlijk veroorzaakt door het feit dat Wine codepaden aanroept die door zeer weinig andere software gebruikt worden. Vanuit Apple wordt echter op een positieve wijze meegewerkt.

Door Harm Hilvers

Freelance nieuwsposter

30-09-2006 • 00:01

57

Bron: WineHQ

Reacties (57)

57
56
28
3
0
22
Wijzig sortering
Wine is leuk als tijdelijk oplossing of als je even een windows applicatie moet draaien. Ik gebruik het amper want native oplossingen zijn vaak toch beter (zeker als je het veel moet gebruiken). Maar toch fijn dat het bestaat.
@madman

Wine is een kopie, althans een poging tot van de Win32 API, het is dus native.

Wine is not an emulator ;)
het mag dan een poging zijn om de Win32 API te implementeren, het is nog steeds (helaas) veel trager dan native onder windows, met name games.
Niet te min, erg netjes dat ze zo ver zijn gekomen.
Functionaliteit heeft de hoogste prioriteit, niet optimalisatie (weet je nog hoe "snel" de eerste releases van Firefox draaiden?) En de reden dat games zo langzaam zijn is dat veel aspecten van de 3D ge-emuleerd moet worden omdat er nog geen vertalingen naar de hardware zijn. Hier zijn met uitgebreidere implementaties van D3D code nog relatief eenvoudig flinke winsten te behalen.
Ik draai World of Warcraft toch echt soepeler onder Linux met Wine dan onder Windows hoor ;)
Het is niet correct dat Wine trager is. Er zijn juist benchmarks die aangeven dat Wine op sommige gebieden zelfs sneller is dan Windows:
http://www.linux-watch.com/news/NS6148938546.html

alleen sommige 3d onderdelen zijn nog wat trager, maar daar gaan ze nu dus nog hard aan werken.
Dit is voor legacy applicaties, die je vroeger op windows had en nu ook nog op Linux wil blijven gebruiken, misschien omdat je er nog aan gehecht bent, of omdat er geen vervanger voor is.
Ik gebruikte toen ik overstapte nog een tijdje mirc, omdat ik mijne helemaal customized had met scripts enzo. Na een tijdje vond ik xchat toch beter, juist omdat mirc zo rommelig was geworden :+
Ik kan me ook voorstellen dat er mensen zijn die MS Office op wine willen draaien, zolang ze nog moeten wennen aan openoffice, of er uberhaupt niet aan willen wennen.
Ik denk dat alle Linux -distribiteurs dit zouden moeten supporten; het (niet) ondersteunen van in gebruik zijnde Win applicaties is een vrijwel onneembare drempel voor bedrijven om Linux voor de desktop zelfs maar te overwegen.
Hoe zouden ze dat dan moeten doen? Het is namelijk niet zo moeilijk om een optie aan te bieden tijdens de installatie om Wine mee te installeren (of het zelfs standaard mee te installeren)

Maar waar moeten bedrijven terecht met vragen over Win32-applicaties onder Linux (via Wine)? Moet een Linux fabrikant mensen hebben die weten wat er allemaal mis kan gaan? Met de vele honderden maatwerk pakketten is dat bijna onmogelijk...

Verder is het natuurlijk de vraag in hoeverre Wine 1.0 al feature-compleet is, welke Win32 API wordt er geimplementeerd (keuze uit meer dan 5 Windows versies). Uit het bericht op WineHQ is overigens helaas niet op te maken wat ze als referentieplatform genomen hebben - voor bedrijven die evt. over willen stappen is het echter heel belangrijk om te weten of de door hen gebruikte applicaties gaan werken op "Winux"....

/me Penguin gaat Wine overigens wel weer eens een keertje uitproberen. Er is in 4 jaar namelijk wel enorm veel veranderd.
Met winecfg kan je instellen welke Windows je wilt 'draaien'. Je kan zelfs aangeven dat wine bij een bepaald programma een andere Windows API moet nabootsen.
Ik hoop dat 1.0 ook Dreamweaver zal ondersteunen.

Dan kan ik de overstap op Linux volledig maken.
Hoezo dreamweaver? Op linux heb je toch ook gewoon vi?

;-)
Dat hier vanaf Apple positief aan meegewerkt wordt is prachtig. Dat betekent dat zij open staan voor het draaien van Windows-programma's op hun besturings systeem. En Linux ook. Als Microsoft hier uiteindelijk ook in mee zou gaan omdat Apple meegaat, komt het er misschien ooit in de hele verre toekomst nog eens van dat gecompileerde applicaties op alle 3 de platformen zullen werken.. Maar dan is er nog een lange weg te gaan.
Ik zie eerder een volledige implementatie van het .NET framework gebeuren dan willekeurige win32 binaries die op elk platform draaien.
Ik niet, want al is het veel moeilijker, het laatste is veel interessanter dan het eerste.
Ik zie persoonlijk beide gebeuren, mono is al heel ver met het framework en het is ook een stuk makkelijker dan bij de win32 API, maar ik denk dat het toch zeker mogelijk is dat in de toekomst nagenoeg alle applicaties waarvoor geen (goede) kloon te verkrijgen is op elk systeem onder wine kunnen draaien.
Misschien als de bedrijven nu eens een licentie betalen voor de Windows toevoegingen had het allang geintregeerd kunnen zijn/worden. Dat is denk ik ook het probleem voor MS om dat zomaar weg te geven, MS krijgt ook niets van de andere developers voor niets ;)
Er is toch nog een hemelsbreed verschil tussen het spelen van DirectX spellen op Wine tegenover Cedega hoor. Ik denk dat ze er een beetje licht over gaan om alles te kunnen ondersteunen. Bijvoorbeeld copy protection en shaders zijn al jaren in ontwikkeling bij TransGaming, en dat doen ze niet op één-twee-drie na voor Wine.
Ik ben een van de Wine ontwikkelaars en onze Shader ondersteuning is veel geavanceerder dan Cedega. Al enkele maanden ondersteunen wij Shader Model 3.0 dmv GLSL. Cedega implementeerd nog niets eens 2.0. Onze ondersteuning is hier en daar nog buggy, maar werkt al wel goed.

Verder Cedega is een zeer oude fork van Wine (toen Wine nog X11 gelicenseerd was) en wordt uitgegeven onder een niet-LGPL vriendelijke licentie. Wine kan niet naar Cedega code kijken. Tevens is alleen de code van een zeer oude Cedega (toen het nog WineX was) 'opensource'. Ze onderhouden deze versie nog wel een beetje. Ze voegen dan enkele LGPL wine dlls toe met hun wijzigingen.
Dat doen ze inderdaad niet 1 2 3. Daar zijn ze al een jaar mee bezig. ;)
Ze hebben het meeste werk maar terug te porten uit Cedega, of ze kunnen er gaan kijken om te zien hoe zij het gedaan hebben aangezien het grootste deel van Cedega terug onder de GPL is vrijgegeven.
Moet er niet iets van een korte inleiding "wat is wine" in het artikel staan?
Ik dacht namelijk eerst dat het misschien een ander project was dan de wine die ik kende.
Dacht dat die inmiddels al lang op versie 1 zaten.
Wine 1.0 > Windows(whatever) + Direct(whatever) .. :P

Gelukkig is de 0.9.19-versie die ik nu gebruik ook al geschikt om mee te gamen (alhoewel ik het enkel gebruik voor het oude Monkey Island 4). Ik vraag me alleen af of met alle virtualisaties van systemen er nog een toekomst of gebruikersgroep overblijft voor Wine. Als je het nog nooit gebruikt hebt, zul je het waarschijnlijk nooit meer nodig gaan hebben.

Dan blijf je gewoon Windows-kneus ! }>
directx10 komt echt wel voor xp. Wacht maar af. Zo gaat het elke keer met die beloftes.
DX10 is niet backwards compatible ;)

http://www.driverheaven.net/articles/dx10/

En het is wel logisch dat het niet backwards compattible is omdat de hele Vista kernel anders te werk gaat met de verschillende hardware. Wel leveren ze een emulator in Vista voor DX9, maar dan kan je voorlopig net zo goed doorgaan met XP, aangezien de emulator toch weer wat vertraagd.
Als Microsoft weer aankomt met zo'n "het is een integraal onderdeel van het operating systeem en kan niet zomaar losgekoppeld worden"

.. dan open ik m'n internet-explorer op m'n ubuntu-bak en probeer windows update te draaien.

Wat zullen de quality assurance mannetjes toch raar opkijken.

Is het iemand trouwens al opgevallen dat je met Wine + IE de windows-genuine verificatie _slaagt_ .. jaja ,, wine is genuine windows. Aldus microsoft wanneer ik directX probeer te installeren. Helaas werkte dat niet, maar ja zo gek ik dat nou ook weer niet.

Humor toch.
Euh.. Ms belooft niets. Ze zeggen juist dat het _niet_ beschikbaar komt voor XP.

Waarom zouden ze daar over 'liegen'. Als ze het achteraf toch beschikbaar stellen, snijden ze zichzelf alleen maar, doordat er dan weer een reden minder is om naar Vista te gaan.

IMO wel erg kool als door wine dadelijk toch een dx10 voor xp kan worden gebakken.

Trouwens er worden nogal wat 3d accelerator gl toestand pakketen gebouwt voor xorg enz, is het niet handig om bv de wine implementaties van DX10 daarvoor te gaan gebruiken. Opengl ligt al zolang stil, en is een drama met zijn 982340 fabrikant specifieke extensies, die nooit hetzelfde werken.
IE7 was vista exclusief en de iPod killer bestond ook niet.
IE7+ is vista exclusief
En een Ipod killer is er ook nog niet :P
Als DirectDraw nou ook ondersteund gaat worden, dan kan ik StarCraft en Red Alert, en alle dergelijke spellen uit die tijd, soepel spelen zonder het commerciële Cedega.
Onder Wine 0.9.15 kan ik StarCraft: Brood War zonder problemen spelen.
Hmm, wine 0.9.8 is de nieuwste stable in Gentoo. Broodwars draait er wel in, maar zonder directe hardware toegang, en als je dan 5 tanks hebt, speelt het heel sloom... (edit: doet de battlenet interface het ook? Bij mij niet. Dat is een bekend probleem).

Red Alert crasht na een paar seconde spelen steeds. Red Alert 2 en Tiberiun Sun doen helemaal niets...
Waarom haal je niet versie 0.9.22 binnen? Wine 0.9.8 is nog van 15 februari! Je loopt 14 versies achter! In die tijd is vooral de DirectX-implementatie er flink op vooruit gegaan.

Stabiele releases zijn er toch nog niet... het is allemaal nog alpha materiaal.
en ook red alert werkt al heel lang onder wine...
C&C Renegade... Carmageddon 2...
Hmm, hoe zit het met de USB support? Ik meen me te herinneren dat (iig een paar maanden geleden) USB totaal niet werd ondersteund door wine. Het artikel en de bron zeggen hier niets over. Iemand enig idee?
waarvoor heb je USB-support onder wine voor nodig :? :?

De USB regeld gewoon het OS waar wine onder draaid
USB regelt gewoon het OS waar wine onder draait
Dat is slechts ten dele waar, als je op driver-niveau verbinding kunt maken met het device is het inderdaad een taak van het OS.

Volgens mij zijn er echter ook situaties waarbij de implementatie op applicatie-niveau gebeurt - ik heb me echter nooit verdiept in de internals van USB onder Windows en het is goed mogelijk dat er altijd een systeemdriver nodig is om met USB devices te communiceren, in dat geval is er helemaal geen hoop op snelle support onder Linux (omdat men dan een driver emulatie moet schrijven en dat is vgls mij geen onderdeel van Wine...)

Op dit item kan niet meer gereageerd worden.