Portage vers mac particulier

[Eldros]

Je suis sûr que les ex-pcistes, nouveau en programmation MacOS X sont légions à vous le demander : Quel est le meilleur choix pour porter une application développé sous Windows de le porte sur mac?

Cependant, si je prend le risque de vous poser la question, c'est qu'il y a quelque contrainte. Le programme que je veux porter est un programme fonctionnant en mode console DOS fait en langage C. Pour être plus précis, ce sera un espèce de chat qui pourra se décliner vers deux objectifs futur :

- Faire des tests pour une AI
- Servir de base à un jeu

J'aimerais en plus pouvoir avoir le moins de modifications possibles à faire entre le code Windows et le code mac, car au final, je ne me consacre pas encore sur l'apparence avec cet partie chat puisqu'elle sera réutiliser par d'autre programme.

J'ai fait le tour des tutoriaux de Project Omega mais rien ne semblait pouvoir m'aider.

Je remercie d'avance toutes personne qui pourrait m'aider dans le choix du langage et du type de projet à utiliser.

Si vous avez besoin du code fait jusqu'à là ou d'autre renseignement, dites le moi aussi.

 

[BooBoo]

a moins de dire des bétises, ton programme en C, s'il utilise les librairies standard doit pouvoir être compilé avec le compilateur gnu (de base, fournit avec OSX) et exécuté dans le terminal.

Mais tu demandes un choix ! Un choix sur quoi ? le language, l'IDE, la librairie graphique pour le jeux ?
exprime un peu plus clairement le besoin...

OUPS, j'avais pas lu jusqu'a la fin...
donc, pour le language, tu peux resté sur le C. Ensuite il y a le C++ ou l'objective-C pour de la programmation objet. XCode et le compilateur gnu gere tres bien tout ces languages

 

[Eldros]

Merci pour ta réponse BooBoo, mais ta réponse m'amène 2-3 questions :

- Avec Xcode, j'ai essayé de mettre mon fichier c dans un projet vide, mais impossible de compiler, l'icone Built reste grisser... :mouais: Ou est-ce que j'ai fait la gourde?

-Ca existe des compilateur Objective-C sous Windows? Si non, y'a moyen de switcher en C ou C++ sans changer beaucoup le code de l'Objective C? (tout comme c'est possible entre C et C++)

La question du premier posts reste ouvertes à d'autre avis, plus j'ai d'avis, plus je pourrais me faire une meilleur idée sur mon propre choix.

 

[BooBoo]

Pour faire du C, il faut choisir comme type de projet:
Command Line Utility -> Standard Tool

pour du C++: C++ Tool

cela va te creer un projet Hello World basique.
Il est compilable et exécutable

 

[Eldros]

Dans ce cas là, à quoi ça sert un projet vide?

 

[BooBoo]

personnelement, ca m'a servi a creer un projet pour un site PHP afin d'organiser les fichiers.
Pas besoin de compilation.

Mais cela peut également servir pour creer soir même sa chaine de compilation avec d'autres outils que ceux fournit par Apple

 

[Eldros]

Encore merci pour les infos, j'ai maintenant créer mon projet correctement, et je peux donc le compiler sans problème.

Maintenant quand je le compile, ce qui me sort c'est ça :

[Session started at 2005-06-20 22:37:23 +0200.]
Erreur a l'initilasitation de la date en mode r.


Realm VII has exited with status 1.

Ce qui est loin d'être le résultat excompté puisque "Erreur a l'initilasitation de la date en mode r" (Remarquer que j'ai superbement orthographié initialisation :siffle: ) est le message qu'il me renvoie lorsqu'il arrive pas à ouvrir mon fichier time.txt. Je suppose que c'est dû au formatage du chemin des fichier qui est différent sous dos et unix.

Juste pour information j'utilise le chemin ./files/time.txt

Donc comment faire?

 

[BooBoo]

attention, l'exécutable généré se trouve en Build/Debug. Il faut donc faire ../../files/time.txt ou indiquer le chemin compet, ou encore indiquer un répoertoire de lancement (je ne sais pas si c'est possible)

 

[Eldros]

Ou tout simplement mettre les repertoires au bon endroit.

Encore, merci ,j'avance à pas de géant ^^.

Mais à chaque fois que je résous un problème, un autre pointe son nez. Mais bon, là c'est un problème mineure. Genre, lorsqu'il enregistre mes phrases dans le log, à la place de ç on trouve ?ß. Problème du formatage du fichier sans doute, mais je doit admettre que ça va me gener légérement, surtout que ça me pose pas de problème sur Windows ça.

 

[BooBoo]

