>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.
parce que c'est plus simple a l'usage.
>Et je crois bien me rappeler que tu as dit qu'elle n'est pas non plus dans PreOS.
Si elle y est.
>Et puis, ce n'est pas compliqué de désallouer un handle. Et le programme sait mieux
>désallouer ses propres handles qu'un kernel externe ne peut le faire.
Tout systeme d'exploitation digne de se nom fait un clean-up complet apres l'utilisation d'un programme. Et puis l'application peut alors se simplifier la vie, et ne pas liberer les handles.
C'est configurable avec un 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.
>Il suffit de programmer correctement et tout ceci n'est pas nécessaire.
>Et il est toujours mieux de programmer correctement que de se fier à l'anti-crash.
Mais l'utilisateur sera content d'avoir un anti-crash.
Il fera plus confiance aux programmes.
>>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.
>>Et les sections BSS ?
>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.
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 puis, Sebastian compte rajouter cette fonctionnalité au linker de TIGCC
>dans une version future (mais chut ).
Arf. La taille des nostub va encore augmenter.
>>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 !
>2. On peut aussi avoir 2 versions différentes pour chaque calculatrice
>(et ça prend moins de place).
Oui, et la compatibilite tu connais ?
>3. Je n'ai jamais vu quelqu'un utiliser cela dans une source.
Moi dans 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 ?
>>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.
>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
>3. Il n'y a pas toutes les adresses dont on peut avoir besoin.
>Par exemple, où est doorsos::HomeScreenEntryLine?
Pas de pbs, je te la mets
>4. Sebastian compte les mettre directement dans les linker (encore une fois, chut ).
A tiens ? Et c'est inutile ?
>>Ben, oui comme tu dis un TSR a besoin de plus de droits que le kernel ne lui donne.
>LOL.
Pourquoi LOL ? L'execution d'un programme kernel se fait dans un environnement bien plus protege que celui d'un nostub.
>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.
> Déjà la protection anti-débordement de la pile et les 2
>modes du processeur sont suffisamment soulants
Hein ?????????????????????????????????????
tu trouves ca soulant ??????????????????????
Mais c'est indispensable !
>(et la protection des HW2 encore plus),
Oui la ok.
>il ne faut pas en rajouter, merci.
> Surtout dans quelque chose qui était prévu à l'origine pour faciliter la programmation
>(le kernel).
Plus un environnement est soumis a des contraintes (savamment choisies), plus la programmation est facile. Cf les langages de hauts-niveaux.
>>Et oui effectivement il faut passer par un nostub actuellement pour le faire.
>>Veux-tu que je fasses une fonction kernel : installTSR(void *start, short size, void
>>*exec, short traps) ?
>Non merci. Je ne l'utiliserais pas de toute façon.
Et les autres ?
>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, respecterait tes conventions de TSR, permettrait de rajouter un mini-stub aux TSR.
Et elle permettrait de dire au kernel qu'effectivement, il y a changement.
>>> La flexibilité de ne pas pouvoir laisser un message dans la barre d'état sous
>>> quelques kernels?
>>O c'est grave !
>Et oui, c'est bien pratique de pouvoir laisser un message. C'est par exemple une
>manière discrète pour afficher le nom du programmeur.
PreOs intercepte le dernier ST_ShowHelp et le reaffiche en quittant
>>> La flexibilité de ne pas marcher sur HW2 AMS 2 non patché (et aussi sans h220xTSR, d'ailleurs)?
>>Pareil pour tous les TSR !
>Ben non, les miens n'ont pas besoin du HW2Patch.
>Et h220xTSR est inclus, donc pas la peine de l'installer avant non plus.
Je te signales que la derniere version d'unios installe automatiquement HW2patch en RAM s'il n'est pas installe. Donc ca revient au meme.
>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.
>>Non, de limitations que l'on imposes pour avoir plus de stabilite.
>LOL. Jamais vu cette stabilité. (Au contraire, les kernels et les programmes pour
>kernel ont une réputation, pas totalement injustifiée, de planter sans arrêt.)
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.
>>> Le seul résultat est que ça limite les possibilités.
>>Ce n'est en aucune facon de l'inflexibilite !
>Si, ça en est bien une.
Non !
>>Non, il rajoute un format en plus du format nostub !
>Oui, mais ce format est lu et "interprété" par un programme au format _nostub AMS,
>donc on passe bien par ce format.
Oui mais c'est une surcouche de ce format ! (On va ya arriver )
>>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 !
>Au lieu de faire une fonction kernel pour détourner les ints qui serait utilisée que par peu de progs, tu devrais rajouter des flags pour demander de ne pas réstaurer les vecteurs (et pareil pour la réstauration de l'écran, comme Unios 1.31).
Non, c'est mieux avec une fonction. Et plus simple.
>>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 !
Dans cette version de KerNO, Greg Dietsche a oublié 1 instruction pour le faire tourner avec mon h220xTSR. Il va nous corriger cela.
