Mais non, c'est pour sécuriser, c'est bien.
Mais si ton prog n'utilise pas de ROM_CALL que pedrom n'a pas, tu mets un define qui enlève cette protection.
Si jamais on rajoute du code pour détecter Pedrom à notre startup code, ça sera pour refuser l'exécution (vu qu'il y a des ROM_CALLs en moins par rapport à AMS 1.01 pour lequel il se fait passer).C'est vraiment bete : Pedrom detecte déja quand des ROM_CALL non reprogrammé sont utilisée. J'espère que tu ne voudrais interdire tout simplement de programmer sur Pedrom.
Mais si ton prog n'utilise pas de ROM_CALL que pedrom n'a pas, tu mets un define qui enlève cette protection.Il vaut mieux l'inverse car après, on obtient des programme qui ont tout pour marcher sur Pedrom mais qui refuse systématiquement car l'auteur n'a pas pris la peine de mettre l'option. Un utilisateur de PedROM sait qu'un programme non concu pour lui a ds chances de ne pas marcher.
XDanger a écrit :
> C'est a PedroM de detecter si ca passe ou pas.
Evidemment que c'est à PedroM de détecter si ça marche ou pas.
Mais ça n'est peut-être pas très facile. C'est plus facile de rediriger vers rien (une routine qui sort proprement, sans memory leaks, en libérant les handles éventuellement alloués et tout et tout) les ROM_CALLs non supportés. Uther Lightbringer dit que ça le fait déjà, apparemment (c'est vraiment la moindre des choses).
GT-BASIC et PedroM sont bien mieux écrits qu'AMS, OK. GT-BASIC est nettement plus puissant que le TI-BASIC, mais il faut tout un truc pour le faire tourner.
PedroM n'a presque pas de fonctions de calcul...
GT-BASIC/GT-Dev est une collection de bonnes idées pour TI s'ils voulaient faire un truc mieux que leur TI-BASIC, mais ils ne le feront certainement pas... Et TI ne mettra jamais un kernel dans le système comme PedroM le fait...
PpHd
a écrit : Pourquoi ? Windows integre bien un kernel. Linux aussi.