# CarbonLib ou émulation pour Windows ?



## Hibou57 (11 Août 2009)

Bonjour,

Je suis à la recherche d'un moyen de concevoir une application basée sur CarbonLib, mais sans Mac _(simplement parce que je n'ai en pas et pas les moyens de m'en acheter un)_.

J'ai tout d'abord appris que certaines versions basiques de CarbonLib fonctionnent sous Mac OS 8.1. J'ai donc tenté un émulateur Mac, mais malheureusement, les émulateurs ne proposent que System 7.5, pour lequel CarbonLib n'existe pas.

J'ai donc ensuite tenté de trouver une émulation de CarbonLib pour Windows XP, mais sans succès.

Quelles sont les possibilités de concevoir _(plus précisement tester)_ une application basée sur CarbonLib en étant sous Windows XP ?

Alternativement, quelqu'un pourrait-il me revendre une licence Mac OS 8.1 pour 10 ou 15&#8364;, que je pourrais faire tourner sous l'émulateur ? _(c'est une des possibilités que j'envisage, mais sans trop savoir si elle est valide)_. Remarque : l'émulateur que j'ai essayé est Basilisk II, qui permet d'émuler un 68K.

Merci


P.S. Je ne souhaite pas passer par la solution Qt ni GTK, car je souhaite utiliser une API native de Mac.


----------



## Céroce (11 Août 2009)

Le plus simple, ce serait de trouver un ancien Mac.
J'ai vu des iMac G3 à 70  dans un dépôt vente, tu dois pouvoir en trouver des moins chers. L'autre défi, ce sera de trouver une version de CodeWarrior, et toute la doc sur la Toolbox d'Apple.

Je trouve l'idée de vouloir développer sous Carbon farfelue, alors que Mac OS X existe depuis 2001. Huit ans, c'est une éternité en informatique.


----------



## Hibou57 (11 Août 2009)

Bonsoir et merci pour ta réponse,



Céroce a dit:


> Le plus simple, ce serait de trouver un ancien Mac.
> J'ai vu des iMac G3 à 70 &#8364;


Je vais peut-être avoir l'air compliqué, mais 70&#8364;, c'est encore trop chèr pour moi _(c'est pour cette raison que je pensais à une licence OS 8.1 d'occasion...)_



Céroce a dit:


> L'autre défi, ce sera de trouver une version de CodeWarrior, et toute la doc sur la Toolbox d'Apple.


Je ne connais pas CodeWarrior, mais merci d'en avoir fait mention, je vais me renseigner à ce sujet.

Pour la documentation des APIs, elle est accessible sur le site Apple.



Céroce a dit:


> Je trouve l'idée de vouloir développer sous Carbon farfelue, alors que Mac OS X existe depuis 2001. Huit ans, c'est une éternité en informatique.


Voyant ta signature, je n'en attendais pas moins d'une personne apparement trés investie dans Cocoa. 

Je vais seulement exposer mon impression, et corrige moi si je me trompe...

J'ai lu ça et là, qu'il serait semble t-il une erreur de considérer que Carbon est « moins bien que Cocoa ». Je ne suis pas utilisateur de Mac, mais les arguments donnés me semblaient crédibles, comme le fait que Explorer pour Mac est basé sur Carbon, et que de nombreuses application célèbre dans le monde Mac, comme PhotoShop, sont basées sur Carbon.

J'ai lu également que lorsque Appel a introduit Carbon, cette introduction n'a pas été prise à la légère que Carbon a été longuement et murement développé, et que Apple assume pleinement cette API qui n'est pas destinées à disparaitre.

Concernant les 8 ans, si je me permet une comparaison avec le monde PC, la plupart des applications Windows XP utilisent un sous ensemble de l'API de Windows XP, qui est assez comparable ce qu'était l'API Windows 98. J'imagine qu'il en va peut-être de même avec Mac, et que le principale était déjà présent il y a 8 ou 10 ans.

Par contre, je suis bien conscient que Carbon n'a pas de connexion avec certains services, comme l'execution de Java par exemple, comme j'ai put le lire, mais ça ne me sera pas nécessaire.

Je recherche également les librairies de bases, comme la librairie C de Mac, pour une environnement de compilation croisée sous Windows. Il est fonctionel pour Linux, mais je cible en fait Mac, et je vais essayer de le faire comme je l'ai fait pour Linux en appliquant le même principe _(Linux ne m'interesse pas en fait, seulement Mac)_.

J'ai rassemblé pas mal de documentations, notament sur les détails importants à prendre en compte pour respecter les notions d'ergonomie de Mac OS _(assez différent des recommandations de MS pour Windows)_, mais je calle toujours sur ces problèmes de librairies &#8212; quoi que j'ai put obtenir la librairie CarbonLib sans problème &#8212; et également sur les moyens de tester.



Petite parenthèse : j'aime bien le concept de ton site Ceroce.com pour le vente de logiciel à prix modéré. C'est exactement ce que je vise _(le prix modéré, mais pas le type d'application)_. Ton idée me plait tellement que je crois je m'en vais de ce pas faire ta publicité sur un forum où je vais fréquement  Avec mes voeux de succès pour ton projet.


----------



## tatouille (11 Août 2009)

http://mac-on-linux.sourceforge.net/


----------



## ntx (11 Août 2009)

Hibou57 a dit:


> J'ai lu ça et là, qu'il serait semble t-il une erreur de considérer que Carbon est « moins bien que Cocoa ». Je ne suis pas utilisateur de Mac, mais les arguments donnés me semblaient crédibles, comme le fait que Explorer pour Mac est basé sur Carbon, et que de nombreuses application célèbre dans le monde Mac, comme PhotoShop, sont basées sur Carbon.


Sont encore en Carbon les applications qui n'ont pas été portées en Cocoa. Si par Explorer tu entends "Finder", avec SnowLeopard c'en est fini de Carbon pour cette application.
Franchement à part la beauté du geste, il n'y a plus aucun intérêt à apprendre cette technologie.


> Concernant les 8 ans, si je me permet une comparaison avec le monde PC, la plupart des applications Windows XP utilisent un sous ensemble de l'API de Windows XP, qui est assez comparable ce qu'était l'API Windows 98. J'imagine qu'il en va peut-être de même avec Mac, et que le principale était déjà présent il y a 8 ou 10 ans.


Et M$ n'est pas une référence, ils maintiennent la compatibilité de leur API pour que les gens ne soient pas tentés d'aller voir autre part 
En passant à Mac OSX et Cocoa, Apple est fait une croix sur la plupart des technologies de Mac OS Classic : le noyau n'est plus le même, les API sont entièrement en POO et Obj-C. Ne reste que quelques couches basses en C, mais pour l'interface graphique tout est passé à la poubelle ou  presque.


----------



## Hibou57 (11 Août 2009)

Re-Hello,



tatouille a dit:


> http://mac-on-linux.sourceforge.net/


C'est un émulateur _(enfin, une machine virtuelle, commes ils le soulignent eux-même)_. Ce n'est pas exactement ce que je recherche. Merci quand-même pour le geste.

Sinon, j'avais déjà eu connaissance de ce projet, mais comme je suis sous Windows _(même si j'ai un Linux sur une clé USB)_, j'ai préféré m'arrêter sur Basilisk II.



