Nieuw project laat OS X-applicaties draaien binnen Linux

Een ontwikkelaar is een opensource-project gestart in een poging OS X-applicaties op Linux te laten draaien. De eerste OS X-software zou inmiddels door The Darling Project worden ondersteund waarbij gebruik wordt gemaakt van een Darwin-emulatielaag.

De Darling-emulatielaag, die is geschreven in C++11 en Objective-C, functioneert volgens de ontwikkelaar in grote lijnen hetzelfde als Wine, de Windows-emulator voor Linux-besturingssystemen. OS X-binaries worden doorgestuurd naar de Darwin-kernel waarna de code wordt gestart. Om de software succesvol te kunnen draaien, zijn er echter ook koppelingen aangebracht naar de zogenaamde abi-compatibele libraries en frameworks die door OS X-software worden gebruikt. Ook is aan Darling code toegevoegd om programma's die in Objective-C zijn geschreven, goed te laten draaien door ondersteuning voor de bijbehorende Cocoa-bibliotheken.

De Darling-emulator is momenteel in staat om enkele eenvoudige OS X-applicaties te draaien binnen Linux. Daarvoor wordt gebruik gemaakt van een zogenaamde Mach-O-loader om de OS X-binaries in te kunnen lezen, een runtime transition layer voor Apple Objective C en een Darwin-emulatielaag.

Hoewel de huidige vroege versie van Darling nog geen iOS-code kan emuleren, zou het theoretisch mogelijk zijn om iOS-applicaties in Linux te draaien. Daarvoor dienen echter wel extra libraries aan Darling te worden toegevoegd en bovendien moet de emulatielaag geschikt worden gemaakt voor de ARM-architectuur.

Momenteel heeft de ontwikkelaar en student Luboš Doležel geen concrete plannen om iOS-emulatie aan Darling toe te gaan voegen omdat in zijn ogen Android momenteel 'de markt domineert'. Verder meldt Doležel dat zijn project uitsluitend gebruik maakt van opensource-code en zijn emulator dus geen copyrights van Apple schendt.

Reacties (67)

[johnkeates]

Dit was ook gewoon slecht seen kwestie van tijd Natuurlijk gaat iedereen nu eindgebruikers-toepassingen verzinnen, maar in dat stadium is dit nog lang niet, en als het eindelijk zo ver is: de mogelijkheden worden opeens eindeloos! Ik denk dat dingen als CS6 & Co. veel sneller via een Mac OS X Mach-O-Loader + RTL kunnen draaien die via de win32 laag van Wine. Waarom? Om dat in Win32 echt NIKS bestaat buiten Windows-specs (en dus kernel) om. Bij Mac OS X kan je met de Unix en POSIX systemen nog vrij veel 1-op-1 overzetten tijdens translation.

[wjvds]

Zou het hiermee in de toekomst ook mogelijk kunnen worden iOS apps op Android te draaien? Dat zou natuurlijk heel veel mogelijkheden brengen voor Android (uitgaande van geen problemen met patenten/licenties).

[Verwijderd]

Ik denk dat het makkelijker is om dat aan de developer zijde te realiseren. Er zijn al tools beschikbaar van waaruit je apps voor diverse platform kunt compileren. De mogelijkheden zijn nog wat beperkt, maar dat lijkt me een kwestie van tijd.

[SoloH]

Dit zijn alleen HTML5 apps gemaakt in speciale frameworks.

[Justhim]

Uiteindelijk zouden er veel apps kunnen draaien, maar er zijn ook heel veel apps die gebruik maken van bijvoorbeeld een push-id, dat door apple wordt gegenereerd als de app dit opvraagt.
Ik vraag me af of je deze functionaliteiten kunt simuleren onder android.

[johnkeates]

Ik denk dat je dan eerst nog het Apps via Apple App Store probleem hebt. Hoe ga je ooit die Apps op je Android toestel krijgen? Volgens mij was per definitie een App die in de Store staat maar buiten de store om geinstalleerd wordt illegaal, tenzij je een developer bent.

[MacPoedel]

Een gejailbreakte iPhone kan ook apps installeren zonder dat Apple er tussen komt. Quasi elke app wordt zo wel gekraakt. Dit zou dus niet de beperkende factor zijn.

