Wine na vijftien jaar eindelijk toe aan versie 1.0

Van Wine, de software die Windows-programmatuur op het Linux-besturingssysteem laat draaien, is na vijftien jaar ontwikkeltijd de eerste stabiele versie verschenen. Wine 1.0 zag op dinsdag 17 juni het levenslicht.

In 1993 begon de ontwikkeling van Wine met als doelstelling om om applicaties voor Windows 3.1 ook onder Linux te laten draaien. Inmiddels is Wine in staat ruim tienduizend DOS- en Windows-programma's onder Linux, BSD en Mac OS X te laten functioneren. Met versie 1.0 kondigt het Wine-team na vijftien jaar ontwikkelen de eerste stabiele versie van de compatibiliteitssoftware aan.

De stabiele 1.0-release van Wine komt, zeker gezien de ontwikkelgeschiedenis, vlot na de eerste release candidate, die op 9 mei vrijgegeven werd. Vier rc's later kwam de gold-versie online. De lange ontwikkeltijd van Wine is onder meer te wijten aan het gebrek aan documentatie voor Windows-componenten: bestandsindelingen en protocollen moesten door het team van Wine met reverse engineering achterhaald worden. Wel kan de software officiële Windows-dll's gebruiken, als die voorhanden zijn; de opensourcesoftware zelf bevat echter geen code van Microsoft. De 1.0-release van Wine is via onze Meuktracker te downloaden.

Reacties (96)

[g4wx3]

Ik heb darwine al een beetje uitgeproveert, en ik moet zeggen, ik verschoot ervan hoe snel sommige programma's werden geïnstalleerd zonder probleem, en dan ook hoe snel die office-programma's opstartte.
Darwine is de OSX versie van wineHQ, eigenlijk is het een Wine versie voor darwin, maar aangezien OSX daar op is gebaseeerd.
Maar wine heeft ook X11 nodig. Dus start in OSX ook X11 op. X11 is echter ook opensource

Het voordeel van CrossOver mac is dat zij dawine en X11 hebben geintegreerd, zodanig je van X11 niks merkt.

Voor wine is er ok een winehelper, deze moet je zeker ook eens starten.


Geschiedenis:

Wine licentie MIT
Geforked
-> WineX -> CEDEGA
-> CrossOver
licentie wine -> GPL
Samenwerking met CrossOver (intens, maar CrossOver loopt altijd achterop, omdat ze meer resultaat gericht zijn voor sommige app's)

[Reactie gewijzigd door g4wx3 op 24 juli 2024 01:17]

[Verwijderd]

Werken nieuwere applicaties ook onder Wine ???

Is het snel ???

(Ik neem aan dat directx niet ondersteund wordt)

[Blokker_1999]

Nieuwere applicaties kunnen werken en kunnen niet werken. Het hangt gewoon af van welke API calls en DLLs zij afhankelijk zijn.

Wine zou in theorie geen vertraging teweeg brengen. Sommige applicaties draaien zelfs sneller onder linux via wine dan native onder Windows. Andersom gebeurd trouwens ook.

DirectX word ook gedeeltelijk ondersteund. Een hele hoop populaire games zijn speelbaar via Wine waaronder WoW en HL2. Multiplayer is vaak moeilijker omdat anti-cheat applicaties (zoals punkbuster) vaak niet correct werken.

[kaconst]

Werken nieuwere applicaties ook onder Wine ???

http://appdb.winehq.org/

Is het snel ???

http://wiki.winehq.org/BenchMark-0.9.5

(Ik neem aan dat directx niet ondersteund wordt)

Toch wel, er zijn genoeg directx spellen die prefect draaien onder wine. Cod2(bvb) draait out of the box en zelfs soepeler dan met xp.

Edit: Ok Cod2 is een slecht voorbeeld maar er zijn genoeg directx spellen die ook goed draaien met minimaal performanceverschil.

[Reactie gewijzigd door kaconst op 24 juli 2024 01:17]

[blouweKip]

cod2 gebruikte opengl dacht ik, dat werkt een stuk beter dan direct3d natuurlijk

[Verwijderd]

Dat ziet er al met al helemaal niet slecht uit.

Misschien zou het een interessante optie zijn voor de game industrie om over te stappen op WINE en spel-DVD's voortaan bootable te maken. Savegames zou je op een flash station kunnen zetten.

En het is natuurlijk een ongelooflijk goedkoop alternatief voor windows.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 01:17]

