Firefox klaar voor Intel-Macs

Begin juni heeft Apple aangekondigd vanaf volgend jaar over te stappen van het PowerPC-platform naar de x86-architectuur. Om deze transitie zo eenvoudig mogelijk te laten verlopen, is het de bedoeling dat software zowel op de PPC- als op de x86-variant van Mac OS X zal werken. Om dat voor elkaar te krijgen, kan gebruikgemaakt worden van een zogenaamde 'universal binary'. In een dergelijk uitvoerbaar bestand is code aanwezig om het programma op beide architecturen te laten werken. Op den duur zal ook Mozilla Firefox als universal binary uitgebracht worden, nu is eerst gewerkt aan het porten van de browser naar de Intel-Mac-architectuur. Om te laten zien hoe eenvoudig dat is, heeft Apple tijdens de Apple Worldwide Developer-conferentie al een gepatchte versie, die werkt op de Intel-Macs, van Firefox vrijgegeven. De patches die Apple hiervoor gemaakt heeft, zijn beschikbaar gesteld aan de ontwikkelaars van de Mac-versie van Mozilla Firefox en op basis daarvan is ontwikkelaar Josh Aas aan het werk gegaan om Firefox klaar te maken voor de Intel-Macs.

Dit was namelijk nog een heel werk en kon niet gedaan worden door eenvoudigweg Apples patches toe te passen op de bestaande Firefox-code. Bij het schrijven van de patches was namelijk geen rekening gehouden met Firefox' cross-platformcompatibiliteit. Daarnaast waren de patches gebaseerd op oude code, omdat er alweer grote wijzigingen waren doorgevoerd met betrekking tot het buildproces van Firefox voor de PPC-Mac. Desalniettemin waren de patches erg bruikbaar, omdat erin te vinden was waar wijzigingen in de broncode nodig waren. Vervolgens zijn verschillende Firefox-ontwikkelaars aan de slag gegaan met de onderdelen, waaronder x86 assembly-code en het buildsysteem, die aanpassing nodig hadden. Al deze patches zijn samengevoegd en hebben geleid tot deze experimentele build die alleen op de Intel-Macs werkt. Vrijwel alles werkt zoals gewenst in deze versie van de browser, op een aantal plugins na. Op dit moment werkt alleen Quicktime goed, andere plugins laten de browser crashen en vereisen dus nog werk van hun respectievelijke makers.

Reacties (55)

Is het niet hopeloos inefficiënt om zowel x86 als PPC code in die uitvoerbare bestanden te stoppen, met die universal binaries?

Waarom is dat inefficiënt? Ik zou zelf het uitrollen van twee verschillende binaries, waar een samengestelde volstaat, inefficiënt noemen. One download, runs on two systems.. Impact qua performance is minimaal. En dat is ook nog eens tijdens opstarten. Runtime merk je geen verschil.

Helemaal mee eens. Verreweg de meeste data van een app bestaat toch meestal uit andere data dan machine-code. Zal een app een paar honderd Kb groter worden, who cares - kan je nauwelijks merken op de 100+ Gb harddisken van nu.

Eén van de redenen dat ik een paar maanden geleden na 20 jaar PC's over ben gegaan naar Mac is juist het gebruiksgemak. Maak liever gebruik van een app dan na te denken welke versie ik op welke Mac moet gaan gebruiken!

Dat is onzin, want het punt is juist dat op de PPC alleen de PPC-versie draait, en op de IA-32 alleen de IA-32 versie! De situatie waarin je beide versies installeert komt dus niet voor, want een van de twee draait gegarandeert niet.

Op de harde schijf is de overhead nog wel acceptabel, maar het is natuurlijk jammer dat alle downloads ook twee keer zo lang duren en twee keer zoveel geld kosten.

De situatie waarin je beide versies installeert komt dus niet voor

Juist wel. Net zoals tijdens de overstap van 68K naar PPC zullen de meeste developers gewoon FAT binaries beschikbaar stellen.

want een van de twee draait
gegarandeert niet.

Dat klopt, maar het voordeel is wel dat je programma's op een PPC Mac gewoon kunt overslepen naar een MacIntel en vice versa.

Lijkt mij ook wel inderdaad. Binary wordt er onnodig groot van.