ntx a dit:


> Sont encore en Carbon les applications qui n'ont pas été portées en Cocoa. Si par Explorer tu entends "Finder", avec SnowLeopard c'en est fini de Carbon pour cette application.
> Franchement à part la beauté du geste, il n'y a plus aucun intérêt à apprendre cette technologie.


En fait je parlais de Internet Explorer pour Mac _(même s'il n'est plus mis à jour)_.

Précisement, est-ce que les applications Carbon posent des problèmes ? Quand tu lance une application Carbon, est-ce qu'il y a des différences avec une applicatio, Cocoa ou est-ce que tu vois la même chose ? _(autant en terme de style graphique que d'ergonomie)_



ntx a dit:


> Et M$ n'est pas une référence,


On dit « MS ». Est-ce que j'écrit Mac O$ ? _(désolé pour le commentaire, mais c'est mieux de respecter les noms propres, d'autant que Apple aussi fait des $ avec ses ventes)_.



ntx a dit:


> ils maintiennent la compatibilité de leur API pour que les gens ne soient pas tentés d'aller voir autre part
> En passant à Mac OSX et Cocoa, Apple est fait une croix sur la plupart des technologies de Mac OS Classic : le noyau n'est plus le même, les API sont entièrement en POO et Obj-C. Ne reste que quelques couches basses en C, mais pour l'interface graphique tout est passé à la poubelle ou  presque.


Zut... moi qui croyais y voir clair, je commence à avoir l'impression de nager dans le brouillard. J'avais cru comprendre que Apple donnait le même soin au support de Carbon que de Cocoa.

Est-ce que tu as connaissance d'un communiqué d'Apple qui tranche entre les deux ?

Je vais voir l'historique des mises à jour de Carbon, ça me donnera certainement un élément d'idée _(pas facile de se faire une idée quand on est soi-même pas sous Mac)_.

-- EDIT --

Voilà un des documents que j'avais lu il y a quelques jours à ce sujet :
Carbon - Cocoa : le Match !

Je m'étais à peut prêt arrêté à ce document, parce qu'il m'avais semblé suffisant.... je me suis peut-être trompé

---------- Nouveau message ajouté à 19h40 ---------- Le message précédent a été envoyé à 19h15 ----------

Update : comme vous m'avez collé un doute, je me suis mis à chercher s'il existe une émulation de Cocoa pour Windows _(ce qui me permettrait de faire les testes sous Windows, ce qui était mon problème au départ)_. Et apparement il semble que oui et que ça s'appel Cocotron.

Je vais me pencher sur cette solution, mais si d'autres personnes sont inspirées pour participer à ce topic, la discussion reste ouverte


----------



## tatouille (11 Août 2009)

tourne un Woodoo kernel sur un PC clone 800 Euros: quad core, carte-intel ou amd, Carbon c'est presque fini et il n'y aura pas de support public 64-bit

Cocotron n'est qu'une implementation tres incomplete du runtime Foundation donc en aucun cas de Cocoa qui rassemble un couple de frameworks, CoreServices, CoreGraphics (& OpenGl), CoreAnimation, Quartz, AppKit ... et j'en passe et des meilleurs, comment veux tu serieusement qu il existe un Cocoa Windows qui ne serait pas le fruit d'Apple "Cocoa" represente le travaille de centaines de personnes sur 15 ans...

Abandonne Windows -> format C: et commence a travailler sur Unix-Like de vrai operating system qui sont somme toute l'avenir.

M$ ou enfin le declin de la merde qui nous bouchait les chiottes


----------



## ntx (11 Août 2009)

Hibou57 a dit:


> En fait je parlais de Internet Explorer pour Mac _(même s'il n'est plus mis à jour)_.


IE sur Mac n'est plus seulement mise à jour, mais il est totalement "has been", il a disparu corps et bien pour de bon.


> Précisement, est-ce que les applications Carbon posent des problèmes ? Quand tu lance une application Carbon, est-ce qu'il y a des différences avec une applicatio, Cocoa ou est-ce que tu vois la même chose ? _(autant en terme de style graphique que d'ergonomie)_


Non, mais quand tu commences à développer une applications il vaut mieux te contenter des technologies actuelles de façon à supporter l'OS en cours, sa version précédente et être sûr de supporter la suivante. Ce n'est pas le cas avec Carbon et SL.


> On dit « MS ». Est-ce que j'écrit Mac O$ ? _(désolé pour le commentaire, mais c'est mieux de respecter les noms propres, d'autant que Apple aussi fait des $ avec ses ventes)_.


Faut il encore avoir envi d'un prêter un minimum de respect à M$. 


> -- EDIT --
> Voilà un des documents que j'avais lu il y a quelques jours à ce sujet :
> Carbon - Cocoa : le Match !
> 
> Je m'étais à peut prêt arrêté à ce document, parce qu'il m'avais semblé suffisant.... je me suis peut-être trompé


Ton doc date de 2003, on est en 2009, 6 ans c'est un gouffre en informatique.


> Update : comme vous m'avez collé un doute, je me suis mis à chercher s'il existe une émulation de Cocoa pour Windows _(ce qui me permettrait de faire les testes sous Windows, ce qui était mon problème au départ)_. Et apparement il semble que oui et que ça s'appel Cocotron.
> 
> Je vais me pencher sur cette solution, mais si d'autres personnes sont inspirées pour participer à ce topic, la discussion reste ouverte


