Integrated Desktop - Page 10

Total Destruction aussi.

Oui mais Total Destruction est un projet quasi fini.
Et puis les RPG Nostub sont minables. XeonTech promettait mais ca fait un moment que l'on a plus de nouvelles de lui.

Bah... le seul jeux _nostub, pour moi, qui pourras peut-être rivaliser avec tous ces monstres kerneleux, c le monstrueux Gun Battle

il lui manque quand même un petit quelquechose

Le lin...
merde Vertyos m'a entendu

Kevin Kofler a écrit :
1. On installe un TSR pour faire marcher un TSR, pas pour faire marcher un programme.
2. Pour h220xTSR, son installation (ou celle du HW2Patch) est inévitable, pas pour un kernel.
3. Pourquoi penses-tu que beaucoup de TSRs (y compris les miens, et y compris PreOs) installent h220xTSR automatiquement, en l'incluant comme librairie statique? C'est fait exactement pour la raison que tu viens de citer.

Pour ma part, car j'ai entendu beaucoup de gens gueules contre l'envoie de roms.
En ce moment je cherche a modifier le certif de la rom pour qu'une rom patche s'envoie sans pb. Apres hw2tsr poubelle Technique secrete de l'ecole PpHd pour faire enrager KK

3 versions bêta de jeux, tous 3 réputés (peut-être à tord, mais ça m'étonnerait quand-même beaucoup) pour être instables. Ce n'est pas le genre de trucs que je mets sur ma calculatrice.

Cf / SMA sont franchement stables. Les seules erreurs reportes sont des erreurs de memoire vive insuffisante. Plus stables que tictex v1.00

Théorique peut-être. Mais en pratique, les librairies dynamiques sont assez souvent une perte de place.

Oué, j'ai gagne la bataille theorique !

KerNO fait ça aussi.

C'est moins performant. Et Kernel est un kernel qui ne veut pas dire son nom.

Ce n'est pas le kernel qui fait ça. (Sauf pour "ASAP or Exec string too long", mais KerNO, IPR, ttstart, TICTEX, AutoStart, ... suppriment aussi cette erreur. Et pour "Invalid Program Reference" quand on utilise une fonction en assembleur/C dans une fonction, mais KerNO[/i] et IPR suppriment aussi cette erreur. Et IPR ne prend même pas un demi-KO.) Pour le reste, c'est h220xTSR ou HW2Patch qui le fait, pas le kernel!

Je crois que je vais me passer d'hw2tsr pour differentes raisons. (Entre autre ces "problemes" de desinstallation).
D'autre part, tu oublies que le kernel peut parfaitement deleguer sa tache a d'autres s'il le souhaite.

Tu peux utiliser Shortcuts de Samuel Stearley pour ça.
KerNO fait ça aussi.

D'autres TSR qui prennent de la place.
Si tu veux je te fais preos en moins de 500 octets.
Chiche ?

Fonctionnalités dépassées et/ou inutiles:
- RAM_CALLs: dépassés pour la plupart (il y a des ROM_CALLs permettant de faire la même chose proprement), à utilité très limitée pour le reste (CALCULATOR - facile à détecter soi-même - et tout ce qui peut être facilement déduit à partir de CALCULATOR, pour lequel il est donc complètement inutile de mettre d'autres RAM_CALLs).

Tres simple d'emploi en ASM. Plus court. Consomme moins de memoire.

- BSS: inutiles. Il y a plein de fonctions d'allocation de mémoire dans AMS, on n'a pas besoin d'une autre.

Tres simple d'emploi en ASM. Plus court. Consomme moins de memoire.

- librairies dynamiques: dépassées (pour la plupart des libraires livrées avec le kernel) et inutiles (il y a les librairies statiques).

UGPlib / shrnklib / genlib depassee ?

Comment ça "aucun problème d'incompatibilité"? TxtRider marche??? Et il y a aussi les programmes écrits pour AMS 1 seulement qui ne marcheront très probablement jamais avec AMS 2.

Il a dit 2 ans

Elle s'appelle doorsos parce que c'est le kernel qui a inventé le format. (PlusShell 0.99 alpha utilisait un autre format, et PlusShell 1.00 alpha n'est sorti qu'après la première bêta de DoorsOS.)

Je te signale que depuis de nouveaux formats sont apparus...
Les pack archive je les mets ou ?

Ce qu'il faudrait leur demander de faire, ça serait de mettre DoorsOS dans "TI-89 (92+) Assembly Shells (out of date)".

Moaips. Ils ecoutent encore ?

> En ce moment je cherche a modifier le certif de la rom pour qu'une rom patche s'envoie sans pb. Apres hw2tsr poubelle
Je trouve que tu t'améliores, tu fais des trucs de plus en plus propres et de plus en plus stables...

> Plus stables que tictex v1.00
En effet, TICT-Explorer 1.00 a un bug sur la routine de test des piles, routine qui ne vient pas de nous; nous avons corrigé cette routine (Francesco Orabona / ExtendeD / myself).

> UGPlib / shrnklib / genlib
C'est quoi UGPlib ? [Je demande de l'information].

XDanger a écrit :
> En ce moment je cherche a modifier le certif de la rom pour qu'une rom patche s'envoie sans pb. Apres hw2tsr poubelle
Je trouve que tu t'améliores, tu fais des trucs de plus en plus propres et de plus en plus stables...

Huhu C'etait au premier ou au second degre ?

> Plus stables que tictex v1.00
> UGPlib / shrnklib / genlib C'est quoi UGPlib ? [Je demande de l'information].

