Software-update: Wine 0.9.35

Zojuist is versie 0.9.35 van Wine uitgekomen. Met behulp van dit programma is het mogelijk om DOS- en Windows-programma's te draaien op POSIX-gebaseerde besturingssystemen, waaronder Linux, FreeBSD en Mac OS X. Wine kan DOS- en Windows-applicaties uitvoeren door deze eerst in een program loader te laden en vervolgens via eigen bibliotheken de verwijzingen naar Windows-API's door te sturen naar de Unix- en X11-tegenhangers. Meer informatie over Wine kan in deze FAQ worden gevonden. Het changelog van deze release laat de volgende veranderingen zien:

What's new in this release:

• Broken aRts sound driver now removed for good.
• Many fixes to the Quartz DLL sound support.
• File I/O performance improvements.
• The usual assortment of Direct3D fixes.
• Lots of bug fixes.

[break]

Versienummer	0.9.35
Besturingssystemen	Linux, BSD, macOS, Solaris
Website	Wine HQ
Download	http://ibiblio.org/pub/linux/system/emulators/wine/wine-0.9.35.tar.bz2
Bestandsgrootte	11,20MB
Licentietype	GPL

Reacties (14)

[Daimanta]

Lots of bug fixes.

Is dit nou een officiële verklaring. Ik zie dit namelijk wel vaker staan op t.net als een van de verbeterpunten.

[robbert]

Ja, zie http://www.winehq.com/?announce=0.9.35

daaronder staat ook de hele lijst met veranderingen, alleen denk ik niet dat die zo interessant zijn voor de gemiddelde Tweakers.net bezoeker.

[Verwijderd]

diamanta, speciaal voor jou een paar mooie gefixte bugs:

wined3d: Only issue state_patchsegments FIXME once.
comctl32: Fix item rect calculation.
wined3d: Add some StretchRectFilterCaps.
d3d9: Break out two helper functions from test_fvf_to_decl.
ole32: In 16-bit OLE, LPOLESTR uses multibyte, not Unicode characters so
make LoadTypeLib16 take an LPSTR instead of LPOLESTR.

zo ben je een stuk wijzer geworden, nietwaar

[Blokker_1999]

staat de final nu eigenlijk al op de planning?

[Verwijderd]

Nou, "final" zal het nooit worden, maar in een recente Wine Weekly News Issue wordt de weg naar 1.0 besproken. Eens in de zoveel tijd praten ze er weer eens over op de mailinglist, maar er wordt niet echt naartoe gewerkt heb ik het idee. De meeste developers werken aan een bepaald stukje Wine om een bepaald programma werkend te krijgen.

[iKiddo]

Wat uitgebreider:

Ze werken er zeker naartoe, de ontwikkeling gaat hartstikke goed. Maar: voordat er een 1.0 zal komen wil het hoofd van het project (alexandre julliard) dat er een periode komt waarin geen toevoegingen worden gedaan, maar alleen verbeteringen worden gemaakt van bestaande mogelijkheden. Om te bepalen wanneer die periode aangekondigd gaat worden zijn voorstellen gemaakt voor criteria. Echter (mede) omdat de Windows API steeds verder ontwikkeld lukt het nooit helemaal precies deze criteria te formuleren. Dit gebeurt meestal doordat mensen het eens zijn over een criterium, maar dat voordat aan het criterium voldaan kan worden nog werk verzet moet worden. En, zoals je waarschijnlijk wel aan voelt komen, verschuift het criterium zo ongeveer rond het moment dat de voldoening in zicht is.

Bijvoorbeeld:
De eeuwig-lijkende verschuiving van criteria voor Direct3D ondersteuning begint wat te vertragen (goed nieuws). Maar nu het zo goed gaat met d3d9, kijken de developers verwachtingsvol naar verbetering van de wine opengl code.

Op het moment lijkt het erop dat vooral implementatie van wine-alsa drivers voor (aanzienlijk) verbeterde DirectSound ondersteuning een belangrijk punt is voordat de rustperiode voorafgaand aan 1.0 ingeluid kan worden.