Je te déconseille ce genre de solution. Celle-ci tout comme GNUStep ou Mono pour le C# sur Mac ou Linux ne peuvent jamais suivre les mises à jour répétés des éditeurs de l'API d'origine. Et l'écart entre les versions ne fait que se creuser aux détriments de leurs utilisateurs qui ont toujours 3 versions de retard. Apple ou M$ n'ont pas les mêmes moyens qu'un bande d'amateurs même avec la meilleure volonté du monde. :rateau:
Si tu veux développer pour Mac et Windows, oublie Cocoa, pense plutôt à QT ou WxWidget.


----------



## Hibou57 (11 Août 2009)

tatouille a dit:


> [...] Abandonne Windows -> format C: et commence a travailler sur Unix-Like de vrai operating system qui sont somme toute l'avenir.


Linux .... n'en veux pas
UNIX-original .... peux pas (pour diverses raisons)
Mais merci pour le conseil, ça fait toujours plaisir des bonnes intentions sincères comme ça



tatouille a dit:


> M$ ou enfin le declin de la merde qui nous bouchait les chiottes


Mon dieu, mais surveillez votre langage 



Bon, je reviens aux jardin ....

Donc Cocotron n'est pas crédible _(ni alors GNUStep je suppose, vu qu'il est réputé encore plus éloigné de Cocoa que ne l'est Cocotron)_, ....

De toute manière, aprés avoir obtenu les sources depuis Google Code, j'ai vite compris qu'il n'est pas fait pour être compilé ailleurs que sous Mac : il n'y a ni &#8220; config.sh &#8221; ni &#8220; Makefile &#8221;.



ntx a dit:


> [...] pense plutôt à QT ou WxWidget.


Qt sous Windows, ce n'est pas Windows, donc j'ai peur que Qt sous Mac, ce ne soit pas Mac _(plus autre raison plus loin)_. Je crois que WxWidget respecte mieux le système sous jacent, mais une question : une appliation WxWidget sous Mac, se comporte t-elle entièrement comme une appliation native ? Utilise t-elle les mêmes contrôles que ceux introduits avec Mac OS X ? Ex. Respecte t-elle l'utilisation d'une barre de menu globale comme toute bonne application Mac ? Necessite t-elle ou pas une librarie particulière ? _(si Oui est la réponse à cette dernière question, alors c'est mauvais signe)_. Par exemple GTK sous Winows, necessite une bonne dizaine de DLLs non-standards, et je souhaiterai éviter ce genre de phénomène.

Mais il reste un hic, avec WxWidget, je ne peux pas utiliser CoreSound par exemple... ou si ?

Remarque : Qt est exclus pour des raisons de licence, je ne peux pas me permettre de payer les 1500$ de la licence Qt qui autorise les applications commerciales.... sachant que je n'ai aucune certitude de vendre un seul exemplaire de mon application _(bonjour le déficite sinon, et je n'ai pas besoin de ça)_ et qu'elle serait à bas prix de toute manière. Donc entre Qt et WxWidget, encore plutôt WxWidget _(WxWidget est sous LGPL, et la page qui décrit sa licence, autorise même explicitement les applications commerciales)_.



P.S. Oui, je sais que Windows n'est pas le top, je suis bien conscient qu'il a manqué le coche il y a 8 ou 9 ans, mais il y a plusieurs raisons qui ont fait qu'il s'est imposé malgré tout, mais ce n'est pas le lieu pour en parler. De toute façon, que Windows soit ce qu'il est, n'empêche pas les bien-heureux possesseurs de Mac à en profiter pleinement.


Allez, un tit dernier pour la route : OS X vaincra :love: ... _(mais non j'fais pas d'la lèche, je fais juste coupinou)_

-- EDIT --

Oui, WxWidget utilise exclusivement la plateforme sous jacente, sans émulation, donc c'est Ok sur ce point. Perfect.



> [...] Unlike other cross-platform toolkits, wxWidgets applications look and feel native. This is because wxWidgets uses the platform's own native controls rather than emulating them. [...]


----------



## Céroce (12 Août 2009)

Hibou57 a dit:


> Je ne connais pas CodeWarrior, mais merci d'en avoir fait mention, je vais me renseigner à ce sujet.



C'était l'IDE de référence sous Mac OS Classic.



Hibou57 a dit:


> Voyant ta signature, je n'en attendais pas moins d'une personne apparement trés investie dans Cocoa.


Non, vraiment, il ne s'agit pas d'une réponse partisane. J'ai développé plusieurs années pour les vieux systèmes 7.5. Carbon, n'en est qu'une légère amélioration. Puisque tu as la doc, regarde comment on fait pour répondre à un clic sur un article de menu:
- obtenir les coordonnées du clic
- déterminer dans quelle fenêtre s'est produit le clic
- si c'est dans la barre de menu (qui est une fenêtre), transformer les coordonnées globales en coordonnées locales
- déterminer quel est l'article de menu à cet endroit.

En Cocoa:
- un message associé à l'article de menu est envoyé.

Développer sous Carbon est long, fastidieux et difficile. Il s'agit d'une solution qui a permis de faire évoluer les logiciels existants pour qu'ils profitent des avantages de Mac OS X (notamment, le multi-processus, la gestion de la mémoire, et l'intégration). Il n'est pas étonnant que Photoshop, Word ou Graphic Converter l'utilisent: ils n'allaient pas tout reprogrammer du jour au lendemain.




Hibou57 a dit:


> J'ai lu ça et là, qu'il serait semble t-il une erreur de considérer que Carbon est « moins bien que Cocoa ».


Tout dépend de ce que tu appelles moins bien. On développe 20 fois plus vite avec Cocoa qu'avec Carbon. Les applis Cocoa adoptent automatiquement un comportement conforme aux recommandations d'Apple.
Certaines applications ne peuvent pas être développées avec Carbon. Par exemple, le système 8.5 utilise le SoundManager, et Mac OS X, CoreAudio. Il est impossible de faire une application audio qui marche sur les deux systèmes. Je crois que c'est pareil pour la vidéo.
Après, effectivement, il est rare de ne pas pouvoir faire avec Carbon ce qu'on peut avec Cocoa.



