Un kernell pour le nostub ??? - Page 3

Laissez-tomber, tout celà est vain...

>PpHd:
>>Pourquoi patcher sa ROM plutôt que d'utiliser des programmes qui marchent sur une
>>ROM non patchée?
>Pour economiser de la RAM et pour eviter de perdre de la place en archive.
>Et aussi, pour ne pas a avoir a le reinstaller apres un reset.

D'accord, mais il vaut mieux avoir le choix de ne pas patcher sa ROM. Patcher sa ROM est dangereux et officiellement invalide la garantie pour ceux qui l'ont encore (mais je ne pense pas que TI en tient vraiment compte).

>parce que c'est plus simple a l'usage.

Non. Il faut toujours faire attention à ne pas envoyer la ROM d'une calculatrice à une autre sans le TIB Receiver. Avec qqch. en RAM, ce problème n'existe pas.

>Tout systeme d'exploitation digne de se nom fait un clean-up complet apres l'utilisation d'un programme.

N'oublie pas qu'on est sur une calculatrice!

>Et puis l'application peut alors se simplifier la vie, et ne pas liberer les handles.

Sebastian et Zeljko peuvent le mettre dans TIGCCLIB si tu leur donnes le code (on aurait alors #define AUTO_FREE_HANDLES de la même manière que #define SAVE_SCREEN).

>C'est configurable avec un flag.

Encore un?! Et comme dit ci-dessus, on peut le mettre aussi, nous (l'équipe de TIGCC), ce flag.

>>Enfin, ce n'est pas impossible de le faire pour les programmes en _nostub (on peut
>>intercepter le trap #$b fonction #$f).
>Oui mais ca ne marche qu'avec AMS 2.0x.

En effet. Mais ce n'est pas un feature indispensable.

>Mais l'utilisateur sera content d'avoir un anti-crash.
>Il fera plus confiance aux programmes.

KerNO est déjà un bon départ pour un anti-crash _nostub. On peut effectivement faire mieux. Et moi, je ne fais aucune confiance en l'anti-crash. Tout ce que ça fait est cacher le fait que la mémoire est corrompue. Mieux vaut le reset. Et puis, fais un sondage sur un forum international qui fait confiance aux programmes pour kernel. Il n'y aura pas grand monde.

>>>Et les libs dynamiques (je sais tu n'aimes pas, mais d'autres aiment) ?
>>FAT Engine, ça te dit quelque chose?
>Oui, tout a fait. Mais c'est l'exption qui confirme la regle : il faut pres d'1Ko pour pouvoir gerer ca dans le programme.

En effet. C'est pour ça qu'il faut l'utiliser seulement quand c'est vraiment nécessaire (en face de la limite de 64 KO par exemple).

>>Ce n'est pas compliqué d'allouer un bloc.
>>Et c'est plus flexible (possibilité d'avoir plusieurs blocs, par exemple).
>Mais c'est plus simple pour le programmeur : il n'a pas a le faire par lui meme.

Ce n'est pas compliqué (2 lignes de C - une pour allouer et une pour désallouer - ou moins de 10 lignes d'assembleur).

>Et aussi, si un programme est reappelle une seconde fois, on pourrait reallouer un autre BSS. Ce qui permettrait de resoudre pas mal de pbs.

Et l'avantage par rapport à laisser le programme faire un autre HeapAllocPtr, c'est quoi? Dans ce cas, le BSS peut être un avantage par rapport à des variables globales dans le programme (mais seulement pour les explorateurs ou dans un environnement multitâches), mais on peut utiliser un bloc alloué "à la main".

>>Et puis, Sebastian compte rajouter cette fonctionnalité au linker de TIGCC
>>dans une version future (mais chut ).
>Arf. La taille des nostub va encore augmenter.

Seulement quand le BSS est utilisé. Et la taille diminuera probablement par rapport à ce que fait TIGCC actuellement pour les variables globales non initialisées (les mettre à 0 et les enregistrer dans le programme).

>>>Et les extra_ram_calls ?
>>J'ai rarement vu quelque chose de plus inutile!
>>1. C'est très facile à faire à la main.
>Oui. Un test, et tout. Mais les extra_ram_calls sont des immediates : elles sont plus rapides !

Et le code auto-modifiant, ça ne te dit rien? Pourtant tu es probablement celui qui l'utilise le plus!

>>2. On peut aussi avoir 2 versions différentes pour chaque calculatrice
>>(et ça prend moins de place).
>Oui, et la compatibilite tu connais ?

C'est à moi que tu dis ça.? XtraKeys pourrait être la moitié de la taille et ne pas avoir besoin d'ExePack si j'avais utilisé des fichiers séparés pour TI-89/92+. Mais j'ai opté pour la compatibilité binaire.

>>3. Je n'ai jamais vu quelqu'un utiliser cela dans une source.
>Moi dans userlib

Mais je n'ai pas vu ton userlib.

>>Et je pense que Sebastian prévoit de mettre leur support directement dans le linker.
>A bon ? Et tu dis que c'est inutile ?

Déjà je ne suis pas sûr s'il veut les mettre (je ne me rappelle plus les détails de son mail à ce sujet, je sais juste que BSS et RAM_CALLs sont prévus). Et puis, Sebastian décide de ce qu'il veut mettre, pas moi.