Cf Preos 0.64 / Src/libs/David /ugp

Uther Lightbringer a écrit :
Le lin... merde Vertyos m'a entendu

#sourd##muet#

PpHd a écrit :
Pour ma part, car j'ai entendu beaucoup de gens gueules contre l'envoie de roms.
En ce moment je cherche a modifier le certif de la rom pour qu'une rom patche s'envoie sans pb. Apres hw2tsr poubelle [0]Technique secrete de l'ecole PpHd pour faire enrager KK[/0]

Et tu as réussi.

Déjà, je doûte que ton idée soit réalisable. Il y a de la cryptographie forte en jeu.

Et ensuite, s'il te plaît, ne supprime pas le support pour h220xTSR! h220xTSR a aussi d'autres avantages:
- moins dangereux. Beaucoup de gens (surtout sur les forums internationaux, mais aussi parfois ici) refusent d'installer le HW2Patch pour des raisons de sécurité. Et si tu te mets à modifier des certificats, il sera encore plus dangereux!
- plus portable!!! TI fait tout pour empêcher à des patches de la ROM comme HW2Patch de fonctionner. Il a fallu une mise à jour du HW2Patch pour chaque mise à jour de AMS. h220xTSR, lui, a dû être mis à jour une seule fois (parce que les registres utilisés par NG_execute ont changé entre AMS 2.05 et 2.07), et il a été mis à jour beaucoup plus rapidement que le HW2Patch. Et HW2Patch ne supporte toujours pas AMS 2.07! Ni 2.00 et 2.02 d'ailleurs. h220xTSR supporte toutes ces versions.
- plus légal. La modification de AMS est de légalité doûteuse.
- source disponible. Ça permet aussi de vérifier que le programme ne fait rien de méchant.
Personnellement, je refuse d'installer le HW2Patch, et tu pourras me retirer de ta liste des testeurs si tu retires le support pour h220xTSR.

Cf / SMA sont franchement stables. Les seules erreurs reportes sont des erreurs de memoire vive insuffisante.

Il y a eu beaucoup de plantages reportés. Si ce sont des problèmes de mémoire, alors il te faudra rajouter des tests pour vérifier que l'allocation ait réussi. Si le programme plante sous des conditions de mémoire insuffisante, c'est un bogue.

Et j'ai aussi reporté un problème de compatibilité de SMA avec h220xTSR, et pour lequel j'attends la correction (une ligne à rajouter) depuis des mois.

Plus stables que tictex v1.00

Ça a été corrigé depuis longtemps.

Oué, j'ai gagne la bataille theorique !

J'ai dit "peut-être".

C'est moins performant. Et [KerNO] est un kernel qui ne veut pas dire son nom.

Mais il ne supporte pas les programmes pour kernel, donc il faut programmer en _nostub pour être compatible avec KerNO.

Je crois que je vais me passer d'hw2tsr pour differentes raisons. (Entre autre ces "problemes" de desinstallation).

Pourrais-tu détailler? Je pense qu'en présence des détails, on trouvera certainement une solution acceptable. Et puis, le problème n'est-il pas résoluble en ne pas incluant h220xTSR statiquement, mais en étant quand-même compatible avec lui?

D'autre part, tu oublies que le kernel peut parfaitement deleguer sa tache a d'autres s'il le souhaite.