[Verwijderd]

DirectX wordt ondersteund, voor een groot deel. Probeer maar eens HL2 Episode 2, of EVE Online. Op dit moment is de AppDB down, maar als de drukte een beetje voorbij is, kan je daar controleren welke programma's werken, en hoe je ze zo goed mogelijk werkend krijgt.

[elleP]

Ja, nieuwe applicaties werken meestal ook.
Ja, het is snel, in sommigge gevallen zelfs sneller dan windows zelf, andere trager.
Ja, directX wordt (deels) ondersteund, ik gebruik het zelf om m'n goede oude collectie Tomb Raider's op te spelen

[Verwijderd]

Echt wel proficiat aan de mensen die aan het project hebben geholpen. Dit is eigenlijk bijna hetzelfde als een OS uitvinden maar je moet dan ook nog eens constant zitten puzzelen.
Zit daar nu bomvol knowhow.

[Verwijderd]

Ze koppelen gewoon de windows aanroepen aan linx aanroepen. Lijkt me net iets makkelijker dan zelf de werking van een besturingssysteem op poten te zetten.

[Verwijderd]

nope. Twee verschillende zaken.

Zelf OS bouwen: bepalen wat je ondersteund, hoe je het ondersteund en wat je er allemaal mee kan doen. Zitten er fouten in die gebruikt of misbruikt worden voor spediale functies so be it. (It's not a bug, it's a feature). Uiteraard moet het wel dermate solide zijn dat het toch door enige vorm van kwaliteitscontrole komt en als het even kan over legacy support beschikken.

De winebouwers moeten echter de hele implementatie nakijken. Die moet ivm patentrisico's middels het cleanroom pricipe reverse engineren. Dan moet er dus weer gecode worden, dat is dus zowel rekening houden met andere api's van windows als de api's van het eigen systeem. Daarna kan men het gaan testen, en dan blijken er ineens toch een aantal programma's te zijn die niet goed functioneren. Dan moeten die programma's dus ook weer moeten worden nagekeken. Meestal door een standaard reverse engineeringsteam (want er komt toch geen product uit) om te kijken hoe het dus met een bepaalde api omgaat. Dat dan weer documenteren richting cleanroom coders zodat iets kan worden aangepast of dat er rare programma specifieke uitzonderings hacks gemaakt moeten worden.

Nadeel voor tweede team is dan ook nog eens dat ze harder voor missers worden afgerekend door het publiek. Een coder die iets bouwt, doet het voor windows en problemen met win daar werkt hij om heen of maakt er indien moigelijk zelfs gebruik van, en anders is zijn product slecht. Het wineteam wordt echter afgerekend op het functioneren van programma x/y/z. Niet de programmeur, en ook niet Microsoft terwijl de eigenlijke problemen daar best wel zouden kunnen liggen.

Twee bijna verschillende disiplines dus. Ieder met hun eigen voor- en nadelen, en beide zaken zijn in hun eigen recht uitdagingen van formaat. Wat makkelijker of moeilijker is, hangt af van je eigen vaardigheden en interesses.

[Verwijderd]

Een OS schrijven kan je in een jaar. Een OS perfect nabouwen, daar doet men nu al 15 jaar over. Je moet niet vergeten dat je als je een OS gaat nabouwen, niet de beste oplossingen voor problemen moet vinden, maar voor elke functie apart moet gaan kijken wat het precies in Windows doet. Dus voor elke API-functie schrijf je een aantal tests om te kijken wat voor eigenaardigheden er in zitten. Dat kost veel meer tijd dan zelf iets beters te verzinnen.