>>>Et les ram_calls ?
>>1. C'est souvent une manière de programmer sale.
>>Pourquoi accéder directement au Heap plutôt que d'utiliser HeapDeref, par exemple?
>Parce que ca permets des trucs qu'HeapDeref ne permets pas simplement. Et ca peut reduire la taille de la source aussi.

Mais c'est sale quand-même et il ne faut pas le faire. Et réduire la taille de la source? La table des RAM_CALLs prend une place énorme!

>>2. On peut trouver ces adresses à la main. Pour certaines, c'est même très facile
>>(FolderListHandle et MainFolderHandle).
>Oui, mais c plus court d'utiliser une RAM_CALL

Mais ça complique le format pour quelque chose dont on peut se passer très bien.

>>4. Sebastian compte les mettre directement dans les linker (encore une fois, chut ).
>A tiens ? Et c'est inutile ?

Encore une fois, c'est à Sebastian de décider. Et je ne vois d'ailleurs pas très bien comment il veut faire. Probablement avec des routines rajoutées au programme sur demande. Mais je ne peux pas promettre que ça y sera effectivement, et encore moins dire quand ça y sera.

>Pourquoi LOL ? L'execution d'un programme kernel se fait dans un environnement bien plus protege que celui d'un nostub.

Environnement protégé? ... Aucune protection ne peut être parfaite sans MMU, donc le seul résultat, c'est de souler les programmeurs.

>>Parce que maintenant, il y a des privilèges à respecter sur une calculatrice avec un
>>Motorola 68000 (sans MMU)?
>Non, je te parle de droits.

Appelle-les comme tu veux, mais les droits faits respecter de manière logicielle ne servent à rien, à part à faire obstacle au programmeur.

>>Déjà la protection anti-débordement de la pile et les 2
>>modes du processeur sont suffisamment soulants
>Hein ?????????????????????????????????????
>tu trouves ca soulant ??????????????????????

Oui. Surtout la protection de la mémoire basse qui fait qu'il faut toujours écrire à $40090 plutôt que $90 par exemple. Ça fait 3 chiffres de plus à taper et ça prend 2 octets de plus pour rien (une adresse en .l plutôt que .w).

>Mais c'est indispensable !