Maar aan de andere kant.. Ik ben sinds een paar maanden ook Mac gebruiker, en aan de programmatuur download sites voor mac enzo alleen al te zien bestaat er onder Mac gebruikers een hele andere mentaliteit dan bij Windows gebruikers.
De sites zitten allemaal erg grafisch in elkaar, en de download zit meestal verscholen onder een groot icoon, waarna de .dmg downloadt en opent en het programma bijna gelijk klaar is voor gebruik.
Kortom: Mac gebruikers willen meer gemak (denk ik), en willen niet een site moeten doorzoeken naar de juiste binary voor hun. Het moet meer klik-en-klaar zijn.. vandaar het universal binary systeem.

Waarschijnlijk wordt die code niet meegecompileerd als je een bepaalde flag zet. Ze zullen wel omsloten zijn door preprocessor directives zeker? Dus als je voor intel-mac compileert, compileer je dat stukje code wel, maar als je voor linux-ppc compileert slaat hij het over.

Het is wel belangrijk dat alle architecturen dezelfde broncode gebruiken, anders zouden die verschillende broncodes waarschijnlijk uit elkaar gaan lopen. Vervolgens wil je een nieuwe feature toevoegen, en moet dat voor elk platform weer anders enzo. Het zou wel heel ingewikkeld worden.

Even goed lezen Sterrenkijker, de opmerking van Biert ging over "Universal Binaries", dus dan staat zowel de x86 als PPC code in de executable. Dit is handig om te voorkomen dat je 2 versies moet distribueren, maar ik vermoed dat de loader alleen de juiste code in het geheugen laadt. De executables (incl. dlls - heeft de mac ook zoiets?) worden idd. groter.

Dat doen nVidia, ATI en nog wel meer toch ook met unified driver packs? Dat vind ik juist extreem makkelijk. Ja, het is een grotere download en grotere install. Maar die paar MB boeien 90% van de gebruikers echt niet meer. Wel het veel grotere gebruiksgemak!

Valt in de praktijk nogal mee gok ik. Binary code is vaak relatief klein en veel (grote) resources, zoals icoontjes en tekst, die je gewoonlijk bij een binary meecompileerd kunnen gedeeld worden.

Je kan je harddisk dan nu volzetten met 5000 programma's voor 1 processor en met een fat binary kunnen er nog maar 2500 op... Maar... Wie gebruikt er 2500 verschillende programma's?

Je kan je harddisk dan nu volzetten met 5000 programma's voor 1 processor en met een fat binary kunnen er nog maar 2500 op...

Veel meer dan 2500 denk ik.. programma's bestaan uit veel meer dan alleen uitvoerbare code. Denk aan plaatjes, teksten, geluiden.. dat wordt allemaal niet verdubbeld natuurlijk.

sorry, verkeerd gelezen.....

Maar er zitten toch niet veel mensen hierop te wachten? De standaardbrowser in OSX (Safari) werkt zowiso een stuk beter en correcter dan Firefox, ik zou niet weten waarom iemand Safari dan per se wil vervangen.

Er zijn natuurlijk een hoop open source fanaten die per se Firefox willen. Bovendien zijn er ook mensen die gehecht zijn aan specifieke plugins.

Er zijn voor FireFox erg veel (honderden) XUL extensions te krijgen

http://extensionroom.mozdev.org/main.php/Firefox

Wat dacht je van FlashBloc?

Replaces Flash objects with a button you must click to play the animation.

of Bookmark LinkChecker?

Verifies whether your bookmarks are still valid.

Of Greasemonkey, waarmee je je favoriete site (Google, Amazon, Marktplaats, etc) kunt customizen,

http://news.com.com/Firefox+add-on+lets+surfers+tweak+sites,+but+is+it +safe/2100-1032_3-5631009.html

Op windows doe ik dat dan weer met Opera, alles wat jij net opnoemde kan met userjs gedaan worden (die greasemonkey is ook niet meer dan wat userjs)

Daarnaast is nog altijd een aardige hand webdesigners op mac die het best prettig vinden dat ff ook mac draait.

Daarnaast met x86 word het best aantrekkelijk dat zowel winxp als mac draaien op 1 systeem en dat er niet gewerkt hoeft te worden met virtual pc die toch echt erg traag is.

Websites bekijken kan nu ongeveer in alle standaard browsers op één systeem en das toch best fijn

Tsja, dat JIJ niet weet waarom je safari zou willen vervangen zegt nog niks over anderen.

Ik vind safari om meerdere redenen niet fijn, dus gebruik ik Camino. (Gecko engine, ook van de mozilla foundation).

