Avis d'un développeur Mac...

Frodon a dit:
Si MacOS venait à mourrir un jour, ca ne serait pas dû au switch sur Intel, mais à un abandon d'a la fois les developpeurs (surement dans un premier temps) puis des clients.
En ce qui concerne les clients, je crains fort que la spécifité d'Apple ne soit plus assez forte pour attirer de nouveaux clients et conserver assez d'ancien. (Si Apple c'est pareil, pourquoi changer?)

Frodon a dit:
Si tu as peur que MacOS meurt et donc rende ton projet subitement non viable, tu peux très bien supporter officiellement que MacOS mais faire tes logiciels suffisamment portables pour pouvoir les adapter rapidement à un autre OS au besoin.
Ouais, vive JAVA (beurk :-( Cela me servira de leçon, fini Altivec et autres trucs proporiètaires, le 64 bits et l'optimisation pour plusieurs processeurs, vive le plus petit dénominateur commun. J'envisage en effet d'utiliser 100% des outils et librairies OpenSource et portable. Mais bon mon soft en X11, pas terrible :nailbiting:

Frodon a dit:
il semble que vous soyez peu nombreux à pre-juger de l'avenir en succombant à vos sentiments.
Je ne parlais de sentiments, mais d'inquiétudes économiques. En ce concerne les sentiments, c'est sûr, je suis trahi par ce que j'aimais le plus et je vais devoir bosser pour l'ennemi de 30 ans, chouette.

Frodon a dit:
Perso je pense qu'Apple a pris beaucoup plus de risque avec la transition MacOS 9 -> MacOS X (bien que comme la transition sur x86 actuelle, la transition vers MacOS X était necessaire car MacOS 9 commencait serieusement à vieillir)
MacOS X était très attendu. x86 n'est ni attendu ni souhaité.

Frodon a dit:
il est evident que les gens qui passent du PC au Mac, switchent parce qu'ils veulent autre chose que Windows et donc pour MacOS X et pour certains le design des machines(comme l'a montré un temoignage d'un switcheur sur ce forum). Tous simplement AUCUNES des personnes à qui j'ai parlé du Mac n'ont été interessé par l'idée de changer type de CPU, car quoiqu'on en dise les CPU Intel (et AMD) sont des bon processeurs, et les gens n'ont pas vraiment de raison de s'en plaindre.

Pour ma part, jes switchers que je connais l'ont fait autant pour l'OS que pour le Hardware. Le PC moyen est quand même d'une fiabilité matérielle assez faible. Certains, peu, (sous Linux-AMD) étaient venus unqiuement pour l'architecture matérielle (XServe, notamment).

Quant à la transition, quitte à apprendre à optimiser du code pour x86, c'est bien plus rentable de le faire pour Windows que pour MacOS dont la PDM sur x86 est actuellement de 0%.

Enfin, pour ce qui est soutien des grands éditeurs, en ce qui concerne Adobe et M$, je doute sérieusement (jene renouvelais plus mes licencces Adobe depuis déjà qulques temps, pour protester contre le comportement anti-Apple d'Adobe). Pour les autres, ils n'ont pas d'autre choix que d'applaudir.

Bref, je vois des raison objectives de ne pas applaudir béatement à ce changement radical et à éprouver des inquiétudes.
 
Bonjour,

Klimi a dit:
En ce qui concerne les clients, je crains fort que la spécifité d'Apple ne soit plus assez forte pour attirer de nouveaux clients et conserver assez d'ancien. (Si Apple c'est pareil, pourquoi changer?)

Mais ca ne sera pas pareil. MacOS X n'a rien à voir avec Windows. Et les Mac Intel garderont le design legendaire des Macs et feront tourner MacOS X. Comparé à la plateforme Mac actuel, RIEN ne change, en dehors du CPU, cela necessite juste un peu de travail pour les developpeurs (mais rien de comparable à la Carbonisation d'un logiciel MacOS 9). Pour l'utilisateur final, il n'y aura aucune différence visible, même leurs logiciels actuels, compilés pour PowerPC, continueront à fonctionner (avec Rosetta).

Ouais, vive JAVA (beurk :-( Cela me servira de leçon, fini Altivec et autres trucs proporiètaires, le 64 bits et l'optimisation pour plusieurs processeurs, vive le plus petit dénominateur commun. J'envisage en effet d'utiliser 100% des outils et librairies OpenSource et portable. Mais bon mon soft en X11, pas terrible :nailbiting:

Tu peux faire des logiciels facilement portable (je parle pas de faire un logiciel qui marche direct avec une simple recompilation, mais d'un programme qui peut être porté rapidement (quelques semaines)) sans aller jusqu'a faire du X11 et du Java.

MacOS X était très attendu. x86 n'est ni attendu ni souhaité.

Détrompe toi, pour certain, notamment certains PC users, l'arrivé de MacOS X sur x86 est attendu. Personnellement je m'attendais à ce que cela arrive, cela dit je l'attendais plutôt comme OS tournant sur n'importe quel PC, car selon moi Apple doit y venir un jour pour que MacOS X ait une chance de vraiment gagner des parts de marché. En faisant passer ses machines actuellement ca devrait déjà faire gagner des parts de marcher, mais à terme il m'a toujours semblé evident qu'il faudra que MacOS X s'ouvre à tous les constructeurs d'ordinateurs (Cela viendra peut être plus tard...), car j'imagine mal un marché informatique dominant n'ayant qu'un seul constructeur d'ordinateur.

Pour ma part, jes switchers que je connais l'ont fait autant pour l'OS que pour le Hardware. Le PC moyen est quand même d'une fiabilité matérielle assez faible. Certains, peu, (sous Linux-AMD) étaient venus unqiuement pour l'architecture matérielle (XServe, notamment).

Les PC fait maison avec des pieces de la rue-montgallet, je suis d'accord, mais des PC de grand constructeurs comme SONY, c'est pas moins fiable que les Mac (mais c'est moins beau ;) ). Que ca soit les PC ou les Mac actuels, les cartes mères sont fabriqué en Asie par les même fabricant et sont architecturé de la même façon (un CPU, un northbridge, un southbridge, des ports PCI et AGP...etc).
Donc penser que le Mac est plus fiable au niveau du hardware qu'un PC c'est une erreur. Il est plus design, mais la fiabilité du hard est similaire à un autre grand constructeur.

Quant à la transition, quitte à apprendre à optimiser du code pour x86, c'est bien plus rentable de le faire pour Windows que pour MacOS dont la PDM sur x86 est actuellement de 0%.

Cela dit si les developpeurs supportait juste la plateforme la plus rentable, le Mac serait mort depuis longtemps. Cet argument n'est donc pas valable.
De plus, optimiser du code x86 sur MacOS X x86, ca restera du code qui marchera aussi sur Windows et inversement.
Et puis avec le systeme d'Universal Binary de MacOS X tu peux supporter en même temps les personnes encore sur PowerPC et les (futur actuellement) utilisateurs déjà sur x86, donc la totalité de la PDM de MacOS X (PPC et x86).

Enfin, pour ce qui est soutien des grands éditeurs, en ce qui concerne Adobe et M$, je doute sérieusement

Et pourtant il l'ont déclaré OFFICIELLEMENT. Il n'y a donc plus AUCUN doute, Adobe et Microsoft supporteront le Mac Intel.

(jene renouvelais plus mes licencces Adobe depuis déjà qulques temps, pour protester contre le comportement anti-Apple d'Adobe).

Ce qui n'est pas bien grave puisque les logiciels PowerPC d'Adobe fonctionne très bien avec Rosetta (même s'il y a une petite perte de performance) sur Mac x86.

Pour les autres, ils n'ont pas d'autre choix que d'applaudir.

Si tu le dis...

Bref, je vois des raison objectives de ne pas applaudir béatement à ce changement radical et à éprouver des inquiétudes.

Ne pas applaudir bêtement, certes, mais il faut bien se rendre à l'évidence, c'était soit Apple choisissait une transition sur x86, soit ils restaient sur PowerPC et se retrouvait dans la même situation d'evolution (très?) lente qui a commencée depuis quelques mois avec le G5 (obligé d'overclocker les G5 et de faire des systèmes de refroidissements de folies pour faire évoluer péniblement les performances du G5, pas de G5 adapté aux portables).

Je n'ai pas vu de raison valable d'avoir des inquietudes dans tout ce que tu viens de dire. Y'avait beaucoup plus de raisons de s'inquiéter lors du passage de MacOS 9 à MacOS X (et encore plus lors du passage du 68k au PowerPC), que lors de cette transition sur x86. En effet lors de la transition MacOS 9->MacOS X, les risques étaient bien plus elevé car pour adapter les logiciels à MacOS X les developpeurs avaient beaucoup plus de travail que pour la transition sur x86 et Apple était en bien moins bonne forme qu'aujourd'hui. Et je ne parles pas de la transition 68k->PPC pour laquelle l'OS ne s'y pretait pas beaucoup au départ (pas portable) et Apple était pas en très bonne santé.

Bref, franchement, c'est se stresser inutilement de s'inquieter pour cette transition vers le x86, y'a vraiment AUCUNE raison que cela ne se passe pas ENCORE MIEUX que la transitions MacOS 9->MacOS X.

A+
 
il faut bien se rendre à l'évidence, c'était soit Apple choisissait une transition sur x86, soit ils restaient sur PowerPC et se retrouvait dans la même situation d'evolution (très?) lente qui a commencée depuis quelques mois avec le G5 (obligé d'overclocker les G5 et de faire des systèmes de refroidissements de folies pour faire évoluer péniblement les performances du G5, pas de G5 adapté aux portables)
IL est certain que le G5 dans 1 portable, ce n'est pas pour demain. Mais je ne crois pas à cette raison officielle, le G4 est suffisant sur un portable (jai encore un PB 68040 pour la maison ;). Je pensais qu'IBM avait jeté Apple, or je viens de lire qu'IBM continue de promouvoir le PowerPC pour micro-ordinateur sur un salon Linux (perdu l'URL). L'hypothèse des DRM avec Palladium dans l'x86 me parait au moins aussi vraisembable (Steve Jobs gagne surtout de l'argent avec Pixar).

Mais quelle que soit la raison réelle, je constate un tollé général provoqué par cette décision.
En ce qui conerne les transitions précédentes, admettons que techniquement, le boulot soit moins dur aujourd'hui, mais il y a une grosse différence : mes commanditaires me demandaient les transitions précédentes, aujourd'hui, ils ne veulent pas de ce changement, dont ils ne comprennent pas le sens (et moi non plus).

Il est logique que je m'interroge alors sur l'opportunité d'investir lourdement ou non sur les Mac-Intel et MacOS X. OK, pour les projets existants (je n'ai pas le choix), mais pour les autres le risque me semble élevé.
 
Bonjour,

Klimi a dit:
IL est certain que le G5 dans 1 portable, ce n'est pas pour demain. Mais je ne crois pas à cette raison officielle, le G4 est suffisant sur un portable (jai encore un PB 68040 pour la maison ;).

Le G4 vieillis serieusement, il faut être réaliste, il atteint peniblement 1.67GHz et le bus systeme avec les G4 est encore à 166MHz. Comparé aux PC portables Pentium-M, ca commence serieusement à faire limite dépassé. Il faut savoir reconnaitre les défauts des Macs quand il y en a, et les Mac portables au niveau du CPU et de la vitesse du bus systemes commence serieusement à vieillir.
Le nier est se voiler la face.

Je pensais qu'IBM avait jeté Apple, or je viens de lire qu'IBM continue de promouvoir le PowerPC pour micro-ordinateur sur un salon Linux (perdu l'URL).

A ce que j'ai lu sur le site d'IBM microelectronics, IBM veut développer l'architecture Power (qui ne se limite pas aux PowerPC), surtout pour l'embarqué, les consoles de jeux, et les serveurs mais pas pour les micro-ordinateurs (tous les PCs vendu sous la marque IBM reste et resteront jusqu'a nouvel ordre avec du x86 (Intel pour la plupart (la totalité?))). Linux a evidement sa place pour ces utilisation, puisqu'il a la capacité de s'adapter aussi bien dans de l'embarqué que dans un serveur (il est par contre moins adapté pour une utilisation Desktop grand public).

Mais quelle que soit la raison réelle, je constate un tollé général provoqué par cette décision.

Tu dois être sacrement selectif sur les articles que tu lis, car si on est objectif et qu'on regarde tout les articles sur cette decision, il y a au contraire beaucoup plus d'avis positifs que negatifs, notamment chez les developpeurs, j'ai vu très peu de reactions negatives.

En ce qui conerne les transitions précédentes, admettons que techniquement, le boulot soit moins dur aujourd'hui, mais il y a une grosse différence : mes commanditaires me demandaient les transitions précédentes, aujourd'hui, ils ne veulent pas de ce changement, dont ils ne comprennent pas le sens (et moi non plus).

Il faut dire que tu pars toi même d'un point de vue personnel pessimiste, ca n'aide pas. Car se changement s'explique tout à fait logiquement si on fait l'effort de mettre de coté son ressentiment personnel et qu'on reflechis au contexte dans lequel est Apple aujourd'hui, et à ce que apporter le passage sur Intel. Je l'ai déjà expliqué, donc je ne vais pas me repeter, désolé.

Il est logique que je m'interroge alors sur l'opportunité d'investir lourdement ou non sur les Mac-Intel et MacOS X.

Evidement, mais il faudrait que tu fasse l'effort de mettre tes pre-jugés de coté, ce que tu semble avoir du mal à faire...

OK, pour les projets existants (je n'ai pas le choix), mais pour les autres le risque me semble élevé.

Rien ne t'empêche de faire des logiciels en Universal Binary de sorte que tu supporte alors tous les parc installé, passé et futur. Et pour le futur je ne pense pas qu'il soit plus risqué avec cette transition qu'il l'aurait été s'il n'y avait pas eu cette décision, au contraire, je pense que ca aurait été plus risqué si Apple n'avait pas réagit et était resté avec le PowerPC (pour les raisons que j'ai déjà expliqués et donc que je ne repeterais pas).

A+
 
Non désolé Fordon tu ne me convainc toujours pas.
Les arguments des autres sont peut etre "idiots" mais même si le portage en Universal Binaries se fait facilement, il reste une version de plus à valider et rien que ca c'est du boulot. D'autant plus qu'il faut deux Macs.

Perso, je vais me retrouver a tester 4 versions : Mac OS 9, Mac OS X 10.4, 10.5 PPC, 10.5 Intel. Et une seule version sur Windows (tout mes softs sont multi plateformes)

La seule chance qu'aurait eut Apple de s'en sortir aurait été de dire OK, on vous force a adapter vos appli mais maintenant elles vont aussi marcher sous Windows car on fourni le kit Cocoa sous Windows. Meme pas ca.


Cordialement
 
Didier, c'est encore raide à dire, mais globalement on sait pourquoi Windows est une chambre à air qui prend l'eau à tous les étages, c'est parce que MS a souhaité une compatibilité ascendante depuis W95 (et encore).

On peut pas d'un côté vouloir un système moderne et qui avance (quitte effectivement à laisser le passé dans le bas côté) et de l'autre avoir un développement unqiue dans ses fondations.

Que tu choisisses de maintenir X versions de tes softs est tout à ton honneur, et par ailleurs j'imagine ton gagne-pain, mais bon faut voir que tu pourrais aussi te concentrer sur les deux ou trois dernières versions (disons les 3 dernières versions/système).
 
Bonjour,

Didier Guillion a dit:
Non désolé Fordon tu ne me convainc toujours pas.
Les arguments des autres sont peut etre "idiots" mais même si le portage en Universal Binaries se fait facilement, il reste une version de plus à valider et rien que ca c'est du boulot. D'autant plus qu'il faut deux Macs.

FAUX! Il faut juste un Mac Intel. En effet, pour tester la version PowerPC, il suffit de faire Pomme-I sur le .app et cocher la case "lancer avec Rosetta".

Je t'accorde qu'il aurait été sympa qu'Apple fournisse également Rosetta pour les machine PowerPC qui ferait alors la traduction Intel->PowerPC. Ca aurait permis à ceux qui peuvent pas se payer el Transition Kit de tester directement leur applis Intel sur leur Mac actuel.

Perso, je vais me retrouver a tester 4 versions : Mac OS 9, Mac OS X 10.4, 10.5 PPC, 10.5 Intel. Et une seule version sur Windows (tout mes softs sont multi plateformes)

Euh Windows bien qu'il y ai qu'une version à compiler, il faut tester sur Windows 9x et Windows NT/2k/XP, le fait qu'un soft Windows tourne sur XP ne garantie pas qu'il tourne sur 9x. A moins que tu ne supporte que WinNT... Et même si on poussait à faire comme tu fais avec le Mac, et donc que tu supporterais Win 3.x en plus, faudrait également faire une version speciale et aussi tester sur Win 3.x.

Pour le Mac, tu n'as besoin que de tester sur MacOS 9 (si y'en a vraiment besoin) et sur MacOS X 10.4 Intel + PPC (via Rosetta). Et bien sûr puisqu'on peut targetter les ancienne version de MacOS X même en faisant un Universal Binary (je vient de le verifier), tu n'as donc même pas besoin de t'amuser à faire une version différentes pour supporter les MacOS X antérieur à l'actuel, il te suffit de selectionner "MacOS X 10.1" (ou autre si tu ne supporte qu'a partir d'une certaine version) dans la propriété "MacOS X Deployment Target".
Le test de la version Intel et PPC se fera juste en desactivant ou activant la case "lancer avec Rosetta". Par contre il est vrai qu'a priori (à verifier) pour tester la version MacOS 9, il faut un vrai Mac PowerPC.

Conclusion:
- Sur Mac, 2 versions:
-> Une pour MacOS 9 à tester sur MacOS 9
-> Une pour MacOS X (Intel ET PPC (Universal Binary), que tu target pour la version minimale de MacOS X que tu veux supporter, et que tu teste sur MacOS X 10.4+ sur Mac Intel (en activant Rosetta pour tester la version PPC (ou direct sur ton Mac PPC si tu maintient la version MacOS 9 c'est qu'a priori tu aura toujours un Mac PPC)).
- Sur PC:
-> Une version à tester sur Win 9x et sur Win NT.
-> OU 2 version, la precedente + une version Win 3.x, si tu supporte Win 3.x, à tester sur Win 3.x

La seule chance qu'aurait eut Apple de s'en sortir aurait été de dire OK, on vous force a adapter vos appli mais maintenant elles vont aussi marcher sous Windows car on fourni le kit Cocoa sous Windows. Meme pas ca.

Mais si tu ne veux pas supporter l'Intel, rien ne te force à le faire (même si vu que c'est finalement pas si compliqué que ca, et qu'une fois le travail d'adaptation fait il n'est pas à refaire (enfin si on fait attention à rester portable), a priori maintenir une version Intel ne demandera pas plus que quelques minutes de plus (le temps de tester le binaire Intel) que de maintenir juste la version PowerPC).

Et pour le Cocoa sous Windows tu crois que ca aurait été possible facilement ca?? Je pense pas que ce genre de chose puisse exister (un jeu d'API système qui permette de compiler son applis ans presque rien changer sur 2 OS totalement différents, sans sacrifier ses fonctionnalité entre les 2 plateformes), ce genre d'API dépendent de trop d'élements du système.
D'ailleurs je pense que si ca avait été possible, ca aurait déjà été fait par la communauté Open Source. Actuellement le mieux que tu peux trouver c'est eventuellement quelques toolkit de GUI tel que GTK+ ou QT en multi-plateforme, mais rien de similaire à des APIs systèmes tel que Cocoa.
En plus t'aurait de toute façon à tester ton applis en lançant Windows.

A+
 
Frodon a dit:
FAUX! Il faut juste un Mac Intel. En effet, pour tester la version PowerPC, il suffit de faire Pomme-I sur le .app et cocher la case "lancer avec Rosetta".
Mouais, est-on sur que Rosetta sur Mas/x86 fonctionne exactement octets par octet comme Mac OSX sur Mac/PPC ? Parce que si on prend l'exemple de Classic, il y a quand même beaucoup d'"incompatibilités" !
Donc je pense que si tu veux faire des tests sérieux il faut : un Mac/PPC sous Mac OSX, un Mac/x86 sous Mac OSX avec Rosetta.
 
ntx a dit:
Mouais, est-on sur que Rosetta sur Mas/x86 fonctionne exactement octets par octet comme Mac OSX sur Mac/PPC ? Parce que si on prend l'exemple de Classic, il y a quand même beaucoup d'"incompatibilités" !
Donc je pense que si tu veux faire des tests sérieux il faut : un Mac/PPC sous Mac OSX, un Mac/x86 sous Mac OSX avec Rosetta.


J'allait répondre la même chose. Faire confiance à un émulateur est plus que risqué...

"It compile, shipt it" n'est pas ma tasse de thé.

Cordialement
 
ntx a dit:
Mouais, est-on sur que Rosetta sur Mas/x86 fonctionne exactement octets par octet comme Mac OSX sur Mac/PPC ?

C'est un emulateur de CPU, au pire c'est moins compatible. Donc si ca marche sur Rosetta, ca marche sur un vrai PPC. Par contre l'inverse n'est pas forcement vrai (si ca marche sur un vrai PPC, ca marche pas forcement sur Rosetta, notamment si y'a du code G4/G5 sans alternative (i.e: sans code générique pour les G3), ca marchera pas puisque Rosetta emule un G3).
Donc si ca marche sous Rosetta, je ne vois aucune raison pour que cela ne marche pas sur un vrai PPC.

Parce que si on prend l'exemple de Classic, il y a quand même beaucoup d'"incompatibilités" !

Si je ne m'abuse, une application qui tourne sous Classic tourne sans soucis sous le vrai MacOS 9. L'incompatibilité est dans l'autre sens (une appli qui tourne sur le vrai MacOS 9 ne tourne pas forcement sous Classic).

Donc je pense que si tu veux faire des tests sérieux il faut : un Mac/PPC sous Mac OSX, un Mac/x86 sous Mac OSX avec Rosetta.

Certe, rien ne t'en empeche de toute je pense que tous le monde aura encore un Mac PPC sous la main pendant encore quelques années. Mais normalement tester sur Mac/x86 et MacOS X avec Rosetta suffit à s'assurer que ca marchera sur tous les Mac G3+ et Intel.

A+
 
Frodon a dit:
:D

Tant d'énergie me fait penser aux threads politiques ;)


Frodon a dit:
Il faut juste un Mac Intel. En effet, pour tester la version PowerPC, il suffit de faire Pomme-I sur le .app et cocher la case "lancer avec Rosetta".

Je t'accorde qu'il aurait été sympa qu'Apple fournisse également Rosetta pour les machine PowerPC qui ferait alors la traduction Intel->PowerPC. Ca aurait permis à ceux qui peuvent pas se payer el Transition Kit de tester directement leur applis Intel sur leur Mac actuel.
Donc en gros il faudra deux machines. Rosetta a beau être la pierre miraculeuse, ça reste un émulateur qui ne fonctionnera pas parfaitement. Le comportement émulé ne sera en rien représentatif d'un comportement natif G4-G5. Bosser sur deux machines restera nécessaire. D'autant plus que le dev KIT n'est pas finalisé (ce qui est normal) : Il manque la gestion de l'audio si je me trompe pas... Alors je vois mal des devs en faire leur machine principal.

En tout cas, je tiens à envoyer tous mes encouragements au développeurs, qui en plus d'ajouter de nouvelles fonctionalités à leur soft (ce qui prend en soi pas mal de temps) devront assurer la compatibilité Intel.
 
Frodon a dit:
Donc si ca marche sous Rosetta, je ne vois aucune raison pour que cela ne marche pas sur un vrai PPC.

Si tu développes une version pour MacPPC et une pour MacIntel, le fait que ça marche sous rosetta, à la limite, tu t'en fous.

Lors du passage de 9->X, Toast ne pouvait pas graver sous Classic. Et pourtant, deux màj de Toast OS 9 sont sorties. Et une version 0S X. Avec ton raisonnement, les dev auraient du se casser la tête à rendre leur appli compatible classic -ce qui n'est pas possible dans tous les cas-. Ca fait un peu perte de temps quand même...
 
KaptainKavern a dit:
Didier, c'est encore raide à dire, mais globalement on sait pourquoi Windows est une chambre à air qui prend l'eau à tous les étages, c'est parce que MS a souhaité une compatibilité ascendante depuis W95 (et encore).

Je suis assez surpris de lire ça, car on peut toujours chercher un logiciel PC de la fin de 88 qui marche sur une machine récente, je pense pas qu'on puisse trouver. Alors que Ragtime 3 tourne toujours sur mon iBook...
 
Excuse moi Frodon, mais je pense que tu n'as pas franchement tord mais simplement une vision un peu théorique du probleme.

Prenons un exemple et dis moi si je me trompe.

Pour générer un Universal Binaries il te faut compiler avec GCC 4.

Or une application compilé avec GCC 4 ne se lance meme plus sur 10.2, il te faut utiliser GCC 3.

Ce qui reviendra en 2006-2007 a poser le choix : perdre les 15% d'utilisateurs Mac encore en 10.2 pour gagner les 1% d'utilisateurs Mac sur MacIntel... pas glop !

Cordialement
 
deadlocker a dit:
Je suis assez surpris de lire ça, car on peut toujours chercher un logiciel PC de la fin de 88 qui marche sur une machine récente, je pense pas qu'on puisse trouver. Alors que Ragtime 3 tourne toujours sur mon iBook...

Window 95, comme son nom l'indique date de 1995 pas de 1988...

Cordialement
 
Bonjour,

deadlocker a dit:
Si tu développes une version pour MacPPC et une pour MacIntel, le fait que ça marche sous rosetta, à la limite, tu t'en fous.

Lors du passage de 9->X, Toast ne pouvait pas graver sous Classic. Et pourtant, deux màj de Toast OS 9 sont sorties. Et une version 0S X. Avec ton raisonnement, les dev auraient du se casser la tête à rendre leur appli compatible classic -ce qui n'est pas possible dans tous les cas-. Ca fait un peu perte de temps quand même...

Non, ce n'est pas ce que j'ai dit. Cela dit puisque juste le CPU change et pas le système, y'a qd même peu de chance d'avoir des prob comme avec Toast sous Classic, prob qui était innerant au fait que Classic n'avait pas acces directement au materiel car tournant dans un environnement separé, ce qui ne sera pas le cas d'une appli tournant sous Rosetta qui dialoguera directement avec OS X, Rosetta ne faisant juste que l'interprete pour que le CPU comprenne.

Cela dit, je parlais de Rosetta comme outil pour tester l'appli PPC. Certe au début on aura tous encore des Mac PPC, donc pour tester nos applis PPC, on utilisera certainement le Mac PPC. Mais il arrivera un jour où on n'aura plus que de l'Intel (plus ou moins proche suivant les capacité financiere du developpeur, certains d'ailleurs sauteront directement le pas car auront besoin de revendre leur ancien Mac pour acheter un nouveau), mais on souhaitera qd même maintenir la version PPC pour les utilsiateurs qui n'ont pas encore de Mac Intel. Et dans ce cas là Rosetta servira à tester les versions PPC de nos applications.

A+
 
  • J’aime
Réactions: meldon
Didier Guillion a dit:
Window 95, comme son nom l'indique date de 1995 pas de 1988...

Cordialement
:D :D

Ce que je voulais dire, c'est que l'argument de la rétro-compatibilité sur Windows m'étonne vraiment. C'est qu'un avis purement subjectif de néophite (autrement dit : une phrase lancée en l'air ;) ), mais des softs sorti en 95 (il est pas sorti en 96? Ou c'est 98 qui est sorti en 99, je sais plus...) qui tournent encore sur les PC d'ajd, ça doit pas courir les rues...
 
deadlocker a dit:
:D :D

Ce que je voulais dire, c'est que l'argument de la rétro-compatibilité sur Windows m'étonne vraiment. C'est qu'un avis purement subjectif de néophite (autrement dit : une phrase lancée en l'air ;) ), mais des softs sorti en 95 (il est pas sorti en 96? Ou c'est 98 qui est sorti en 99, je sais plus...) qui tournent encore sur les PC d'ajd, ça doit pas courir les rues...

Avec le passage du DOS à 95, beaucoup de softs n'ont plus fonctionnés. Le passage de 95 à XP a de même remisé un paquet de logiciels au placard et a nécessité de nouvelles versions.
 
Bonjour,

Didier Guillion a dit:
Excuse moi Frodon, mais je pense que tu n'as pas franchement tord mais simplement une vision un peu théorique du probleme.

Prenons un exemple et dis moi si je me trompe.

Pour générer un Universal Binaries il te faut compiler avec GCC 4.

Hmm surement, cela dit il doit être possible de faire un Universal Binary à la main avec un binaire PPC compilé avec GCC3 (indépendament du binaire i386), et un binair i386 compilé avec GCC 4, avec la commande "lipo" (lipo -create <binaire_ppc> <binaire_i386> -output <universal_binary>.

Or une application compilé avec GCC 4 ne se lance meme plus sur 10.2, il te faut utiliser GCC 3.

Donc cela signifie qu'ils ont changé le format des binaires? Parce que sinon je vois pas pourquoi d'un coup un exe compilé avec GCC3 ne pourrait pas marcher sous les premiers MacOS X (à partir du moment où il est bien specifié que le target minimal est inférieur ou egale à la version en question et qu'aucune API specifiques aux versions supérieur n'est utilisé dans le programme).

Par exemple sur un autre OS (MorphOS pour pas le nommer), j'ai déjà vu des exe compilé avec GCC3 (en cross-compiling sous Linux) qui marchent très bien sur l'OS alors même que le kit officiel de developpement ne support que GCC 2.9x...

Si tu as un MacOS X 10.2 ou 10.1 sous la main, essais voir ce binaire (un projet cocoa vierge compilé avec GCC4 avec comme target MacOS X 10.1 et en Universal Binary): http://ifrodo.free.fr/TestUniversal10.1+.tar.gz
Et aussi une appli avec Universal Binary composé d'un binaire compilé avec GCC 3.1 pour PPC et un binaire compilé avec GCC 4 pour i386 (crée avec /usr/bin/lipo à partir de binaires issues de deux compilation séparés. Ce qui est surement automatisable avec des petits scripts): http://ifrodo.free.fr/TestUniversalGCC3-PPC+GCC4-i386-10.1+.tar.gz
Et encore plus poussé, la même appli compilé en Universal Binary composé d'un binaire PPC compilé avec GCC 3.1 en utilisant le SDK 10.2.8 et un binaire i386 compilé toujours avec GCC 4 et le SDK 10.4 Universal: http://ifrodo.free.fr/TestUniversalGCC3-PPC-SDK10.2+GCC4-i386-10.1+.tar.gz

A+
 
Bonjour,

Je viens de prendre la discussion en cours avec un peu de retard, mais je ne peux pas m'empêcher de rajouter mon grain de sel ;)

En tant que "petit" développeur indépendant, mais vivant de ses productions, je rejoins Didier, au moins partiellement, concernant ses inquiétudes. Depuis 2 ans sur Mac, l'essentiel de mon boulot consistait jusqu'à aujourd'hui à convertir mon code PC pour Mac. Comme il s'agit de moteur 3D temps réel, le framework joue, par chance, un rôle mineur, OpenGL étant heureusement cross-platform.

Je suis en train de développer un nouveau soft stand alone. Partant de mon travail de portage précédent, et du fait que ma connaissance des spécificités de programmation du Mac est plutôt limitée (je pense à Cocoa et Objective-C) , j'ai naturellement adopté Carbon, dont le modèle de gestion événementiel est suffisamment proche de Win32 pour envisager un portage PC de mon appli à long terme si la version Mac ne me permet pas de subsister :)

L'annonce de la WWDC a-t-elle modifié ma feuille de route ?

OUI, pleinement. Ayant vécu de très nombreuses transitions technologiques, j'ai pour habitude de ne pas les prendre à la légère. Mon soft étant en début de conception, j'ai la "chance" de pouvoir infléchir mes choix de dev, aujourd'hui.

Mon avis (il vaut ce qu'il vaut :siffle:), c'est que face à l'afflux attendu de la concurrence Windows (parce que bootable sur MacTel, parce que les émulateurs feront sans doute beaucoup mieux demain, et parce que le portage Mac d'applis PC sera grandement simplifié), la survie sur Mac des petits développeurs tel que moi, dépendra grandement de leurs possibilités de suivre parfaitement les évolutions technologiques de Mac OS : CoreImage, CodeData, SpotLight, le look and feel du Mac en somme. Ce sera la plue-value de nos softs face à des softs Windows ou des portages de Windows. De l'esprit Mac, la préservation, garant nous serons :))))

La conséquence ? En dehors de Cocoa point de salut !

Les équipes de dev de Carbon se sont considérablement réduites (plus que 5 ingénieurs chez Apple). Les fonctions GUI de Cocoa ne sont pas ou sont mal intégrées à Carbon (il n'y a qu'à jeter une oeil au sélecteur de couleur). CoreData par exemple est clairement fait pour Cocoa. Les exemples du désintérêt croissant d'Apple pour Carbon pullules. Malgré le fait qu'il soit tenu de le maintenir (Office et Photoshop obligent), Carbon est clairement perçu par Apple comme une épine dans le pied. Ce que je peux comprendre parfaitement.

Cependant, embrasser Cocoa pour un soft qui doit être portable demande un effort de conception CONSIDERABLE ! Je ne parle même pas de ceux qui ont des applis Carbon et qui voudrait passer à Cocoa.

J'ai donc du repenser complètement mon applis.... En pratique : 2 applis indépendantes. L'une en C/C++ qui est totalement portable (MAC, PC, LINUX, ...) et qui comprend toute mes libs et toute la R&D de mes applis, que je ne peux me permettre et ne veux réécrire. L'autre en Objective-C++, en charge de toute la partie interface, et de la conception objet.

Que je me fasse bien comprendre : Cocoa et Objective-C sont des technologie extraordinaire et enthousiasmante pour un developpeur qui aime l'élégance. Et je ne juge nullement leurs qualités intrinsèque, ni ne rechigne à switcher parce que je suis un vieux con :). Ce que je veux vous montrer, c'est que la décision de passer à Intel n'est pas simplement dépendante de la vitesse ou la facilité de recompilation comme voudrait nous le faire croire SJ, loin de là !!!

Et si Steve Rate son coup, mon appli devenant beaucoup plus dépendante des particularités de programmation de Mac OS, il y a des chances que je sombre avec lui :)) Encore une fois le gars compte sur nous pour assurer la transition... En retour je compte sur lui pour assurer notre survie...