[Ozzie]

Het is gewoon niet te vergelijken. Dat zeg je zelf ook al. Dus het slaat ook nergens om te zeggen dat ze sneller een OS hadden kunnen maken. Dat was helemaal niet het beoogde doel.
Trouwens, Windows en Linux zijn ook al meer dan 15 jaar in ontwikkeling.

[mae-t.net]

Dat ze sneller een OS hadden kunnen maken, zei DOT dan ook niet. Die zei alleen maar dat 'een OS schrijven' (algemeen dus) in een jaar wel zou lukken. Een nogal belangrijk nuanceverschil. Verder kloppen de uitspraken die hij over het nabouwen doet mijnsinziens helemaal (behalve dan dat het geen nabouwen is, maar omdat het ook geen emuleren is weet ik even niet hoe hij het dan zou hebben moeten noemen).

[Verwijderd]

Echt wel proficiat aan de mensen die aan het project hebben geholpen. Dit is eigenlijk bijna hetzelfde als een OS uitvinden maar je moet dan ook nog eens constant zitten puzzelen.
Zit daar nu bomvol knowhow.

Nou, een OS uitvinden... het is eerder uitpuzzelen waar een bestaand OS allemaal al uit bestaat, en dan zonder documentatie. Zonder meer knap te noemen, maar absoluut niet hetzelfde als "een OS uitvinden".

[Kevinp]

Als je een OS bouwt heb je zelf alles 100% in de hand. Je kan zelf functies toevoegen of verwijderen naar keuze. DLL's(of iets wat daar op lijkt) maken en gebruiken. Alles kan je zelf doen.

Dat is nog steeds moeilijk genoeg om dat op windows formaat te doen(of linux formaat). Maar wanneer je dat zonder documentatie van bv HW moet doen en zonder enig aanknooppunt is het al weer heel wat moeilijker.

Dit i erg knap alleen jammer dat je dus geen "emulator" hebt want dan zou in één keer alles(in theorie) moeten werken.

[gertvdijk]

Dit i erg knap alleen jammer dat je dus geen "emulator" hebt want dan zou in één keer alles(in theorie) moeten werken.

Een echte emulator komt wel erg dicht in de buurt van een virtualisatiepakket als VirtualBox of VMWare. En het zou ook nadelen hebben. Immers, je kan dan niet meer de integratie met het OS garanderen of wordt ranzig/omslachtig opgelost om dat alsnog mogelijk te maken. Denk aan hoe dat nu gaat in een VM.

offtopic:
[q]Als je een OS bouwt heb je zelf alles 100% in de hand. Je kan zelf functies toevoegen of verwijderen naar keuze. DLL's(of iets wat daar op lijkt) maken en gebruiken. Alles kan je zelf doen.

Dat is nog steeds moeilijk genoeg om dat op windows formaat te doen(of linux formaat).[/q]
Met Linux is dat wel degelijk mogelijk. Doordat de sourcecode helemaal beschikbaar is (kernel en de meeste applicates) en de GPL licentie je het toestaat, kan en mag je alles naar wens aanpassen.

[Verwijderd]

Dus je bouwt zowat een OS na met extra moeilijkheid dat je een bestand moet zitten nameken waar je amper iets over weet.

Ze hadden veel sneller zelf een nieuw os kunnen maken.

[needless to say]

Dat denk ik niet. Het 'enige' wat wine moet doen is de calls die windows programma's doen interpreteren op zo een manier, dat ze het onderliggende Linux-OS kunnen gebruiken. Heel het low-level gedeelte van Windows moeten ze gewoon niet aan komen. Ze moeten enkel de dll's herschrijven die door programma's gebruikt worden.

