Kevin Kofler
:

Flanker
: 16o de signature

Plus la signature est longue, moins il y a de risques de faux positifs (programme qui commencent par cette signature par hasard).

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)

numéro de révisions sur un longword

C'est pour une plus grande évolutivité. Je n'ai pas envie d'être obligé de remplacer complètement le standard parce qu'on a dépassé le nombre maximum de révisions prévues. Le standard de base ne changera plus, il peut juste y avoir ajout de nouveaux champs. Donc le versionnement doit être préparé pour une longue vie.

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

Flanker
: mais par contre, ça risque d'être désagréable si on veut faire une fonction qui extrait de façon définitive un ppg (pour remettre les commentaires à leur place)

Tu ne remets pas les commentaires à leur place, ils seront de toute façon dans le programme décompressé aussi. (Copier les commentaires en compressant est implémentable, les virer du programme original, pas vraiment.)

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

Godzil :
Ce que je trouve restricitf ? -> 'l'authorité" qui en est en charge

Donc c'est bien par pur esprit de contradiction.

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

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

Vertyos
:

parce que ce serait idiot qu'un shell doive en gérer plusieurs

Mais non... Un shell peut gérer le standard si il le veut, si son auteur a envie de faire quelque chose qui soit totalement incompatible, il risque de ne pas avoir d'utilisateurs du tout et alors, tant qu'il fait ce qui lui plait, où est le problème ?

Que l'utilisateur se retrouve avec un programme pour lequel son shell n'affiche pas le commentaire, l'icône, ... pour la seule et unique raison que monsieur le programmeur de ce programme a refusé de respecter le standard existant et inventé son propre format que personne n'implémente.

bah de toute façon, vu l'utilisation qu'il y a de ce standard, on peut pas vraiment par ler de standard

Bah oui, pratiquement tous les programmes ne sont pas du tout incompatibles avec un anti-plantage (la preuve: TICTEX, PreOs Browser etc. peuvent les lancer sans problèmes), pour ceux qui le sont, mes TSRs et ceux de Samuel Stearley ont déjà été mis à jour pour inclure les flags d'incompatibilité, et pour les autres (qui ne doivent pas être beaucoup), je ferai un patcheur (mkcompat à la M$) pour permettre de rajouter un header de commentaires contenant les flags d'incompatibilité demandés et éditer la table de relogements en conséquence. (Rajouter des commentaires dans un binaire est moins dur que les supprimer parce qu'en rajoutant, on peut mettre les données où on veut, ils ne seront pas en plein milieu du fichier.)

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