[switchboy]

V0.9999999991

[Verwijderd]

Dus wine dient ervoor om een .exe te draaien in linux alks ikd at zo goed begrepen heb?

Betekent dit bijv dat ik winamp en bepaalde spellen(neem aan dat neit alels ondersteund is) kan draaien vanaf mijn windows ntfs schijf in linux?

[Peetke]

Yep, Yep.

Je kunt ook de programma's gewoon installeren, want veel installers doen het ook gewoon. Om ruimte te besparen kun je je windows partitie mounten. Maar dan heb nog niet perse je registry enzo helemaal OK in Wine.

[flowerp]

Windows zelf is een moving target. Met VISTA is de lat weer wat hoger gelegd.

Maar...

Win32 wordt natuurlijk niet meer echt verder ontwikkeld als public API. Alle nieuwe programma's op Windows zouden gebruik moeten maken van de .NET API's. Nu weet ik wel dat sommige mensen zeggen "f*ck" .NET, maar wat moet je anders gebruiken voor een first class Windows applicatie? MFC wordt al jaren niet meer geupdate, en Win32 nu dus ook niet meer met functies die voor desktop applicaties nuttig zijn.

Het zou dus best kunnen zijn dat er over een jaar of 6 al inderdaad een Wine final komt. Die zal dan ongeveer de win32 API implementeren zoals 2000 of misschien zelfs wel XP dat nu doet.

[ernstblaauw]

Gelukkig hebben we Mono :-)

[E-jey]

Mja MS is met .net wel heel leuk java uit de markt aan het drukken, maar windows .net applicaties draaien mooi niet op linux. Het hele verhaal dat .net applicaties op meerdere OSen draaien is allemaal schijn. En als het mono lukt om alle windows .net applicaties op linux te draaien, dan gaat MS even met zijn patenten zwaaien en roepen dat de open source community microsoft "technologie" gebruikt. Ze zijn niet gek in redmond...

[Verwijderd]

.NET is van het begin af aan ontworpen om platformonafhankelijk te werken. Microsoft wil op deze manier inderdaad Java uit de markt drukken. Microsoft moedigt Windows-ontwikkelaars echt niet aan in .NET te werken in plaats van met win32 en/of kernel calls om ze vervolgens met behulp van patenten weer aan Microsoft te koppelen.

Parallel ziet Microsoft in dat ze met Internet Explorer het Internet flink verstierd hebben. In de persoon van Chris Wilson neemt Microsoft enthousiast deel aan de discussies op de public-html mailinglist van het W3C.

[flowerp]

.NET is van het begin af aan ontworpen om platformonafhankelijk te werken.

Volgens mij is dat niet zo in de zin die jij nu waarschijnlijk bedoeld.

.NET is ontworpen zodat Windows applicaties hardware architectuur onafhankelijk kunnen draaien.

Microsoft heeft er geen enkele belang bij dat Windows alleen voor x86 zou moeten zijn. Windows zelf (de echte, niet die win9x crap) is namelijk van meet af aan ontworpen om op alle types CPU te draaien. MIPS, Alfa, PPC, etc.

Alleen wilde de applicaties niet mee. NT op Alfa en recent XP op Itanium kwam/komt amper van de grond omdat er behalve Windows zelf niets anders op draait. Net zoals b.v. directx de GPU abstract maakt, maakt .NET de CPU abstract voor Windows programma's.

De implementatie van Mono kun je gedeeltelijk zien als het feit dat Linux on x86 net zo goed x86 binaries zou kunnen draaien als Windows on x86. Alleen zijn de libraries waar de code naar linked (i.e. win32 dus) niet echt beschikbaar onder Linux, waardoor het dus niet direct werkt.

Het Mono project zal dus voor een gedeelte net zoals Wine dat doet MS API's moeten reverse engineeren en overnieuw implementeren. Als het zo simpel was als jij voorstelt, waarom kan ik dan niet een willekeurige .NET programma (zeg paint.net) gewoon zonder problemen op Linux draaien?