WINE för OS X!

Det skulle inte funnits något alls om det inte vore Open Source. Det har lagts ner förmodligen tusentals mantimmar med arbete som inget företag skulle ha råd med. Wine kallar sig inte för version 1.0 ännu, men egentligen borde de nog vara version 8.5 eller något så länge som de har hållit på och så väl som det fungerar.

Ciryon

Bochs är en gräsligt ineffektiv emulator, eftersom den tar in instruktionerna en och en för att sedan översätta dem till PPC-kod. Har du en loop som upprepar sig 100 gånger kommer alltså varenda instruktion i loopen att översättas 100 gånger. Det är alltså inte konstigt att du fick dåliga prestanda, med andra ord.

Men: De goda nyheterna är att Darwine enligt deras egen FAQ inte använder Bochs utan QEMU. QEMU fungerar på det sättet att den tar in större block av instruktioner, som översätts till native-instruktioner och cachas. Emulatorn i VPC sägs f.ö. fungera ungefär på samma sätt. Enda haken är att QEMU inte har samma kompletta emulering av en hel dator som Bochs har, men det är tydligen inga problem alls för Wines del. Det verkar alltså som att det finns goda möjligheter att få bra prestanda i Darwine, och det skulle ju onekligen vara rätt trevligt...

Jaha, så det fanns mer än en opensource x86emulator för ppc då.

Edit: Förtydligade mig

/Kristofer

Det största farthindret med X86 emulering borde ju vara konverteringen från little endian till big. X86 har ju sina rötter i 70-talet.

Vad jag har förstått så är det inte ett så stort problem som man kan tro under PPC-arkitekturen, eftersom den till största delen är anpassad till att arbeta med little endian också. För en PPC är det precis lika enkelt att läsa in (eller lagra) ett bakvänt heltal som det är med ett rättvänt, och det är ingen hastighetsskillnad heller. Allt man behöver göra är att använda PPC-instruktionerna "Load byte reversed" resp. "Store byte reversed" i stället för de vanliga "Load" och "Store". Samma trick går tyvärr inte att göra med flyttal, utan de måste först skickas till en heltalsenhet för att vändas bak och fram innan de kan matas in i flyttalsenheten.

Internt i processorn så fungerar det däremot lite annorlunda. Till skillnad från internminnet kan inte PPC:ns register adresseras på byte- eller bitnivå, så på den nivån existerar inte ens endian-begreppet! Med andra ord är inte little endian vs. big endian något stort problem alls för PPC-arkitekturen - bortsett från specialfallet att läsa in flyttal från minnet så är den tillräckligt smart gjord för att inte bry sig.

Fast denna feature hos PPC-arkitektueren finns inte med hos PPC-970 (aka G5). Har jag förstått det hela rätt så var det detta faktum som gjorde att VirtualPC inte lirade på G5 utan större modifieringar i källkoden.

Emulering är läckert. Men, det känns som om förväntningarna hos användarna är på tok för höga. Om man emulerar en tvättmaskinsprocessor, eller en 10 år gammal processor kan man med en modern dator få en emulerad miljö som springer cirklar kring originalet. Men, jag tycker mig se förhoppningar att en modern Mac skall kunna emulera en moderna PC med vettig fart. Glöm det. Inte heller kommer en moderna PC kunna emulera en moderna Mac med vettig fart.

WINE har som sagt inget med processoremulering att göra. Det är ett försök att kopiera delar av WindowsAPIet. Jag har svårt att tänka mig ett jobbigare uppdrag. Hatten av för dom som försöker, men jag har mycket svårt att tänka mig att jag mha WINE kan installera godtycklig windowsbinär på min Linuxmaskin om 3 år.

Jag har hört lite olika bud om just den biten. Microsoft hävdar att PPC 970 inte har det stödet, men jag har hört från andra håll att det skulle vara ren lögn. Själv vet jag alldeles för lite om 970:ans instruktionsuppsättning för att avgöra vem som har rätt, men det lär vi väl märka om inte annat...

Slashdotkommentar. Jag är heller ingen auktoritet på instruktionsuppsättningar, men det här låter trovärdigt:

It is, because the G5 DOES support pseudo little-endian mode. It must be a stupid fuck-up on MS's side (as if that'd suprise anyone).

VirtualPC does not use the PowerPC's ability to boot in big or little endian - it uses the lwbrx/stwbrx instructions, which will automatically endian-swap during a load or store. This allows them to keep data in memory in little endian form, have it swapped automatically when it's brought into a register for processing, and have it swapped back when it's written out to memory.

This is the feature which isn't present on the G5, and was responsible for the big speedup in the latest rev of VPC - and the reason it now requires a G3 or G4 (since the previous PPC chips didn't support these instructions).

Since the G5 doesn't support this feature either, they'll need to go back and resurrect some of their previous code - they will doubtless take a performance hit for having to do the swapping themselves, but the massive bandwidth in the new systems will probably help cancel some of that out.

Mindre bra för emulatorfolket ifall det stämmer, men jag har inte kunnat verifiera slashdotkommentaren du klistrade in ovan ens med IBM:s referensmanualer. Jag har lite svårt att tro att IBM utelämnar standardinstruktioner i en processor helt utan att nämna det i dokumentationen, så jag är fortfarande skeptisk till att så skulle vara fallet. Men om du hittar mer underbyggd info om saken så låter jag mig gärna överbevisas!

Grattis till wine projektet :

http://99mac.se/forum/showthread.php?t=39805

Kommer varken att göra till eller från tror jag. Källkoden till Windows är copyrightskyddad, och den som använder sig av den läckta källkoden gör sig skyldig till brott mot copyrightlagstiftningen. Sedan tror jag faktiskt inte att Wine-teamet egentligen är särskilt hjälpta av att få tillgång till Windows-källkoden. Syftet med Wine är i princip att efterapa de funktionsanrop Windows-programmen gör till det underliggande systemet, och de funktionsanropen är inte hemliga (även om den underliggande implementationen är det). De försöker alltså inte "klona" Windows, utan bara skapa ett kompatibilitetslager.

Ett undantag skulle eventuellt kunna vara ifall läckaget leder till att funktioner som inte är publikt dokumenterade, och som bara MS programmerare känt till, upptäcks. Men frågan är bara om det är riktigt lagligt att använda sig av den informationen i så fall - själv kan jag nästan inget om juridik men någon som är mer insatt kanske kan upplysa oss?

Ja kanske, det är tydligen bara några få % av koden också,
angående det juridiska så kan man väl bara konstatera att alla utvecklare som ertappas med koden inte kommer att bli speciellt väl behandlade av MS

Det kommer vara väldigt svårt att veta om koden har använts för den här typen av projekt. Samma sak med drivrutiner och annat till Linux-kärnan. Intressant utveckling. Jag skapade en tråd om det här.

Ciryon

Undrar hur wine teamet kan kolla att koden inte kommer från denna läcka, vem som helst kan bidra med kod.
Men wine teamet får inte läsa MS kod, hur vet dom då ?

Hmm

MS lär nog berätta för dom om så är fallet...

jobbig situation ...