A propos des des"commentaires" nostub - Page 3

T'as pas vraiment compris...
Ce topic parle de standards, que ce soit sur TI ou ailleurs, même si effectivement à l'origine, c'est ceux pour TI.
Quand à la fermeture du sujet, il n'y en a aucune raison, sauf sur demande de l'auteur ou si il y a de réels problèmes de comportement, or tout le monde poste correctement (sauf toi).
Et oui, tu as raison, ça risque de modérer sec si tu continues ce genre de posts.

on ne saurait que trop recommander une fermeture d'un tel sujet

ce topic a été créé pour éviter que les discussions qui ont lieu ici ne pourrissent d'autres topics...
il ne sera donc pas fermé. (sauf en cas d'insultes ou de choses dans ce genre, naturellement)

Et même <br /> n'est pas correct en HTML, cf. http://www.hixie.ch/advocacy/xhtml. Le XHTML n'est pas compatible à 100% avec le HTML quoiqu'en dise la pub du W3C. C'est vraiment dommage de voir le W3C sortir un standard buzzwords-compliant (buzzword du jour: "XML", donc tout doit être en XML) après l'autre au lieu de garder celui qui existe déjà.

Le passage a XHMLT était nécéssaire pour restandardiser le tout é devrait permettre justement d'éviter de polluer bètement le standard a l'avenir le X c'est pou eXtensible.
Le W3C n'a jamais dit que xhtml était 100% compâtible avec HTML, d'ailleurs s'il avait été compatible il auraient certainement appelé ça HTML 5.0.
Ils ont juste dit que ça passe relativement bien si on prend ces précaution sur un broswer HTML.

Et même à l'intérieur du standard HTML, je suis contre certains changements, notamment le fait que des tags comme FONT ont été déclarés "deprecated". On ne déclare jamais quelque chose qui fonctionne "deprecated" si on pense un minimum à la compatibilité. En l'occurrence, les tags FONT fonctionnent très bien, même s'ils ne sont pas conformes au buzzword du jour qui est "separation of contents and presentation".

Certe, le but étant d'inciter a l'utilisation des styles qui sont un réel progrès et donc eviter d'avoir des fonction en double c'est discutalble mais de toute façon dans la pratique tout le monde s'en fout. Ceux qui utilisent cette balise n'ont probablement jamais lu et ne liront jamais la spécification HTML.

En résumé, le problème est que le W3C est dominé par des commerciaux qui s'occupent plus de buzzwords (mots-clef à la mode) que de considérations pratiques comme la compatibilité.

Ho le joli troll. c'est tellement gros que je le laisse comme ça

Entendu. Il faut néanmoins considérer le cas de Kevin.
Imaginons que je parle de quelqu'un ici de la même façon
qu'on parle de Kevin, il semble que ça ne passerait pas.
Donc il faut croire qu'on ferme les yeux facilement quand
il s'agit de cogner sur Kevin.

Quand à la discussion sur les normes, je trouve que les
kernels sur TI, c'est nul. Mais je ne défends pas plus la
prog TIGCC, qui est clairement loin d'être du vrai nostub.

Et pour le W3C, je considère qu'ils prennent ce qu'ils marchent
pour l'empêcher de marcher. Si encore ils étaient fichus de
dire comment faire ce qu'on faisait en HTML 4.01 avec du XHTML 1.1.
Mais ils éliminent purement et simplement pleins de choses,
qui sont impossibles à faire désormais en XHTML 1.1.
Je m'y adapte mais je ne vois pas ça d'un bon oeil, d'autant
plus qu'il est vital d'apprendre le CSS, moi qui ait commencé sur
du HTML 4 simple. Pourquoi faire simple quand on peut faire compliqué.

[HS]

snow-tiger :
Entendu. Il faut néanmoins considérer le cas de Kevin.
Imaginons que je parle de quelqu'un ici de la même façon
qu'on parle de Kevin, il semble que ça ne passerait pas.
Donc il faut croire qu'on ferme les yeux facilement quand il s'agit de cogner sur Kevin.

Après un an t'as toujours pas compris que c le même qui ouvre les hostilités...

Quand à la discussion sur les normes, je trouve que les
kernels sur TI, c'est nul. Mais je ne défends pas plus la prog TIGCC, qui est clairement loin d'être du vrai nostub.

Snow-Charvet dans ses grandes heures...

[/HS]

---

Cela dit, est-ce que ce serait possible de désactiver l'ajout de ces "commentaires" quand on fait un nouveau projet sous TIGCC ? Ça me gêne un peu de commencer un prog en appuyant d'abord sur Suppr :]

