Pollux
:Mouais enfin même en se restreignant à des numéros "parlants", 256 versions x 256 révisions devraient largement suffire...

Pas sûr...

Pourquoi ne pas juste extraire les commentaires du ppg, s'ils sont au début du fichier ? Parce que sinon c'est pas le fait que ça prenne 2x plus de place qui va arranger les choses ^^

Parce que:
1. ça change tous les offsets, il faudrait recalculer la table des relogements, voire les tables de relogements si on utilise les tables personnalisées permises par TIGCC,
2. les commentaires peuvent être n'importe où dans le fichier, le header ne contient que des pointeurs,3. les commentaires peuvent aussi être en même temps des données (c'est le cas pour certains TSRs de Samuel Stearley ou de moi).

Pkoi ne pas les mettre dans des sections de startup ?

Parce que l'utilisateur peut les mettre où il veut, ça fonctionne avec presque les mêmes mécanismes du linker que les exports kernel. La différence se trouve dans ce qui est exporté uniquement (des métadonnées dans le premier cas, des fonctions ou données dans le deuxième, même si le standard _nostub est suffisamment puissant pour qu'on puisse exporter tout et n'importe quoi, même des fonctions, en utilisant les codes réservés à l'application, il faut juste me demander de réserver une plage de codes pour éviter les conflits). Les programmes en assembleur utiliseront forcément la méthode bas-niveau (Samuel Stearley définit même le header lui-même, moi, j'utilise les _nostub_data__0000 du linker; et comme déjà dit, on réutilise les chaînes de caractères si elles sont déjà dans le programme), et le système de compression automatique doit être compatible avec l'assembleur aussi.

Bah non, je fais pas ça en bas niveau comme vous, j'utilise les méthodes de haut-niveau pour le faire (COMMENT_BW_ICON, etc...)

Et tu définis COMMENT_BW_ICON comment? Tu utilises un symbole interne à GTC?

Flanker
:tu crois franchement que 16o c'est pas trop ? y a combien de faux positif pour les prog kernel (alors que la signature est sur 4o)

4 octets donnent toujours une probabilité assez grande de faux positifs, c'est une ou deux instructions, ou 4 caractères d'une chaîne de caractères, ou une ligne d'un sprite 32×32. A priori, on ne sait même pas s'il y a du code ou des données à cet endroit.

franchement, je veux pas te vexer, mais je crois pas qu'il y aura 4294967296 versions différentes de ce standard. A raison d'une par seconde, ça sera atteint dans 136 ans Déjà 255, ça me paraît bcp

255, c'est peu! On aurait peut-être pu s'en sortir avec 65536, mais c'est trop tard, le format est fixé! C'est tout l'intérêt d'avoir un standard avec des numéros de version et tout: le format ne change plus! Et le longword a été choisi parce que c'est le même format utilisé aussi pour les numéros de version des programmes dans le même standard, pour la consistence. Et pour les numéros de version des programmes, on a utilisé un longword pour pouvoir coder des numéros de version comme 0.94 Beta 18 r1 de manière lisible (0.94.18.1 - comme dit dans le standard, il est conseillé d'afficher les numéros de version numériques comme des adresses IP).

chouette encore un gain de place avec un peu de chance, ça compensera le gain gané par la compression

En échange, la taille du lanceur a été réduite de 546 octets, et il y a encore des optimisations en cours.

en même temps, je le comprends, vu que tu es incapable de reconnaître qu'il faut faire évoluer un standard. Un standard permet pas de faire un truc ? Bah on fait pas alors, hors de question de changer le standard

Le standard de commentaires _nostub a été conçu pour être évolutif.

Godzil :
Heu franchement obliger le programmeur a avoir une feature dont il veux pas je deteste ce genre de politique

On ne t'oblige à rien, la touche "Suppr", ça existe.

ouééééé "M$" se fait condamner par l'UE pour avoir fait la même chose, je te signale

Parce qu'ils sont un monopole. Les distributions Linux le font aussi et n'ont pas eu de problèmes. Et puis ce qu'on fait, nous, n'est pas tout à fait la même chose.

comme d'hab, ça fait profondément chier l'utilisateur de devoir changer UN programme, par contre, le forcer à télécharger un programme pour patcher tous ses programmes, c'est

1. Personne ne t'obligera à utiliser un kernel intégrant cet anticrash.
2. Tu n'as qu'à corriger tes TSRs, ça fera des programmes à patcher en moins. Les miens et ceux de Samuel Stearley sont déjà corrigés depuis longtemps.

Sinon, je suis assez d'accord avec le ./92 de Sasume, sauf pour la dernière phrase. Phrase qui n'a vraiment pas sa place dans ce topic, d'ailleurs.