Hibou57 a dit:


> Apple assume pleinement cette API qui n'est pas destinées à disparaitre.


Carrément si. Déjà, on ne peut pas faire d'appli 64 bits avec Carbon.




Hibou57 a dit:


> J'ai rassemblé pas mal de documentations, notament sur les détails importants à prendre en compte pour respecter les notions d'ergonomie de Mac OS (assez différent des recommandations de MS pour Windows)


J'aurais tendance à dire que la "culture" se fait à l'utilisation.




Hibou57 a dit:


> Avec mes voeux de succès pour ton projet.


Je te remercie, j'en aurai bien besoin !



			
				Hibou57 a dit:
			
		

> Je crois que WxWidget respecte mieux le système sous jacent, mais une question : une appliation WxWidget sous Mac, se comporte t-elle entièrement comme une appliation native ?


Pas tout à fait, mais ils ont fait du très beau travail. On retrouve ses repères (barre de menus, raccourcis clavier), et c'est très réactif. C'est bien mieux qu'une appli Java, par exemple. Si je devais écrire une appli multi-plateforme, ce serait sans doute avec le couple WxWidget + Python.



			
				Hibou57 a dit:
			
		

> Necessite t-elle ou pas une librarie particulière ?


Oui, mais tu dois pouvoir la placer facilement à l'intérieur de l'appli. 



			
				Hibou57 a dit:
			
		

> Mais il reste un hic, avec WxWidget, je ne peux pas utiliser CoreSound par exemple... ou si ?


Si, tu peux utiliser CoreAudio, mais forcément, il faudra reprogrammer pour l'équivalent pour la version PC. Ou alors utiliser une bibliothèque multi-plateforme comme OpenAL.


Je vais finir par une question: tu n'as pas de Mac, pourquoi veux-tu absolument développer sur Mac ?
Cela va te demander deux fois plus de travail. Je serais toi, je ne développerais que sous Windows.


----------



## Didier Guillion (12 Août 2009)

A Céroce :

Carbon propose un accès au Sound Manager, donc une appli audio fonctionnera sans problème sous Mac OS 9 et sous Mac OS X.
Pour la vidéo, on peut "attaquer" QuickTime avec Carbon également, donc même réponse.

Mais un point essentiel à mon avis, c'est que pour vraiment utiliser Cocoa il faut écrire en Objective-C et non en C.
Quand on écrit en Objective-C, le code devient difficilement portable. Ça existe Obj-C ailleurs que sur Mac ?

Tu dit que c'est plus rapide de développer sous Cocoa que sur Carbon, je suis d'accord avec toi. 

Par contre, pour avoir un peu pratiqué les deux, dès que l'application Cocoa devient un peu conséquente, je m'y perds rapidement. Certes en Carbon, on doit faire beaucoup de chose à la main, mais au moins quand on a un problème, on trouve rapidement ce qui se passe.

Par exemple, je ne comprends pas pourquoi on est obligé d'associer une ressource Nib à un source Objective-C, en basculant sans arrêt entre Interface Builder et XCode. Je m'attendait vraiment à ce que le source soit directement dans l'objet. 

Bref, je pratique Cocoa+Obj-C, mais je ne suis pas à l'aise.

Bon, il est vraisemblable que j'ai travaillé trop longtemps en C+Carbon pour me faire à autre chose...
J'ai vu passer tellement de solutions de programmation différentes que cela ne me concerne plus, si j'ai un outil qui me permet de transcrire mes idées de manière correcte, je le garde.

Cordialement


----------



## Céroce (12 Août 2009)

Didier Guillion a dit:


> Carbon propose un accès au Sound Manager, donc une appli audio fonctionnera sans problème sous Mac OS 9 et sous Mac OS X.


Pas pour l'acquisition, qui d'ailleurs, j'en suis quasiment sûr, ne marchait pas du tout dans les premières versions de Mac OS X.



Didier Guillion a dit:


> Mais un point essentiel à mon avis, c'est que pour vraiment utiliser Cocoa il faut écrire en Objective-C et non en C.
> Quand on écrit en Objective-C, le code devient difficilement portable. Ça existe Obj-C ailleurs que sur Mac ?


Eh bien pour moi, c'est un point de détail. Ce serait un souci si ObjC était un mauvais langage ou s'il était très difficile à apprendre, mais ce n'est pas le cas.
Carbon, ça existe ailleurs que sur Mac ? Non. Ton code a beau être écrit en C, il n'est pas du tout portable.




Didier Guillion a dit:


> Bref, je pratique Cocoa+Obj-C, mais je ne suis pas à l'aise.


Cocoa est fort complexe. Trop en fait. Et la doc d'Apple est bien trop bavarde et imprécise. Il m'arrive souvent d'adopter des solutions de la vieille école parce que ça m'évite de me taper 100 pages de doc d'Apple. L'investissement intellectuel et temporel est bien plus rentable.



Didier Guillion a dit:


> Bon, il est vraisemblable que j'ai travaillé trop longtemps en C+Carbon pour me faire à autre chose...
> J'ai vu passer tellement de solutions de programmation différentes que cela ne me concerne plus, si j'ai un outil qui me permet de transcrire mes idées de manière correcte, je le garde.



Didier, je comprends ta situation perso, mais tu ne peux décemment pas conseiller d'utiliser Carbon à quelqu'un qui commence un projet aujourd'hui, justement parce qu'il n'a pas, comme toi en réserve, les milliers de lignes de code nécessaires pour réaliser chaque tâche. Avec Cocoa, je peux ouvrir une URL dans le navigateur avec une seule ligne. Tu as peut-être ta fonction perso pour ça, mais lui n'en disposera pas, et sera obligé de chercher comment faire, dans une doc qui n'est plus maintenue, pour un environnement pour lequel plus personne ne programme. Il va galèrer.