Mais ce n'est pas une fonctionnalité du kernel dans ce cas.

D'autres TSR qui prennent de la place. Si tu veux je te fais preos en moins de 500 octets.

Comment?

[>CALCULATOR et RAM_CALLs liés] Tres simple d'emploi en ASM.

Avec le nouveau linker de TIGCC 0.95, il suffira de mettre quelques xdef pour avoir le "startup code" qu'il faut.

Plus court. Consomme moins de memoire.

Quelques octets en moins peut-être. Mais le stub et le header du format kernel prennent plus de place que ça.

[>BSS] Tres simple d'emploi en ASM.

Je ne vois pas en quoi c'est plus simple qu'un simple appel à HeapAllocPtr et HeapFreePtr.

Plus court. Consomme moins de memoire.

Quelques octets en moins peut-être. Mais le stub et le header du format kernel prennent plus de place que ça.
Et puis, ce n'est plus court que si on "abuse" des BSS en les utilisant comme des malloc (avec un lea begin_bss_block,an). Sinon, il y a un relogement pour chaque référence à un bloc BSS!

UGPlib / shrnklib / genlib depassee ?

Celles-là pas vraiment. Mais c'est le genre de trucs pour lesquelles les librairies statiques conviennent très bien. Donc l'utilisation des librairies dynamiques pour ce genre de trucs est dépassé.
Et puis shrnklib est dépassée parce que ttpack compresse mieux. (J'ai fait les tests, et j'ai posté les résultats plusieurs fois.)

Il a dit 2 ans

Où ça? Et puis, les programmes de HerveRV sont sortis il y a moins de 2 ans, et ils n'étaient pas compatibles AMS 2 lors de leur sortie.

Je te signale que depuis de nouveaux formats sont apparus...

Ça reste essentiellement le format DoorsOS.

Les pack archive je les mets ou ?

Dans doorsos, avec "[PreOs 0.62 or higher]" au début du titre.
Et tu peux essayer de demander une section preos. Peut-être que tu en auras une.

Moaips. Ils ecoutent encore ?

Je pense que oui.

XDanger a écrit :
> En ce moment je cherche a modifier le certif de la rom pour qu'une rom patche s'envoie sans pb. Apres hw2tsr poubelle Je trouve que tu t'améliores, tu fais des trucs de plus en plus propres et de plus en plus stables...

Tu appelles ça propre et stable??? Moi, j'appelle ça très sale et très dangereux. Je préfère de loin h220xTSR.

> UGPlib / shrnklib / genlib C'est quoi UGPlib ? [Je demande de l'information].

C'est une librairie de vidéos, à utilité doûteuse, et très rarement (voire pas du tout) utilisée.

Kevin Kofler a écrit :
Et tu as réussi.

Oué !

Déjà, je doûte que ton idée soit réalisable. Il y a de la cryptographie forte en jeu.

Je crois pas.

Et ensuite, s'il te plaît, ne supprime pas le support pour h220xTSR! h220xTSR a aussi d'autres avantages:
- moins dangereux. Beaucoup de gens (surtout sur les forums internationaux, mais aussi parfois ici) refusent d'installer le HW2Patch pour des raisons de sécurité. Et si tu te mets à modifier des certificats, il sera encore plus dangereux!

J'ai jamais dit que je le ferais.

- plus portable!!! TI fait tout pour empêcher à des patches de la ROM comme HW2Patch de fonctionner. Il a fallu une mise à jour du HW2Patch pour chaque mise à jour de AMS. h220xTSR, lui, a dû être mis à jour une seule fois (parce que les registres utilisés par NG_execute ont changé entre AMS 2.05 et 2.07), et il a été mis à jour beaucoup plus rapidement que le HW2Patch. Et HW2Patch ne supporte toujours pas AMS 2.07! Ni 2.00 et 2.02 d'ailleurs. h220xTSR supporte toutes ces versions.

Il y a un moyen de deproteger la protection hardware fonctionnant sur tous AMS, sur tous HW, en C...

- plus légal. La modification de AMS est de légalité doûteuse.

C'est precise dans la licence d'AMS ?

- source disponible. Ça permet aussi de vérifier que le programme ne fait rien de méchant.

Ca peut etre aussi disponible !

Personnellement, je refuse d'installer le HW2Patch, et tu pourras me retirer de ta liste des testeurs si tu retires le support pour h220xTSR.

Je note.