Uther
: Ils ont juste dit que ça passe relativement bien si on prend ces précaution sur un broswer HTML.

Mais si tu avais lu mon lien, tu verras que c'est un hack qui consiste à donner à bouffer du HTML incorrect (du XHTML correct, ou alors même pas!) aux navigateurs.

Ceux qui utilisent cette balise n'ont probablement jamais lu et ne liront jamais la spécification HTML.

J'utilise la balise <FONT> et j'ai regardé au moins suffisamment bien pour savoir qu'elle est "deprecated"...

snow-tiger :
Je m'y adapte mais je ne vois pas ça d'un bon oeil, d'autant
plus qu'il est vital d'apprendre le CSS, moi qui ait commencé sur du HTML 4 simple. Pourquoi faire simple quand on peut faire compliqué.

Rien ne t'oblige à passer au XHTML, je reste au HTML 4.01, moi (en fait du HTML 3.2 + frames), et stallman.org est écrit carrément en HTML 2.0 et marche aussi.

naPO
: Cela dit, est-ce que ce serait possible de désactiver l'ajout de ces "commentaires" quand on fait un nouveau projet sous TIGCC ?

Non.

Ça me gêne un peu de commencer un prog en appuyant d'abord sur Suppr :]

Alors utilise-les.

stallman.org:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

nabo >
*Après un an t'as toujours pas compris que c le même qui ouvre les hostilités...*
Je parlais des hostilités visant Kevin, que je n'ai jamais provoqué.
Nettoie tes têtes de lecture.

T'étais prévenu, et si en plus tu ignores mes mini messages je ne peux rien pour toi.
Je t'inviterai si tu as quelquechose d'intéressant à dire, dans ce cas, envoie moi un mini message.

Incident clos.

perso, ce que je reproche vraiment, c'est la taille des données 16o de signature, numéro de révisions sur un longword... complètement inutile

[semi-off-topic]
Il est prévu d'implémenter le format de commentaires AMS native dans TICT-Explorer (téléchargez le fichier dans le topic approprié de Custom Beta Tests sur le forum de TIGCC/TICT).
Le problème est de trouver le temps pour le faire. J'avais demandé à Matthieu si je pouvais voir comment il avait fait, pour éventuellement pouvoir le réutiliser. Ca n'est pas la première fois que nous ferions ce type de trucs (CS et tthdex ont été développés plus ou moins en parallèle pendant un moment, nous avons échangé des infos), et il n'y a pas tellement de concurrence entre nos shells. Je ne sais plus où ça en est.
[/semi-off-topic]

16, ou 10, octets de signature (en fait, tu comptes les branchements dedans, ou pas) ?

On n'a a priori (je ne l'ai pas vu dans une lecture rapide) pas encore discuté de mettre ça dans les PPG: bonne idée ou pas (ça dépendra du niveau d'intégration à TIGCC) ?

j'ai isolé le code pour récupérer un attribut, mais faut que je le nettoie un peu

si c'est fait proprement (i.e. juste parès les données compressées), je trouve que c'est une bonne idée. 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)

Flanker :
bah le pb, c'est qu'une fois tu es entré dans le var-link, tu perds complètement le contrôle, comme dans un programme standard. On peut afficher des infos uniquement pour les types OTH (j'avais fait une petite app flash en RAM qui affichait le type et la taille d'origine des fichiers .ZIP)

Si c'est faisable, j'ai deja vu une app flash afficher le contenu de ces fichier perso (pas un format standard) dans le F6 du var-link, donc doit bien y avoir un moyen...

Godzil> J'aimerais bien que tu dises en quoi tu trouves le standard actuel trop restrictif, et que tu indiques quelle a ta source d'inspiration pour ta super idée révolutionnaire, loin des jouets actuels...

J'aimerai aussi savoir ce que tu trouve trop restrictif dans le format actuel qui me semble assez efficace et évolutif pour le moment(pas forcement de nous dire ce que tu prévois).

Deja, combien de fois il faudra que je repete que mon projet n'a RIEN a voir avec ce truc

Ce que je trouve restricitf ?
-> 'l'authorité" qui en est en charge
-> ce qui induit qu'on peut pas en faire ce qu'on veux
-> fait que pour mettre des petites choses
-> pas pratique a utiliser dans le programme en lui meme

