Kernel vs Nostub? - Page 19

Héhé le Kernel est donc vainqueur
Mais bon... Faut trouver quelquechose pour relancer là, ce serait dommage de s'arrêter en si bon chemin pour doubler la taille de la BDD

voué, mais continue sur ton avance, il va capituler a force

PpHd, raconte nous l'histoire des librairies statiques et de la DLL

Mes pauvres amis, les DLL _nostub c'est de la merde. Qui aimerait manger une telle chose ! Ca n'a pas la bonne saveur subtile du terroir kernel. C'est intrinsequement limite à plusieurs couches sans aucun lien entre elles, dont les auteurs avaient esperes que ca donnerait une saveur indefinissable. C'est bien une saveur indefinissable : bon pour la poubelle Tandis que la cuisine kernel est si subitle, si pleine de compromis judicieux, que, pardonnez moi l'expression, mes babines en frissonnent rien que d'y penser.

Quel bel hommage a notre cher ami disparu récement ... (bon, j'ai pas trouvé l'oiseau ... mais la vonlonté y était !)

(javais pas vu la deuxième page)

La 19^ème plutôt.

lol, ben KK, aucune remarque sur la jolie histoire de père PpHd ?

nEUrOne a écrit :
lol, ben KK, aucune remarque sur la jolie histoire de père PpHd ?

Il ne réponds plus, ça veut ptêt dire qu'il est d'accord que le kernel mode est le meilleur...