[BoringDay]

Een gejailbreakte iPhone heeft nog altijd een UID/IMEI nummer en noem maar op.
En een App heeft nog steeds verificatie codes.

Dat verhaal gaat dus niet op.

[BoringDay]

Elke App heeft ook nog eens een unieke sleutel welke weer samenhangt met het toestel.
Kans het ooit zal lukken is daarom ook nihil

[Verwijderd]

Dan nog even je GUI pimpen naar Mac-style en hoppa, je hebt geen original meer nodig!

Onder de kap is het toch bijna allemaal hetzelfde, als ik in Ubuntu de terminal open pas ik nagenoeg dezelfde commando's toe als in de Mac-terminal.

*nix=*nix

Al zal ik toch een echte Mac blijven houden, dat "net-niet-gedoe" levert in de praktijk toch altijd wel ergens een compatibaliteitsprobleem op, meestal op het moment dat je een cruciaal iets nodig hebt. Wel cool zou zijn als je XGrid dan ook op je 8-core kan draaien en zo wat CPU-power kan lenen aan je Mac voor renderen ofzo...toch wel nuttig dacht ik zelf.

[Verwijderd]

En wat te denken van support? Het is leuk om mee te hobbyen natuurlijk, maar als je het serieus wilt gebruiken (zakelijk) dan wil je ook gewoon support op de applicaties. Als je het dan op een platform hebt draaien wat niet op de zijkant van de doos staat (bij wijze van spreken) dan is er ook geen support. En dat om een paar honderd euro op de hardware te besparen...

[Verwijderd]

Je kan Mac4Lin gebruiken om er voor te zorgen dat je Linux er net zo uitziet als OSX.

[arjankoole]

Onder de kap, en dat gaat *veel* verder dan terminal app opstarten die onder Linux, BSD en OSX bash start, lijken ze totaal niet op elkaar. De kernels zijn anders, de libs, de so's (dylib onder osx) zijn anders, de binaries zijn anders. Alles is anders, behalve de gebruikte Shell.

[Verwijderd]

Als het mogelijk is om XCode te draaien kan dat handig zijn om zonder een dure apple te kopen toch voor OSX en iPhone te kunnen ontwikkelen. Voor de rest zie ik het nut er niet van in, er zijn weinig tot geen applicaties met unieke mogelijkheden die alleen op een apple draaien.

[milan475]

Ik weet wel dat Adobe er alternatieven voor heeft. Maar volgens mij zijn er zeker sectoren waar Final Cut Pro of Logic pro zeer van belang zijn.

[Verwijderd]

Als een specifieke app van belang is voor een bedrijf dan zijn de investering in de hardware niet het probleem. Dan schaf je gewoon een Mac aan als je FCP nodig hebt.

[kramer65]

er zijn weinig tot geen applicaties met unieke mogelijkheden die alleen op een apple draaien.

Dat klopt, maar gezien Mac OSX een stuk dichter bij Linux staat dan Windows, zou ik het me voor kunnen stellen dat sommige applicaties juist makkelijker te emuleren zijn van Mac OSX naar Linux dan van Windows naar Linux.

Zo zou ik erg blij zijn met Photoshop en Ableton (alhoewel die laatste over een tijdje bij mij vervangen zal worden door de aanstormende DAW voor Linux: Bitwig!)

Maar dit is ook slechts speculatie. Ik weet zelf te weinig van dit project en de techniek er achter om er echt iets intelligents over te zeggen..

Iemand anders die hier iets over kan zeggen?

[Reactie gewijzigd door kramer65 op 22 juli 2024 23:39]

[Verwijderd]

geen appels met pinguins vergelijken. unix en linux verschillen zo enorm van elkaar.
dat het gewoon net zo moeilijk is als een linix windows emulator te vormen. misschien is het wel gemakkelijker om een bron code van een OSX programma's te nemen en dat dan compilen voor linux lijkt me een stuk gemakkelijker dan OSX emuleren.

[SoloH]

Kan je toch beter een dure Apple kopen? Heb je de kracht van osx en Darwin tot je beschikking. Meer dan de helft van de Google developers programmeren ook op Apple. Geen rede tot schaamte hoor
En je kan gewoon x Windows draaien en er zijn duizenden Mac ports beschikbaar.