Je crois par ailleurs que, parfois, faire table rase apporte du soulagement. Si tu as remplacé ton code QuickDraw par du code Quartz, ce fut sans doute un gros investissement, mais au final, cela a simplifié ton code, et aujourd'hui, si tu as besoin de dessiner une courbe de Bézier, créer un PDF ou remplir une ellipse avec un dégradé, c'est beaucoup plus facile.
Le souvenir que j'ai du SoundManager, c'est que c'était une saloperie, avec lequel seulement charger un son et le jouer nécessitait 200 lignes de code. CoreAudio est une petite merveille à côté. Bien sûr, c'est nouveau, il y a des choses qui marchent différemment, mais il y a aussi un tas de choses futiles que tu n'as plus à gérer.

J'utilise les technologies d'aujourd'hui, pas par attrait de la nouveauté, mais parce qu'elles me permettent de me concentrer sur le problème à résoudre, plutôt que sur les détails de l'implémentation. Les utilisateurs attendent des applications qu'elles soient connectées à Internet, que les tâches y tournent en parallèle, et en plus avec de jolies animations. Ce sont juste les attentes normales des utilisateurs d'aujourd'hui. Si je veux répondre à ces attentes, je ne peux pas me coltiner des API qui ne sont même pas foutues de me dire si un bouton est cliqué. Carbon ne répond pas aux défis d'aujourd'hui.


----------



## Didier Guillion (12 Août 2009)

A Céroce

Tout d'abord je ne conseille à personne de démarrer en Carbon+C sur Mac. Je suis désolé si c'est ce que j'ai eut l'impression d'écrire. Mais, si l'on veut un code portable, écrire en Obj-C plus Cocoa est, à mon avis, une impasse à long terme.

Et mon code en C est absolument portable, j'en fait l'expérience tous les jours puisque j'écrit en C+Carbon et que cela se recompile sans problème sur Windows.
Moi, Xcode+Resedit (avec SheepShaver),  l'autre coté Codewarrior 10 sur Windows.
 Bon, il est vrai que nous avons écrit une librairie Carbon pour Windows...

Pour l'acquisition audio, je n'ai jamais eut de problème. Cela marche tout seul depuis des années.

En ce qui concerne les "Technologies Nouvelles", je prends un peu de recul. J'utilise quotidiennement  des progs que j'ai écrit en 87 en C, je ne suis pas sur que l'on pourra en dire pareil dans 20 ans sur les applis obj-c.


Cordialement


----------



## Hibou57 (13 Août 2009)

Céroce a dit:


> C'était l'IDE de référence sous Mac OS Classic.


Maintenant plus d'actualité, pour ce que j'en ai lu. Apparement stopé par Apple.



Céroce a dit:


> Non, vraiment, il ne s'agit pas d'une réponse partisane. J'ai développé plusieurs années pour les vieux systèmes 7.5. Carbon, n'en est qu'une légère amélioration. Puisque tu as la doc, regarde comment on fait pour répondre à un clic sur un article de menu:
> - obtenir les coordonnées du clic
> - déterminer dans quelle fenêtre s'est produit le clic
> - si c'est dans la barre de menu (qui est une fenêtre), transformer les coordonnées globales en coordonnées locales
> - déterminer quel est l'article de menu à cet endroit.


Effectivement, ce n'est pas propre. Même l'API Windows 3.1 était plus évoluée.



Céroce a dit:


> En Cocoa:
> - un message associé à l'article de menu est envoyé.


Comme sous Windows _(3.1, 9x, 2000, XP)_, à la différence que le gestionnaire d'évenement de la fenêtre reçois un identifiant pour l'entrée de menu, et que cet identifiant peut être partagé par plusieurs entrées de menu ou controles, si plusieurs entrées de menus ou controles sont conceptuellement associés à un même action.



Céroce a dit:


> Développer sous Carbon est long, fastidieux et difficile. Il s'agit d'une solution qui a permis de faire évoluer les logiciels existants pour qu'ils profitent des avantages de Mac OS X [...]


Tu m'as convaincu. Et j'ai effectivement appris aussi de mon côté que Carbon est progressivement abandonné.




Céroce a dit:


> J'aurais tendance à dire que la "culture" se fait à l'utilisation.


Mais je vais devoir me contenter de la litérature _(et du bon sens un peu aussi)_.




Céroce a dit:


> Je te remercie, j'en aurai bien besoin !


De rien :rose:




Céroce a dit:


> Pas tout à fait, mais ils ont fait du très beau travail. On retrouve ses repères (barre de menus, raccourcis clavier), et c'est très réactif. C'est bien mieux qu'une appli Java, par exemple. Si je devais écrire une appli multi-plateforme, ce serait sans doute avec le couple WxWidget + Python.


À ce sujet, je viens de faire une petite découverte. Je me suis inscrit sur le « Apple Developper Network » _(si je ne me trompe pas de nom)_. Aprés m'être inscrit, j'ai récupéré un fichier xcode313_2736_developerdvd.dmg que j'ai ouvert avec 7-Zip _(un archiveur sous Windows, qui est capable d'ouvrir les DMG de Mac)_. Il contenait entre autre, un MacOSX10.4u.sdk qui contient des entêtes pour wxWidgets et wxPython  Et encore un autre fichier DevSDK.pkg, qui contenait lui aussi des définitions pour wxWidgets. Comme l'environnement XCode est fourni par Apple, on peut peut-être en conclure que Apple donne une reconnaissance à wxWidgets.




Céroce a dit:


> Oui, mais tu dois pouvoir la placer facilement à l'intérieur de l'appli.


Oui, bundle, ou encore mieux, liaison statique.




Céroce a dit:


> Si, tu peux utiliser CoreAudio, mais forcément, il faudra reprogrammer pour l'équivalent pour la version PC. Ou alors utiliser une bibliothèque multi-plateforme comme OpenAL.


Comme le problème est pour moi de tester sous Windows parce que je ne peux pas tester sous Mac, ça ne m'avancera pas. Plutôt OpenAL alors.




Céroce a dit:


> Je vais finir par une question: tu n'as pas de Mac, pourquoi veux-tu absolument développer sur Mac ?
> Cela va te demander deux fois plus de travail. Je serais toi, je ne développerais que sous Windows.


Parce que ce qui m'interesse avec Mac, ce n'est pas seulement l'environnement logiciel, mais également l'environnement utilisateur. Je crois deviner que les utilisateurs de Mac accordent plus de valeur à leurs applications, d'ailleurs il font proportiellement plus régulièrement les mise à jour système que les utilisateurs de Windows.

