Pas de 64 bits pour Carbon

Christophe Laporte |
Lors du Keynote, Steve Jobs a longtemps insisté sur le fait que Mac OS X 10.5 serait totalement 64 bits. Durant son discours, il a évoqué essentiellement les possibilités que cela ouvrait aux applications Cocoa, mais pas un mot sur Carbon. Sur la nouvelle page consacrée au 64 bits, Apple évoque bon nombre de frameworks à l'exception notable de Carbon.



Il semble donc qu'il ne sera pas possible de développer des applications 64 bits en Carbon. C'est d'autant plus surprenant qu'Apple avait laissé entendre le contraire lors de la WWDC précédente (voir à ce sujet la page dédiée au 64 bits sur le site d'Apple France qui na pas été mise à jour). Quoi qu'il en soit, cela confirme le fait qu'Apple souhaite visiblement mettre en stand-by Carbon et inciter le plus de développeurs à se mettre à Cocoa.

Cette décision devrait toutefois avoir des conséquences. Bon nombre de logiciels, surtout ceux qui sont multiplateformes, vont avoir du mal à passer au 64 bits, car ils font appel et à Carbon et à Cocoa. Dans ce type de cas, les développeurs devront supprimer toutes les références à Carbon pour passer en 64 bits. Dernière chose que Steve Jobs n'a pas précisée au sujet du 64 bits, cela devrait gonfler un peu plus la taille des applications. Les exécutables comprendront le code nécessaire pour chaque processeur ainsi que pour le 32 bits et le 64 bits.
avatar Anonyme (non vérifié) | 
On est pas sortis de l'auberge. Si en plus on doit compiler des applications encore plus volumineuses... Il faudra avoir des gros disques et des bons serveurs :-/
avatar Anonyme (non vérifié) | 
C'est pas OOo aqua qui est ecrit en carbon?? pourtant depuis longtemp il avait été suggeré a ericb et a son equipe, de developper OOo en cocoa, bien plus moderne. OOo va etre vieux avant de naitre. Je sens que ericb va arriver et va dire que c'est du benevola et que si on est pas content , tanspis et qu'ils ont besoin de dons et patati patata....
avatar Anonyme (non vérifié) | 
Du calme, le 64bits ne va pas sauver le monde non plus. Je dirais même que pour OOo, ça n'apporterait rien. Donc tout va bien.
avatar Anonyme (non vérifié) | 
elian a écrit > > Je sens que ericb va arriver et va dire que c’est du > benevola et que si on est pas content , tanspis et > qu’ils ont besoin de dons et patati patata.... > Et c'est bien là le problème avec le libre. Dès qu'il s'agit de faire mumuse<br /> dans son coin, y a du monde. Mais lorsqu'il s'agit vraiment de faire un<br /> travail sérieux et de qualité, il n'y a plus personne. Dans ces conditions, nous n'avons d'autres choix que de nous tourner vers les alternatives propriétaires autrement plus aboutis et vraiment adaptés à notre OS. A part ça, moi dans la vie, j'aimerais bien écrire des tribunes dans MacGéné. Alors, c'est d'accord? nona
avatar Anonyme (non vérifié) | 
Ben c'est sûr que le poids des Applications désormais développées va sacrément gonfler -> Universal Binaries = PPC + Intel -> et maintenant 32+64 bits !!! Ce qui serait cool et qui est déjà le cas pour certaines applis c'est d'avoir le choix entre PPC et intel, ça allège considérablement le poids (+ de la moitié)... Pour le reste, à savoir Cocoa et Carbon j'ai rien compris !
avatar Anonyme (non vérifié) | 
Excellente nouvelle. Parce que ça signifie que pas mal d'API qui étaient encore exclusivement Carbon (comme QuickTime, dont le QTKit de Cocoa est une vaste blague) vont passer sous Cocoa avec Leopard. Ouf.
avatar Anonyme (non vérifié) | 
Bonjour à tous ! Cocoa facilite en effet beaucoup la vie des programmeurs mais n'est accessible qu'en Objective-C (et aussi Java). Dès lors qu'il faut porter une appli venant d'une autre plateforme, les développeurs utilisent le plus souvent Carbon qui est accessible en C/C++, le language le plus souvent utilisé. Il est donc étonnant que carbon ne supporte pas le 64 bits aussi. Mais peut-être Apple préfère mettre en avant Cocoa qui permet d'avoir des applis plus conformes à l'esprit MacOSX ? Et comme le disait vintz72, le 64 bits ne va pas sauver le monde : autant c'est devenu indispensable pour les serveurs et les Gestionnaires de Base de Données, autant pour un traitement de texte cela est superflu.
avatar Anonyme (non vérifié) | 
Pour ceux qui veulent un peu plus d'infos sur Carbon, voici le lien WikiPedia (anglais) : http://en.wikipedia.org/wiki/Carbon_API <br /> et pour Cocoa: http://en.wikipedia.org/wiki/Cocoa_API
avatar Anonyme (non vérifié) | 
Tout est très logique là-dedans. Apple pousse Cocoa à fond pour créer une vraie différence avec d'autres OS. Seules les applis qui s'appuient sur Cocoa bénéficient de toute la puissance de l'OS : Core Animation, corrections orthographique, les services, etc. etc. L'utilisateur ne fait plus la différence entre l'interface d'XP et celle de MacOS X à cause de Carbon qui permet une unification, il est temps de montrer sa différence jusqu'à la moindre appli. Mais il est clair qu'il y a un sacré boulot à faire pour que les appels à Carbon dans bon nombre d'applis pro puissent être pris en charge par Cocoa.
avatar Anonyme (non vérifié) | 
Oui c'est logique. Carbon c'était surtout fait pour la transition, avec le temps, tout le monde passera à Cocoa même les gros dinosaures comme Adobe ou MS.
avatar Anonyme (non vérifié) | 
Ceux qui critiquent l'Open Source me font quand même doucement marrer, surtout pour dire que c'est pas coder en Cocoa qui n'apporterait strictement rien dans ce cas... Merci de se renseigner un minimum sur l'ensemble de ces choses avant de sortir de telles énormités
avatar Anonyme (non vérifié) | 
Nona, si tu as envie de payer pour une suite buggée elle aussi développée en Carbon, c'est ton choix... mais merci de ne pas critiquer ceux qui bossent bénévolement avec des technologies parfaitement à l'ordre du jour (Carbon)...
avatar Anonyme (non vérifié) | 
@tom : non, Carbon n'est pas (plus) une API de transition. Et normalement, on doit pouvoir accéder à toutes les nouvelles technos OSX (CoreAudio, coreAnimation, ...) via cette API. (Cf les liens Wikipedia que j'ai posté plus haut).
avatar Anonyme (non vérifié) | 
"Pour ainsi dire, Cocoa (qui est un framework) n’existe pas sans Carbon (qui est aussi un framework)." Donc NextStep n'existait pas. <br /> On peut très bien avoir un core utilisant du carbon et une interface 100% cocoa et cela coûte moins cher en portage que de tout faire en carbon. Seulement, il faudrait réfléchir à l'interface graphique ce qui n'est apparemment pas le but de beaucoup d'éditeur.<br /> En gros, ce qui compte, le nombre de fonctions au détriment de la facilité d'utilisation. Hé bien chez Apple, et pour les mac user, c'est l'inverse.
avatar Anonyme (non vérifié) | 
@Un Type: complétement d'accord. Après c'est une question de gros sous et de temps, comme d'habitude. Cependant, c'est toujours dur de faire une appli multi plateforme qui prenne en compte les spécificités de chacune. C'est pour cela que parfois il vaut mieux se rabattre sur un logiciel développé pour l'OS que l'on préfère. Bonjour Maurice, toujours en pleine forme à ce que je vois ;)
avatar Anonyme (non vérifié) | 
Carbon n'est certainement pas une API de transition *uniquement*. Si c'était le cas, l'API n'aurait pas autant évolué qu'elle l'a fait. Les HIView et tout ce qui a été ajouté aux CarbonEvent vont bien au delà de la simple transition, et la plupart ont été ajoutés *après X.2*.
avatar Anonyme (non vérifié) | 
et on en saura un peu plus ce soir, après la session sur la HIToolbox d'aujourd'hui à la WWDC
avatar Anonyme (non vérifié) | 
Sur le lien de MacG menant au site Apple : > Désormais, les frameworks applicatifs Cocoa et Carbon, les > graphismes, les scripts et les autres composants du système > s'exécutent tous en mode 64 bits.<br /> J'ai louper un truc ?
avatar Anonyme (non vérifié) | 
Finalement, sur Apple.com on trouve : > Now the Cocoa application frameworks, as well as graphics, scripting, > and the UNIX foundations of the Mac, are all 64-bit.
avatar Anonyme (non vérifié) | 
@ Nico : Les défenseurs hystérisés du libre qui ne supportent pas la moindre critique, même quand elle est constructive (ça peut arriver) sont aussi particulièrement fatiguants. Et ne pas comprendre l'ironie est aussi le propre des intégristes... C'est assez amusant de parler du 'libre' mais de ne pas supporter la 'liberté' d'expression... On appelle ça se tirer un balle dans le pied... ou perdre toute crédibilité...
avatar Anonyme (non vérifié) | 
Ce qui ne me paraît pas choquant. Si vous lisez la documentation destinée aux développeurs, vous verrez écrit noir sur blanc dans les documentations consacrées aux environnements de développement et aux langages, qu'Apple préconise de programmer pour l'environnement Cocoa, environnement de prédilection pour l'Objective-C. Quand un éditeur insiste comme ça, ce n'est pas pour rien. Cela veut dire en général que certains environnement anciens ne seront plus supportés par la suite. Bingo, c'est le cas pour Carbon. L'environnement Carbon n'était là qu'à titre de rétro compatibilité au niveau du code source et pour faciliter les développeurs à transiter vers l'Objective-C. Carbon est présent sur Tiger (et ces prédécesseurs) afin de faire passer les développeurs vers Cocoa. <br /> C'est dans les docs de la Pomme...
avatar Anonyme (non vérifié) | 
@v. Ce que je voulais dire, c'est qu'en étant qu'utilisateur d'informatique, il ne faut pas à tout pris chercher à acquérir la dernière techno "à la mode". Il faut bien cerner ses besoins car parfois, utiliser une nouvelle techno peut être moins "productif" que continuer à utiliser ce que l'on avait déjà... Je n'ai JAMAIS voulu dire que le 64 bits était inutile. S'il vous plait, avant de répondre à un poste, relisez-le, et essayez de comprendre ce que l'auteur à voulu dire. Merci.
avatar Anonyme (non vérifié) | 
@Xit : Cela fonctionnera sur un G4 (à mon avis 800MHz minimum)
avatar Anonyme (non vérifié) | 
>Si, mais la version de Next s’appuyaient sur la BlueBox et la<br /> >YellowBox... ce qui est faux.. NextStep ce basais sur le framework "NextStep" renommé plus tard OpenStep. La "yellow box" est le terme utilisé par Apple pour nommer OpenStep, et la BlueBox a été inventé par Apple pour avoir une boite de compatibilité entre les Mac OS classiques et OS X. D'ailleurs, la BlueBox.. ce n'est meme pas Carbon, mais "TruBlueEnvironment" cad l'environement classic pour Mac OS X.. >Carbon/Corefundation et consort sous OS X. Carbon n'est pas la BlueBox. CoreFondation a été inventé par apple vers a peu pret Panther pour uniformiser les types de données entre Carbon/Cocoa et si certaines "fonction" de Cocoa sont mappé sur des fonctions CoreFundation ce n'est que pour un problème de vitesse. L'Obj-C est plus lent que du C de base. C'est un fait et ça le sera toujours. <br /> >Mais Cocoa Seul, niet... Et si Cocoa peut "vivre" tout seul sans utiliser un gramme de C/C++ ou de carbon, mais le problème reste que ec n'est pas efficace, c'est lent etc..
avatar Anonyme (non vérifié) | 
La liberté d'expression semble un terme à redéfinir pour pas mal de personnes... Se renseigner avant de critiquer n'en n'est pas une limitation... M'enfin bon...
avatar Anonyme (non vérifié) | 
@Diafon Les Core 2 Duo sont 64bit, donc oui. Les Core Duo sont 32bit "seulement".
avatar Anonyme (non vérifié) | 
Normal, impossible d'implémenter les deux caisses de couilles qui vont avec les 64 bits...

CONNEXION UTILISATEUR