Ce n'est pas vraiment le but de Haiku: on est là pour faire un système pour les PC de bureau. Donc tout ce qui est embarqué, ce n'est pas notre cible et on ne peut pas trop s'en occuper (on a déjà pas le temps pour ce qu'on essaie de faire...)
Sur le plan technique, on peut quand même avancer quelques réponses:
Les syscalls: il vaut mieux ne pas les utiliser directement, car on se permet des modifications dans leur API et ABI régulièrement. Il est très probable que les applications qui les utilisent cessent rapidement de fonctionner. Il faudra utiliser la libc pour les APIs POSIX et du C++ (pas le choix) pour les APIs de BeOS permettant de communiquer avec le serveur graphique. On pourrait virer le serveur graphique et utiliser directement le framebuffer, mais ce sera limité au VESA (les pilotes fonctionnant dans le serveur graphique pour les autres cas).
Les ABI: l'ABI pour le C++ ne fait pas partie du standard C++, mais aujourd'hui gcc et clang (au moins) sont d'accord pour utiliser l'ABI C++ définie à l'origine pour les processeurs Itanium, et qui s'adapte très bien aux autres machines. On peut donc utiliser indifférement ces deux compilateurs. Le problème, c'est que cette ABI est arrivée dans gcc version 3, et que BeOS utilisait la version 2. La solution pour l'instant est d'avoir 2 ensembles de bibliothèques compilées avec ces 2 versions (le problème ne se pose que pour la version x86 32bit de Haiku, pour les autres versions la compatibilité avec BeOS n'est pas assurée).
Il y a aussi plusieurs astuces dans la façon de définir les classes pour pouvoir les modifier après coup:
- Déclaration d'emplacements réservés à la fin de la vtable et des données de chaque objet, qui peuvent être remplacés ensuite par des méthodes si nécessaire,
- Ajout d'une méthode "Perform(int operationCode, ...)" qui permet de faire toutes sortes de choses et qui est systématiquement surchargée par tous les objets,
- Déclaration à la main de symboles C++ pour des méthodes qui n'existent plus
Ces acrobaties demandent un peu d'habitude mais cela permet de faire fonctionner des applications écrites il y a plus de 20 ans sur les versions actuelles de Haiku. Les développeurs de chez BeOS s'étaient déjà posé la question et avaient mis en place ces solutions.
Aujourd'hui on peut également ajouter le versionnage des symboles qui permettent de modifier une fonction tout en gardant les versions précédentes pour les anciennes applications.
[^] # Re: mode 'brut'
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 5.
Bonjour,
Ce n'est pas vraiment le but de Haiku: on est là pour faire un système pour les PC de bureau. Donc tout ce qui est embarqué, ce n'est pas notre cible et on ne peut pas trop s'en occuper (on a déjà pas le temps pour ce qu'on essaie de faire...)
Sur le plan technique, on peut quand même avancer quelques réponses:
Les syscalls: il vaut mieux ne pas les utiliser directement, car on se permet des modifications dans leur API et ABI régulièrement. Il est très probable que les applications qui les utilisent cessent rapidement de fonctionner. Il faudra utiliser la libc pour les APIs POSIX et du C++ (pas le choix) pour les APIs de BeOS permettant de communiquer avec le serveur graphique. On pourrait virer le serveur graphique et utiliser directement le framebuffer, mais ce sera limité au VESA (les pilotes fonctionnant dans le serveur graphique pour les autres cas).
Les ABI: l'ABI pour le C++ ne fait pas partie du standard C++, mais aujourd'hui gcc et clang (au moins) sont d'accord pour utiliser l'ABI C++ définie à l'origine pour les processeurs Itanium, et qui s'adapte très bien aux autres machines. On peut donc utiliser indifférement ces deux compilateurs. Le problème, c'est que cette ABI est arrivée dans gcc version 3, et que BeOS utilisait la version 2. La solution pour l'instant est d'avoir 2 ensembles de bibliothèques compilées avec ces 2 versions (le problème ne se pose que pour la version x86 32bit de Haiku, pour les autres versions la compatibilité avec BeOS n'est pas assurée).
Il y a aussi plusieurs astuces dans la façon de définir les classes pour pouvoir les modifier après coup:
- Déclaration d'emplacements réservés à la fin de la vtable et des données de chaque objet, qui peuvent être remplacés ensuite par des méthodes si nécessaire,
- Ajout d'une méthode "Perform(int operationCode, ...)" qui permet de faire toutes sortes de choses et qui est systématiquement surchargée par tous les objets,
- Déclaration à la main de symboles C++ pour des méthodes qui n'existent plus
Ces acrobaties demandent un peu d'habitude mais cela permet de faire fonctionner des applications écrites il y a plus de 20 ans sur les versions actuelles de Haiku. Les développeurs de chez BeOS s'étaient déjà posé la question et avaient mis en place ces solutions.
Aujourd'hui on peut également ajouter le versionnage des symboles qui permettent de modifier une fonction tout en gardant les versions précédentes pour les anciennes applications.