euh... on est pas non plus sur des progs open-source ou le moindre petit changement autorise à changer le numéro de la 4é décimel du deuxième chiffre de la centainePourquoi pas c'est juste qu'on en a pas encore eu l'ocasion pour certais progs qui ont eu de nombreuse release comme Total Desctruction, ca aurait été bien utile.
bah... même en numérique ça suffis. Vous allez pas me dire que faire un name&" V"&num1&"."&num2&" beta "&"num3"&" RC"&num4&" by"&auteur en C n'est pas possibleCertes mais comme je l'ai dis plus haut tu as le choix d'utilser ce qui t'arranges te plus ou les deux ou meme pas du tout. Personellemnt, je trouve que le deux sont utiles
Donc le champs version en caractère est inutils.
Et enfin, dernière question: pourquoi t'obstines-tu à argumenter sur ce sujet malgré le fait que le numéro de version lettré est déjà fixé dans la spécification et qu'il ne sera certainement pas supprimé, quels que soient les arguments proposés?
Kevin Kofler a écrit :
Non, mais j'en ai marre de voir des gens flooder tous les topics avec leur pub pour cette merde!!!
) de cette chaîne en repérant les chiffres.
> PreOS ameliore la stabilite du systeme par son anticrash. KerNO aussi.
)
tigcc.a fait au moins 46 KO (46 KO sur TIGCC 0.94 Beta 20). "tigcclib.xxz" peut-elle donc vraiment faire 11 KO ?
Uther Lightbringer a écrit :
Certes mais comme je l'ai dis plus haut tu as le choix d'utilser ce qui t'arranges te plus ou les deux ou meme pas du tout. Personellemnt, je trouve que le deux sont utiles et dans mon shell j'afficherai la chaine de caratère en priorité et si elle n'y est pas la série de chiffre. et dans les détails des fichiers, les 2 versions.
Personellement je trouve se standard très bien fait. Le seul truc qui me chiffone dans ce format c'est le problème des Icones N&B que j'ai cité plus haut.
Et bien oui dans ce forum on a été mis devant le fait accompli un débat aurait été plus utile avant.
nEUrOne a écrit :
L'hopital qui se fout de la charité
Thibaut a écrit :
Réponse à la question #89 :
Pourquoi s'obstine-ton à argumenter sur ce sujet malgré le fait que the Kernel Killer impose ses idées qui ne seront certainement pas changées, parcequ'il est trop borné ?
Alors disons que la version en chaîne suffit. Un petite fonction permettrait d'extraire un numéro numérique () de cette chaîne en repérant les chiffres.
godzil
a écrit : de toute facon (et heureusement !) aucun de ses champ n'est obligatoire, mais je voudrait rappeler un truc, maintenant qu'on se met a ajouter des choses qui ne sont pas dans le format natif, si precieux a certain, on a plus affaire a du nostub !!! mais bien un programme avec un stub...
MacIntoc
a écrit : 1°)pasque c débile de faire ça sur TI, les progs n'évolus pas autant que dans le monde des PC.
2°)J'ai répondu à la question. Plutot que de faire sa norme de version chacun dans son coin, il aurait mieux fallu définir une norme global. Comme ça, se serait plus la peine de se faire chier à savoir comment fonctionne tel numéro de version.
3°)Microsoft à sa propre norme de version. Il faudrait faire de même sur les TI.
).
4°)sans commentaire...
Si tu veux que je réponde quelque chose, il faut dire quelque chose.
5°)pasque vous comptez pas faire évoluer cette norme ????
PpHd a écrit :
>Kevin: Là, c'est une question philosophique: "Doit-on tolérer l'intolérance?" Le format kernel est intolérant parce qu'il discrimine envers les utilisateurs qui ne veulent pas installer de kernel pour des raisons de stabilité du système, de consommation de RAM et d'archive etc. Mais dans ce cas, on doit taxer TOUT d'intolerant mon cher. Meme le _nostub qui ne veut pas s'executer sur Pc directement. Il faut installer un emulateur. Et si l'utilisateur ne veut pas. C'est nul ton argument.
>stabilité du système Faux. PreOS ameliore la stabilite du systeme par son anticrash.
>de consommation de RAM Petite consommation. Que l'on peut enlever apres usage !
>et d'archive etc. Ca fait partie du programme. Ou est le probleme ?
Kevin Kofler a écrit :
Pourquoi pas?
Il est complètement irréaliste pour un standard comme le nôtre de vouloir imposer des systèmes de numéros de version aux projets.
Nous ne sommes pas M$ (quoiqu'en dise Thibaut
Idem.Si tu veux que je réponde quelque chose, il faut dire quelque chose.
Oui, mais pas de manière incompatible. Et la suppression d'un champ est un changement incompatible, donc hors de question. On peut rajouter des champs s'ils sont vraiment utiles, mais pas les supprimer.
), mais à part ça...MacIntoc
a écrit : pasque les prog sur TI ne sont pas aussi complex que sur PC, à quelques trés rare exeption prés (pour ne pas dire que ça existe pas).
>Il est complètement irréaliste pour un standard comme le nôtre de vouloir imposer des systèmes de numéros de version aux projets. pkoi donc ???
ça empèche pas de reprendre certaine de leur bonne idée
bah... une évolution ajoute de bonne idées, comme elle peut enlever les mauvaises...
Non, on ne peut pas enlever des extensions déjà définies.
Je ne vois pas où est le problème si tu affiches le plan principal de l'icône en gris en absence d'une icône en N&B. Et d'ailleurs, il suffit d'utiliser DrawDEBWIcon qui s'occupera de tout ça pour toi.
Il fallait lire le topic sur Einstein...
Je ne floode pas tous les topics avec de la publicité hors-sujet, moi.
C'est un header (entête), pas un stub. Un stub est un morceau de code qui appelle un TSR ou une DLL en dehors du programme, et c'est ce TSR ou cette DLL qui exécute réellement le programme "stubbé". Mon header n'a rien à voir avec un stub. De la même manière, le code de tipatch.lib est du startup code (code de démarrage), pas un stub.Enfin ca donne quand meme que le programme que l'on a écris ne corespond plus exactement celui qui est (assemblé/compilé), ce qui était un réel avantage du nostub.
Donc on s'amuse à installer et désinstaller le kernel en pemanence? Je faisais ça au début (des temps de DoorsOS), mais ça m'a vite lassé.C'est quoi vraiment l'intéret de s'embéter autant pour 3 Ko! Mais mon uninstall s'appelle RESET
Uther Lightbringer
a écrit : Donc comme je te l'ai déja dis le résultat risque d'etre vraiment pas beau
C'est pire c'est de la pub anti-sujet que tu fait
Enfin ca donne quand meme que le programme que l'on a écris ne corespond plus exactement celui qui est (assemblé/compilé), ce qui était un réel avantage du nostub.
C'est quoi vraiment l'intéret de s'embéter autant pour 3 Ko! Mais mon uninstall s'appelle RESET
Pour le reste je comprend vraiment pas ce qui vous chifonne dans ces num de version, On utilise ce qu'on a envie et y'en a pour tout le monde: je vois pas oou est le pb
).
MacIntoc a écrit :
perte de place flagrante
mouais... mais faut pas que ça deviennent exeptionnelle au point de devenir inutils, limite qui est franchis ici.(je reprend ou on en était
et puis, c pas de l'autoritarisme, c de la normalisation.
donc vous préférez trainer les boulets plutot que de les supprimer (comme microsoft avec DOS)
IroS
a écrit : Kevin Kofler>Donc pour utiliser tout ça il faut juste définir des char _comment[], char _program_name[], char _version_string[] et inclure dataext.h?
Le voilà:
This is the library and header file patch for (TI)GCC C programs. To apply this
patch using GNU patch, copy patches.txt to your TIGCC directory, "cd" to it and
use:
patch -p1 <patches.txt
This should work with both the Windows and the Linux/Unix version of TIGCC.
After applying this patch, TIGCC will automatically create an extension header
when one or more of the following reserved symbols are defined in your main
source file: _comment, _program_name, _version_string, _version_number,
_bw_icon, _grayscale_icon, _incompat_flags.
Their data types should be:
_comment: char []
_program_name: char []
_version_string: char []
_version_number: one of the following:
* VERSION_NUMBER as defined in dataext.h
* unsigned long
* the following structure:
struct {
unsigned char major;
unsigned char minor;
unsigned char revision;
unsigned char subrev;
} __attribute__((aligned(2)))
_bw_icon: ICON or short [16]
_grayscale_icon: ICON [2], short [2][16] or short [32]
_incompat_flags: INCOMPAT_FLAGS as defined in dataext.h or unsigned long
See the sample program for an example of each of those extensions.
Kevin Kofler