Safari werkt volgens jou een stuk beter en correcter dan firefox. Wil je dat even uitdiepen? Volgens mij klopt dat namelijk niet zonder meer.

Ik ben overigens zeker geen open source fanaat, maar vind toevallig de bruikbaarheid van Camino en overigens ook Firefox hoger dan het meegeleverde Safari.

goh jammer om te horen dat het toch niet zo makkelijk met "a little checkbox" te porten is.
wel fijn natuurlijk dat de fabrikanten al druk bezig zijn om hun programma's te porten.

Dat heeft dan ook niemand beweerd. Steve Jobs heeft duidelijk aangegeven dat het in sommige gevallen weken tot maanden kan duren om iets te porten. Maar er zijn ook genoeg verhalen in het nieuws geweest over applicaties die direct voor x86 te compilen waren.
Ik was wel blij te horen dat grote developers als Microsoft, Adobe (en Macromedia) Mac op x86 volledig zullen ondersteunen. Adobe heeft meteen aangegeven bij eerste te willen zijn die al haar applicaties voor x86 beschikbaar maakt.

Tja, diezelfde dingen werden bij de overstap van Classic (Mac OS 9) naar OS X ook gezegd, Adobe was zeker niet snel toen (duurde naar ik meen 3/4 jaar voordat Photoshop en Illustrator als beta beschikbaar kwamen en die hingen nog zwaar op de compatibliteitsinterface carbonLib ... de achterstand die Adobe opliep hebben ze nooit ingehaald en kostte bv Adobe Premiere de kop, ten kostte van Final Cut Pro)

Quark was nog erger, het duurde bijna 4 jaar voordat Xpress beschikbaar kwam, ook een ramp voor de Grafische sector en welke betekende dat men lang bleef hangen aan OS9 en weifelde met de overstap ..

Microsoft was eigenlijk de enige, helaas is die juist op Apple gebied niet de sterkste in bedrijfstoepassingen (alhoewel natuurlijk wel met Office, echter juist waar Mac sterk is, video-editting en grafisch speelt MS een duidelijk mindere rol )

Wat dat betreft hoeven 'beloftes' nog niks te betekenen en zal het ook een enorm belangrijke sale-punt voor Apple worden hoe snel de overtsap voor andere fabrikanten lukt en moet Apple heel goed met hen samenwerken, anders zou deze overstap marketingtechnisch een 'brug te ver' blijken te zijn, als 75% van de veel gebruikte programmatuur domweg niet goed te draaien is op een nieuw Intel-based Mac.

