Ca, les vieilles habitudes des pionniers qui n'avaient pas tigccdoc, dur de leur en vouloir quand même.

On pourrait leur en vouloir parce qu'utiliser des adresses absolues vers des variables internes du système est une programmation particulièrement sale
Même si les adresses utilisées n'ont pas changé dans toute la série des AMS 1.xx, ce qui a permis à ce hack sale de fonctionner aussi longtemps.
On pourrait aussi leur en vouloir de ne pas avoir cherché à regarder mieux que ça ce qu'il y avait dans AMS.

Au fait, j'ai oublié de relever un truc dans ./44: le fait de rechercher en binaire, sur des dizaines de milliers d'octets, les fonts d'AMS - ce que font les kernels - est un gros hack sur AMS, Martial
Par rapport à SetupCharSet, il est très lent, et ne prend pas en compte la redéfinition des fonts possible sous AMS 2.xx (rarement utilisée en pratique, on est d'accord - en revanche, tous les utilisateurs d'AMS 2.xx souffrent du fait que cette capacité ralentit beaucoup DrawChar/DrawStr). PpHd a changé la spec dans PreOS pour toujours chercher la font dans le boot code, ce qui maintient la compatibilité avec le comportement "vieux style" (pas adapté aux AMS postérieurs à 1999) des kernels précédents.
Par rapport à la phrase précédente: quand on dit que le kernel-based, c'est une technologie dépassée, on a évidemment raison. Ca ne souffre d'aucune discussion, et ça n'en a d'ailleurs jamais souffert sur un quelconque argument que ce soit. Ce n'est que par pur esprit de contradiction que certains osent encore contester ce fait absolument indiscutable. Point à la ligne