et le but de ce topic n'est PAS de parler de mon projet (dont j'avais deja un peu parlé il ya longtemps)

Mais si tu avais lu mon lien, tu verras que c'est un hack qui consiste à donner à bouffer du HTML incorrect (du XHTML correct, ou alors même pas!) aux navigateurs.

Je sais c'est même ce que j'ai dis quelque posts au dessus, tu tient vraiment a avoir le dernier mot.

J'utilise la balise <FONT> et j'ai regardé au moins suffisamment bien pour savoir qu'elle est "deprecated"...

Je voulais dire la très grande maojorité. Après tu est libre de faire ce que tu veux

snow-tiger :
Je m'y adapte mais je ne vois pas ça d'un bon oeil, d'autant plus qu'il est vital d'apprendre le CSS, moi qui ait commencé sur du HTML 4 simple. Pourquoi faire simple quand on peut faire compliqué.

Rien ne t'oblige à passer au XHTML, je reste au HTML 4.01, moi (en fait du HTML 3.2 + frames), et stallman.org est écrit carrément en HTML 2.0 et marche aussi.

tu peux très bien rester au HTML(noatment pour un site perso) surtout si tu n'utilise pas CSS. HTML n'est pas près de disparaitre. Cependant, si tu te met sérieusement à la construction de sites, je te conseille vraiment de te mettre au moins au CSS. Quand on en prends l'habitude c'est vraiment pratique.

naPO :
Cela dit, est-ce que ce serait possible de désactiver l'ajout de ces "commentaires" quand on fait un nouveau projet sous TIGCC ?

Non.

d'accord Je pense que c'est pas trop mal de rapeller que les metadonnées nostub existent. elle ne sont pas assez employées à mon avis(quoique c'est un peu de ma faute, il faudrait que je me dépèche à sortir TIM )
Et puis rien ne t'oblige à utilise TIGCCIDE
Et puis ca demanderait de refaire la boite de dialogue qui a été supprimé(enfin je croi ça fait un moment que j'ai plus utilisé l'IDE) donc une boite de dialogue vs la touche suppr, je choisis la touche suppr

perso, ce que je reproche vraiment, c'est la taille des données 16o de signature, numéro de révisions sur un longword... complètement inutile

Certes mais ce n'est tout de même pas dramatique à mon avis.

Heu franchement obliger le programmeur a avoir une feature dont il veux pas je deteste ce genre de politique un Wizard bien fait a la création du projet est 100% meilleur que devoir aller dans une boite de dialogue de merde pour parametre le projet avec des nom barbares ou il faut chercher dans la doc pendant 30min pour en comprendre le sens

Bref tigccide suit une evolution a l'envers (du pratique vers l'impratique) mais bon c'est pas le sujet ici

<HS>

Kevin Kofler :
C'est pour ça que Backgammon est en 7 niveaux de gris.