Tja, diezelfde dingen werden bij de overstap van Classic (Mac OS 9) naar OS X ook gezegd, Adobe was zeker niet snel toen (duurde naar ik meen 3/4 jaar voordat Photoshop en Illustrator als beta beschikbaar kwamen en die hingen nog zwaar op de compatibliteitsinterface carbonLib

De overstap van OS9 naar OSX was wel even van een ander kaliber dan de overstap van OSX (PPC) naar OSX(x86). Developers moesten software aanpassen en soms hele stukken herschrijven omdat met de komst van de Carbon API veel oude OS9 API calls niet meer te gebruiken waren.

BTW Ik heb al een aantal Cocoa en Carbon programma's (grootste app >5 miljoen regels) compileerd voor MacIntel. Het enige probleem dat ik ben tegengekomen was een Carbon programma die tijdens het wegschrijven naar een bestand geen rekening hield met de endianess van het platform.

Echt lastig wordt het pas voor software welke gebruik maakt van assembly (zoals FireFox)

Quark was nog erger, het duurde bijna 4 jaar voordat Xpress beschikbaar kwam,

Quark heeft extreem lang gewacht (management blunder) voordat ze uberhaupt aan een OSX versie begonnen en daarnaast hebben ze gekozen voor een complete rewrite in Cocoa.

Vreemd was de gedachte die bij mij opkwam, waarom maakt het voor een browser, wat geen low-level applicatie i (op IE na dan) uit op wat voor hardware het OS draait.

Mischien is het niet zo vreemd als je bedenkt dat het programma gebruik maakt van mogelijkheden die een architecteur biedt. De ppc-architectuur heeft bijvoorbeeld altivec en de x86-architectuur maakt bijvoorbeeld weer gebruik van MMX en sse etc. (Dit verschilt ook weer per processor) om die mogelijkheden te kunnen benutten maakt het zeker wel uit op wat voor hardware het os draait. (Het programma en ook een browser moet toch weten hoe de hardware omgaat met zijn signalen en wat hij dan terug krijgt.)

Als je de programma netjes programmeert, dan is het wel degelijk een simpele "checkbox". OpenTTD, die al totaal cross-platform en portable is hoefde alleen maar een flag in de makefile te veranderen om het ook voor Intel-Macs te laten werken.

Beat that

Is het nu volledig x86 wat de klok slaat ?
Of blijven ze nog even langs elkaar bestaan ?

Ten eerste worden er nog steeds PPC-Apples verkocht en gaat dat voor sommige modellen ook zeker nog een jaar door. Daarnaast gaan Apples over het algemeen vrij lang mee dus zal het nog wel een jaar of vier duren voordat de helft van alle Apples Intel-CPU's draait.

Reken maar dat bijvoorbeeld software-producentenn zo'n grote groep PPC-gebruikers niet zomaar zal laten liggen en hun software voorlopig PPC-compatible zal blijven ontwikkelen.

Vanaf juni 2006 zullen de eerste MacIntels op de markt verschijnen voor consumenten. Vanaf juni 2007 zal Apple geen Macs met een PowerPC CPU meer verkopen. Er is dus aardig wat tijd voor ontwikkelaars om hun zaakjes op orde te krijgen en er is een flinke overlapperiode.

Nou.. gezien de performance issues bij een 3,6 ghz intel verwacht ik niet dat ze de G5 er zo snel uit goeien. Ik verwacht eerlijk gezelgd dat er altijd wel een high end powerpc machine blijft, zeker tot 2008.

Performance issues bij Intel's op 1 na snelste? Zeker dat hij veel sneller is dan de huidige Appels ja

Volgens Steve Jobs is het her-compilen van software naar het intel platform helemaal niet zo groot.

Apple een compiler ontwikkeld waarmee je bestaande code voor het ppc platform zo om kan zetten naar het intel platform.

Ontwikkelaars hebben beschikking gekregen over deze software zodat men er klaar voor kan zijn in 2006.

Apple een compiler ontwikkeld waarmee je bestaande code voor het ppc platform zo om kan zetten naar het intel platform

Nou die compiler heet GCC en heeft Apple niet ontwikkeld..

komt daarmee de cross-platformcompatibiliteit niet in gedrang?

ze gaan dus aparte versies ontwikkelen voor intel-macs?

Tuurlijk niet, de Linux -en Windowsversies zijn toch ook hetzelfde alleen draaien ze op een ander platform maar de architectuur blijft Intel.

In het blog staat ook:

Firefox was developed to run Intel x86 Processors before it was ported to the Macintoh. The Macintosh is now being ported to use intel processors.

Dus Macintosh zelf wordt geport van PPC naar Intel, niet de PPC versie van Firefox terug naar Intel.

Als ik ernaast zit roepen jullie wel he want ik begin steeds meer te twijfelen nu, maar het is ook al laat

Hopelijk is de browser goed afgeschermd van de plugins, want de kans bestaat dat een plugin die niet geschikt is voor de x86 versie, niet alleen zichzelf, maar ook de browser zelf onderuit haalt.

Het is gewoon een onafhankelijke architectuur; op dit moment worden er ook geen Windows of Linux versies van plug-ins op PPC Macs geïnstalleerd; waarom zou dat met plug-ins voor Intel Macs (die net zo goed een incompatible architectuur hebben) anders zijn?

Zie eens hoe snel de transitie naar een ander platform gemaakt kan worden, dat vind ik nou mooi. niet iets wat ik de maker een zekere browser met blauwe E zo snel zie doen.

Er is nochtans een zekere browser met blauwe E beschikbaar voor mac

Safari mag dan mijn hoofdbrowser zijn op de Mac, maar keuze is altijd prettig natuurlijk. En Firefox doet het ook op de Mac uitstekend, zeker met bankensites.

Trouwens, als dat wat jij (Boeboe) zegt, logisch was, had ik niet zoveel moeite hoeven doen om IE zoveel als mogelijk van de PC te verwijderen.

Een FAT binary is een feite gewoon een folder met daarin een mapje voor Mac os en een Map voor intel.

Dus als je straks je apps kleiner wil maken haal je gewoon de mac of intel map eruit.

De reden dat firefox wat lastiger te porten was, komt door dat firefox geen cocoa app is.
alle cocoa apps zijn redelijk eenvoudig te porten want het framework verhuist gewoon mee