Il y a eu beaucoup de plantages reportés. Si ce sont des problèmes de mémoire, alors il te faudra rajouter des tests pour vérifier que l'allocation ait réussi. Si le programme plante sous des conditions de mémoire insuffisante, c'est un bogue.

Le programme reporte un 'Memory Error' lorsqu'il y a une erreur d'allocation memoire.
C'est ce qu'il reporte.
Ensuite y'a le probleme du programme basic a mettre en mode anglais.
Enfin, y'a le pb d'hw2tsr.

Et j'ai aussi reporté un problème de compatibilité de SMA avec h220xTSR, et pour lequel j'attends la correction (une ligne à rajouter) depuis des mois.

Sorti il y a quelques jours.

Mais il ne supporte pas les programmes pour kernel, donc il faut programmer en _nostub pour être compatible avec KerNO.

C'est ca le comble du ridicule !

Pourrais-tu détailler? Je pense qu'en présence des détails, on trouvera certainement une solution acceptable. Et puis, le problème n'est-il pas résoluble en ne pas incluant h220xTSR statiquement, mais en étant quand-même compatible avec lui?

Une procedure de desinstallation correcte. Je t'en ai deja parler, tu ne m'as jamais repondu.

Mais ce n'est pas une fonctionnalité du kernel dans ce cas.

L'utilisation du kernel assure cette fonctionnalite.

Comment?

Recherche dynamique de preos en archive, et copie en RAM temporaire des fonctions utilées.

Avec le nouveau linker de TIGCC 0.95, il suffira de mettre quelques xdef pour avoir le "startup code" qu'il faut.

????

Quelques octets en moins peut-être. Mais le stub et le header du format kernel prennent plus de place que ça.
Je ne vois pas en quoi c'est plus simple qu'un simple appel à HeapAllocPtr et HeapFreePtr.
Quelques octets en moins peut-être. Mais le stub et le header du format kernel prennent plus de place que ça.

Pas sur. Ca depend de la bonne utilisation du format.
PS: Il n'y a pas d'appel a HeapAllocPtr donc c'est plus simple !

Celles-là pas vraiment. Mais c'est le genre de trucs pour lesquelles les librairies statiques conviennent très bien. Donc l'utilisation des librairies dynamiques pour ce genre de trucs est dépassé.

Pour toi tout convient en lib statique.

Et puis shrnklib est dépassée parce que ttpack compresse mieux. (J'ai fait les tests, et j'ai posté les résultats plusieurs fois.)

Pas forcement. Je t'en ai deja fait la remarque.
Et c'est bien plus rapide a l'extraction !

Où ça? Et puis, les programmes de HerveRV sont sortis il y a moins de 2 ans, et ils n'étaient pas compatibles AMS 2 lors de leur sortie.

L'exception qui confirme la regle.

Ça reste essentiellement le format DoorsOS.

Bof. Pas vraiment.

Dans doorsos, avec "[PreOs 0.62 or higher]" au début du titre.
Et tu peux essayer de demander une section preos. Peut-être que tu en auras une.

Surement pas. Et je ne mets plus aucun fichier sur ticalc. C'est pas que je les boycotte. C'est eux qui me boycottent

Tu appelles ça propre et stable??? Moi, j'appelle ça très sale et très dangereux. Je préfère de loin h220xTSR.

C'etait peut etre du second degre ?

C'est une librairie de vidéos, à utilité doûteuse, et très rarement (voire pas du tout) utilisée.

Y'a pas mal d'exemples dispos a ti92\graphics sur ticalc.

Et y'a comme une petite inversion citations<->réponses dans ton post

oui et le plus chiant pour comprendre c'est que ce n'est meme pas inversé sur tout le post!

Perso je préfère un patch qu'un TSR, un TSR ça bouffe de la RAM inutilement

C'est pas si grave. Ca a son charme

Je ne sais pas si ça à grand chose à voir, mais je n'y connais rien au Kernel, qu'est-ce qu'un BSS

Je crois pas.

Ben si, la somme de contrôle MD5 est protégée par du RSA avec une clé longue.

J'ai jamais dit que je le ferais.

Ben si, tu as dit que tu comptes changer les certificats.

Il y a un moyen de deproteger la protection hardware fonctionnant sur tous AMS, sur tous HW, en C...

Et les AMS et HW futurs, tu y as pensé?

C'est precise dans la licence d'AMS ?

Je pense que oui. À vérifier.