Les 2 modes ne sont pas vraiment nécessaires (mais ça c'est Motorola qui les a mis, pas TI ni les programmeurs de kernels). Pour la protection anti-débordement de pile, c'est vrai qu'elle peut être utile contre les débordements de pile et contre les essais de déréférencer NULL et d'y écrire.

>Plus un environnement est soumis a des contraintes (savamment choisies), plus la programmation est facile. Cf les langages de hauts-niveaux.

Ce qui fait la facilité des langages de haut niveau ne sont pas les contraintes. Ce sont les contraintes qui sont effet collatéral non voulu des abstractions qui facilitent la programmation. C'est pour cela que beaucoup de langages proposent l'assembleur inline (pour pouvoir éviter les contraintes).

>>Et puis, je ne vois pas en quoi le passage par une fonction supplémentaire
>>serait plus stable. Ça sera juste plus lent et plus gros.
>Non. Elle ferait aussi l'allocation et la copie,

OK.

>respecterait tes conventions de TSR,

1. Ces conventions ne sont que pour les hooks d'évènements, pas pour les autres catégories de TSRs.
2. Je ne considère pas un programme pour kernel comme respectant ma convention:
evhkconv.txt lignes 102-103:
* ajouter 0x40010 à l'adresse du bloc:
- 0x40000 pour HW 2 AMS 2 sans HW2Patch (mais le HW2 AMS 2 TSR support est nécessaire dans ce cas)
Donc il faut que ça tourne là-dessus.
Et je vais peut-être mettre le fait que le mode kernel est interdit explicitement dans la prochaine version de evhkconv.txt.

>permettrait de rajouter un mini-stub aux TSR.

Quel genre de mini-stub? Les 16 octets de header demandés par ma convention? Tout ce qui est en plus serait complètement idiot. Surtout il n'y a pas besoin de relogement puisque le bloc d'un TSR n'est pas déplacé!

>Et elle permettrait de dire au kernel qu'effectivement, il y a changement.

Le kernel peut aller vérifier lui-même dans EV_hook et dans les vecteurs pour voir si un TSR a été installé (c'est-à-dire si une de ces adresses a été changée et qu'elle pointe en dehors de l'espace exécution du programme), et garder les handles correspondants.

>PreOs intercepte le dernier ST_ShowHelp et le reaffiche en quittant

Encore une bidouille. Mais j'avoue que c'est une bonne idée.

>>Et puis, un programme simple en _nostub n'a pas besoin de TSRs, donc pas du
>>HW2Patch ni de h220xTSR. Un programme "simple" en kernel, lui, a besoin d'un
>>kernel qui à son tour a besoin du HW2Patch.
>Et un programme complique aura toujours besoin soit d'hw2tsr (donc augmentation complexite code) ou d'hw2patch...
>Les 'Hello world' ca suffit.

Un jeu n'a pas besoin de TSRs, donc pas de h220xTSR ni HW2Patch. La plupart des programmes de mathématiques ou de sciences non plus. h220xTSR est nécessaire seulement pour les programmes résidents en mémoire (TSR) et dans la situation suivante: un programme en assembleur lance un programme en TI-BASIC qui lui-même lance un programme en assembleur ou une chaîne Exec. (Je vais probablement faire une version spéciale pour le deuxième cas, qui ne sera installée que pour le temps que le programme "père" est exécuté, puis désinstallée.) Sinon, on n'a pas besoin de h220xTSR! On peut utiliser enter_ghost_space (la méthode la plus simple est d'utiliser ExePack) puis si vraiment on veut exécuter quelque chose d'externe au programme, ajouter 0x40000 à son adresse. FAT Engine fonctionne comme ça, par exemple.

>LOL. Tu dates de quand ?
>Les programmes instables sont ceux faits avant l'apparition de la ROM 2.0x ou des programmes utilisant le format PSv0. C'est tres vieux.

Oui, mais la plupart des programmes pour kernel datent de cette époque. Ils ont été portés, mais sont instables. Et la plupart des grands classiques en font partie.

>>>Mais en mode kernel, tout est centralise.
>>C'est une des choses que je lui reproche.
>C'est une des choses que j'aime. La correction s'effectue une fois !

Mais s'il y a un bogue, tous les programmes boguent! Oui, on peut le corriger en une fois. Mais tant que ce n'est pas corrigé, tout bogue.

>>>Kevin va te répondre que ç'est au programmeur de bien programmer, et que mieux
>>>vaut un bon reset après un crash, même récuppéré
>>Tout à fait.
>Desole moi je reset jamais sauf en cas de forces majeures meme apres un crash
>Et ca marche bien !

Utilises-tu les fonctions mathématiques? Si c'est non, ça expliquerait tout...
[edit]Edité par Kevin Kofler le 20-11-2001 à 23:11:48[/edit]

>>Pour economiser de la RAM et pour eviter de perdre de la place en archive.
>>Et aussi, pour ne pas a avoir a le reinstaller apres un reset.
>D'accord, mais il vaut mieux avoir le choix de ne pas patcher sa ROM.
>Patcher sa ROM est dangereux et officiellement invalide la garantie pour
>ceux qui l'ont encore (mais je ne pense pas que TI en tient vraiment compte).
Patcher sa rom n'est pas plus dangereux que de changer de ROM.
Et je doute que Ti aille verifier qu'a l'adresse untel, il y a un zero au lieu de $73FF !

>>parce que c'est plus simple a l'usage.
>Non. Il faut toujours faire attention à ne pas envoyer la ROM d'une calculatrice
>à une autre sans le TIB Receiver. Avec qqch. en RAM, ce problème n'existe pas.
Tu envoies souvent ta ROM a quelqu'un ? Moi jamais.

>>Tout systeme d'exploitation digne de se nom fait un clean-up complet
>>apres l'utilisation d'un programme.
>N'oublie pas qu'on est sur une calculatrice!
Et alors ? Ce n'est pas une excuse !

>>Et puis l'application peut alors se simplifier la vie, et ne pas liberer les handles.
>Sebastian et Zeljko peuvent le mettre dans TIGCCLIB si tu leur donnes le code
>(on aurait alors #define AUTO_FREE_HANDLES de la même manière que
>#define SAVE_SCREEN).
C'est pas complique comme code. Il existe deja dans doorsos.

>>C'est configurable avec un flag.
>Encore un?! Et comme dit ci-dessus, on peut le mettre aussi, nous
>(l'équipe de TIGCC), ce flag.
Oui, je compte en rajouter beaucoup. (de flags).

>>Mais l'utilisateur sera content d'avoir un anti-crash.
>>Il fera plus confiance aux programmes.
>KerNO est déjà un bon départ pour un anti-crash _nostub. On peut effectivement faire
>mieux. Et moi, je ne fais aucune confiance en l'anti-crash. Tout ce que ça fait est
>cacher le fait que la mémoire est corrompue. Mieux vaut le reset.
Effectivement KerNo est largement insufisant.
J'ai moi meme essayer d'implementer la protection anticrash pour les nostub : c'est plus une source de bugs nouveaux qu'une relle protection !
Le probleme est que le transfert d'erreur : Address error / illegal / ... en ER_throw n'est pas parfait et pose certains pbs sous certaines configurations...

> Et puis, fais un
>sondage sur un forum international qui fait confiance aux programmes pour kernel. Il
>n'y aura pas grand monde.
Il ya aura moi deja

>>Oui, tout a fait. Mais c'est l'exption qui confirme la regle :
>>il faut pres d'1Ko pour pouvoir gerer ca dans le programme.
>En effet. C'est pour ça qu'il faut l'utiliser seulement quand c'est vraiment nécessaire
>(en face de la limite de 64 KO par exemple).
Le kernel centralise ca sans aucun probleme.

>>Mais c'est plus simple pour le programmeur : il n'a pas a le faire par lui meme.
>Ce n'est pas compliqué (2 lignes de C - une pour allouer et une pour désallouer - ou
>moins de 10 lignes d'assembleur).
Mais c'est plus simple !

>>Et aussi, si un programme est reappelle une seconde fois,
>>on pourrait reallouer un autre BSS. Ce qui permettrait de resoudre pas mal de pbs.
>Et l'avantage par rapport à laisser le programme faire un autre HeapAllocPtr,
>c'est quoi? Dans ce cas, le BSS peut être un avantage par rapport à des variables
>globales dans le programme (mais seulement pour les explorateurs ou dans un
>environnement multitâches), mais on peut utiliser un bloc alloué "à la main".
Non, utiliser un bloc allouer a la main ne suffit : il faudrait faire en plus une liste chainee des bloc alloues pour que ca marche bien.

>>Arf. La taille des nostub va encore augmenter.
>Seulement quand le BSS est utilisé. Et la taille diminuera probablement par rapport à
>ce que fait TIGCC actuellement pour les variables globales non initialisées (les mettre
>à 0 et les enregistrer dans le programme).
Oui probablement. Mais pourquoi attendre ?

>>Oui. Un test, et tout. Mais les extra_ram_calls sont des immediates :
>> elles sont plus rapides !
>Et le code auto-modifiant, ça ne te dit rien? Pourtant tu es probablement celui qui
>l'utilise le plus!
Surement. Mais j'aime bien que le kernel le fasse a ma place

>>Oui, et la compatibilite tu connais ?
>C'est à moi que tu dis ça.? XtraKeys pourrait être la moitié de la taille et ne pas avoir
>besoin d'ExePack si j'avais utilisé des fichiers séparés pour TI-89/92+. Mais j'ai opté
>pour la compatibilité binaire.
Bien je vois.

>Déjà je ne suis pas sûr s'il veut les mettre (je ne me rappelle plus les détails de son mail à ce sujet, je sais juste que BSS et RAM_CALLs sont prévus). Et puis, Sebastian décide de ce qu'il veut mettre, pas moi.
Ok. On verra.

>Mais c'est sale quand-même et il ne faut pas le faire. Et réduire la taille de la source?
>La table des RAM_CALLs prend une place énorme!
Peut etre. Tu parles de la table de relogement dans les programmes ou de la table dans le kernel ?

>>Oui, mais c plus court d'utiliser une RAM_CALL
>Mais ça complique le format pour quelque chose dont on peut se passer très bien.
>Pas vraiment.
Et par exemple tios::HomeEntry n'est pas quelque chose de simple a trouver

>>Pourquoi LOL ? L'execution d'un programme kernel se fait dans un environnement
>>bien plus protege que celui d'un nostub.
>Environnement protégé? ... Aucune protection ne peut être parfaite sans MMU, donc le seul résultat, c'est de souler les programmeurs.
Souler ? Pourquoi ?

>>Non, je te parle de droits.
>Appelle-les comme tu veux, mais les droits faits respecter de manière logicielle ne
>servent à rien, à part à faire obstacle au programmeur.
S'il a vraiment besoin de les depasser, il le fait en nostub, ou il demande au prog du kernel.
Mais je doute que + de 10% des progs en ai reellement besoin.

>>tu trouves ca soulant ??????????????????????
>Oui. Surtout la protection de la mémoire basse qui fait qu'il faut toujours écrire à
>$40090 plutôt que $90 par exemple. Ça fait 3 chiffres de plus à taper et ça prend 2
>octets de plus pour rien (une adresse en .l plutôt que .w).
Et tu es ironique ? Parce si ca, tu le fais tres bien
Non, ce qui est chiant, c'est qu'on puisse ecrire sans deproteger la memoire basse.

>>Mais c'est indispensable !
>Les 2 modes ne sont pas vraiment nécessaires (mais ça c'est Motorola qui les a mis,
>pas TI ni les programmeurs de kernels).
Tu n'as jamais fait de systeme d'exploitation toi

>Pour la protection anti-débordement de pile,
>c'est vrai qu'elle peut être utile contre les débordements de pile
>et contre les essais de déréférencer NULL et d'y écrire.
Entre autre, mais pas que ca.

>Ce qui fait la facilité des langages de haut niveau ne sont pas les contraintes.
>Ce sont les contraintes qui sont effet collatéral non voulu des abstractions qui facilitent
>la programmation. C'est pour cela que beaucoup de langages proposent l'assembleur
>inline (pour pouvoir éviter les contraintes).
Pas pour pouvoir eviter les contraintes !
Pour etre plus performant !

>>respecterait tes conventions de TSR,
>1. Ces conventions ne sont que pour les hooks d'évènements,
>pas pour les autres catégories de TSRs.
Pas grave, ca peut se generaliser

>2. Je ne considère pas un programme pour kernel comme respectant ma convention:
>evhkconv.txt lignes 102-103:
>* ajouter 0x40010 à l'adresse du bloc:
>- 0x40000 pour HW 2 AMS 2 sans HW2Patch (mais le HW2 AMS 2 TSR support est
>nécessaire dans ce cas)
>Donc il faut que ça tourne là-dessus.
Et un programme kernel ne peut pas le faire ? En quoi il ne peut pas ajouter $40000 a une adresse ?

>Et je vais peut-être mettre le fait que le mode kernel est interdit
>explicitement dans la prochaine version de evhkconv.txt.
Pourquoi ?

>>permettrait de rajouter un mini-stub aux TSR.
>Quel genre de mini-stub? Les 16 octets de header demandés par ma convention?
Oui, mais aussi un truc du genre :
dc.l 'Ev2t' ; Oublie signature
dc.l 0,0 ; Nom
old dc.l 0 ; Liste chaine
movem.l d0-d7/a0-a6,-(sp)
bsr exec
movem.l (sp)+,d0-d7/a0-a6
move.l old(Pc),-(sp)
bne.s ok
addq.l #4,sp
no rts
...
Oups ... je respecte pas a 100% ta convention. Pourtant c'est plus clean. A ces contraintes, c'est vraiment chiant

> Tout ce qui est en plus serait complètement idiot.
>Surtout il n'y a pas besoin de relogement puisque le bloc d'un TSR n'est pas déplacé!
Heu... oui. Mais pourquoi tu le dis ?

>>Et elle permettrait de dire au kernel qu'effectivement, il y a changement.
>Le kernel peut aller vérifier lui-même dans EV_hook et dans les vecteurs pour voir si
>un TSR a été installé (c'est-à-dire si une de ces adresses a été changée et qu'elle
>pointe en dehors de l'espace exécution du programme), et garder les handles
>correspondants.
Non, il pourrait s'agir d'une erreur, un oubli un vecteur non remis en place.
La le programme lui dit explictement de ne pas y toucher.

>Et la plupart des grands classiques en font partie.
Je sens la frustration de Tetris la ...

>>C'est une des choses que j'aime. La correction s'effectue une fois !
>Mais s'il y a un bogue, tous les programmes boguent!
>Oui, on peut le corriger en une fois. Mais tant que ce n'est pas corrigé, tout bogue.
Et bon, si c'est corrige une fois, c'est termine. Alors qu'en nostub faudra penser a recompiler tous les programmes pour que la correction soit effective !

>>Desole moi je reset jamais sauf en cas de forces majeures meme apres un crash
>>Et ca marche bien !
>Utilises-tu les fonctions mathématiques? Si c'est non, ça expliquerait tout...
Si quand meme. Mais mes crashs sont en general tres simples.
[edit]Edité par PpHd le 21-11-2001 à 16:02:27[/edit]

QUAND EST - CE QUE LES BONS JEUX KERNELS VONT ENFIN ETRE REECRITS EN NOSTUB ?

Il faut a tout prix traduire SMQ, SOR3, SFT, TETRIS , etc !!!!
[edit]Edité par anthop le 21-11-2001 à 17:27:59[/edit]

Jamais.

C'est sûr, ça sera plus stable, plus petit. J'ajoute qu'il faudra les améliorer et les réécrire complètement, pas simplement les traduire.

>Plus stable: Non
>Plus petit: Plus gros

XDanger> tu veux les réécrire totalement ?
Et bien, bon courage !!! (surtout si tu n'as pas les sources !)

pphd : file les source de sma a Xdanger, et dit luide revenier kand il aura fini de le metre en nostub, qu'il prendra moins de place et qu'il sera plus stabe ...

Adieu XDanger

Ben... elles existent deja en libre service les sources de SMA
Suffit d'aller sur timetoteam.
http://brian.t.free.fr/SMA/

arf

Kevin, je suis pas sûr, mais je pense que tu t'es fait avoir :
tu dis toi même que les kernels ne sont en définitifs que des TSR. Je penses pas que tu en soit à un TSR prés d'installer ?

arf....

>PpHd:
>Patcher sa rom n'est pas plus dangereux que de changer de ROM.
>Et je doute que Ti aille verifier qu'a l'adresse untel, il y a un zero au lieu de $73FF !

Il suffit de vérifier si la signature est correcte. Ils sont capables de le faire. Mais je ne pense pas non plus qu'ils prennent le temps de le faire.

>Tu envoies souvent ta ROM a quelqu'un ? Moi jamais.

Quand j'étais encore à l'école, où il y avait plein de TI-89, oui.

>>N'oublie pas qu'on est sur une calculatrice!
>Et alors ? Ce n'est pas une excuse !
Ben si. Un OS de calculatrice n'est pas un OS d'ordinateur.

>J'ai moi meme essayer d'implementer la protection anticrash pour les nostub : c'est plus une source de bugs nouveaux qu'une relle protection !
>Le probleme est que le transfert d'erreur : Address error / illegal / ... en ER_throw n'est pas parfait et pose certains pbs sous certaines configurations...

Si tu interceptes le trap #$B fonction #$f, ça peut fonctionner exactement aussi bien ou mal que pour les programmes en mode kernel. Il faut juste faire en sorte que ça marche correctement en combinaison avec h220xTSR (qui lui aussi passe par cela).

>Non, utiliser un bloc allouer a la main ne suffit : il faudrait faire en plus une liste chainee des bloc alloues pour que ca marche bien.

Si on garde l'adresse du bloc dans un registre et que le système de multitâchage garde la valeur de ce registre séparément pour chaque instance du programme (comme il faut), alors il n'y a pas de problème.

>>La table des RAM_CALLs prend une place énorme!
>Peut etre. Tu parles de la table de relogement dans les programmes ou de la table dans le kernel ?

La table au début du programme.

>Et par exemple tios::HomeEntry n'est pas quelque chose de simple a trouver

Il y a la routine de Samuel Stearley. On trouve ça dans XtraKeys et dans Complete en assembleur et dans AutoStart en C. Et elle n'est pas longue du tout.

>Souler ? Pourquoi ?

Parce qu'il y a des choses qu'on ne peut pas faire, ou pour lesquelles il y a des choses inutilement compliquées à faire. C'est exactement ce que tu critiques pour le _nostub (choses inutilement compliquées), mais pour le kernel, tu le défends au nom d'une "protection" qui ne peut être parfaite en l'absence d'une MMU.

>Non, ce qui est chiant, c'est qu'on puisse ecrire sans deproteger la memoire basse.



>Pas pour pouvoir eviter les contraintes !
>Pour etre plus performant !

Les deux.

>>- 0x40000 pour HW 2 AMS 2 sans HW2Patch (mais le HW2 AMS 2 TSR support est
>>nécessaire dans ce cas)
>>Donc il faut que ça tourne là-dessus.
>Et un programme kernel ne peut pas le faire ?

Le jour où un kernel tournera sur HW2 AMS 2 sans HW2Patch (mais avec h220xTSR), peut-être.

>En quoi il ne peut pas ajouter $40000 a une adresse ?

Si, et il doit même le faire, sinon UnInEvHk ne reconnaîtra pas le hook. (C'est aussi écrit dans evhkconv.txt, et tu peux vérifier dans les sources de UnInEvHk si tu ne me crois pas.)

>>Et je vais peut-être mettre le fait que le mode kernel est interdit
>>explicitement dans la prochaine version de evhkconv.txt.
>Pourquoi ?

Parce qu'il n'est pas compatible avec HW2 AMS 2 non patché.

>Oui, mais aussi un truc du genre :
> dc.l 'Ev2t' ; Oublie signature

C'est 'evHk'.

> dc.l 0,0 ; Nom
>old dc.l 0 ; Liste chaine
> movem.l d0-d7/a0-a6,-(sp)
> bsr exec
> movem.l (sp)+,d0-d7/a0-a6
> move.l old(Pc),-(sp)
> bne.s ok
> addq.l #4,sp
>no rts
>...
>Oups ... je respecte pas a 100% ta convention.

Là, je pense que c'est tout à fait acceptable. Je ne peux pas penser à une situation où ça pourrait poser problème.

>Pourtant c'est plus clean.

Pas vraiment. Enfin, ça dépend de ce qu'on entend par "clean".

>A ces contraintes, c'est vraiment chiant

Ma convention est la seule manière d'éviter une catastrophe si on essaye de mettre plusieurs hooks en même temps. Et en effet, avant, les hooks d'évènements étaient écrits vraiment n'importe comment, comme ceux de TeOS et DoorsOS par exemple (qui ne prennent pas du tout en considération l'idée qu'un autre hook pourrait avoir été installé avant).

>>Surtout il n'y a pas besoin de relogement puisque le bloc d'un TSR n'est pas déplacé!
>Heu... oui. Mais pourquoi tu le dis ?

Parce que quand un kerneliste parle de "stub", ma première association est tout de suite de mettre une dizaine de tables de relogement différentes.

>Non, il pourrait s'agir d'une erreur,

Tu penses qu'on écrit à une adresse comme $40090 par hasard? C'est très improbable!

>un oubli un vecteur non remis en place.

Pas si c'est en dehors de l'espace d'exécution du programme.

>La le programme lui dit explictement de ne pas y toucher.

Mais c'est une tâche de plus pour le programme. Alors que le kernel pourrait le faire. Et l'algorithme que j'ai donné pourrait même être utilisé dans un bon anti-crash pour le _nostub.

>>Et la plupart des grands classiques en font partie.
>Je sens la frustration de Tetris la ...

Ne te préoccupe pas, j'avais déjà abandonné Tetris89 bien avant les kernels parce qu'il m'a toujours reconnu des touches 2 fois, ruinant ainsi toutes les parties longues.

>MacIntoc:
>Kevin, je suis pas sûr, mais je pense que tu t'es fait avoir :
>tu dis toi même que les kernels ne sont en définitifs que des TSR. Je penses pas que tu en soit à un TSR prés d'installer ?

C'est un TSR incompatible avec h220xTSR. Je refuse d'installer des TSRs qui nécessitent le HW2Patch.
Et si les programmeurs étaient moins paresseux, ou plus au courant des nouveaux développements (TIGCC 0.92 SP1 permet très facilement l'usage de librairies statiques en assembleur!), ou les deux, les kernels ne seraient pas nécessaires!

>Il suffit de vérifier si la signature est correcte. Ils sont capables de le faire. Mais je ne pense pas non plus qu'ils prennent le temps de le faire.
Et si on est a l'ecran 'Press I to install', comment qu'ils font ?
On peut toujours dire qu'on a debranche le cable durant le transfert, ce qui engendrera une mauvaise signature.

>Ben si. Un OS de calculatrice n'est pas un OS d'ordinateur.
Pourquoi ?

>Si tu interceptes le trap #$B fonction #$f, ça peut fonctionner exactement aussi bien ou mal que pour les programmes en mode kernel. Il faut juste faire
>en sorte que ça marche correctement en combinaison avec h220xTSR (qui lui aussi passe par cela).
Certes... mais j'ai trouve une autre solution qui me semble bien meilleure et marcherait sur tous les AMS.

>Si on garde l'adresse du bloc dans un registre et que le système de multitâchage garde la valeur de ce registre séparément pour chaque instance du
>programme (comme il faut), alors il n'y a pas de problème.
Oui.

>La table au début du programme.
Cool. Je suis en train d'essayer de compresser les tables de relogement

>Il y a la routine de Samuel Stearley. On trouve ça dans XtraKeys et dans Complete en assembleur et dans AutoStart en C. Et elle n'est pas longue du tout.
Mais plus longue qu'un lea tio::dcdd,a0

>Parce qu'il y a des choses qu'on ne peut pas faire, ou pour lesquelles il y a des choses inutilement compliquées à faire. C'est exactement ce que tu
>critiques pour le _nostub (choses inutilement compliquées), mais pour le kernel, tu le défends au nom d'une "protection" qui ne peut être parfaite en
>l'absence d'une MMU.
Elle n'est pas parfaite mais elle existe bel et bien. Et je l'essayes chaque jour.

>>Et un programme kernel ne peut pas le faire ?
>Le jour où un kernel tournera sur HW2 AMS 2 sans HW2Patch (mais avec h220xTSR), peut-être.
Et alors ? Pour installer le TSr on a besoin d'un kernel, mais une fois installe on peut desonstaller le kernel

>Si, et il doit même le faire, sinon UnInEvHk ne reconnaîtra pas le hook. (C'est aussi écrit dans evhkconv.txt, et tu peux vérifier dans les sources de
>UnInEvHk si tu ne me crois pas.)
Je n'ai pas compris pk d'ailleurs.

>Parce qu'il n'est pas compatible avec HW2 AMS 2 non patché.
Et alors ?
Si la calc est pactche, le kernel tourne et les tsr tournent !

> dc.l 'evHK' ; Oublie signature
> dc.l 0,0 ; Nom
>old dc.l 0 ; Liste chaine
> movem.l d0-d7/a0-a6,-(sp)
> bsr exec
> movem.l (sp)+,d0-d7/a0-a6
> move.l old(Pc),-(sp)
> bne.s ok
> addq.l #4,sp
>no rts
>Là, je pense que c'est tout à fait acceptable. Je ne peux pas penser à une situation où ça pourrait poser problème.
D'ailleurs c'est plus simple que ton code avec rechargement de a2... et plus clean. (On laisse tous les registres tels que).

>Ma convention est la seule manière d'éviter une catastrophe si on essaye de mettre plusieurs hooks en même temps. Et en effet, avant, les hooks
>d'évènements étaient écrits vraiment n'importe comment, comme ceux de TeOS et DoorsOS par exemple (qui ne prennent pas du tout en considération l'idée
>qu'un autre hook pourrait avoir été installé avant).
Tu es content : PreOs n'utilises pas du tout EV_hook.
Il le laisse tel que.

>Parce que quand un kerneliste parle de "stub", ma première association est tout de suite de mettre une dizaine de tables de relogement différentes.
Pas forcement. C'est quelque chose en plus, de maqique.

>Tu penses qu'on écrit à une adresse comme $40090 par hasard? C'est très improbable!
OUI ! Il suffit qu'il reste lors de l'installation d'un autre vecteur, petite modif de a2, et
reecriture du vecteur

>Mais c'est une tâche de plus pour le programme. Alors que le kernel pourrait le faire. Et l'algorithme que j'ai donné pourrait même être utilisé dans un
>bon anti-crash pour le _nostub.
Sauf qu'il l'installe, le copie, alloue le bloc, ajoute ta convention, realloue le tsr, ...
Bref il en fait plus !

>Ne te préoccupe pas, j'avais déjà abandonné Tetris89 bien avant les kernels parce qu'il m'a toujours reconnu des touches 2 fois, ruinant ainsi toutes les
>parties longues.
Certes. Mais queue est pire.

>C'est un TSR incompatible avec h220xTSR. Je refuse d'installer des TSRs qui nécessitent le HW2Patch.
Si tu veux je te fais une version speciale compatible hw2tsr...
Mais je ne garantis pas son bon fonctionnement

>Et si les programmeurs étaient moins paresseux, ou plus au courant des nouveaux développements (TIGCC 0.92 SP1 permet très facilement l'usage de
>librairies statiques en assembleur!), ou les deux, les kernels ne seraient pas nécessaires!
Arf !
Tu oublies tous les TSR necessaires a installer pour remplacer un kernel (Afin de lever toutes les protections).
Et je ne parles pas des libs dynamqiues.

j'adore la longueur de ces posts

Si ces posts sont longs, c'est qu'on a des choses a dire.

oué, ça vaut mieux
Mais c'est instructif, au moins.

>PpHd:
>>Ben si. Un OS de calculatrice n'est pas un OS d'ordinateur.
>Pourquoi ?

C'est comme ça. Les attentes d'un OS de calculatrice sont différentes. (On s'attend moins d'un OS de calculatrice que d'un OS d'ordinateur.)

>>Si tu interceptes le trap #$B fonction #$f, ça peut fonctionner exactement aussi bien ou mal que pour les programmes en mode kernel. Il faut juste faire
>>en sorte que ça marche correctement en combinaison avec h220xTSR (qui lui aussi passe par cela).
>Certes... mais j'ai trouve une autre solution qui me semble bien meilleure et marcherait sur tous les AMS.

Et ça serait...? (Je suis curieux. )

>>>Et un programme kernel ne peut pas le faire ?
>>Le jour où un kernel tournera sur HW2 AMS 2 sans HW2Patch (mais avec h220xTSR), peut-être.
>Et alors ? Pour installer le TSr on a besoin d'un kernel, mais une fois installe on peut desonstaller le kernel

Mais on ne peut pas désinstaller le HW2Patch, même en RAM, sans un reset qui virerait aussi le TSR.

>>Si, et il doit même le faire, sinon UnInEvHk ne reconnaîtra pas le hook. (C'est aussi écrit dans evhkconv.txt, et tu peux vérifier dans les sources de
>>UnInEvHk si tu ne me crois pas.)
>Je n'ai pas compris pk d'ailleurs.

C'est écrit dans evhkconv.txt, mais je le répète quand-même:
C'est une deuxième protection contre les hooks d'évènements incompatibles en plus de la signature "evHk".
Et c'est aussi un moyen de pression pour forcer les programmeurs à faire des TSR compatibles avec h220xTSR.

>>Parce qu'il n'est pas compatible avec HW2 AMS 2 non patché.
>Et alors ?
>Si la calc est pactche, le kernel tourne et les tsr tournent !

Je suis contre quand-même.

>Tu es content : PreOs n'utilises pas du tout EV_hook.
>Il le laisse tel que.

Oui. Universal OS ne touche pas à EV_hook non plus d'ailleurs.

>>Tu penses qu'on écrit à une adresse comme $40090 par hasard? C'est très improbable!
>OUI ! Il suffit qu'il reste lors de l'installation d'un autre vecteur, petite modif de a2, et
>reecriture du vecteur

Ça ne m'a pas l'air très probable tout de même.

>Si tu veux je te fais une version speciale compatible hw2tsr...
>Mais je ne garantis pas son bon fonctionnement

Ça vaudrait bien un essai.

>Tu oublies tous les TSR necessaires a installer pour remplacer un kernel (Afin de lever toutes les protections).

h220xTSR + IPR suffisent pour lever toutes les protections (HW2, "ASAP or Exec string too long", "Invalid Program Reference").

>Et je ne parles pas des libs dynamqiues.

Toi avec tes libs dynamiques...

>C'est comme ça. Les attentes d'un OS de calculatrice sont différentes.
>(On s'attend moins d'un OS de calculatrice que d'un OS d'ordinateur.)
Pour une calc comme la 89/92p, mes attentes sont les memes.

>Et ça serait...? (Je suis curieux. )
Faire un hot reboot.
Je resete la calc en reecrivant une partie de EV_centralDispatcher.
J'ai essaye ca marche, et ca permetra peut etre de faire une protection nostub stable.
Mais faut encore que je sache vider:
+ Les ER_throw (facile)
+ Les fenetres (s'il reste des fenetres a virer).
+ Fermer toutes les apps pour les restarter (Sinon ca plante par un internal_error).
Mais ca ne resout pas tous les pbs... Enfin, on verra.

>Mais on ne peut pas désinstaller le HW2Patch, même en RAM,
>sans un reset qui virerait aussi le TSR.
T'es difficile.

>Et c'est aussi un moyen de pression pour forcer les programmeurs à faire
>des TSR compatibles avec h220xTSR.
Je crois plutot

>Je suis contre quand-même.
A cool. J'ai gagne la

>Ça ne m'a pas l'air très probable tout de même.
Mais loin d'etre impossible.

>Ça vaudrait bien un essai.
J'essairais. Mais d'abord je finis de le rendre stable (et surtout finir la protection nostub qui me fait trop *ù*ù*ù*^$*$*).

>h220xTSR + IPR suffisent pour lever toutes les protections
>(HW2, "ASAP or Exec string too long", "Invalid Program Reference").
Oui

>Toi avec tes libs dynamiques...
Mais j'aime ca !

>+ Fermer toutes les apps pour les restarter (Sinon ca plante par un internal_error).

Sous AMS 1, les numéros des applications sont fixes et il y a juste à envoyer l'évènement de fermeture de l'application à chaque numéro d'un intervalle donné avec EV_sendEvent.
Sous AMS 2, tu prends une application arbitraire (par exemple TIHOME), tu lis son AppId avec EV_getAppId, qui est aussi le handle de son ACB, et tu traverses la liste doublement chaînée des ACBs dans les 2 sens en partant de l'application choisie pour envoyer l'évènement de fermeture à toutes les applications installées.
Cf. la documentation de TI FlashStudio (le SDK officiel de TI) pour le layout des ACBs, et celle de TIGCC, ainsi que ses sources (pour certaines constantes), pour tout le reste.

>+ Les fenetres (s'il reste des fenetres a virer)

Les fenêtres sont également dans une liste chaînée qui devrait te permettre de les fermer toutes. Cf. http://tigcc.ticalc.org/doc/wingraph.html#FirstWindow.

Mais je pense que ton approche pourrait causer de sérieux ennuis si des TSRs ont été installés avant PreOS. Et puis, utiliser ton propre distributeur central d'évènements (central event dispatcher) donnera probablement à PreOS une réputation d'être mal programmé et instable. En tout cas, moi, j'ai bien peur que ça peut entraîner plusieurs ennuis, surtout des incompatibilités subtiles, qui ne se font remarquer que dans certaines conditions qui font tout planter.

Merci pour les informations. Il faudra que j'essaye.