Nu, op zich is dit natuurlijk al erg veel werk, vooral omdat het via reverse engineering moet en zonder documententatie. Maar het ontdekken hoe een ander OS bepaalde handelingen doet is helemaal iets anders als zelf uitvinden hoe een OS in elkaar moet steken + heel het lowlevel gedoe die de interactie met de hardware verzorgt. Wine herschrijft maar een deeltje van het Windows OS.

[Verwijderd]

Wine is echt wel moeilijker dan een OS bouwen hoor. Het tweede doen ze op school voor de fun zelfs een keertje op minimalistische schaal.

Wat wine doet is een persoon, doof vanaf geboorte, perfect doen spreken.

[needless to say]

Leuk, heb ik ook reeds gedaan. Maar die vingeroefeningen op school zijn helemaal niet te vergelijken met een volwaardig OS met de complexiteit van Windows. Een OS is heel wat meer dan een paar honderd lijnen assembler (cf. oefening op school) of een hoopje DLL's die voor een deel eigen functies en methodes bezitten en voor een deel win32 function calls vertalen naar Linux calls (cf. Wine).

[Reactie gewijzigd door needless to say op 24 juli 2024 01:17]

[lamme23]

Het ligt er aan wat je een OS noemt. Een minimaal OS stelt inderdaad niet veel voor. Zeker als je het nauwelijks hoeft te testen, want je hebt maar een paar calls.

Als het echt zo makkelijk was, zat bijvoorbeeld Windows niet zo vol met fouten.

Het enige dat Wine moet doen is de system calls omleiden naar het Linux OS. In plaats van wat de win32api doet een call als "hFileToRead = CreateFile(sPath, GENERIC_READ, 0,lpSecurityAtrribs, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);" moet de Wine 'shell' een antwoord terug geven aan degene die de win32 api call doet en zelf iets van "FILE *fopen(const char *path, const char *mode);" (na compilatie) doen.

En dat voor alle opcodes die mogelijk aangeroepen worden. En als je die calls dan allemaal moet ondersteunen en je weet niet precies hoe ze gebruikt worden, omdat je daar geen documentatie van hebt, dan vind ik het best knap.

[graey]

Veel sneller een nieuw OS. Hmm, ReactOS probeert dat, en komt aardig vooruit, maar het duurt nog wel enige jaren voor er een bruikbare (stabiele) beta is (!).
EDIT: ja, en ik weet dat de roadmap anders stelt, maar goed, kijk maar eens rond in de fora en zie wat er over de roadmap gezegd wordt, en over de haalbaarheid zoals het er nu uitziet.

[Reactie gewijzigd door graey op 24 juli 2024 01:17]

[Damic]

Er zitten een paar mensen van Wine in het Reactos.org team, die zijn nu een os aan't bouwen met standaard ondersteuning van windows programma's

[graey]

Bij mijn weten zijn er anders geen Wine-ontwikkelaars meer (vast) betrokken bij ReactOS sinds de (valse) beschuldigingen over hergebruik van gelekte Windows 2000-broncode.

[AlBundy]

Petje af, ik gebruik Wine bijna dagelijks (in de gedaante van Cedega dan) om Windows-games op te spelen. GTA Vice City, Need For Speed Carbon en Civilization III draaien vlekkeloos, zelfs op mijn ATI-kaart (dat gaf in het verleden nog vaak problemen).

En Cedega heeft heel veel van haar aanvullingen op Wine ook teruggegeven aan de community, ik denk dat dat heel erg heeft geholpen om Wine te krijgen waar het nu staat.

[Verwijderd]

Hehe, ik denk het niet. Bijna niks van Cedega vloeit terug naar Wine. Ze hebben een paar jaar geleden, toen Wine nog onder een MIT-licentie werd uitgebracht, Wine geforked, en sindsdien hun aanpassingen verkocht. De MIT-licentie verplichtte niet dat zij hun aanpassingen moesten teruggeven aan Wine, dus gebeurt dat niet. Tegenwoordig is de licentie van Wine veranderd naar de LGPL, waardoor Cedega niet zomaar meer code kan jatten.