Ca peut etre aussi disponible !

Si tu veux te faire massacrer par JM, Zeljko, ExtendeD etc., vas-y...

Et je ne vois vraiment pas ce que ça te coûte de laisser le support h220xTSR en place dans PreOs. Au moins dans les sources. Il suffit de ne pas retirer les macros qui y sont déjà.

Le programme reporte un 'Memory Error' lorsqu'il y a une erreur d'allocation memoire. C'est ce qu'il reporte.

Ben, les bogues reportés étaient des plantages, des contenus d'écran totalement corrompus etc.

Ensuite y'a le probleme du programme basic a mettre en mode anglais.

En effet. Tu attends quoi pour corriger ça?

Enfin, y'a le pb d'hw2tsr.

Plutôt le problème de SMA avec h220xTSR.

Sorti il y a quelques jours.

Enfin! Ça faisait des mois que je t'ai reporté ce problème!

C'est ca le comble du ridicule !

Ce n'est pas du tout ridicule. En supprimant l'émulation du vieux format dépassé, on peut faire gagner pas mal de place aux kernels.

Une procedure de desinstallation correcte. Je t'en ai deja parler, tu ne m'as jamais repondu.

Peux-tu me rappeler le problème?
Tu veux faire quoi exactement? Intégrer unin2tsr à uninst? Permettre d'installer h220xTSR temporairement dans un lanceur ou équivalent?

L'utilisation du kernel assure cette fonctionnalite.

Mais c'est un moyen excessif.

Recherche dynamique de preos en archive, et copie en RAM temporaire des fonctions utilées.

Ah, je pensais 500 octets en total, alors que tu parlais de 500 octets en RAM. Ça explique des choses?

<< Avec le nouveau linker de TIGCC 0.95, il suffira de mettre quelques xdef pour avoir le "startup code" qu'il faut. >> ????

Il te suffira d'activer le bon "global import" avec un __ref_all_foobar: xdef __ref_all_foobar et tu auras ta détection de modèle. Ou ton SET_FILE_IN_USE_BIT. Ou tout ce que tu veux.

Pas sur. Ca depend de la bonne utilisation du format.

Moi, je vois 2 méthodes d'utiliser un BSS: une qui est à peu près équivalente à HeapAllocPtr, ce qui est un peu un abus du système de BSS (et en tout cas supprime tous les avantages des BSS et ne laisse que les désavantages: un seul bloc, donc 64 KO maximum, pas de possibilité de changer sa taille dynamiquement, ...), et une autre qui donnera un relogement pour chaque accès, donc du code horrible.

PS: Il n'y a pas d'appel a HeapAllocPtr donc c'est plus simple !

Non. Avec HeapAllocPtr, on comprend tout de suite ce qui se passe. Alors qu'un débutant pris au hasard ne comprendra pas du tout le fonctionnement d'un segment BSS. Donc HeapAllocPtr est plus simple.

Pour toi tout convient en lib statique.

<< Et puis shrnklib est dépassée parce que ttpack compresse mieux. (J'ai fait les tests, et j'ai posté les résultats plusieurs fois.) >> Pas forcement. Je t'en ai deja fait la remarque.

Sans aucun chiffre. Alors que moi, j'ai donné mes chiffres.

Et c'est bien plus rapide a l'extraction !

Pas tant que ça. PreOs Browser ne se charge pas vraiment plus rapidement que TI-Chess.

L'exception qui confirme la regle.

L'exception qui fait que "tous" est faux.

Surement pas. Et je ne mets plus aucun fichier sur ticalc. C'est pas que je les boycotte. C'est eux qui me boycottent

Parce que tu es un fanatique des kernels peut-être.

Y'a pas mal d'exemples dispos a ti92\graphics sur ticalc.

Ah, des exemples codés pour la vieille TI-92... Donc c'est bien dépassé, parce que pratiquement plus personne ne l'utilise maintenant.

Link a écrit :
Je ne sais pas si ça à grand chose à voir, mais je n'y connais rien au Kernel, qu'est-ce qu'un BSS

C'est une manière horriblement compliquée et inflexible de faire un HeapAllocPtr.

loufoque
a écrit : Perso je préfère un patch qu'un TSR, un TSR ça bouffe de la RAM inutilement

Et un patch, ça modifie la ROM inutilement. Tu es libre de choisir ce que tu veux.

modif de la ROM
ça évite d'avoir à l'installer 36 fois