Sous Windows, le climat et la culture ambiante ne sont pas bonne, et pour un utilisateur de Windows, une application n'a généralement pas de valeur, c'est « un dû », et même s'il la considère comme un dû, il dira systématiquement que ça ne vaut rien, raison pour laquelle également il ne fait pas les même à jour système _(mais il y a d'autres raisons aussi, ce n'est pas toujours si simple)_. Pour résumer, pour l'utilisateur moyen sous Windows, un logiciel, n'a jamais aucune valeur.

Le nombre d'utilisateurs d'une plateforme n'est rien, si ce ne sont pas de bons utilisateurs. Mieux vaut la qualité que la quantité, et sous Windows, la culture est plutôt « piratage et téléchargement à gogo »

Évidement, je ciblerai Windows également, parce que techniquement ce sera plus facile _(vu que je suis sous Windows)_, mais je n'en attend rien de bon à priori.

Remarque : j'avais au préalable tenté une application en ligne _(mais pas pour le même domaine)_, en pensant que c'était plus facile avec une application en ligne, de se protéger contre le piratage et d'offrir aux utilisateurs potentiels, un essai directe et aisement accessible. Mais les seuls personnes interessées, ont été des entreprises.... mais qui la voulait gratuitement _(parce que dans leur esprit, sur internet = gratuit, même si eux voulaient faire des bénéfices avec)_. Donc je vais finalement tenter les applications « sur poste » et laisser tomber les applications en ligne. Et comme je le disais, je pense que les utilisateurs Mac, sont plus regardant sur la qualité, et cherche peut-être moins à remplir leur disque dur de téléchargements en tout genre _(gratuit, évidement)_ pour rien et sans savoir pourquoi.

---------- Nouveau message ajouté à 12h53 ---------- Le message précédent a été envoyé à 12h48 ----------




Didier Guillion a dit:


> Pour la vidéo, on peut "attaquer" QuickTime avec Carbon également, donc même réponse.


L'API QuickTime existe sous Windows également, donc ce serait interessant.



Didier Guillion a dit:


> Mais un point essentiel à mon avis, c'est que pour vraiment utiliser Cocoa il faut écrire en Objective-C et non en C.
> Quand on écrit en Objective-C, le code devient difficilement portable. Ça existe Obj-C ailleurs que sur Mac ?


Oui, ça existe ailleur que sous Mac. Objective-C est un des langages pris en charge par GCC. Mais GCC n'est pas le seul, il en existe d'autres. Avec une bonne culture des abstraction informatique, il ne devrait pas être inabordable. J'avais lu un livre et quelques articles à son sujet en 1998, et même si c'est loin, j'en ai le souvenir de quelque chose d'accessible.



Didier Guillion a dit:


> Tu dit que c'est plus rapide de développer sous Cocoa que sur Carbon, je suis d'accord avec toi.


Aprés ses explications, impossible de douter.



Didier Guillion a dit:


> Par contre, pour avoir un peu pratiqué les deux, dès que l'application Cocoa devient un peu conséquente, je m'y perds rapidement. Certes en Carbon, on doit faire beaucoup de chose à la main, mais au moins quand on a un problème, on trouve rapidement ce qui se passe.


Des problèmes de typages ? De liaison dynamique ?

[/QUOTE]

---------- Nouveau message ajouté à 12h57 ---------- Le message précédent a été envoyé à 12h53 ----------




Didier Guillion a dit:


> Et mon code en C est absolument portable, j'en fait l'expérience tous les jours puisque j'écrit en C+Carbon et que cela se recompile sans problème sur Windows.
> [...]
> Bon, il est vrai que nous avons écrit une librairie Carbon pour Windows...



 Dis en plus, ça m'interesse énormément !


----------



## Didier Guillion (13 Août 2009)

Bonjour Hibou,

