erreur doorsos - Page 3

Oui. Au fait, (attenton encore un "ou tout l'un ou tout l'autre")
tu pourrais pas implémenter un RAM Call d'allocation de mémoire sécurisée ?
Je veux dire par là qu'il y aurait une pile des handles, comme genlib,
et que quand on quitte sans libérer tous les handles PreOS peut le détecter et
les libérer lui-même, ou bien quand il y a une erreur il ne se contente pas
de récupérer seulement l'erreur (Crash Intercepted d'accord, mais la mémoire système est passée
à 90000 et la caltos va devoir resetter de toute manière), mais plutôt qu'il intercepte l'erreur
ET libère les handles éventuellement alloués.

Il ne le fait pas déjà ?

Je n'en suis pas sûr mais je ne crois pas, vu que s'il le fait je n'ai aucune idée de comment,
car il n'y a pas de RAM Call pour ça, et je ne sais pas comment PreOS
pourrait repérer un appel de HeapAlloc par exemple. (Va pas modifier les ROM Calls quand m^ )

Je crois qu'il ne le fait correctement que pour les progs kernel (attention, ceci n'est pas une certitude !!!)

Enfin bon faut pas trop déresponsabiliser le codeur non plus, c'est quand même assez crade de ne pas libérer soi-même ses handles, en cas de crash je veux bien que le kernel tente de recoller les bouts, mais sinon.. Et en plus c'est pas la mort à coder soi-même ce genre de fonction

, bien que j'aurais préféré ça à la place des extensions des fonctions TI-Basic.

Ximoon > pense à ceux qui n'ont pas connu la stabilité de Fargo I, ils ne savent pas ce que c'est

Tout ce qui est NoStub a tendance a très bien marcher.
Les seuls bugs que j'ai eu:

- Kerno a provoqué un Reset récemment
- Edit3D plante au bout d'un certain temps, il y a une fuite mémoire quelquepart.
- Quand je passe n'importequoi à flib et vertel il arrive aussi que ça plante.

Enfin, ajoutons que quand j'ai commencé aucun programme Kernel ne marchait sur ma 92+ (car hw2 et AMS 2.05)
jusqu'à la sortie de UniOS 1.30/hw2patch. Quand 'essayait Doors II avec l'ancien patch, ça plantait.
Donc pendant un petit moment je suis resté en NoStub pur, les jeux de FlashZ notamment.
Et j'ai jamais eu d'autre plantage que ceux ci-haut, à part avec les programmes, qui sont de
très méchants hacks très mal programmés (sciemment)

Il libere automatiquement les handles d'un programme kernel (saufs les handles de la VAT et de la home screen).
En _nostub, c'est impossible.

Comment il repère un HeapAlloc ?
Avec les définitions un pe spéciales des ROM Calls en kernel ?

Si en kernel j'appelle à la main:

move.l ($C8),a5
move.l 576(a5),d0
move.w #150,-(a7)
jsr (a0)

Là il va le repérer ?

Comment il fait ?

Reflechis. C'est simple.

Vraiment, je ne trouve pas...
Est-ce que tu touches aux ROM Calls ? (Est-ce que tu modifies la table ou qqch comme ça ?)
Et si c'est en regardant dans le code, j'ai aussi du mal à voir pourquoi ce serait impossible en nostub... ???

PpHd :
Pas forcement. Kerno n'intercepte pas aussi bien les crash que preos

Mais l'anti-crash de KerNO fonctionne contrairement à l'anti-crash _nostub de PreOs. (Cf. le bogue avec ESC+ON reporté par geogeo et confirmé par d'autres.)

Tu veux dire le contraire ?

Mais l'anti-crash de PreOS fonctionne contrairement à l'anti-crash _nostub de KerNo. (Cf. le bogue avec ESC+ON reporté par geogeo et confirmé par d'autres.)

PpHd
: En _nostub, c'est impossible.

En _nostub sous AMS 2, c'est possible!
Je peux intercepter le lancement de n'importe quel programme de manière fiable. (La preuve: sinon, h220xTSR ne marcherait pas.)

Reste le problème des TSRs, mais si un kernel fait le travail proprement, ça poussera les auteurs de TSRs (*ahem* moi *ahem* - Samuel Stearley le fait déjà, par exemple) à mettre enfin le flag INCOMPAT_CREATES_HANDLES qu'on est censés mettre depuis quelques mois déjà. Et on peut prévoir un programme de style mkcompat qui rajoute le flag à un programme existant.

./77: Oui mais je ne suis pas sur que ca soit suffisament stable.

PpHd :
Tu veux dire le contraire ?

Mais l'anti-crash de PreOS fonctionne contrairement à l'anti-crash _nostub de KerNo. (Cf. le bogue avec ESC+ON reporté par geogeo et confirmé par d'autres.)

Ben non!
Lis le topic d'Arkanoid.
D'ailleurs, le code fonctionnait quand je l'ai écrit. Ça doit être toi qui as modifié quelque chose que tu n'aurais pas dû.

KerNo est notoirement buggue avec ESC+ON...
je n'ai rien change dans le ESC+ON depuis longtemps.

il se met où, le flag INCOMPAT_CREATES_HANDLES ? dans les progs nostub ou les progs kernel ?

donc c'est dans les programmes nostub...
ça obligerait pas à utiliser le format _nostub ? ET si on veut pas l'utiliser ?

Flanker
: il se met où, le flag INCOMPAT_CREATES_HANDLES ? dans les progs nostub ou les progs kernel ?

RTFM

Flanker
: ça obligerait pas à utiliser le format _nostub ? ET si on veut pas l'utiliser ?

En kernel, c'est PpHd qui décide, et il a gentiment décidé pour vous qu'il faut utiliser tios::HdKeep.
Et ça n'a rien à voir avec le format de commentaires/flags _nostub, les kernels libéraient les handles sans demander bien avant ça déjà.

Reste le problème des TSRs, mais si un kernel fait le travail proprement, ça poussera les auteurs de TSRs (*ahem* moi *ahem* - Samuel Stearley le fait déjà, par exemple) à mettre enfin le flag INCOMPAT_CREATES_HANDLES qu'on est censés mettre depuis quelques mois déjà. Et on peut prévoir un programme de style mkcompat qui rajoute le flag à un programme existant.

Et si on veut pas utiliser le standard nostub ? Il fait comment le kernel ?

Flanker
:

Reste le problème des TSRs, mais si un kernel fait le travail proprement, ça poussera les auteurs de TSRs (*ahem* moi *ahem* - Samuel Stearley le fait déjà, par exemple) à mettre enfin le flag INCOMPAT_CREATES_HANDLES qu'on est censés mettre depuis quelques mois déjà. Et on peut prévoir un programme de style mkcompat qui rajoute le flag à un programme existant.

Et si on veut pas utiliser le standard nostub ? Il fait comment le kernel ?

Cf. ./85 (mon post croisé).

En _nostub, tu peux mettre le flag _INCOMPAT_CREATES_HANDLE dans le header standard du _nostub (Cf doc de Kevin sur le sujet) et esperer que le programme appelant gere ce flag.
En kernel, tu peux appeler la fonction kernel::HdKeep pour signifier au kernel que cet handle n'a pas a etre efface (REM: Les handles des fichiers et de home ne sont pas effaces). Il faut aussi que le kernel le gere (Preos quoi).

C'est ce que j'ai dit.

Je n'etais pas sur qu'il ait bien compris. Oui, oui