J'oubliais que Backgammon était en effet un jeu qui peut sans problème se mesurer aux créations actuelles... (</SARCASM>, puisque c'est toi je précise )

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 ? Ça ne regarde que lui
(je sors volontairement du contexte précis du topic où Godzil veut, il me semble, remplacer le standard existant : je parle uniquement de la liberté de l'ignorer totalement)
</HS>

Sinon je suis assez d'accord avec naPO, ça serait pas mal de pouvoir ne pas les utiliser et donc ne pas avoir à les effacer en début de création d'un projet (que ceux à qui ça ne convient pas, d'après ce topic il y en a quelques uns, ne soient pas genés)

(je sors volontairement du contexte précis du topic où Godzil veut, il me semble, remplacer le standard existant : je parle uniquement de la liberté de l'ignorer totalement)

Non, NON et NON !!!

bon sang

de tte maniere ces metadonnée me servent (et je trouve qu'elle en servent) a rien donc je vois pas l'utilité de faire qq chose uniquement pour remplacer ça, mon projet a un autre but completement différent, meme si dans un sens certaines choses pourrait se ressembler

PpHd :
stallman.org:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

Il a changé ça très récemment alors, il n'y a pas longtemps, c'était du HTML 2.0...
Mais ça reste du HTML, pas XHTML.
(En revanche, www.gnu.org utilise du XHTML.)

Bah évidemment, si le site était conçu à la base en HTML, c'est pas forcément la peine de tout convertir... Mais je ne vois pas en quoi ça prouve que XHTML/CSS est Mal, ou qu'il fragmente la communauté ? (sachant que c'est qd même bcp plus flexible, et que pour faire un site à partir de rien c'est une meilleure solution)

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).

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.

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.)

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

Donc c'est bien par pur esprit de contradiction.

-> ce qui induit qu'on peut pas en faire ce qu'on veux -> fait que pour mettre des petites choses

N'importe quoi. Tu me demandes une plage de numéros (dans la plage réservée pour les applications), je te l'assigne, et tu peux en faire pratiquement ce que tu veux: tu mets le pointeur (relatif au début du fichier) dans le header conformément au format, et après ta structure de données vers laquelle il pointe peut contenir absolument ce que tu veux, il n'y a aucune limitation (à part le fait que ce ne serait pas malin de mettre dans ta structure privée des informations qui sont déjà dans le header commun).

-> pas pratique a utiliser dans le programme en lui meme

Si:
* Rien ne t'empêche d'accéder à _nostub_data__1234 comme à n'importe quel autre label.
* Tu peux même lire les exports exactement de la même manière de laquelle un shell les lirait (même plus facilement parce que tu n'es pas obligé de chercher le fichier), en te servant de __ld_entry_point qui te donne un pointeur vers le début du fichier.
On voit que tu ne connais pas du tout le fonctionnement du linker de TIGCC.

et le but de ce topic n'est PAS de parler de mon projet (dont j'avais deja un peu parlé il ya longtemps)

Euh si, parce que c'est bien ton projet qui a déchaîné la discussion qui était hors sujet dans l'autre topic!

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.

un Wizard bien fait a la création du projet est 100% meilleur que devoir aller dans une boite de dialogue de merde pour parametre le projet avec des nom barbares ou il faut chercher dans la doc pendant 30min pour en comprendre le sens

N'importe quoi, les noms des options dans la nouvelle boîte de dialogue sont les mêmes que celles dans l'ancien wizard.

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.

Sinon je suis assez d'accord avec naPO, ça serait pas mal de pouvoir ne pas les utiliser et donc ne pas avoir à les effacer en début de création d'un projet (que ceux à qui ça ne convient pas, d'après ce topic il y en a quelques uns, ne soient pas genés)

Bah non, on veut vous encourager à utiliser ce feature. Quand l'anticrash de Iceberg 2.00 fera planter ou boguer vos programmes parce que vous n'avez pas mis les flags d'incompatibilité qu'il faut, ce sera trop tard.

ba si stallman est l'homme a suivre, qui a toujorus raison, tu le savait pas ????

Kevin Kofler
: 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.

He bien l'utilisateur il vire le shell en question et il va en d/l un autre... Programmation amateur (et bénevole, dans ce cas), aucune exigence à avoir de la part des utilisateurs ou de qui que ce soit d'autre, c'est à prendre ou à laisser.

Vertyos
:

Kevin Kofler
: 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.

He bien l'utilisateur il vire le shell en question et il va en d/l un autre...

Ah, parce qu'en plus tu donnes la faute au shell pour une incompatibilité causée par le programme!?! Super... Tu ne fais que prouver à quel point j'ai raison: ça emm*rde tout le monde à part le programmeur qui s'en fout du standard, et c'est ça qui me fait ch**r le plus avec cette attitude.

Si on pense comme toi, les shells vont vite faire 200 KO ou plus parce qu'ils devraient d'après toi s'amuser à implémenter un standard de commentaires pour chaque programme. Tu verras vite que ce n'est pas réalisable! Les programmes sont bien obligés de se plier aux exigences des shells! (Mais l'inverse aussi, c'est pour ça qu'il y a un standard.)

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).

Ce qui ne prouve pas non plus que 16 octets est la taille optimale...

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.

Tu comptes faire plus de 65536 révisions du standard ?

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.)

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 ^^

-> pas pratique a utiliser dans le programme en lui meme

Si:
* Rien ne t'empêche d'accéder à _nostub_data__1234 comme à n'importe quel autre label.
* Tu peux même lire les exports exactement de la même manière de laquelle un shell les lirait (même plus facilement parce que tu n'es pas obligé de chercher le fichier), en te servant de __ld_entry_point qui te donne un pointeur vers le début du fichier. On voit que tu ne connais pas du tout le fonctionnement du linker de TIGCC.

Je précise tout de suite que ce genre de hack ne fonctionnera pas avec les programmes auto-extractibles de GTC, puisque le format ne fera pas la bêtise de mettre les infos en double ^^ (et en plus ça ne demande aucun support dans le shell à part le support pour les programmes _nostub "normaux")

Sinon je suis assez d'accord avec naPO, ça serait pas mal de pouvoir ne pas les utiliser et donc ne pas avoir à les effacer en début de création d'un projet (que ceux à qui ça ne convient pas, d'après ce topic il y en a quelques uns, ne soient pas genés)

Bah non, on veut vous encourager à utiliser ce feature. Quand l'anticrash de Iceberg 2.00 fera planter ou boguer vos programmes parce que vous n'avez pas mis les flags d'incompatibilité qu'il faut, ce sera trop tard.

Tu mets ces flags en opt-in ?

Kevin Kofler
:

Vertyos
:

Kevin Kofler
: 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.

He bien l'utilisateur il vire le shell en question et il va en d/l un autre...

Ah, parce qu'en plus tu donnes la faute au shell pour une incompatibilité causée par le programme!?! Super... Tu ne fais que prouver à quel point j'ai raison: ça emm*rde tout le monde à part le programmeur qui s'en fout du standard, et c'est ça qui me fait ch**r le plus avec cette attitude.

Si on pense comme toi, les shells vont vite faire 200 KO ou plus parce qu'ils devraient d'après toi s'amuser à implémenter un standard de commentaires pour chaque programme. Tu verras vite que ce n'est pas réalisable! Les programmes sont bien obligés de se plier aux exigences des shells! (Mais l'inverse aussi, c'est pour ça qu'il y a un standard.)

Ta phrase était ambiguë, et Vertyos a dû la comprendre comme "un shell non-standard©" et pas comme "un programme non-standard©" ^^

Pollux :
Tu comptes faire plus de 65536 révisions du standard ?

On ne sait jamais, et puis un numéro parlant comme 1.0.0.0 est bien mieux qu'un serial comme 0x0004.

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).

Je précise tout de suite que ce genre de hack ne fonctionnera pas avec les programmes auto-extractibles de GTC,

Ce n'est pas un hack, c'est un feature documenté. Si ton compresseur s'amuse à éditer le binaire, il est bogué. Et en plus, je veux bien voir comment tu vires un commentaire du fichier principal sachant que le header de commentaires ne contient qu'un pointeur, que le vrai commentaire peut être n'importe où dans le fichier, et qu'il peut y avoir des sauts PC-relatifs par dessus le commentaire.

Bah non, on veut vous encourager à utiliser ce feature. Quand l'anticrash de Iceberg 2.00 fera planter ou boguer vos programmes parce que vous n'avez pas mis les flags d'incompatibilité qu'il faut, ce sera trop tard.

Tu mets ces flags en opt-in ?

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.)

Mais attention, tout ceci n'est qu'une idée de projet, je n'ai pas encore écrit une seule ligne de code pour cet anticrash!

Kevin Kofler
:

Pollux :
Tu comptes faire plus de 65536 révisions du standard ?

On ne sait jamais, et puis un numéro parlant comme 1.0.0.0 est bien mieux qu'un serial comme 0x0004.

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

Rappelle-moi, y en a eu combien pour l'instant ?

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 ?

Je précise tout de suite que ce genre de hack ne fonctionnera pas avec les programmes auto-extractibles de GTC,

Ce n'est pas un hack, c'est un feature documenté. Si ton compresseur s'amuse à éditer le binaire, il est bogué. Et en plus, je veux bien voir comment tu vires un commentaire du fichier principal sachant que le header de commentaires ne contient qu'un pointeur, que le vrai commentaire peut être n'importe où dans le fichier, et qu'il peut y avoir des sauts PC-relatifs par dessus le commentaire.

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...) Je vois pas pkoi j'autoriserais le nom du programme à être n'importe où dans le fichier si ça empêche de compresser le programme ou si ça aboutit à un prog plus gros ?

Mais après si certains programmes veulent absolument faire ça eux-mêmes en bas niveau, il faut pas s'étonner qu'ils doivent être portés à la main sachant que le système de linking n'est pas du tout le même dans GTC...

Pollux :
Ta phrase était ambiguë, et Vertyos a dû la comprendre comme "un shell non-standard©" et pas comme "un programme non-standard©" ^^

Oui...