Martial Demolins (./218) :
Surtout que dans le cas de CF, tu avais demandé à PpHd de réduire sa consommation de RAM. Pourquoi tu fais pas pareil pour C99?
Certes,
Corridor 99 devrait consommer moins de RAM, mais ça ne change pas que le kernel l'empêche de fonctionner.

Un mini-kernel alors, ça te va? 

Appelle-le "code de démarrage" tout simplement, parce que c'est ce que c'est.
Kevin Kofler (./212) :
* Je veux les voir, les jeux qui utilisent 50 KO de ExtGraph.
Il ne resterait plus que 14 KO pour le jeu!
Sauf avec les DLLs, tu sais, celles qui sont des vrais DLLs mais ou on peut pas faire comme en vrai avec, celle qui ont été désignées avec les pieds quoi.
La bonne solution quand on dépasse les 64 KO est d'optimiser en taille.
Cela dit, on peut aller jusqu'à 128 KO de code pur (les données peuvent être externes aussi) avec le système de DLLs de TIGCCLIB, c'est largement suffisant.
Mais tu as évite le point principal de la citation:
"Je veux les voir, les jeux qui utilisent 50 KO de ExtGraph.

"
Abus de fonctionnalité? J'ai le droit de faire des expériences non?
Bah, si ça t'amuse... Le problème est que tu présentes ces méthodes comme la panacée alors que tes exemples ne prouvent pas du tout qu'elles ont un intérêt, parce que ce serait plus efficace de ne pas utiliser les méthodes que tu montres.
Et je me suis surtout rendu compte que ces features offraient bien plus que des simples "libs conditionnelles", mais permettaient de gagner en place et en facilité de développement de manière impressionnate.
Dans tous les exemples que j'ai vu, tu as perdu en place et rendu le développement plus difficile.

Par exemple, le seul gain de place de ton système avec les libs conditionnelles, c'était la RAM consommée en temps d'exécution, mais tu as réduit la RAM de quelque chose comme 10 KO à quelque chose comme 5 KO, ce qui est totalement sans intérêt étant donné qu'on est loin de la taille totale de la RAM et de ce que d'autres jeux nécessitent.
De plus, il ne faut pas oublier que pour ton pack archive, il y a d'abord un twin du pack complet compressé qui est créé en RAM par AMS,
PreOs va le libérer (je suppose... je n'ai plus lu le code de
PreOs depuis longtemps), mais si tu crées un pack archive de 30 KO, même si ton programme ne prend que 10 KO maximum à l'exécution grâce à la segmentation en librairies (parce que c'est bien ça ton système, une segmentation comme les overlays DOS, très obsolète comme technique de codage), il faudra quand-même 30 KO de RAM pour le faire tourner parce qu'AMS crée d'abord le twin pour tout le pack archive.
TIGCC propose quoi pour l'exécution de programmes externes?
"devrais rajouter" != "propose"
Et je fournis le code que j'ai à tous ceux qui en ont besoin (même Thibaut).
On aurait à ce moment parlé carrément de kernel embarqué
Bah, vous le faites déjà.

Ce n'est pas ça qui va le rendre vrai.
C'est pas de ma faute si ton code de démarrage n'est pas générique
C'est ton code qui n'est pas générique, justement.
et peut-être facilement optimisé.
Pour un cas particulier, peut-être. Mais il faut savoir ce que tu veux, du code parfaitement optimal à tout prix ou la facilité de programmation.
Nous nous sommes cassés pas mal la tête à rendre le code de démarrage aussi compact que possible.
Ceci dit, quand on propose des contributions, c'est comme si on pissait dans un bazooka
Je n'ai jamais vu une version de ton handler F-Line (pour citer un exemple) qui s'intègre correctement au code de démarrage de TIGCCLIB, satisfait les contraintes sur les registres détruits de cet endroit du code de démarrage, est aussi flexible que celui qu'on a actuellement (morceaux activables sur demande) et est compatible à 100% avec les programmes existants. (Indice: il faut une dixaine de fichiers .s, pas un seul, et il faut aussi qu'il y ait le bon contenu dedans.) Donc la "contribution", je ne vois pas où elle est.
Ce que tu as contribué et qui n'est pas encore mergé (j'ai mergé ta première optimisation de la routine de gris le 30 octobre 2006), ce sont des optimisations qui gagnent 2 octets chacune, pour un total de combien? 4? 6? 8 octets? Enfin, rien qui changera le monde.
donc on fait par soi-même. D'ailleurs, je ne sais si tu connais ce proverbe français qui dit "On n'est jamais si bien servi que par soi-même", je ne fais que l'appliquer.
Mais du coup tu es mal placé pour dire que le
_nostub complique la vie, parce que c'est toi qui te la compliques en réinventant la roue.
Attends, un peu de bonne foi, en tant que linuxien tu dois bien savoir que pour arriver à faire ce qu'on veut avec sa machine, pour faire de la configuration avancée et pour exploiter les capacités a fond, on doit nécessairement mettre les mains dans le cambouis.
Justement, le but des distributions modernes est de rendre ça inutile.
Et je n'ai jamais vu de logiciel GNU/Linux qui dit qu'il faut installer un "kernel" supplémentaire parce que celui de Linux ne lui convient pas. Alors pourquoi faire ça avec AMS?
Quant à dire que je suis un monopole au même titre que chez Bilou, je ne vois vraiment pas d'où tu sors ça. Le jour où Windows sort sous GPL, on pourra en reparler.