(là encore c'est pour relancer le débat)

Il le sait très bien mais il est trop fier pour admettre son erreur première

vince
a écrit : Il ne réponds plus, ça veut ptêt dire qu'il est d'accord que le kernel mode est le meilleur...

Non, c'est que j'ai autre chose à faire que de répondre à toutes les c*nneries postées par les pro-kernel.

C'est pas très sympa comme réponse ça

défense de merde pour une personne qui n'arrive plus à définir le nauhstubbe

Kevin Kofler a écrit :
Non, c'est que j'ai autre chose à faire que de répondre à toutes les c*nneries postées par les pro-kernel.

Note je suis pro rien du tout, je suis pro-FARGO I à la rigueur...

Moi pro Fargo II avec à la rigueur modules de compat 1.0 et 2.0

> défense de merde pour une personne qui n'arrive plus à définir le nauhstubbe
"Argument" de merde donné par quelqu'un qui est incompétent et en programmation et en débat kernel/_nostub, qui fait chier beaucoup de monde, particulièrement Kevin et moi...

Mais pourquoi tant de haine et de violence verbale?

Bon, vu que je m'ennuie:

Uther Lightbringer a écrit :
>Pourquoi le faire signer par TI ? Pas besoin Tu est sérieux? Si tu arrivais a faire ca ca serait vraiment énorme!

Ça m'étonnerait...

>>>Le standard de commentaires _nostub est plus propre et mieux défini que le "standard" imposé par l'usage des kernels.
>>Je vois pas en quoi ca peut etre plus propre et mieux definis.
>En tout cas, la spec du standard de commentaires _nostub est probablement plus claire et mieux définie que les super specs de certains trucs du kernel (au hasard, les RAM_CALLs de fonts)... Je ne comprend pas un mot de vos arguments, les commentaires sont très bien définis et je ne vois vraiment pas au est le problème de RAM_CALLS de font

* problème de compatibilité avec des émulateurs
* problème potentiel de compatibilité avec les versions futures du boot code
* algorithme de recherche extrêmement stupide (on cherche un certain long dans la ROM entière)
* utilise des fontes potentiellement différentes de celles utilisées par AMS

XDanger a écrit :
> les commentaires sont très bien définis Le format de commentaires kernel ? Je ne suis vraiment pas un expert de ce sujet, mais je ne pense pas qu'il soit aussi bien défini que le format de commentaires _nostub. D'autre part: ce format de commentaires kernel, résulte-t-il d'une consultation publique (comme cela a été fait pour le format de commentaires _nostub), ou est-ce un "standard" défini par quelques programmeurs et par l'usage ?

La deuxième solution. Le format kernel a été spécifié de manière autoritaire.

godzil
a écrit : TIGCC IDE est le pire des IDE que la terre est pu porter !

Argument très constructif...

Il extiste des 10zaine d'IDE bcp plus souple, leger, et utilisable ! (Un bon exemple, mais pas pour la "légéreté" : Jext)

S'il y a qqch. qui te dérange dans TIGCC IDE, donne-nous des critiques concrètes. Parce que là, il n'y a rien de concret.

Un truc a propos de ses stupide comparaison avec le DOS, si on veux vraiment comparer avec le DOS, le nostub = appli dos standard, un prog kernel = Appli DOS avec un DosExtender!

Sauf que le "DOS Extender" apporte de vraies fonctionnalités (mode 32 bit).

Sinon mon chti point de vus, je croit que je vais adopter le kernel pour tt se qui est programe "normale" mais pour certain program spécifique demandant de toucher directemetn a la TI, le nostub prime.

Et le raisonnement derrière? Le _nostub convient pour tous types de programmes!

Uther Lightbringer
a écrit : Je ne comprend pas vraiment pourquoi la TIGCC s'embète a faire une IDE(même sous Linux) alors qu'il existe plein d'éditeurs qui au déja fait leur preuves.

Sebastian n'était pas au courant de tous ces éditeurs quand il a commencé TIGCC IDE. Maintenant, TIGCC IDE existe, fonctionne très bien et est ce qu'il y a de plus adapté pour développer sous TIGCC, donc pourquoi l'arrêter? De plus, TIGCC IDE est sous licence GPL. Et quand on ajoutera le débogage à TIGCC, ça sera très probablement avec TIGCC IDE uniquement.

Ceci dit tu y va un peu fort TIGCC IDE n'est pas mauvais, mais il y a mieux!

Quoi par exemple. Et ne me dis pas Emacs. Emacs:
* n'est pas un IDE
* est très difficile à utiliser
* comme tout éditeur généraliste, est très loin d'offrir l'intégration offerte par TIGCC IDE.

nEUrOne
a écrit : ConText + batch power ... pis au moins ca bug pas et c pas lourd

C'est moins pratique que TIGCC IDE.

solid a écrit :
beuh, moi g context et pourtant j'utilise l'ide

Enfin des mots encourageants.

Pen^2 a écrit :
ben je sais pas moi, je ne passe pas mon temps à lire ce topic, je suis tombé sur ton post c tout

On ne répond pas à un message sans lire le contexte.

Ximoon a écrit :
>Mais, moi, j'ai des arguments. Avec la méthode de PpHd, tu affiches tout l'écran à chaque frame. Avec la mienne, tu scrolles (ce qui va plus vite que de tout réafficher, il y a beaucoup moins de calculs à faire) et tu affiches une seule rangée de sprites.
franchement je ne pense pas qu'en pratique ce soit réellement plus rapide

Pourquoi? Il y a beaucoup moins de calculs à faire.

>LOL, je ne te conseille pas de faire tes jeux en ASCII art! Ce que je te conseille, c'est juste de ne pas abuser de graphismes. C'est très différent.
>Et donne-moi un exemple de jeu rapide qui ne plante pas et qui ne remplit pas la mémoire archive entière, pas CF ou SMA.

Fernando

Bon, d'accord, mais ses graphismes sont affreux (personnages composés surtout de lignes et de cercles). Et en plus, c'est en grande partie du blanc&noir.

>Bon sang, encore un qui n'a pas compris que le nom de la partie correspond au kernel qui a inventé le format, pas au kernel qui est actuellement le moins pire. Et pourtant, je l'ai déjà expliqué plein de fois sur ce forum.
Et on t'a déjà dit pourquoi on trouvait ça stupide.

Ce n'est pas une raison de faire semblant de ne pas avoir compris le critère. Et je ne vois pas pourquoi ça serait stupide.

N'empêche que [CF] est certainement le plus gros projet jamais releasé sur TI68k, et que quand on voit certaines news qu'ils ont déjà posté, on est en droit d'attendre que CF ait au moins le droit à être vaguement nommé

S'ils ne l'ont pas posté, c'est qu'ils ne l'ont pas trouvé digne de news. Réessayez à la prochaine release. Michael Vincent semble être disposé à annoncer des bêtas et même des alphas, donc peut-être que ça marchera. Mais je vous avertis, il a l'air d'être un fan de KerNO.

>Et bravo pour avoir multiplié la taille du téléchargement par 5.
>C'est un gaspillage de place et de temps de téléchargement. La version _nostub PPG marche très bien sur toutes les calculatrices, donc les autres sont inutiles.

Dans un programme nostub, les fonctions sont inclues non? dis-toi que c'est un zip nostub avec 5 fois les mêmes fonctions, ça passera mieux

Mais je ne vois vraiment pas l'intérêt de faire 5 versions alors qu'une seule (_nostub PPG) suffit pour couvrir toutes les TI-89/92+/V200.

Nil a écrit :
Ce topic ne sert que deux objectifs : - Indiquer à ceux qui ne savaient pas exactement (comme moi) ce qu'est le mode kernel et ce qu'est le mode _nostub (au fait, pourquoi conserver le "_" devant lorsqu'on en parle de façon normale ? Je trouve que ça fait "bourge de la prog").

Parce que c'est plus correct. Mais tu fais ce que tu veux.

- Peut-être arriver à ce que TIGCC supporte mieux (sic) les programmes kernel.

On les supporte déjà parfaitement. Tout ce qui est possible en _nostub avec TIGCCLIB (à part EXECUTE_IN_GHOST_SPACE et ENABLE_ERROR_RETURN, mais c'est au kernel de s'occuper de tout ça) est aussi possible en mode kernel.

En tous cas, c'est assez instrucitf (surtout qu'il y a deux opinions différentes, donc on peut choisir), sauf les posts de Ti-Mad... Je me demade s'il ne va pas passer en mode X (Ignorer) .

XDanger a écrit :
> défense de merde pour une personne qui n'arrive plus à définir le nauhstubbe "Argument" de merde donné par quelqu'un qui est incompétent et en programmation et en débat kernel/_nostub, qui fait chier beaucoup de monde, particulièrement Kevin et moi...

SURTOUT kevin et toi

PpHd a écrit :
<< Il est vraiment dommage qu'on en soit arrivé là! Le problème "missing libs" est tellement grand qu'on en est arrivé avec PreOs à vouloir copier toutes les librairies dynamiques sur toutes les calculatrices. (Et encore, il existe au moins une douzaine de librairies dynamiques exotiques qui ne sont pas dans stdlib.) Il y a au moins une demi-douzaine des librairies de stdlib qui ont de bonnes chances d'être totalement inutilisées sur la plupart des calculatrices. Si ce n'est pas un gaspillage de place énorme, c'est quoi??? Et pourtant, la vraie solution au problème serait tellement simple: le linkage statique! >>

Mais je n'empeche personne de se faire des collections de libs persos. Perso je ne mets pas tout sur ma calc.

Mais si on ne veut pas avoir des erreurs "missing lib" dès qu'on essaye un nouveau programme/jeu qui utilise des librairies dynamiques, on n'a pas d'autre choix que de mettre stdlib en entier. Alors que les librairies statiques résolvent ce problème une fois pour toutes, et sans la solution barbare, gaspillante et imparfaite (cf. api92, smqlib et autres libs "exotiques") qu'est stdlib.

>LOL, je ne te conseille pas de faire tes jeux en ASCII art! Ce que je te conseille, c'est juste de ne pas abuser de graphismes. C'est très différent.
>Et donne-moi un exemple de jeu rapide qui ne plante pas et qui ne remplit pas la mémoire archive entière, pas CF ou SMA.

Fer3c

Cf. ma réponse à Ximoon un peu plus haut.

>Fonctionnalité qui serait inutile si vous arrêtiez enfin de programmer en le format dépassé (kernel). Donc économie de place (comme déjà dit, KerNO est nettement plus petit, et de plus le _nostub marche aussi très bien sans KerNO).
Sauf que la place est rattrapee rien que pour cc.

Pas sûr. Les tables de relogement se compressent bien. Et puis, CC n'est pas le genre de programme qui se retrouve sur beaucoup de calculatrices, vu qu'il n'est utile qu'aux développeurs qui développent on-calc et acceptent les limitations de CC.

>Un usage raisonnable des graphismes ne veut pas nécessairement dire que c'est moche. Il est beaucoup plus intéressant de chercher à faire quelque chose de beau avec peu d'effets spéciaux.
Oui. Mais utiliser beaucoup d'effets est aussi interressant.

Je ne suis pas d'accord.

>Ne perds pas ton temps à contenter les extrémistes. La version _nostub marche très bien sur les calculatrices avec kernel (alors que l'inverse n'est pas vrai!), donc je ne vois aucun intérêt de faire une version kernel. Si PpHd veut boycotter le _nostub, c'est son problème. Peut-être même que ton jeu le fera changer d'avis.
Non, pas sur la mienne.

Et pourquoi?

C'est une concertation entre PlusShell et DoorsOs, donc les 2 devraient figurer.

Le premier shell avec ce format à être sorti était DoorsOS. Aucun dossier de ticalc.org ne porte le nom de 2 shells/kernels ou plus.

> [1.] CF n'est qu'une bêta.
> [2.] C'est une bêta instable et bourrée de bogues.
> [3.] Elle est en mode kernel.
> [4.] Elle remplit la mémoire archive entière.
1. Ticalc a deja fait des news sur beaucoup de beta.

Mais ce n'est qu'une des 4 raisons.

2. instable: Faux. C'est stable. Ya des bogues, mais c'est stable.

Ça plante parfois, donc c'est instable.

3. Peut etre... 4. Et ?

Un jeu qui remplit la mémoire archive entière a intérêt à valoir ce qu'il prend en mémoire. S'ils jugent que ce n'est pas le cas, c'est une raison de ne pas faire de news.

>Ça reste quand-même un 68k à 10 ou 12 MHz, pas un Athlon à 2 GHz. Il faut s'adapter à cette situation.
Oui. Mais 96 missiles ne necessitent pas un Athlon a 2 Ghz.

Mais ce n'est quand-même pas une solution adaptée à un 68k à 10-12 MHz.

>C'est exactement la même attitude que celle de TI. Et pourtant les pro-kernel gueulent toujours sur TI à cause de ça...
Ben je voudrais qu'ils mettent a jour leur lib. Faut que je les pousse.

C'est exactement cette attitude qui m'énerve. Tu essayes de contraindre les programmeurs à faire tout ce que tu veux. Et après, il y en a (n'est-ce pas Thibaut ) qui nous accusent de faire ce genre d'actions. On n'a jamais mis des messages d'"erreur", voire des désinstallations automatiques, intentionnellement pour forcer les programmeurs à se mettre à jour.

Et je n'ai toujours pas compris pourquoi il est un problème si grand que ça d'avoir une librairie qui a son numéro de version à 0.

Mais le PPG n'est pas concu pour fonctionner en kernel. Le Pack Archive, oui.

Le PPG est conçu pour fonctionner avec n'importe quel programme. Il ne supportait pas le kernel à l'origine parce que ça plantait, mais ce problème-là est règlé depuis longtemps.

Pas forcement. Avec un bon utilitaire de compression, cela ne multiplira que par 2.

Non, au moins par 3. Les packs archive sont compressés avec un algorithme totalement différent que les PPG, donc il n'y aura pas de séquences en commun entre les 2. Et d'ailleurs, les séquences _nostub et kernel sont également assez différentes.

>Si c'est ça qui te fait peur, envoie tes sources à quelqu'un qui reste dans la communauté avant de "disparaître".
>Ou alors, encore mieux: ne disparais pas entièrement. Tu peux arrêter d'écrire de nouveaux programmes, mais continuer quand-même la maintenance de ceux que tu as déjà sortis... C'est juste une question de recompilation normalement.
Normalement.

Si ce n'est pas le cas, c'est qu'il y a un bogue quelque part.

PpHd a écrit :
>Ça répond à la question. Ce que squale92 veut faire, c'est de partager du code entre plusieurs projets, donc je lui dis qu'il ne doit pas utiliser une "DLL _nostub" pour ça, mais une librairie statique.
Une lib dynamique kernel est aussi parfaitement adaptee.

Mais une librairie statique aussi, donc je ne vois pas pourquoi je ne devrais pas lui en parler.

>Et puis on peut avoir un problème supplémentaire avec le mode kernel: vous faites quoi si h220xTSR et HW2Patch ne fonctionnent plus à cause d'une mise à jour matérielle?
Faux. On pourra toujours faire un lanceur kernel.

Et tu fais quoi de tous les shells pour kernel qui utilisent NG_execute pour lancer des programmes en assembleur ou des programmes en BASIC qui font appel à des programmes en assembleur?

>Il n'utilise aucune fonctionnalité du kernel, donc il n'y gagnera strictement rien.
De la place dans son executable.

D'ordre de grandeur totalement négligeable. Les essais de Zeljko et de Patrick Davidson le montrent.

>"Il y aurait gagné en taille" peut-être si tu ne comptes pas la taille du kernel ni celle de genlib, mais certainement pas si tu les comptes! J'ai vraiment marre de cette manière truquée de compter la taille. Ce n'est pas parce que vous (PpHd, toi, ...) cachez des octets dans des fichiers externes qu'il ne faut pas les compter!
Mais on ne les compte qu'une fois parmi tous nos projets.

Et voilà l'erreur. Tu présupposes que tout le monde aura forcément tous ces projets sur sa calculatrice en même temps.

>Ce n'est pas un concept défectueux, c'est le seul moyen de faire un programme _nostub de plus de 64 KO, et c'est exactement pour ce but-là qu'il est prévu.
Et c'est pkoi le terme DLL est inapte !

Non, puisque c'est ce que c'est techniquement.

>>et qui sont apparues alors qu'il existe un concept de lib dynamique reconnu et qui a fait ces preuves sur TI.
>Mais qui nécessite un kernel.
Et alors ?

Ce n'est pas pratique.

Ca marche bien mieux !

Pas pour ce pour quoi les DLLs _nostub sont prévues.

>>en asm la grog kernel est bien plus facile est tout aussi efficace
>Elle n'est pas du tout "bien plus facile". Tu n'as pas l'air d'avoir lu ça.
je l'ai lu, et c'est bien plus simple en kernel.

Alors là pas du tout. En quoi jsr doorsos::toto est-il plus simple que ROM_CALL toto???

<< Compare avec les documentations que j'ai écrites, moi. Celle-là par exemple: http://pub26.ezboard.com/ftichessteamhqfrm3.showMessage?topicID=161.topic. Dans la documentation de PreOs, il y a plein d'abbréviations, de phrases nominales etc. Dans les miennes, il y a des phrases complètes qui expliquent tout en détail. >>

Ok, tu critiques mon niveau d'anglais Desole

Non, ce n'est pas ton niveau d'anglais le problème. Tes documentations en français ne sont pas mieux.

>Comme j'ai déjà dit, ses fonctionnalités ne sont pas tout à fait comparables.
Mais taille GTC << taille GCC

Ça ne change rien au fait que les fonctionnalités ne sont pas tout à fait comparables.

>Non. Ici, c'est l'antre du kernel! Le reste du monde considère les kernels comme dépassés presque unanimément.
t'exageres. Il y a toi par exemple.

Mais j'ai malheureusement l'impression d'être en minorité sur ce forum. Alors que partout ailleurs, la réaction au mot "kernel" est presque toujours "that outdated piece of crap".

>Pas du tout. Je compte exactement 9 instructions (dont seulement 6 différentes) dans mon code. Pour n'importe quel programmeur ayant le minimum d'expérience en assembleur, ça prend au maximum 1 minute d'écrire ça.
Il supporte aussi les Pack Archives en une passe au lieu de 2.

C'est le résultat qui compte. Donc ça revient au même.

>[Parlant du support des streams std* dans les fonctions de fichiers de stdio.h:] Surtout: ça double la taille des programmes qui utilisent ces fonctions.
On veut surtout de la portabilite, pas de la taille lorsqu'on utilise ces fonctions la.

Mais l'ajout minimal à la portabilité vaut-il le coup si ça double la taille? Je ne suis pas de cet avis-là.

>Ça apporte aussi:
> [1.] la coloration syntaxique pour exactement les langages dont tu as besoin (C, A68k, GNU as 68k).
> [2.] la coloration des parenthèses: j'aime beaucoup la manière de laquelle TIGCC IDE colore les parenthèses. Les autres éditeurs que j'ai vus ne font pas ça aussi bien.
> [3.] la possibilité de tester ton fichier sur VTI ou sur une vraie calculatrice avec un seul clic.
> [4.] une interface simple à utiliser, pas alourdie par des fonctions qui ne servent que si on programme sur PC.
...
1. Tous les autres le font.

Non. Je ne connais aucun autre éditeur qui a des règlages spécialisés (séparés) pour A68k et pour GNU as. Sans parler du Quill Adventure Writer de Zeljko Juric, pour lequel je ne connais que TIGCC IDE qui fait la coloration syntaxique.

2. Les autres ont des reconnaisances automatiques de paires.

C'est moins pratique que la méthode de TIGCC IDE.

3. Ca sert a rien

Si, c'est très pratique!

et ca marche pas sur PedroM

Sur VTI, ça marche même avec PedroM. Pour la vraie calculatrice, si ça ne marche pas, c'est que ton gestionnaire du link bogue.

4. C'est lourd.

Il y a quoi qui est lourd? Moi, je ne vois rien de lourd.

Ben je trouve UEdit bien plus simple d'emploi que Tigcc IDE.

Pourquoi? TIGCC IDE est très simple à utiliser!

Et c'est pas de la bidouille.

Si, utiliser un autre éditeur que celui prévu est un bidouillage.

<< Tu [Uther] utilises les RAM_CALLs directement?! Tu devrais utiliser les macros de compat.h! En mode kernel, elles sont automatiquement transformées en RAM_CALLs quand il y a un RAM_CALL correspondant. En _nostub, elles sont implémentées différemment. >>
Et en ASM ?

Mais il programme en C!

Et les ram_calls non supportees en _nostub ?

Ils n'ont aucun intérêt. Il y a des ROM_CALLs qui font la même chose proprement. Et l'usage de ces RAM_CALLs sous TIGCC n'est pas supporté, donc ça pourrait arrêter de fonctionner à tout moment. Ce n'est pas un argument valable pour garder USE_KERNEL. (Il y en a, sinon ça ferait longtemps que ça n'existerait plus, mais celui-là n'en est pas un.)

>[Le système de packs archive] est plus pratique comment??? Oncalc.

Je parle de vraie compression, pas de ziplib.

Et plus flexible.

Pas vraiment. ExePack est plus flexible parce qu'il:
* marche aussi sans kernel
* permet le lancement par plein de manières différentes: lanceur personnalisé, ttstart, AutoStart, TICT Explorer, explorateurs d'auteurs tiers, ...

PpHd a écrit :
>La différence de taille n'est pas si minime que ça, et la différence de temps de décompression est minime. Donc ttpack est bien meilleur.

Ben alors je vais creer une lib dynamique ttpacklib

Tu veux vraiment faire ch**r Thomas de cette manière?
Et je n'ai toujours pas compris pourquoi tu n'as pas intégré ttunpack_decompress à PreOs. Ça aurait rendu le système de packs archive beaucoup plus transparent et amélioré la qualité de la compression.

> * Quel intérêt d'utiliser graphlib? Pratiquement toutes ses fonctions sont déjà dans la ROM!
Plus rapide.

Pas d'une manière qui justifie le gaspillage de place.

> * Pour ziplib, elle compresse tellement mal que si on l'utilise, on gaspille automatiquement pas mal de place.
t'exageres.

Non. ziplib est très loin d'offrir le taux de compression offert par ttpack.

> * Aucun
de ces programmes n'est nécessaire pour faire fonctionner le _nostub! Si tu veux les fonctionnalités qu'ils apportent, mets-les, si tu préfères économiser la place, ne les mets pas.
Et si on veut les utiliser, pourquoi ne pas offrir des programmes optimises pour ?

Parce que les programmes pour kernel ne sont pas des programmes optimisés pour ces fonctionnalités, mais pour des "fonctionnalités" (le format kernel) qui, comme le montrait ma liste de programmes, n'ont aucun rapport.

> * Je ne vois pas ce que vient y faire XtraKeys. Ça n'a aucun rapport avec les fonctionnalités de PreOs.
SHIFT+ON je pense.

XtraKeys ne gère pas [SHIFT]+[ON]. Il doit confondre avec ShortCuts de Samuel Stearley.

>Pas du tout. Un jeu peut très bien être un bon jeu sans utiliser la centaine d'effets graphiques qu'il y a dans genlib! Juste un exemple: TI-Chess.
C'est un jeu d'echec !

Un jeu d'échecs ne peut-il pas être un bon jeu pour toi??? Pour moi, TI-Chess est un excellent jeu. D'ailleurs, je veux te voir coder un jeu d'échecs, toi... Et: non, changer 3 lignes dans TI-Chess ne compte pas. Ton jeu doit être indépendant de TI-Chess pour qu'il soit intéressant.

<< Et puis, si la documentation de genlib était écrite en anglais compréhensible ou en français compréhensible, je l'aurais peut-être comprise plus facilement. Mais là, c'est du jargon illisible... La documentation est probablement le plus grand problème de genlib (mis à part le fait que c'est une librairie dynamique ). >>

Desole. Encore une nouvelle critique de mon anglais. Sniff.

Ton texte en français est tout aussi illisible, donc le problème n'est pas la langue.

>Inconvénients absolument minimes. Surtout par rapport au grand nombre d'inconvénients des librairies dynamiques.

Qui sont ?
Probleme de mise a jour : aucun probleme. Gaspillage de place pour les fonctions supposees inutilisees : faux.

N'essaye pas de nier des problèmes qui sont réels et indéniables. Les librairies dynamiques portent à des conflits de version et gaspillent de la place pour les fonctions inutilisées (qui le sont vraiment, donc le mot "supposées" est mal placé). Et il y a aussi d'autres inconvénients. À titre d'exemple, la nécessité de code spécial pour les reloger en temps d'exécution, alors que les librairies statiques sont relogées lors de l'édition des liens. Un autre exemple d'inconvénient est le fait que l'utilisateur doit s'occuper d'"installer" (copier sur la calculatrice) les librairies dont le programme a besoin alors que pour les librairies statiques, c'est l'éditeur de liens qui fait ça automatiquement.

PpHd a écrit :
>Pas très coopératif. Mais je te comprends, je ne serais pas très content non plus de voir mes routines utilisées dans un concurrent commercial à mon propre projet.
Ben s'ils m'ambauchent, c'est ok.

>Et tu as pensé au nombre de vieilles librairies qu'il y a avec une version 0? smqlib par exemple? Oui, c'est un abus des librairies dynamiques, mais elles y sont quand-même!
Oui.

Alors pourquoi ce système de suppression automatique?

Ca reste vrai. J'ai differencie _nostub pur, et _nostub version booste tigcc avec stub.

Ce n'est pas un stub, c'est du code de démarrage!

>C'est un kernel pour les programmes _nostub. Il apporte les fonctionnalités des kernels sauf le format kernel. C'est peut-être "bâtard", mais quand-même utile pour certains.

Je vois pas comment a part interdire l'install d'un laucnher kernel

Il est utile parce qu'il apporte l'anti-crash et d'autres fonctionnalités utiles, ou du moins que toi, tu juges utiles au point de les inclure à PreOs.

>Tu fais un tableau des possibilités qu'un format offre aux programmeurs. crashlib est une possibilité proposée aux programmeurs _nostub, donc elle a bien sa place dans ton tableau.
Je ne rentre pas en details des librairies offertes !

Tu fais une liste des fonctionnalités utilisables en chaque mode. L'anti-crash avec crashlib est utilisable en _nostub, donc tu devrais le mettre.

>Les DLLs _nostub ne sont pas du tout un truc bâtard.
Ca porte mal son nom.

Ça porte le nom de ce que c'est techniquement.

>Parce que c'est un hack qui ne tient pas en compte la redéfinition des fontes qui est possible sous AMS 2.
Et c'est normal !

En quoi est-ce normal d'utiliser d'autres fontes que AMS???

Uther Lightbringer a écrit :
>[PpHd:] Ben alors je vais creer une lib dynamique ttpacklib
Une très bonne idée

En quoi est-ce une très bonne idée? Presque personne ne l'utilisera, donc le "gain de place" (entre guillemets, parce que ce n'est pas vraiment un gain de place) des librairies dynamiques (dû au partage) est totalement inexistant.

Oui la aussi ca me fait peur Il faudrait que cette option ne soit fonctionelle que pour les lib en double(on suprime la plus ancienne)

Voilà une idée bien meilleure que la suppression barbare de toute librairie portant un numéro de version de 0.

godzil
a écrit : Je croit que tu oublie un cas "pire" (UniOS pour pas le citer) et la a cette epoque tu n'avais rien dit que je sache (pour rappel UniOS possede toutes les libs DIRECTEMENT dans le fichier "kernel"...)

Si, j'ai toujours dit que Universal OS était du bloatware par excellence.
Et puis, Universal OS intégrait moins de librairies que stdlib.

Perso la profusion des libs j'ai jamais trop aimé sa (enfin je rangait sa plutot bien dans un joli ptit rep "Libs" ) mais le coup d'UniOS je trouvait sa plutot lourd, mais perso PreOS a "répondu" a mon apel avec le PackLib
plus de soucis now

Sauf que c'est du gaspillage de place!

PpHd a écrit :
>PpHd, a ce propos, (j'ai pas chercher des masses) il serait pas possible de puovoir ajouter/supprimer d'un PackArchive des fichier directement de la calc ? sa serait
Oui c'est possible. Mais seulement en compressant avec ziplib.

Beurk! Autant dire que ce n'est pas possible.

solid a écrit :
> Il y a plusieurs raisons de ne pas faire de news sur CF:
> [1.] CF n'est qu'une bêta.
> [2.] C'est une bêta instable et bourrée de bogues.
> [3.] Elle est en mode kernel.
> [4.] Elle remplit la mémoire archive entière.
1- 95 % voire plus des jeux ds les archives 68k sont des BETAS

Mais ce n'est qu'une des 4 raisons citées.

2- Elle est aussi stable que Ti-chess, je peux te le garantir : ayant utilisé les 2, g constaté qu'ils ont planté le mm nbre de fois (0),

Chez toi peut-être. Pas chez d'autres.

pour les bogues : on se demande pkoi il y a autant de releases pour les jeux comme TI-Chess huhu... (qui a dit bugs ? )

Il y a eu autant de releases parce qu'ils apportaient des fonctionnalités supplémentaires! Regarde dans l'historique de TI-Chess...

3- Et alors ?

Presque tout le monde est contre les kernels.

le kernel reste le moyen le plus efficace pour ecrire un jeu

Faux.

4- Faux, j'avais encore la place pour mettre SMA

Tu n'as pas dû mettre tous les levels de SMA, toi... Voire même le fichier avec les ennemis...

nEUrOne
a écrit : Que ce soit de la programmation de jeux ou d'apps, il est plus avantageux pour le programmeur de programmer KERNEL mais pas pour l'utilisateur non programmeur

Pourquoi? TIGCCLIB apporte exactement les mêmes fonctionnalités en les 2 modes!

solid
a écrit : sur Ti, pour ecrire un jeu rapide et puissant, le seul moyen c le kernel, je ne pense pas avoir besoin d'argumenter, vous devriez etre d'accord avec moi

Non, je ne suis pas du tout d'accord, donc je suis désolé, tu as besoin d'argumenter.

par contre pour faire des jeux moins orientés rapidité et graphismes, ou pour un utilitaire, nostub est mieux adapté selon moi

Là, tu as raison. Mais il est le mieux adapté aussi pour les jeux "rapides et puissants".

solid a écrit :
pardon, les données viennent de changer en la faveur du kernel pour tous les jeux et utilitaire

XDanger a écrit :
> Tu vas te faire taper dessus, Solid Et ce d'autant plus (pas de façon trop méchante cependant, c'est évident) qu'il donnera moins d'arguments et qu'il utilisera plus de formules du style "vous devriez être d'accord avec moi"... C'est valable aussi pour nEUrOne qui ne donne aucun argument...

En effet.

Il n'y en a que très peu qui sont capables de donner des arguments corrects pour justifier ce que dit Solid. Soit Solid n'en fait pas partie, soit il ne se donne pas la peine de le faire, ce qui est une forme de mépris...

Entièrement d'accord.

Ximoon a écrit :
[...] il est inutile de faire des utilitaires sous Mac et Linux pour particuliers. Et pourquoi traduit-on des films en Français alors qu'après tout cette langue est minoritaire dans le monde

La différence est que les programmes _nostub marchent très bien sur les calculatrices avec kernel. Pourquoi faire un programme pour un ensemble A d'utilisateurs si on peut le faire pour l'union de l'ensemble A avec un autre ensemble B? C'est limiter stupidement la portée du programme!

solid a écrit :
Alors, tu me demandes pkoi le kernel est le plus adapté pour faire des jeux puissants ?
genlib non c vrai, g pas vraiment d'arguments techniquesmais il me semble que l'utilisation de libs dyna rend un jeu plus rapide

C'est faux. L'appel d'une librairie statique est au moins aussi rapide que l'appel d'une librairie dynamique kernel.

et evite les "DLL" [insulte] du nostub

... qui ne sont pas du tout prévues pour cette utilisation-là, mais tu ne l'as toujours pas compris.

>> utilitaire, nostub est mieux adapté selon moi
>[Xdanger:] Rien de ce qui se fait en mode kernel n'est infaisable en _nostub; la réciproque est fausse...

a ton tour d'argument tres cher monsieur parce que je suis pas du tout convaincu

La preuve: le kernel est un programme _nostub.

>> pardon, les données viennent de changer en la faveur du kernel pour tous les jeux et utilitaire
>[Xdanger:] D'une, il n'y a pas d'arguments; de deux, je rappelle encore une fois que le kernel est utilisé par une minorité de gens, il est donc *bête* de faire un utilitaire sous kernel, alors que le but de cet utilitaire est d'être utilisé par un nombre de personnes aussi grand que possible...
tigcclib.9xz

Ce n'est pas un argument. Ça n'apporte aucune fonctionnalité supplémentaire par rapport à tigcc.a. Et tu as complètement ignoré la partie "de deux".

Uther Lightbringer a écrit :
Xdanger a raison puisse qu'en effet un kernel est programmé en nostub En nostub tu peux ecrire un kernel qui te permet de faire tout ce que fait le kernel

Et voilà.
Et on peut faire tout ce que fait le kernel même sans écrivant un kernel.

PpHd a écrit :
>Rien de ce qui se fait en mode kernel n'est infaisable en _nostub; la réciproque est fausse... Rien de ce qui se fait en C n'est infaisable en ASM ; la réciproque est fausse...

C'est faux. Par exemple, le C permet de garder la compatibilité source entre 2 versions d'une librairie beaucoup plus simplement.

Rien de ce qui se fait en C++ n'est infaisable en C ; ...

Donc vive le C!

[ftp83plus]
a écrit : Kevin> chui pas paresseux, mon parti est déjà pris, c tt...

Si tu as pris un parti pour le kernel (et contre le _nostub), et avant d'écouter les arguments en plus, c'est que tu es paresseux. Désolé.


Et voilà, j'ai répondu aux pages 13 et 14. On va voir une autre fois pour le reste.

y s'est lâché là Kévin ! bonne chance à PpHd pour lui répondre !

Désolé Kevin j'ai lu tous les arguments des deux parties en présence et je ne peux pas m'empêcher de préférer le kernel pour tous ses avantages.

Je résume ce qui est important pour moi (du moins)

1- Facilité de mise à jour des programmes.
Si une librairie dynamique est buguée (ça arrive), pas besoin de recompiler tous les programmes l'utilisant pour le coup. Il suffit juste à l'utilisateur de télécharger la lib et de l'envoyer sur sa calc. Tu dis que c'est du travail supplémentaire pour les utilisateurs et je répond faux: pour une lib statique le programmeur doit recompiler son programme (tous les programmeurs doivent recompiler tous leurs programmes) et les utilisateurs doivent également le renvoyer sur leur calc. Il y a donc plus de perte de temps pour la mise à jour des libs statiques.
Je passe outre l'argument de la taille puisque je sais que tu ne seras pas d'accord.

2- stabilité.
Tu peux dire tout ce que tu veux mais les différents systèmes de protections d'un kernels offrent une bien meilleure protection à l'utilisateur dont tu es si soucieux du confort. Les pro-nostub installent 2-3 tsr et quelques patches pour palier à celà, c'est complètement stupide! Ils prennent une partie des avantages du kernel avec plusieurs progs différents et délaissent d'autres avantages majeurs! Décidément y'a une erreur dans le raisonnement là...

3- facilité de programmation.
Tu as beau dire, je trouve toujours un programme kernel plus facile à développer qu'un programme nostub, malgré tous les outils apportés.

4- portabilité.
Mêmes remarques que pour les libs statiques. Il suffit de quelques changements chez ti pour que les programmes nostubs ne marchent plus. Et on n'aura pas toujours la source du prog ou quelqu'un pour sortir un patch général pour corriger tout ça. Le kernel offre la possibilité d'aider à éviter ce genre de problèmes dans certains cas. Maintenant tu vas dire que c'est la faute des programmeurs qui font mal leur boulot, erreur encore une fois: il n'ont aucun engagement envers la communauté, s'ils décident de tout laisser tomber c'est dommage mais ils en sont libres. S'ils avaient voulu faire quelquechose de durable ils auraient choisi la flexibilité.

Et dire tout simplement 'le kernel c'est dépassé car plus personne ne s'en sert' ne changera rien à mon opinion. Ca n'est absolument pas constructif et à la limite de l'hypocrisie.

Dire que 'le nostub est le format natif' non plus. Avec tout ce que vous rajoutez sur votre calc pour transformer ce format en natif, vous utilisez presque des pseudos-kernels modulaires qui se gardent bien de dire leur nom.

Dire ensuite qu'il est normal que ticalc refuse de mettre des programmes en news parcequ'ils sont kernels ou prennent trop de place ou je ne sais quoi est honteux, s'ils avaient un minimum de tolérance ils mettraient des news pour tous les bons programmes (et non, un prog kernel n'est pas un mauvais prog par définition, je te vois venir).

Maintenant je sais que tu vas réfuter mes arguments avec plus ou moins de bonne foi, mais ma position est inflexible.

En fait je suis à peu près d'accord avec ximoon sauf...

Ximoon a écrit :
Désolé Kevin j'ai lu tous les arguments des deux parties en présence et je ne peux pas m'empêcher de préférer le kernel pour tous ses avantages.

Je résume ce qui est important pour moi (du moins)

1- Facilité de mise à jour des programmes.
Si une librairie dynamique est buguée (ça arrive), pas besoin de recompiler tous les programmes l'utilisant pour le coup. Il suffit juste à l'utilisateur de télécharger la lib et de l'envoyer sur sa calc. Tu dis que c'est du travail supplémentaire pour les utilisateurs et je répond faux: pour une lib statique le programmeur doit recompiler son programme (tous les programmeurs doivent recompiler tous leurs programmes) et les utilisateurs doivent également le renvoyer sur leur calc. Il y a donc plus de perte de temps pour la mise à jour des libs statiques.
Je passe outre l'argument de la taille puisque je sais que tu ne seras pas d'accord.

Je pense que tu n'aurais pas du faire l'impasse dessus, même si Kevin n'est pas d'accord, avoir des progs les plus petits possible reste essentiel sur TI le fait d'avoir un programme sans stub ne voudra pas forcément dire qu'il prendra moins de place, la place utilisée par les lib doit aussi être comptabilisée.

2- stabilité.
Tu peux dire tout ce que tu veux mais les différents systèmes de protections d'un kernels offrent une bien meilleure protection à l'utilisateur dont tu es si soucieux du confort. Les pro-nostub installent 2-3 tsr et quelques patches pour palier à celà, c'est complètement stupide! Ils prennent une partie des avantages du kernel avec plusieurs progs différents et délaissent d'autres avantages majeurs! Décidément y'a une erreur dans le raisonnement là...

C'est clair qu'il pourraient reconnaitre «le _nostub c'est bien mais pour l'exploiter à fond, deux trois prog kernel en plus c'est mieux»
Dans la mesure ou les deux modes cohabitent parfaitement sur la même cible, je ne vois pas l'intérêt d'être 100% pro nostub (100% pro kernel non plus d'ailleurs) il faut savoir établir un compromis

3- facilité de programmation.
Tu as beau dire, je trouve toujours un programme kernel plus facile à développer qu'un programme nostub, malgré tous les outils apportés.

Je ne me prononce pas, les quelques programmes que j'ai réalisé l'ont été pour FARGO I et pour Doorsos (la première version, avant l'apparition de plusshell)

4- portabilité.
Mêmes remarques que pour les libs statiques. Il suffit de quelques changements chez ti pour que les programmes nostubs ne marchent plus. Et on n'aura pas toujours la source du prog ou quelqu'un pour sortir un patch général pour corriger tout ça. Le kernel offre la possibilité d'aider à éviter ce genre de problèmes dans certains cas. Maintenant tu vas dire que c'est la faute des programmeurs qui font mal leur boulot, erreur encore une fois: il n'ont aucun engagement envers la communauté, s'ils décident de tout laisser tomber c'est dommage mais ils en sont libres. S'ils avaient voulu faire quelquechose de durable ils auraient choisi la flexibilité.

Je trouve qu'on a eu suffisement d'exemples du genre dans les 6 derniers mois pour savoir que même les meilleurs codeurs peuvent s'arrêter du jour au lendemain...

Et dire tout simplement 'le kernel c'est dépassé car plus personne ne s'en sert' ne changera rien à mon opinion. Ca n'est absolument pas constructif et à la limite de l'hypocrisie.

ça fait en effet un peu "blinkers" à la rigueur nous dire que ça va devenir obsolète parceque vous arrivez à endoctriner les nioobies et que quand les anciens partiront y'aura plus que ça pourquoi pas

Dire que 'le nostub est le format natif' non plus. Avec tout ce que vous rajoutez sur votre calc pour transformer ce format en natif, vous utilisez presque des pseudos-kernels modulaires qui se gardent bien de dire leur nom.

le format natif c'es celui utilisé dans les chaines exec... on pourra interpoler en disant que "natif" est utilisé pour signifier l'ancienneté historique... dans ce cas là, il faut se référer aux écrits de Jimmy Märdel...

Dire ensuite qu'il est normal que ticalc refuse de mettre des programmes en news parcequ'ils sont kernels ou prennent trop de place ou je ne sais quoi est honteux, s'ils avaient un minimum de tolérance ils mettraient des news pour tous les bons programmes (et non, un prog kernel n'est pas un mauvais prog par définition, je te vois venir).

C'est de la discrimination... Ca entre dans ce que pas mal de personne te reprochent : ta "propagande _nostub omniprésente"...

Maintenant je sais que tu vas réfuter mes arguments avec plus ou moins de bonne foi, mais ma position est inflexible.

Bah te fatigue pas à faire deux réponse parceque comme dit en début de post, je partage globalement l'avis de Ximoon

Chouette c'est repartit

Sinon un mot sur ticalc.org : c'est un vieux site, les membres n'ont peut être plus envie de tester tous les programmes qui sortent, d'où le manque de news. Concernant les kernels, ils ont du en rester à l'époque où ceux ci étaient effectivement instables. Et ce n'est pas la propagande des pro-nostub qui va changer ça...

Ah et puis je ne résiste pas à répondre à cette petite réplique de Kevin que je trouve hilarante de mauvaise fois :

> >> utilitaire, nostub est mieux adapté selon moi
>>[Xdanger:] Rien de ce qui se fait en mode kernel n'est infaisable en _nostub; la réciproque est fausse...
>
>a ton tour d'argument tres cher monsieur parce que je suis pas du tout convaincu


La preuve: le kernel est un programme _nostub

Ben moi j'ai un scoop : MS-DOS offre les même possibilités que Linux ! La preuve ? Loadlin est un programme DOS

Sauf que le "DOS Extender" apporte de vraies fonctionnalités (mode 32 bit).

Le kernel aporte aussi de vraies fonctionnalités. Tu ne les trouves pas utilile mais ce n'est pas le cas de tout le monde

Sebastian n'était pas au courant de tous ces éditeurs quand il a commencé TIGCC IDE. Maintenant, TIGCC IDE existe, fonctionne très bien et est ce qu'il y a de plus adapté pour développer sous TIGCC, donc pourquoi l'arrêter? De plus, TIGCC IDE est sous licence GPL. Et quand on ajoutera le débogage à TIGCC, ça sera très probablement avec TIGCC IDE uniquement.

Mais c'est de pire en pire! Pourquoi vouloir interdire une autre IDE que TIGCC-IDE, ca sert a rien et ca emmerde du monde. On dirait que vous faites exprès de vouloir interdire tout ce qui n'est pas programmation exactement comme vous le voulez.

Quoi par exemple. Et ne me dis pas Emacs. Emacs:
* n'est pas un IDE
* est très difficile à utiliser * comme tout éditeur généraliste, est très loin d'offrir l'intégration offerte par TIGCC IDE.

* Emacs n'est pas une vrai IDE mais s'en approche. De plus, il offre des fonctions bien plus avancées que l'IDE
* Je dirais complexe a prendre en main, mais tellement plus efficace quand on sait l'utiliser.
* La seule vraie intégration qu'offre TIGCC-IDE, c'est le lien automatique
Et enfin emacs n'est pas le seul Editeur de texte, si tu n'as pas envie de faire l'effort de l'apprendre, tu peux utiliser UltraEdit, Context, ... qui permettent plus que TIGCC-IDE, pompent moins de ressources et ne ralentissent pas la compilation.

Bon, d'accord, mais ses graphismes sont affreux (personnages composés surtout de lignes et de cercles). Et en plus, c'est en grande partie du blanc&noir.

Moi je trouve au contraire que ces graphismes épurés font son charme, mais bon ca dépends des gouts ca.

S'ils ne l'ont pas posté, c'est qu'ils ne l'ont pas trouvé digne de news. Réessayez à la prochaine release. Michael Vincent semble être disposé à annoncer des bêtas et même des alphas, donc peut-être que ça marchera. Mais je vous avertis, il a l'air d'être un fan de KerNO.

Il faut vraiment être borné pour ne pas reconnaitre les qualités de CF même si on est fan de Kerno

On les supporte déjà parfaitement. Tout ce qui est possible en _nostub avec TIGCCLIB (à part EXECUTE_IN_GHOST_SPACE et ENABLE_ERROR_RETURN, mais c'est au kernel de s'occuper de tout ça) est aussi possible en mode kernel.

Ca serait quand même bien que tigcc gere les plus de PreOS. Mais c'est vrai que vous n'ajouterez plus quoi que ce soit qui avantage le kernel par rapport au nostub, c'est dommage.

Mais si on ne veut pas avoir des erreurs "missing lib" dès qu'on essaye un nouveau programme/jeu qui utilise des librairies dynamiques, on n'a pas d'autre choix que de mettre stdlib en entier. Alors que les librairies statiques résolvent ce problème une fois pour toutes, et sans la solution barbare, gaspillante et imparfaite (cf. api92, smqlib et autres libs "exotiques") qu'est stdlib.

Je considère ces lib comme des fichiers de données externes dans un prog nostub(même si je sait que ce n'est pas le cas) car elles ne sont pas utilisées dans plus d'1 ou 2 prog et qu'elles sont fournies dans le zip. Elles ne posent donc pas de réel problèmes. Ceci le problème est du aux auteurs n'auraient pas du avoir fait de lib dynamiques pour cette utilisation.

2. Ça plante parfois, donc c'est instable.

Donc aucun de tes progs n'est stable. Tous les progs sont suseptibles de planter et CF fait partie de ceux qui plantent le moins(en tout cas moi je l'ai jamais planté).

3.4 Un jeu qui remplit la mémoire archive entière a intérêt à valoir ce qu'il prend en mémoire. S'ils jugent que ce n'est pas le cas, c'est une raison de ne pas faire de news.

C'est a l'utilisateur de juger si ca en vaut la peine! pas a celui qui poste le news!

C'est exactement cette attitude qui m'énerve. Tu essayes de contraindre les programmeurs à faire tout ce que tu veux. Et après, il y en a (n'est-ce pas Thibaut ) qui nous accusent de faire ce genre d'actions. On n'a jamais mis des messages d'"erreur", voire des désinstallations automatiques, intentionnellement pour forcer les programmeurs à se mettre à jour.

Non et interdire autre chose que TIGCCIDE ou bloquer Pedrom, c'est quoi alors.
--- a suivre ---
Ps: Je ne répond plus aux arguments auquel on a répondu 15 fois et que Kévin ignore, ca tape vraiment sur les nerfs à force
----

Uther Lightbringer a écrit :
--- a suivre ---
Ps: Je ne répond plus aux arguments auquel on a répondu 15 fois et que Kévin ignore, ca tape vraiment sur les nerfs à force
----

C'est con, ptet qu'à la 97ème fois il aurait répondu

Il est clair que l'argumentation sélective peut porter à confusion ici

<< Tu [Uther] utilises les RAM_CALLs directement?! Tu devrais utiliser les macros de compat.h! En mode kernel, elles sont automatiquement transformées en RAM_CALLs quand il y a un RAM_CALL correspondant. En _nostub, elles sont implémentées différemment. >>
>Et en ASM ? Mais il programme en C!

Non j'ai commencé a me mettre a l'ASM aussi.

Pas vraiment. ExePack est plus flexible parce qu'il:
* marche aussi sans kernel * permet le lancement par plein de manières différentes: lanceur personnalisé, ttstart, AutoStart, TICT Explorer, explorateurs d'auteurs tiers, ...

* oui mais a mon avis ca vaut le coup d'avoir un kernel
* Permet le lancement encore plus simple par tout programme ou une simple ligne de commande.

Tu veux vraiment faire ch**r Thomas de cette manière? Et je n'ai toujours pas compris pourquoi tu n'as pas intégré ttunpack_decompress à PreOs. Ça aurait rendu le système de packs archive beaucoup plus transparent et amélioré la qualité de la compression.

Ca aurait augmenté la taille de PreOS et non de stdlibet vu le format utilisé par PreOS une lib dynamique est plus adaptée. Mais c'est vrai que a mon avis, ca en aurait valu la peine.

Non. ziplib est très loin d'offrir le taux de compression offert par ttpack.

Par rapport a TTPack oui mais par rapport a rien du tout, ca vaut le coup

XtraKeys ne gère pas [SHIFT]+[ON]. Il doit confondre avec ShortCuts de Samuel Stearley.

Pardon je ne connais pas parfaitement le nom ce cette TSR vu que je ne l'utilise pas

Ce n'est pas un stub, c'est du code de démarrage!

C'est un presquestub

Je suis content

c ridicule de comparé ttpack à ziplib ... ttpack compresse-t'il oncalc ?