probleme de format d'encodage des fichiers:
Choisi Format->File Encoding->UTF-8

ca devrait de même marcher sur windows



Bon, dodo pour moi

 

[BeNBiBiFoKe]

Je suis content de voir que tout ce résout pour toi

Et comme l'a dit le post précédent, encode tes fichiers TXT en UTF-8 et petit conseil profite en pour dire a ton editeur de texte d'utiliser ça tout le temps...pcq MacRoman c souvent la merde avec les autres Os

 

[Eldros]

Je vous remercie pour votre aide qui m'as été très précieuse, et qui me permet, maintenant de faire marcher l'ersatz de programme. (Désolé pour le retard mais entre la recherche de stage et le début du stage tout de suite aprèsla fin des cours, j'ai pas vraiment eu beaucoup de temps à moi)

Toujours est-il une question n'a toujours pas reçu de réponse ; est-il possible de compiler du Obj-C sous Windows?

Et puis il ne faut pas oublier la question principal du fil (et tous le monde est invités à donné son avis) : Quel serait le(s) meilleur(s) langage(s) pour mon projet afin qu'il y ai une portabilité maximum?

Pour vous aider à vous faire une meilleur idée du projet, je vais rajouter quelque éléments.

Après reflexion, j'ai divisé le projet en quatre programmes (qui ne serait pas forcément réalisé dans le même langage):

- Le serveur

- Le client, d'abord en ligne de commande, puis peut-être en interface propriaitaire par la suite (surement Cocoa ou Carbon pour Mac OS

- Un module d'apprentisage, c'est-à-dire quelque chose qui apprendrait à un objet à simuler une personne

- Le simulateur de personne (avec peut-être une base derrière)

Il va de soit que pour l'instant je vais principalement me concentrer sur les deux premiers.

Et sur ce point, j'ai récupéré le code d'un chat client-serveur d'un gars de ma promo, qui, d'après les dires du jury, serait un "émulateur de thread" (m'en demandais pas plus, je sais pas ce que sait). Je m'étais dis que j'allais pouvoir le mettre à la sauce mac (bien évidemment, le programme avait été fait sous PC), mais je tombe sur un os avec une bibliothèque qui m'était inconnu jusque là et qui porte le mélodieux nom d'allegro . Je suis pose que c'est une bibliothéque propriétaire, existerais-t-il un equivalent mac?

 

[ntx]

Bonjour,

Toujours est-il une question n'a toujours pas reçu de réponse ; est-il possible de compiler du Obj-C sous Windows?

oui, regarde du cote du projet GNUStep qui est une implementation d'OpenStep (i.e. un Cocoa en moins fourni) pour differentes plateformes.

Et puis il ne faut pas oublier la question principal du fil (et tous le monde est invités à donné son avis) : Quel serait le(s) meilleur(s) langage(s) pour mon projet afin qu'il y ai une portabilité maximum?

Java est portable sur de nombreuses plateformes. Mais les interfaces graphiques sont lentes.
Le C++ aussi si tu utilises les bonnes librairies. Le plus delicat dans ce cas est l'interface graphique (voir des librairies comme GTK, QT ou WxWidget) et peut etre aussi la gestion des threads et des processus (differente entre Windows et les Unix). Pour Mac OSX, tu peux tout a fait melanger de l'objective-c et du c++ : ca s'appelle objective-c++.

Et sur ce point, j'ai récupéré le code d'un chat client-serveur d'un gars de ma promo, qui, d'après les dires du jury, serait un "émulateur de thread" (m'en demandais pas plus, je sais pas ce que sait). Je m'étais dis que j'allais pouvoir le mettre à la sauce mac (bien évidemment, le programme avait été fait sous PC), mais je tombe sur un os avec une bibliothèque qui m'était inconnu jusque là et qui porte le mélodieux nom d'allegro . Je suis pose que c'est une bibliothéque propriétaire, existerais-t-il un equivalent mac?

Il s'agit peut de cette librairie ? Il existe une version Mac OSX.

 

[daffyb]

Dans mon ancien temps, à l'école, nous avions un projet informatique à faire.
Pour ma part il s'agissait d'un logiciel de simulation numérique.
L'ensemble de programme fonctionnait en mode ligne de commande et fonctionnait donc sous Windows, MacOS X et tous les Unix...
En suite, nous avons fait une interface graphique pilotant la version ligne de commande. Une IHM par plateforme/OS

 

[Eldros]

[...]

Java est portable sur de nombreuses plateformes. Mais les interfaces graphiques sont lentes.
Le C++ aussi si tu utilises les bonnes librairies. Le plus delicat dans ce cas est l'interface graphique (voir des librairies comme GTK, QT ou WxWidget) et peut etre aussi la gestion des threads et des processus (differente entre Windows et les Unix). Pour Mac OSX, tu peux tout a fait melanger de l'objective-c et du c++ : ca s'appelle objective-c++.

Suite à ta remarque, et après avoir farfouiller un peu dans la doc Xcode, je me demandais s'il était possible d'utiliser le Java pour les tache de fons, ce qui me ferait un "noyau" portable sans modification de code. Et ensuite, je pourrais peut-être faire l'interface graphique en GNUStep si ça se fait.

Il s'agit peut de cette librairie ? Il existe une version Mac OSX.

C'est exactement ça, et je pense que je vais garder cette librairie sous le coude, car elle pourrait m'être utile dans bien des aspects. Notemment avec l'interface, comme alternative à GNUStep. D'autant plus que c'est une librairie faite pour la création de jeux.

De tout de façon, au pire des cas, je ferais des interfaces propriétaires pour chacune des platformes.

Dans mon ancien temps, à l'école, nous avions un projet informatique à faire.
Pour ma part il s'agissait d'un logiciel de simulation numérique.
L'ensemble de programme fonctionnait en mode ligne de commande et fonctionnait donc sous Windows, MacOS X et tous les Unix...
En suite, nous avons fait une interface graphique pilotant la version ligne de commande. Une IHM par plateforme/OS

Est-ce que tu pourrais me dire les langages que vous aviez utiliser? (Pour le programme en ligne de commande et pour les interfaces.)

 

[ntx]

Tu peux appeler du C (ou un de ses dérivés) à partir du Java (mais ne me demande pas comment on fait ); par contre l'inverse je doute ?
Si ton noyau ne fait que du calcul ou du traitement de données, du code C++ utilisant des librairies communes (stl, boost, ...) sera tout aussi portable que du Java. Si tu veux faire le noyau en Java, fait toute ton appli en Java ce sera plus simple.
Sinon si tu ne veux pas une IHM trop perfectionnée, tu peux aussi la faire en TCL/TK et appeler ta librairie "noyau" en C++ à partir de l'IHM.

 

[Eldros]

Voilà qui a le mérite de mettre les points sur les i. Cependant dans le noyau, je voudrais utiliser des sockets. JE m'y connais pas des masses en ce qui concerne la programmation réseau, mais généralement les bibliothèque socket en C sont propriétaire, non? Si c'est le cas, il existe peut-être un autre moyen de faire du client/serveur que les socket?

 

[ntx]

Bonsoir,
pour les sockets, il doit être possible de faire du code C commun aux Unix en utilisant les sockets BSD; par contre pour Windows, il faudra faire du code spécifique.
Un autre moyen de faire discuter des ordinateurs en client-serveur, est de faire du corba, mais la ce sera en C++ ou en Java. On trouve des librairies gratuites telles que TAO. Par contre c'est plus complexe à mettre en oeuvre et cela nécessite des connaissances en programmation objet. Mais cela permet de faire discuter toutes sortes d'ordinateurs (Mac, Windows, Unix) et d'applications entre elles (C++, Java, ....). La technologie microsoftienne concurrente est .net et son implémentation libre mono, mais ce dernier est encore en développement et cela ne marche qu'en C#.

 

[Eldros]

Oh, il me vient une idée. Est-ce qu'il est possible de faire communiquer des applis, situées sur une même machine entre elles? Je veux dire sans passer par des technologies réseaux. Car si c'est le cas, je pourrais créer deux applis distinctes étant le client et l'interface, et je les ferias communiqué entre elles.

 

[ntx]

Moi ce que je ferai :
- une libraire écrite avec du C standard pour effectuer toutes les opérations du noyau (hors réseau) commune à toutes les plate-formes.
- une librairie pour les fonctions réseau pour les Unix et une pour Windows, avec des interfaces communes.
- une librairie pour les threads pour les Unix et une pour Windows, avec des interfaces communes.
- une librairie pour gérer les accès système (gestion des fichiers sur le disque, etc) par plate-forme, avec des interfaces communes.
- une application basée sur une librairie graphique commune (gtk, qt ou wxWidget) appelant des fonctions dans les librairies précédentes.

Si tu ne veux pas réinventer la roue, il existe des librairies effectuants les taches les plus courantes et qui sont multiplate-forme :
- Boost te permet de gérer les threads et les systèmes de ficher ou les threads, mais aussi plein d'autres choses.
- ACE pour les fonctions réseau et les threads, et des pattern pour les gestions de flux de données.