Je ne suis pas sur que nous soyons les seuls a travailler en Carbon sous Windows...
Je t'explique un peu notre cheminement, si cela t'intéresse.
Au fil des ans (on développe depuis 1982) on a commencé à en avoir un peu marre de voir des technologies disparaître et nous obliger à reprendre notre code à chaque fois pour l'adapter. Pour nous la programmation n'est qu'un moyen de réaliser ce que l'on a en tête, pas un but.
On a cherché le point commun entre les différents systèmes. 
Clavier, souris, écran. 
C'est la base. 
Alors si on sait allumer un pixel de la bonne couleur à la bonne place et recevoir un événement d'un périphérique connecté, on a tout.
En 1995, on a décidé de se créer une sur-couche qui puisse nous rendre indépendant du système. Comme les API Mac/OS nous semblaient bien faites, nous avons choisi de les réécrires en C. On est parti de l' Inside Macintosh, et entrée par entrée nous avons tout recodé.
Ce qui fait que nous avons une librairie, appelée ACAM ("As Clever As Mac", référence au rasoir d'Occam) qui nous permet de faire pas mal de choses de manière indépendante de la machine.
On a même fait une version pour Atari ST, c'est dire.
Donc, si par exemple Apple décide d'abandonner Carbon, on n'a plus qu'a recompiler notre librairie et hop, on continue à travailler.
Il y aura toujours des pixels à colorier et des événements clavier à recevoir...
Si Linux commence à pointer un nez intéressant dans le grand public, même opération. 
Conséquence intéressante, le temps de portage de nos applis entre Mac et Windows est de zéro.
En info, si on veut durer, il faut être un peu parano. 

Cordialement


----------



## Hibou57 (13 Août 2009)

Hi Didier,

Je vois que vous avez vu venir,

Mais si je dois refaire moi aussi toute une API de ce genre, je ne vais jamais y arriver. C'est une tâche titanesque que vous avez fait _(depuis 1982, je comprend que vous avez eu de quoi faire, et je me doute bien que votre Carbon pour Windows ne se balade pas sur le net)_.

Mon problème est surtout que je ne peux pas tester sous Mac.

Toi qui a l'air bien versé sur la question, tu me conseillerai quelle solution pour cibler Mac en étant sous Windows ? wxWidgets + QuickTime te semble être un bon choix ? Nota : je ne fais pas du C, mais de l'Ada _(question de maintenabilité et de lisibilité, j'ai été échaudé par le C, mais Ada interface facilement / naturellement le C, et un peu plus laborieusement le C++)_

Je ne suis pas trop regardant sur le temps de développement &#8212; étant sans emploie &#8212;, mais il faut que ça reste raisonnable tout-de-même, et que j'aboutisse à quelque chose dans un délais raisonable. Je pense que redévelopper une librairie de ce genre est exclus... sauf avec un sponsor _(et là ce serait avec joie)_.

Cheers


----------



## Didier Guillion (13 Août 2009)

Je ne connaît pas wxWidgets, mais les conseils de Céroce me semblent plus que judicieux...

Essaie néanmoins de jeter un oeil sur SheepShaver un émulateur Mac OS 9 que j'utilise quotidiennement sur Mac OS X. 
Je ne l'ai jamais testé sous Windows.

http://sheepshaver.cebix.net/

Cordialement


----------



## Céroce (17 Août 2009)

Didier Guillion a dit:


> Tout d'abord je ne conseille à personne de démarrer en Carbon+C sur Mac. Je suis désolé si c'est ce que j'ai eut l'impression d'écrire. Mais, si l'on veut un code portable, écrire en Obj-C plus Cocoa est, à mon avis, une impasse à long terme.



Effectivement, c'est ce que j'avais compris.
Tu seras peut-être surpris, mais je pense également que ObjC + Cocoa est une impasse à long terme. C'est le présent pas l'avenir. Seulement, je ne sais pas ce qu'est l'avenir, alors je code avec ce qui me semble les outils les plus efficaces aujourd'hui. Par contre, je soigne mes formats de fichiers, pour être capable de les relire dans 10 ans si nécessaire !

@Hibou
Ne te fais pas trop d'illusions avec les utilisateurs Mac non plus. Ça ne fait que deux semaines que j'ai lancé mon logiciel, et déjà des gens arrivent sur mon site web avec les mots clés "licence crack".


----------



## Vivid (17 Août 2009)

Céroce a dit:


> Effectivement, c'est ce que j'avais compris.
> Tu seras peut-être surpris, mais je pense également que ObjC + Cocoa est une impasse à long terme. C'est le présent pas l'avenir. Seulement, je ne sais pas ce qu'est l'avenir, alors je code avec ce qui me semble les outils les plus efficaces aujourd'hui. Par contre, je soigne mes formats de fichiers, pour être capable de les relire dans 10 ans si nécessaire !




Pour ce qui est d'Objective C, moi, j'ai même pas commencer !!  heureusement je suis pas obliger !
a faire dans la daube rapide (techniquement parlant), le flash version POO semble avoir plus d'avenir. Si c'est programmer correctement, question ressource sa passe !! je sais sur Mac....
La valeur sure... le 'C' et le plaisir d'allouer des pointeurs, pointeurs de pointeurs...


----------



## Hibou57 (17 Août 2009)

Juste rapidement en passant en coupe de vent : Snow Leopard pourra bien faire tourner les applications 32 bits, et supportera toujours l'API Carbon 32 bits, ainsi que d'ailleur, l'API Cocoa 32 bit à côté de l'API Cocoa 64 bits.

Comme témoigne cette représentation d'une vue des deux systèmes 10.5 et 10.6 :






Source : Snow Leopard et le 64 bits... et le 32 bits (macspirit.fr)


----------



## ntx (17 Août 2009)

Certes et 10.7 ? Dans deux ans, tu réécrits toutes tes applications. :rateau:
10.6 supporte ces technologies car des nombreuses vieilles applications les utilisent mais si Adobe se casse le c... à réécrire ses applications alors qu'ils ne l'ont pas fait depuis bientôt 10 ans qu'existe Mac OSX, c'est qu'ils doivent avoir une bonne raison. Ils ont peut être plus d'infos que toi


----------



## Didier Guillion (17 Août 2009)

Désolé, je n'ai toujours pas compris ce que veut dire 64 bits et 32 bits. Quand on déclare un int il sera 64 bits et non plus 32. Qu'est ce que cela change... ?
C'est le code qui sera 64 bits et prendra deux fois plus de place ? Quels sont les gains ?
Eh, Tatouille, explique nous !

Cordialement


----------



## Vivid (17 Août 2009)

Didier Guillion a dit:


> Désolé, je n'ai toujours pas compris ce que veut dire 64 bits et 32 bits. Quand on déclare un int il sera 64 bits et non plus 32. Qu'est ce que cela change... ?
> C'est le code qui sera 64 bits et prendra deux fois plus de place ? Quels sont les gains ?
> Eh, Tatouille, explique nous !
> 
> Cordialement



Cela permet d'adresser plus de 4 Gigas de ram pour les applications, parfait pour l'image de synthèse, sinon en C un long double sera 'traiter' en une seule fois... théoriquement 

le 64 bits consomme un peu plus de mémoire.


----------



## ntx (17 Août 2009)

Didier Guillion a dit:


> C'est le code qui sera 64 bits et prendra deux fois plus de place ? Quels sont les gains ?


A toi de choisir la taille de tes données en fonction de tes besoins. Si tu n'as pas besoin d'un long long contente toi d'un int ou d'un short. :rateau:

Sur un Intel 64 bits :
char  : 1 octet
short : 2 octets
int    : 4 octets
long  : 4 octets
long long : 8 octets

Par contre quelle est la subtile différence entre int et long ?


----------



## tatouille (17 Août 2009)

Je pense que Didier "pamphletait"  et qu'il n'a pas besoin que tu lui donnes un calcule concernant les types (donne en byte :rateau ceci dit pouvant etre aussi a la discretion du compiler*, heureusement le faite de garder une int (bit) de taille 32, ca peut servir  because of myint >>32 could give us some surprises! enfin c'est a demi-mot que je viens ici.

*compiler
en effet si ton compiler et pas trop con ici il devrait faire quelques optimizations (pourquoi reserver une taille de 32 ici...)

```
int i;
for (i = 0; i < 5; i++) {} 
// dans le cas LP64 long i; pourquoi reserver une taille de 64 ici...
// pareil pour les pointers
```



ntx a dit:


> différence entre int et long ?



32-bit familly et assimiles: 
les *pointeurs* , "*int*" , "*long*" ont tous une "largeur/taille" de 32-bit.

true-64-bit familly:
*** si LLP64-env *(c'est la que tu trouves long long type rustine)*,  les "*int*" et "*long*" ont toujours une "largeur/taille" de *32 *, mais les *pointeurs* ont une taille de *64*

*** si LP64-env (LES UNIX-LIKEs), les "*int*" ont toujours une "largeur/taille" de *32*, mais le type "*long*" 
et les *pointeurs* ont une taille de *64*, 

*** si ILP64-env, "*int*", "*long*" et *pointeurs* ont une taille de *64*, 

*** si SILP64-env, "*short*" ont aussi une taille de *64*.

tu comprendras pourquoi certains sont un peu septiques a propos de l'ere 64, un beau bordel en perspective.


----------



## Hibou57 (17 Août 2009)

ntx a dit:


> Certes et 10.7 ? Dans deux ans, tu réécrits toutes tes applications. :rateau:
> 10.6 supporte ces technologies car des nombreuses vieilles applications les utilisent mais si Adobe se casse le c... à réécrire ses applications alors qu'ils ne l'ont pas fait depuis bientôt 10 ans qu'existe Mac OSX, c'est qu'ils doivent avoir une bonne raison. Ils ont peut être plus d'infos que toi


Se casse les quoi ? Si tu écris les mots à moitié, on ne va pas te comprendre




Didier Guillion a dit:


> Désolé, je n'ai toujours pas compris ce que veut dire 64 bits et 32 bits. Quand on déclare un int il sera 64 bits et non plus 32. Qu'est ce que cela change... ?
> C'est le code qui sera 64 bits et prendra deux fois plus de place ? Quels sont les gains ?
> Eh, Tatouille, explique nous !
> 
> Cordialement


La taille des int _(entiers naturels)_, des long et des pointer _(alias void*)_, se voient attribués individuellement soit une taille de 32 bits soit une taille de 64 bits.

Cette assignation dépend du compilateur et du système d'exploitation cible. Mais en pratique, l'OS et le compilateur sont aussi étroitement liés que par contrat _(un OS = un compilateur officiel)_, et on peut le plus souvent de référer à l'OS et à implicitement un compilateur _(ou une configuration d'un compilateur)_.

Il existe plusieurs combinaisons possibles, mais deux d'entre elles _(en dehors de plus exotiques)_ sont plus fréquentes : la convention Windows et la convention UNIX.

Sous *Windows* 64, int et long font 32 bits, pointer fait 64 bits.
On fait référence à cette convention, sous le terme *IL32P64*

Sous *UNIX* 64, int fait 2 bits, long et pointer font 64 bits.
On fait référence à cette convention, sous le terme *I32LP64*

Personellement, je trouve la convention de Windows plus judicieuse, car correspondant plus aux besoins, plus économe et facilitant la migration des applications 32 bits.

Remarque : ces problèmes ne se posent que parce que le C est le C _(pas portable)_. Un language stricte et préis comme Ada, assigne au type pointer _(access)_ le type requis par le système et les type entiers sont le plus souvent définis par des intervals de valeurs _(et peuvent même recevoir des clauses de représentation, pour les interface de bas niveau)_



Vivid a dit:


> Cela permet d'adresser plus de 4 Gigas de ram pour les applications, parfait pour l'image de synthèse, sinon en C un long double sera 'traiter' en une seule fois... théoriquement
> 
> le 64 bits consomme un peu plus de mémoire.


Un peu plus... ou nettement plus ...


Je doute un peu de l'utilité du passage au 64 bits, dont l'évidence n'est pas aussi flagrante que lors du passage du 16 bits au 32 bits _(mais je n'ai pas envie d'en discuter sur l'instant)_.

Et le problème, est comme souvent qu'il s'agira d'une migration forcée _(pour forcer un rachat de nouveau matériel ?)_


Documents interessants à ce sujet :

Optimization of 64-bit programs
Ce que le 64 bits peut promettre et ne pas promettre.
L'intérêt de ce document, et qu'il n'est pas trop partisan

C variable types and declarations / Size
Bien que le C soit laxiste dans sa définition des type de base et surtout des types dérivés, il existent tout de même des obligations en ce qui concerne les relation entre les différents modificateurs des types de base. Ce document en fait un rappel.

[Libvir] Windows sizeof(long) != Linux sizeof(long)
Interessant témoignage dans une mailing liste, d'une personne venant de découvrir que le type long n'est pas le même sous Winows 64 que sous Linux 64.

64-Bit Programming Models: Why LP64?
Où l'on reparle de la différence entre IL32P64 vs I32LP64


----------



## tatouille (17 Août 2009)

Vivid a dit:


> Cela permet d'adresser plus de 4 Gigas de ram pour les applications, parfait pour l'image de synthèse, sinon en C un long double sera 'traiter' en une seule fois... théoriquement
> 
> le 64 bits consomme un peu plus de mémoire.



GPU + CPU 64-bit, il y a aussi un gros marche concernant la 3d, mais aussi pour les floats... et l'algo... ca ouvre des portes parfois bien plus simples et rapides mais cf: ma precedente reponse.

PS: si tu es sur le campus et le souhaite, on pourra prendre une boisson un de ces jours 

---------- Nouveau message ajouté à 23h46 ---------- Le message précédent a été envoyé à 23h09 ----------

pour en revenir a la question, ayant une experience multi-platforme avec WX ce n'est pas aussi simple et les doigts dans le nez que ca, 

il y a encore beaucoup trop d'objets differents par platforme et certains font crasher tout bonnement ton appli (la doc sucks too), il y a bien des macros if WX_MAC WIN GTK ecetera, mais cela demande un test constant sur chaque platforme avec des ajustements et pas des moindres, sur** plus propre que java et rapide que java, car c'est une API C++, MAIS CA N'ECESSITE le fait d'avoir les OS target, et un investissement dans le framework pour connaitre ces nombreux glitches.



pour ton argumentaire sur la "probalité fausse", tu devrais lire  "Les Principes du _calcul infinitésimal", ce qui pourrait te donner quelques explications a propos de la separation, et Couturat avec son fameux _"De l'infini mathématique_".

et tu devrais installer un simple wordpress sans fioritures ce qui donnerait plus de place au texte 

_


----------