Mais ça modifie la ROM et empêche de l'envoyer.
Personnellement, c'est depuis que j'ai à moitié bousillé la calc d'un ami de cette façon que je trouve qu'hw2patch est à bannir. NON aux modifs de la ROM.

Moi aussi, ça me fait peur un patch...
Pourtant, je ne vois pas trop en quoi c'est plus dangereux qu'un TSR...
En fait, c'est surtout que ça me fait chier de raflasher

C'est plus dangereux parce qu'il faut déprotéger la FlashROM (même pour le HW2Patch en RAM d'ailleurs - les ports matériels en question sont protégés par la même protection). Et à FlashROM déprotégée, du code foireux pourrait écraser tout sauf le boot code. Y compris la zone des certificats!

h220xTSR ne touche pas à cette protection. Il fait juste un enter_ghost_space (qui fait faire le travail au trap #$B de AMS - aucun code en dehors de ce trap n'est exécuté à protection désactivée), puis détourne le trap #B.

en parlant de Command to Conquer II, j'aimerais bien m'atteller à la tâche pour le poursuivre, mais
1) la source est énorme
2) la source est horrible
3)Trop de variables globales

->J'ai envoyé un mail à l'auteur mais il reste sans réponse
->J'ai commencé à découper la source mais à cause des variables globales c'est pour le moment non compilable
-> J'ai déjà gagné 32 octets sur le fichier compilés par une modification toute bête d'une fonction.

->Je compte modifier le programme de manière à ce que tout l'écran d'une 92 soit occupé avec les vrais icônes du jeu pour le 'build mode', des touches adapté à la 92
-> modification de l'interface graphique (horriblement moche selon moi)
->changement des fonctions de sauvegarde de manière à ne pas utiliser fopen et cie. (mais pour ca, il faut que je finisse de me faire la main sur mon agenda.)

> 1) la source est énorme
Oui.

> 2) la source est horrible
Oui.

> 3)Trop de variables globales
>->J'ai commencé à découper la source mais à cause des variables globales c'est pour le moment non compilable
Tu les mets dans un header .h.

-> J'ai déjà gagné 32 octets sur le fichier compilés par une modification toute bête d'une fonction.
Alors, je pense que tu pourras gagner beaucoup plus en modifiant d'autres fonctions...

->Je compte modifier le programme de manière à ce que tout l'écran d'une 92 soit occupé avec les vrais icônes du jeu pour le 'build mode', des touches adapté à la 92
Ca peut être intéressant, mais je pense que pour des questions d'efficacité (surtout au niveau de la taille), il faut faire des versions incompatibles on-calc.

-> modification de l'interface graphique (horriblement moche selon moi)
Faudrait avoir la réponse de l'auteur avant...

->changement des fonctions de sauvegarde de manière à ne pas utiliser fopen et cie. (mais pour ca, il faut que je finisse de me faire la main sur mon agenda.)
Ca, c'est très bien.

Mais ça modifie la ROM et empêche de l'envoyer.

depuis la sortie de la ROM2.05 ou, du moins, peu après, j'ai une ROM2.05 patchée avec MaxMem, et avec quelques chaines modifiées (le tout on-pc : maxmem tournait pas on-calc sur 2.05)
ça m'a jamais géné. au contraire

Personnellement, c'est depuis que j'ai à moitié bousillé la calc d'un ami de cette façon que je trouve qu'hw2patch est à bannir. NON aux modifs de la ROM

je n'ai jamais eu besoin d'envoyer d'une calc à une autre : j'ai toujours fait passer par un PC.

les gens qui étaient dans ma classe en term et qui avaine tdes hw2 ont tous installé HW2patch, et pas de pb.

En fait, c'est surtout que ça me fait chier de raflasher

erf

et puis, vu que mon port est pas loin d'être mort, je prend pas le risque de renvoyer une ROM qui risque de pas passer en entier...

> 3)Trop de variables globales
>->J'ai commencé à découper la source mais à cause des variables globales c'est pour le moment non compilable
Tu les mets dans un header .h.

il fo pas plutôt déclarer toutes les vars globables dnas un fichier .c, et toutes les mettre en extern dans un .h, que tu inclu dans tous les autres .c ?
(c ce que je fais pr mon projet à l'IUT... mais c du C++)

Je m'insurge contre les pratique de dérive de ce forum. Il ne devrai pas servir QU'A ID ???

Bienvenue sur yarOnet.cOm

Erf