Cedega had een paar jaar het voordeel dat zij een begin hadden gemaakt aan DirectX-ondersteuning. De DirectX-support van Wine is from scratch geschreven, en is nu al een tijd in een verder stadium dan die van Cedega. Wat Cedega nu nog heeft, is een betere marketing, en een makkelijke UI.

Als je graag Wine wilt supporten, dan kan je beter Crossover Games kopen dan Cedega. Crossover Games wordt gemaakt door Codeweavers, het bedrijf achter Wine. Het is verder vergelijkbaar met Cedega, in dat het focussed op games, en een makkelijke UI heeft.

[AlBundy]

Was WineX vroeger niet van CodeWeavers, en dat opgegaan in Cedega? Of zit ik er nu heel erg naast?

Toch ook eens naar Crossover kijken in dat geval

[Verwijderd]

Nee, WineX was de vroegere naam van Cedega. Toen die groep programmeurs commercieel ging, hebben ze de naam veranderd, en hun bedrijf gestart: Transgaming. Zij hebben nu een deal met EA om games naar de Mac te porten, wat nogal wrang is, gezien de voorgeschiedenis.

Codeweavers heeft dan weer een goede relatie met Google. Ze hebben Picasa en Google Earth geport naar Linux, en een aantal Google werknemers werkt nu mee aan Wine.

[AlBundy]

Ok dan is het me een beetje duidelijk

Valt me wel op dat de games-ondersteuning bij CrossOver me wat tegenvalt itt Cedega, maar ik zal eens wat gaan klooien

[elleP]

Cedega heeft de meeste aanpassingen nooit teruggeven aan wine, waardoor met name directx jarenlang niet actief is ontwikkeld. Cedega had namelijk beloofd dit wel terug te leveren en het was dus niet de moeite om dubbel werk te doen.

[progster]

cedega geeft heel weinig tot niets terug aan wine, ze zijn ook gebaseerd op een (nu) heel oude wine versie die nog onder een andere licentie werd uitgebracht...

[Noxious]

Ik gebruik CrossOver:Games en die geven dus wél al hun verbeteringen terug aan de community daarnaast zijn ze niet geforkt vanaf een zwaar antieke Wine-versie wat per update vaak een hoop extra's geeft die Cedega mist. Ik raad je aan eens de trial te proberen, als je je aanmeld als advocate voor een applicatie (tester) heb je geen recht op support maar je gebruikt het dan wel gratis, da's ook een optie.

[Pozo]

MIsschien is iets meer info handig voor hen die niet heel into linux zijn (zoals ik). Ik weet dat het programma een windows emulator is, maar is die met deze versie (1.0) dan geperfectioneerd of crashed hij nu gewoon niet meer?

[Admiral Freebee]

Ik denk dat v1.0 gewoon meer een symbolische stap is. De ontwikkelaars zien hun programma nu als een goed werkbaar middel om veel Windows programma's te kunnen draaien maar er zal altijd wel werk blijven aan Wine.

Ten eerste blijft Windows ook altijd maar evolueren en zoals in het artikel staat is het moeilijk om hier op in te spelen. Ten tweede is er zoveel software dat het volgens mij absoluut onmogelijk is om ooit alle software te ondersteunen. Immers gebruikt men soms wel heel lelijke achterpoortjes om software te laten 'werken'.

[humbug]

Microsoft is min of meer de windows api aan het verlaten en aan het vervangen door de .net api. Dit betekent dat toekomstige applicaties voor windows meer en meer .net gebaseerd zullen zijn.

Maar goed Photoshop maakt (nog) geen gebruik van .Net dus voorlopig is er zeker nog een plaats voor Wine. Maar het is jammer dat Wine dus pas bij versie 1.0 is aanbeland terwijl er bij microsoft al een beweging naar een andere api plaatsvindt en wine dus wel eens op korte termijn "obsolete" kan worden.

[Verwijderd]

The name 'Wine' derives from the recursive acronym Wine Is Not an Emulator



