Martial Demolins (./101) :
Si, PpHd a eu l'accord d'autres auteur de kernel pour faire évoluer le format (il a dit ça je sais plus où sur le forum) (au moins de l'auteur de UniOS).
Mais pas de tous, il n'a certainement pas la mienne, et d'ailleurs si Iceberg a géré les extensions propriétaires de PreOs (enfin pas toutes, parce qu'il en a rajoutées depuis), c'est uniquement parce que c'était un fork de PreOs 0.67 (pour des raisons de licence et parce que c'était le plus à jour pour les nouveaux AMS; point de vue maintenabilité j'aurais plutôt choisi la version C de
DoorsOS, beaucoup plus facile à modifier).
Alors pourquoi t'as implémenté les relogements compressés? 
Parce que c'était une nouvelle spécification (pas des extensions propriétaires à une existante), et justement ça aurait résolu le problème du plantage sous les anciens kernels proprement (le stub aurait détecté que le nouveau format n'est pas supporté et affiché une erreur "Kernel too old"). Pourquoi tout ça est-il au conditionnel? Ben, parce que manque de chance, c'était une spécification préliminaire et PpHd a choisi de ne pas l'implémenter.
(Du coup, je ne sais pas trop quoi faire, je vais finir par supprimer tout le code pour cette spécification parce qu'il ne sert à rien sans le kernel qui va avec.
)
Cela dit, les relogements compressés sont gérés pour les formats
_nostub (relogés par le code de démarrage) et Fargo (format qui était
plus moderne que celui actuel, qui est un pas en arrière), donc tout n'a pas été codé pour rien, juste le code pour le format PreOs (cela dit, il y a eu quelques réorganisations internes dans
ld-tigcc rien que pour ça, parce que la spécification prévoyait plusieurs tables à la suite et pas une à la fois comme le reste du monde
).
Et si un autre kernel voit le jour, il n'aura qu'à se plier aux specs existantes pour marcher, à lui d'être compatible, c'est pas aux programmes actuels de faire de la futuro-compatibilité, ça bride gravement le progrès des trucs comme ça!
Pour moi, ce n'est pas du progrès de dépendre d'un kernel comme dans les vieux temps alors que toutes les TI-68k actuelles (la Nspire n'est pas une 68k
) gèrent l'assembleur nativement.
)
Je parle des méthodes qui devraient fonctionner, mais plantent sous les vieilles versions.) Or ce problème crée des programmes qui plantent sous les kernels en question. Donc il faudrait tester des identifiants de kernels au démarrage, ce qui AMHA n'est pas une bonne idée (parce qu'un nouveau kernel pourrait sortir un jour, cf. TitaniK et Iceberg qui ont été nécessaires parce que PpHd a mis trop de temps pour mettre à jour PreOs pour la Titanium).
(Du coup, je ne sais pas trop quoi faire, je vais finir par supprimer tout le code pour cette spécification parce qu'il ne sert à rien sans le kernel qui va avec. 
)
).
). Un jeu n'a pas de raison d'avoir besoin du HW3Patch!
).