[RoestVrijStaal]

Gezien het feit dat via het Darwin Project de meest essentiële zaken bekend is om een 'MacOSX-laag' te maken, gaat bij mij de vlieger niet op om dit project met Wine te vergelijken.

Bij langena niet. Bij dit project maken ze van een rode appel (Linux) een groene appel (MacOSX) en niet een peer (Windows), want zowel MacOSX en Linux zijn UNIX-achtig en beide zijn POSIX-compatibel.

Ik gok er zelfs op dat dit project eerder klaar is dan dat de doelstellingen van Wine acceptabel genoeg gehaald zijn.

Overigs wens ik ze wel veel succes om de 'juridische druk' van Apple te trotseren.

[rob12424]

Windows is tegenwoordig ook op delen POSIX-compatibel.

Dit is overigens niets nieuws. Ik kende iemand die linux al met een aangepaste Carbon Libary draaide. Hij is er mee gestopt toen ze over gingen op Cocoa. Een vriend van mij vroeg waarom hij niet doorging. Zijn reden was dat hij dan aangeklaagd kon worden het een hobbyproject was van een paar jaar. (hij had het er wel over dat het met cocoa een stuk ingewikkelder werd om de boel te symlinken, maar niet onmogelijk was om Apple programma´s zelfs native op Linux te draaien) Volgens hem koste het project toen 6 jaar van zijn tijd in de avond uren. Het totaal overnieuw uitvoeren zou 13 jaar ongeveer kosten en dan hadden ze waarschijnlijk al weer nieuwe libs. (3-4 uur per avond zo ongeveer)

[--Andre--]

Tegenwoordig? Volgens mij is dit al vanaf 1993. In die tijd werdt het POSIX subsystem standaard met Windows NT geïnstalleerd, dit om de overstap van UNIX naar Windows NT te vergemakkelijken. Tegenwoordig is dit is optioneel.

[Verwijderd]

Overigs wens ik ze wel veel succes om de 'juridische druk' van Apple te trotseren.

Zolang het een hobby-project blijft is er niets om bang voor te zijn, lijkt mij (ik ben geen jurist). Zodra de ontwikkelaar er geld mee wil verdienen, of zodra linux-distributies dit willen bundelen, wordt het denk ik een ander verhaal.

Maar... volgens mij staat het iedereen vrij om API's na te maken (was er onlangs niet een rechtzaak over Java, die Google gewonnen had?). Dan is alleen de artwork een probleem.

[hardwareaddict]

compleet hopeloos project vanuit juridisch oogpunt.

het zal wel snel doodbloeden.

[Verwijderd]

wine is na 15 jaar nog steeds niet geschikt voor alle software, dus een goede emulator is blijkbaar geen makkie

Windows evolueert nog constant, Wine blijft daar altijd volgend. En aangezien de API's lang niet altijd perfect beschreven zijn, blijft dat altijd vallen en opstaan.

En ten overvloede Wine is *NOT* an Emulator. Wine schrijft de Windows API's om naar Linux, dus een Windows Applicatie draait in principe native, niet geëmuleerd.

Dat maakt het naar mijn idee ook een stuk lastiger. Het is een ambitieus project, te ambitieus als je het mij vraagt. Maar het zou mooi zijn als je op een gegeven moment niet meer hoeft te kijken waarvoor je de applicatie koopt. Windows, Linux en Apple allemaal uitwisselbaar.

[Thlinx]

Ik ben het met je eens dat Windows een moving target is, echter ik zou het al prima vinden als Wine alleen XP software perfect zou kunnen draaien.
Dat is helaas in veel gevallen nog steeds niet zo. Zelfs een nog steeds erg populair spel als C&C red alert is met de laatste versie van Wine niet te draaien. Er zijn Wine versies die niet crashen, echter het is altijd een hit/miss situatie en helaas meestal miss..
Ik heb ook niet het idee dat het nu vaker hit is dan vroeger, programma's die het vroeger niet deden gaan zelden ineens werken.

Ik vrees ook dat de euforie over dit 'Darling' over een tijdje ook wel over zal gaan in gelatenheid. Zelden zie je dat een mooi concept in de praktijk goed werkt.

[Wim-Bart]