het is geen emulator!

[xaddict]

idd, is een laag tussen een .exe en de manier waarop Linux de API afhandelt

dus rechtsreekse calls van het 'windows'programma naar de Linux afvang van dit soort calls

[Verwijderd]

Met Wine 1.0 wilden de developers een paar programma's zo goed als foutloos draaien onder wine. Photoshop CS2, Word viewer 2003, Excel Viewer 2003 en Powerpoint Viewer 2003 zijn programma's die goed moesten draaien. Maar ook andere programma's zoals Guild Wars Draait zou zo goed als foutloos draaien.
(http://tech.slashdot.org/...08/06/17/1547241&from=rss)

[CherandarGuard]

Alle features die men er in wilde hebben om het echt een volledige versie te kunnen noemen, zijn werkend. Dat is wat Wine verstaat onder hun versie 1.0, voor zover ik het heb begrepen.

[Miauw]

gewoon heel wat bug fixes en meer compatibility. Stabieler ook crashed/hangt minder.

[magic31]

Het zou toch erg grappig zijn als mensen straks juist Linux gaan draaien om hun huidige (waardevolle) Windows programmas nog te laten draaien omdat het niet meer op Windows 7 en hoger draait.

[graey]

Of wanneer men Wine naar Windows 7 port om backwards compatibility. Dan zijn alle kampen blij: Microsoft gooit ouderwetse standaarden en troep overboord, en begint met een schone NT-kernel en een nieuw subsysteem en alles, en de bedrijven/hobbyisten/thuisgebruikers die WEL Windows 7 willen en OOK compatibiliteit installeren Wine4Seven .

[Snake]

Het is geen emulator (Wine is not an emulator)!

Het emuleert die libraries niet, het vangt die calls af en doet er dan *iets* mee, weet het niet meer

[Verwijderd]

goede poging tot win32 api implementatie voor diverse platformen

[flowerp]

Inderdaad, het is 'gewoon' een implementatie van de win32 API. Er zijn enkele raakvlakken met het begrip emulator, maar wine zelf is dat niet echt.

Neem bijvoorbeeld aan API zoals GTK+. Is de Linux implementatie hiervan een emulatie, of is de Windows versie hiervan een emulatie? Beiden zijn geen emulatie. De API is abstract opgesteld en er zijn (in dit voorbeeld) 2 verschillende implementaties van.

[Verwijderd]

Wine is een emulatieLAAG, geen emulator.

[SSH]

Wine is werkwoordelijk wel een emulator.

woordenboek > all

/discussie

[Verwijderd]

Dan is Windows ook een Win32 emulator.

[graey]

Eigenlijk al sinds de DOS-based reeks ook, immers, in DOS zelf zat geen win32-api, Windows was toen nog een laagje over een ander OS heen. Met Windows NT is dat wat minder duidelijk geworden voor gebruikers, maar het is natuurlijk nog steeds zo: je hebt de NT-kernel, en dan het win32-subsysteem die de win32 api implementeert. Net zoals je ook een OS/2 en een POSIX subsysteem hebt voor (in ieder geval een paar delen van) de NT-serie. Wine doet eigenlijk hetzelfde als het win32-subsysteem in Windows 9x/NT, alleen dan met de linux-kernel.

[Dreamvoid]

Da's ook niet helemaal een goede vergelijking, want Win32 (zoals in Windows 95) was ook geen schil om 16-bit DOS/Win16 heen dat 32-bit code naar 16 bit vertaalde, het werkte er volledig naast en had directe 32-bit geheugen- en 32-bit disk access.

Windows 95 had alleen DOS nodig als bootcode, na het booten nam de 32-bit kernel het over en kwam er geen 16-bit code meer aan te pas (tenzij natuurlijk 16 bit programma's werd gedraaid, dan werd in een gereserveerd stuk geheugenruimte weer die bejaarde en f&*king instabiele 16-bit code geladen die vanuit Windows 3.x brak geport was). Ik heb hier nog ergens het boek "Inside Windows 95" liggen waar het allemaal mooi in beschreven staat. Je kon bv na het booten naar 32-bit Windows ook gewoon command.com (de DOS 'kernel') verwijderen - het zaakje crashte alleen als je 16-bit programma's probeerde te draaien.

Wine vertaalt Win32 calls naar native Linux/OSX calls, het heeft geen eigen exclusieve geheugentoegang en werkt niet op kernel-level. Heel ander concept.

[Reactie gewijzigd door Dreamvoid op 24 juli 2024 01:17]

[Verwijderd]

Een beetje late reactie, maar dit moet ik toch even recht zetten.

Wine vertaalt Win32-calls niet naar Linux-calls, maar voert ze uit op de machine, eventueel pratend met de Linux/OSX-kernel, net zoals Windows ze uitvoert op de machine, eventueel pratend met de NT-kernel. Het verschil is dus dat er aan de achterkant met een andere kernel gebabbeld wordt, maar voor het gebruikende programma werken de Win32-calls exact hetzelfde.

Programma's hebben in Wine dus gewoon (protected) geheugen-access. Na het laden van de executable met de Wine loader (de Linux/OSX-kernel kent het PE-formaat van een Windows-executable niet), verschilt er niets tussen een app draaiend in Wine, en een app draaiend zonder Wine. Een Wine-app kan gewoon native Linux/OSX-functies aanroepen, en een native Linux-app kan gewoon Wine-libs (de DLL's) gebruiken. De DLL's van Wine zijn net zo native als andere libraries in Linux/OSX, en net zo native als Windows' eigen DLL's onder Windows. Wine breidt dus eigenlijk gewoon de besturingssystemen uit tot Linux+Windows, of OSX+Windows.

DLL's die niet met de kernel praten (dat zijn er een hoop) kan je daarom ook gewoon vervangen door de Windows-variant, zonder dat er iets verandert. Op het gebied van DirectX is het iets anders natuurlijk, omdat er geen DirectX-drivers zijn voor Linux. Daar moet de call worden omgezet naar een OpenGL-call. Dat gaat zonder snelheidsverlies op de plekken waar DirectX en OpenGL overeenkomen, maar heeft een kleine overhead op de plekken waar bepaalde functionaliteit op een andere manier moet worden aangeboden. Gelukkig zijn DirectX en OpenGL steeds meer hetzelfde gaan doen (wat wil je, ze leggen dezelfde hardware bloot ).

[Sorcix]

Waar je dat vandaan haalt weet ik niet, maar Snake was gewoon juist hoor.
Zoals ondertussen al meerdere malen gezegd: Wine Is Not an Emulator.

[AcidBanger]

http://en.wikipedia.org/wiki/Wine_software

[El Cid]

Toch is het opmerkelijk dat je na 15 jaar nog steeds niet een willekeurig programma voor Windows, gegarandeerd probleemloos kan draaien onder Wine. Dat games problemen geven kan ik begrijpen, want DirectX is constant aan verandering onderhevig. Maar de standaard Windows API is toch al tijden redelijk stabiel? Waarom duurt het zo lang om die te implementeren?

[Verwijderd]

Omdat MS niet erg scheutig is met informatie over bepaalde API's.

[daft_dutch]

Kan je een willekeurig Windows programma draaien onder windows zonder problemen?
Nee! hoe veel dingen gaan er fout bij een nieuwe Windows versie of een SP.

Daarbij als je een willekeurig programma pakt is er ook een grote kans dat je een virus pakt. En die doen het meestal niet ^^

[Miauw]

Zeker wel een mooie ontwikkeling. Gebruik wine zelf om websites te testen in IE onder linux.

[Verwijderd]

Interssante opmerking. Want dat scheelt in het heen en weer switchen tussen machines en in de warmte op mijn werkkamer.

Dus Wine geinstalleerd en IE gestart. Maar dan zegt hij 'installeren gecko engine'. Dat doet me sterk vermoeden dat het allemaal niet zo native is, en dus niet geschikt om mee te testen.

Ligt dit aan een versie of zo?

[d-snp]

Er is een speciaal pakket voor wine dat er voor zorgt dat je IE onder linux kunt draaien en het heet ies4linux. Tis alweer een paar maanden geleden dat ik het voor het laatst probeerde, dat was toen IE7 nog in beta was. Onder debian(achtige) systemen is het een kwestie van de package installeren, en het runnen. Alle versies van IE kun je gewoon naast elkaar draaien, cool was dat ie ook de IE7 engine al draaide enkele dagen na de release van de beta.

Eigenlijk werkt het allemaal nog vloeiender dan onder windows...

[Verwijderd]

Ik weet niet zeker of dit de goede oplossing is, maar je kan eens proberen om IE7 van de MS website te downloaden, en deze met behulp van Wine te installeren, en hem dan vervolgens te gebruiken.

[Maghiel]

virtualmachine anders?

[Teun_2]

Ik geloof dat veel rendercalls voor ie opgevangen worden door de gecko engine omdat die nu eenmaal goed en snel werkt. Dus niet echt helemaal correct. Maar volgens mij (ben hier niet helemaal zeker van) ken je in principe ook gewoon ie met zijn eigen render engine installeren.

Maar stek dat je bijvoorbeeld steam wil installeren, die gebruik maakt van de ie-engine, dan zullen die calls standaard worden opgevangen en doorgestuurd worden naar de gecko renderengine.

[graey]

Tenzij je aangeeft dat hij de internet-explorer DLLs moet gebruiken (kan in de wine-config tool), mits je ies4linux hebt geinstalleerd (of gewoon Internet Explorer, op eigen houtje).

[Jelmoh]

Ik kan je met vrij veel zekerheid zeggen dat het niet is geperfectioneerd.
Dit zal waarschijnlijk een stabiele versie zijn die beter met Windows programmatuur om kan gaan.
Ik heb zelf langere tijd met Wine gewerkt en geexpirimenteert.. Het werkte niet echt lekker naar mijn mening, was nog veel geknutsel van gebruiker vereist...

Ik hoop dat het hiermee een beetje beter en makkelijker werkt, maar ook ik zou graag wat meer informatie willen omtrent wat er precies veranderd/verbeterd is.
Ik ga dit zeker weten weer testen!

[Verwijderd]

Wat ik altijd wilde doen was CS source, als dat draaide vond ik het prima. Dat doet het nu ook, alleen werkte het geluid nog niet. Nog geen aandacht aan besteed, ik weet alleen wel nu dat ik mijn 6600GT moet gaan vervangen, want je trekt niet de volledige power uit je videokaart net als dat in Windows wel gebeurd. Alles werkt wel goed, echt geen gliches in het spel te bekennen, terwijl in versie 9,4xx nog wel problemen waren met oa het menu ingame..

[Dartillus]

Ik had ook een probleem met geluid onder Wine, maar bij mij klaarde het op toen ik CS:S draaide als root. Is niet veilig gezien in de ogen van een *nix gebruiker, maar onder Microsoft ben je het toch 24/7

[Verwijderd]

Heh... Je hoeft dan alleen maar even je rechten na te kijken. Waarschijnlijk probeert wine een bepaalde interface in /dev/ aan te roepen voor de audio, check welke groep daar rechten op heeft en gooi je user in die groep.

[Jogai]

Om te helpen kun je op een windows pc deze link klikken:
http://test.winehq.org/da...d0e66b5207056775bcb3b09ff
Dan kunnen ze wine vergelijken met windows dacht ik.

[Verwijderd]

Zo te zien kunnen we het beter gewoon op KDE of zo houden.

[M-Opensource]

KDE is een desktopmanager... iets andere richting... maar je zat in de buurt

[Noxious]

Je weet wel waar je over praat neem ik aan?