Si nous avions travaillé seulement sur Windows, nous n'aurions pas eu besoin de trop modifier nos fichiers sources C. Hélas, nos programmes doivent aussi se compiler sur MacOS, et là les choses se gâtent.
Un peu partout depuis les 30 dernières années, nous avons utilisé le type "long" pour désigner les entiers 32 bits. Mais d'après le grand livre du C, la taille en bits de ce type peut varier en fonction de la plateforme sur laquelle on est.
Sur Windows, le "long" reste à 32 bits, même si on compile un programme en mode 64 bits. Sur Macintosh par contre sa taille est doublée, ce qui rend la version 64 bits du programme incompatible avec tous les fichiers que l'application a pu sauvegarder précédemment, et pose des problèmes quasiment insolubles.
Seule solution, cesser d'utiliser ce type, et le remplacer pas le tout nouveau typage du C à nombre de bits définis, en l'occurence int32_t.
Nous avons entamé des essais de remplacement globaux, suivis d'une grosse session de correction du code pour éviter les alertes de compilation (le compilateur dit qu'il peut y avoir un problème, mais ce n'est pas sûr). C'est un travail de forçat.
Nous avons commencé par la seule librairie ACAM (notre socle de compatibilité entre les différents systèmes) et une très très petite application, avec une seule fenêtre et 3 boutons.
Nous avons effectué environ 6000 remplacements dans les 300 fichiers source C, puis avons commencé à traiter une à une les 1200 alertes de compilation afin de les faire disparaître.
Nous en sommes environ à la moitié, et pour l'instant, aucune ne pouvait déboucher sur une véritable erreur. Mais au moins, nous aurons une compilation plus "propre", et cela évitera que les vraies indications de problème se retrouvent noyées dans les alertes inutiles. |
|
|
| by Olivier Guillion |  |
| |
|
Cela fait assez longtemps maintenant que les systèmes d'exploitation sont passés en 64 bits.
D'abord Linux, puis Mac OS font maintenant pression sur les développeurs pour que leurs applications soient portées en 64 bits, menaçant d'arrêter à plus ou moins court terme le mode de compatibilité qui permet de continuer à les faire fonctionner.
D'abord, soyons clairs : à moins que l'application gère de très gros volumes de données (vidéo, photographie HD...) son passage 64 bits n'apporte strictement rien, au contraire.
Le code et la place mémoire nécessaire pour les données seront augmentés, la rapidité restera sensiblement identique, et ce ne sera pas plus stable.
Nous avons, ces dernières années, fait quelques tests pour évaluer le travail nécessaire, et c'est un gros, très gros travail. Chaque système semble avoir géré cette transition à sa façon, demandant plus ou moins de travail au développeur. Jusqu'ici le pire est le Macintosh, qui n'a pas hésité à changer la taille du types standard C "long" de 32 à 64 bits, rendant le portage cauchemardesque pour les développeurs ayant utilisé ce type.
Sur Windows, c'est mieux. En une journée de travail, nous sommes presque parvenus à faire apparaitre une fenêtre avec des boutons et une zone de saisie.
Le problème est que nous n'avons pas trouvé moyen de demander au compilateur de nous indiquer les sources potentielles de problème. Nous devons donc compiler, lancer, attendre un crash, et lorsqu'il survient, effectuer les corrections nécessaires et recommencer. Cela peut fonctionner pour un test simple, mais est inenvisageable pour une application comme Harmony Assistant, où il faudrait plusieurs années pour tester tous les cas (si une telle chose est possible)
Donc, nous essayons de trouver un moyen plus sûr et plus rapide d'effectuer un tel portage, qui nous mobiliserait un certain temps, pour aboutir à une application strictement identique, juste un peu plus lente et plus gourmande en mémoire.
Le plus tard sera donc le mieux, et, à l'issue, ce travail ne pourra certainement pas être fourni gratuitement. |
|
|
| by Olivier Guillion | |
| |
|
|