Eigenlijk wil je helemaal af van Windows XP. meuk, alleen al omdat veel XP software zon slecht is geschreven dat het niet eens werkt op moderne os'en zonder te hoeven rotzooien met bijvoorbeeld Thinapp of iets dergelijks.

[Amanoo]

PlayOnLinux scheelt hiermee. Die maakt meerdere "virtuele machines", of iets wat hierop lijkt, aan met WINE. Je kan dus voor ieder programma een aparte WINE versie hebben, eventueel met zijn eigen hacks. Verder is er ook een databaseje met over sommige software informatie hoe het draaiend te krijgen is. Persoonlijk ben ik niet echt weg van WINE en hierop gebaseerde software.

[borft]

zoals eerder gemeld is wine dus ook niet een virtual machine. Het is een beperkte implementatie van een aantal windows libraries zoals oa directx.

[Verwijderd]

Tja. Technisch heel leuk, maar:

- is er iemand met Linux die per se die ene OSX-only applicatie wil draaien?

- wine is na 15 jaar nog steeds niet geschikt voor alle software, dus een goede emulator is blijkbaar geen makkie

- als je het toch per se wil, draai dan OSX / Hackintosch in een VM. Of koop een Mac. Dan heb je tenminste de hele OSX-beleving.

[hardwareaddict]

dit wordt natuurlijk illegale software deze emulator als het project ooit goed gaat werken, want ik vermoed dat de dagvaarding al onderweg is. procederen tegen het bedrijf met meer cash geld in kas dan enige overheid ter wereld heeft

[Amanoo]

Waarom wordt dat illegaal? Mensen hebben toch ook niet WINE op hun computer om illegaal Windows-programma's te draaien? Er zullen er vast wel wat zijn die een illegale versie van Office op hun Linux draaien, maar dat is een keuze van de gebruiker buiten WINE om, net als dat het een keuze van de gebruiker buiten Windows om, om een illegale Office op Windows te draaien. Daar is Windows ook niet schuldig aan. En zo ook dit.

[blouweKip]

- is er iemand met Linux die per se die ene OSX-only applicatie wil draaien?

Die zullen er altijd zijn zolang applicaties niet platformonafhankelijk zijn

- wine is na 15 jaar nog steeds niet geschikt voor alle software, dus een goede emulator is blijkbaar geen makkie

Wine draait erg goed tegenwoordig, je vergeet echter dat dat een heel andere situatie is aangezien het daar om de windows api's gaat die buiten windows nergens gebruikt wordt (=veel meer werk)

- als je het toch per se wil, draai dan OSX / Hackintosch in een VM. Of koop een Mac. Dan heb je tenminste de hele OSX-beleving

Het gaat er natuurlijk om om voor applicaties niet telkens te hoeven herstarten naar een ander OS, hackingtoshen is inderdaad het makkelijkste.

[Shark.Bait]

Raar eigenlijk dat niemand anders dit al voor onder BSD heeft gemaakt

[ZpAz]

Je hebt al jaren gnustep enzo, de kernel mag dan vergelijkenissen tonen met linux, maar de frameworks waar het om gaat verschillen behoorlijk. Dit gaat dus de wine kant op maar dan met 12 jaar achterstand en minder support omdat er minder interesse voor is.

[teek2]

Aperture!
Zou mooi zijn maar denk dat, omdat het van Apple's eigen maak is, ze er alles aan doen om het osX exclusief te laten zijn.

[Verwijderd]

Inderdaad, ik denk sowieso dat alle grafische elementen (iconen, scrollbars, etc.) onder copyright vallen.

[Amanoo]

Gezien hoe het tot nu toe met spiritueel broertje WINE staat, na ondertussen vele jaren van ontwikkeling, heb ik er maar bar weinig vertrouwen in. WINE kan nog steeds veel dingen niet, en heeft toch echt al een zeer lange tijd van ontwikkeling gehad. En dit project heeft een lange achterstand op WINE...

[tweakerbee]

WINE moet echter de volledige win32 API implementeren, terwijl er hier een open source kernel beschikbaar is en het besturingssyteem zelf ook POSIX compliant is. Ik heb er geen goede kijk op, maar kan me voorstellen dat dit gemakkelijker is dan het reverse engineren wat bij WINE nodig is.