Discussion :

[Utundu]

Bonsoir,

Je dois revectoriser l'interruption 08h pour faire appel à une procédure perso.
Seulement voilà, ça ne fonctionne pas ...

• Quand je laisse l'horloge appeler mon interruption, mon débuggeur se fige à la première ligne de celle-ci et tout l'environnement (DOS & pwb) plante, sans m'informer de quoi que ce soit ...
• A l'inverse, quand j'appelle INT 08h dans ma boucle principale, aucun soucis : le débuggeur entre dans la procédure, en ressort et tout se passe bien.

J'ai essayé avec 1Ch, pas mieux ...

Je précise que j'appelle une autre procédure dans ma procédure d'interruption, qui est un peu "lourde" (50 instructions à tout casser).
J'ai cru comprendre qu'il était conseillé d'en faire le moins possible dans 08h ...
Cela dit, même en commentant l'appel à mon autre procédure, voire tout sauf le iret, c'est pareil.

Au cas où, l'interruption en question, bien que je doute que ça vienne de là ... Mais alors d'où ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
NewInt	proc	far
	push	 ds
	push	 ax
	mov	 ax,MyData
	mov	 ds,ax
	assume	ds:MyData
 
	; Ancienne 08h
	CALL Ex08h 
       ; Ex08h est un double mot stockant l'adresse de l'ancienne 08h récupérée plus tôt de la sorte : 
        ;MOV AH, 35h
	;MOV AL, 08h
	;INT 21h
	;MOV WORD PTR[Ex08h], BX
	;MOV WORD PTR[Ex08h+2], ES
 
	;Procédure utile au programme
	CALL UpdateData
 
	pop	 ax
	pop	 ds
	assume	ds:nothing
	iret
NewInt   ENDP

Je sais que c'est très peu, mais je suis perdu et ne sais pas vraiment dans quelle direction orienter mes recherches.

Merci d'avance pour votre aide.

[Obsidian]

Bonjour et bienvenue,

Il y a effectivement plusieurs erreurs.

D'abord, ton CALL est incorrect. Il manque au minimum un FAR pour lui faire comprendre qu'il faut faire un bond sur 32 bits en tenant compte du segment. Ensuite, il faut effectuer une indirection avec « [ ] » car écrit de cette façon, ton programme va sauter à l'adresse où se trouve cette variable (qui ne contient donc rien d'exécutable) et pas à l'adresse indiquée par cette variable.

Ensuite, tu ne peux pas appeler une interruption de cette manière. Une interruption, qu'elle soit déclenchée matériellement via les IRQ ou logiciellement par l'instruction INT, provoquement l'empilement de plusieurs registres, dont les flags, et inhibe les IRQ à venir le temps de la procédure. C'est pour cela qu'il existe une instruction IRET (« Interrupt Return ») et que l'on utilise pas simplement RET. Ça veut dire que si tu souhaites appeler une autre interruption en cascade depuis ta routine, il faut soit le faire avec INT, soit empiler toi-même les bons registres pour que l'état de celle-ci soit compatible avec l'instruction IRET située au bout de l'interruption que tu appelles.

Dans le cas le plus courant, sous DOS, quand on veut simplement faire un hook comme le tien, on redirige le vecteur sur sa routine, on effectue les tâches demandées et on termine par un JMP vers la routine originale, à qui on laisse le soin de sortir.

Enfin, effectivement, il est recommandé d'en faire le moins possible et de s'efforcer d'écrire des routines d'interruptions les plus rapides possibles. Par exemple, si l'arrivée d'une interruption doit déclencher le démarrage d'une procédure relativement longue, il est préférable de faire en sorte que son handler lève un flag qui sera ensuite examiné par le flot normal. Il est également très déconseillé, en dépit de mon paragraphe précédent, d'appeler les interruptions en cascade. Entre autre ennuis, tu risques de faire face à des problèmes de réentrance. Il faudra alors mettre en place une sorte de mutex pour éviter les boucles infinies et les débordements de pile.

[Utundu]

Merci pour ta réponse Obsidian.

Si je comprends bien, si je modifiais ma procédure de la sorte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
NewInt	proc	far
	JMP [Ex08h]
NewInt   ENDP

Cela devrait fonctionner (ça ne sert à rien pour mon application, soit), ou tout du moins ça ne devrait pas planter n'est-ce pas ?

Edit : et avec l'appel à ma procédure avant, ça fonctionne bien. Merci infiniment Obsidian ! Bon, le débuggeur continue de planter, mais l'exécution se déroule correctement.
Puis-je abuser et poser une petite question ? Est-il normal que la mémoire ne soit pas libérée une fois le programme exécutée ? Tout du moins, PWB ne veut plus se lancer par manque de mémoire après une exécution ("programme trop grand pour tenir en mémoire")... De quoi cela pourrait-il venir ?

[Obsidian]

Cela devrait fonctionner (ça ne sert à rien pour mon application, soit), ou tout du moins ça ne devrait pas planter n'est-ce pas ?

N'oublie pas de faire un JMP FAR !

Puis-je abuser et poser une petite question ? Est-il normal que la mémoire ne soit pas libérée une fois le programme exécutée ? Tout du moins, PWB ne veut plus se lancer par manque de mémoire après une exécution ("programme trop grand pour tenir en mémoire")... De quoi cela pourrait-il venir ?

Probablement de la même chose qu'au-dessus, mais c'est difficile à dire sans voir l'affaire de mes propres yeux car je ne connais pas du tout PWB.

[Utundu]

Mon compilateur ne veut pas de cette syntaxe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

JMP FAR [var]

Cela semble marcher sans ... semble ...

[Obsidian]

Mon compilateur ne veut pas de cette syntaxe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

JMP FAR [var]

Étrange. Ça fonctionne avec NASM mais celui-ci est parfois plus permissif que la syntaxe originale d'Intel, ou en tout cas celle de MASM. As-tu bien remplacé « var » par « Ex08h » ?

Cela semble marcher sans ... semble ...

Si ton code source est appelé avant la routine initiale, tu peux en avoir l'impression effectivement

[Utundu]

Pardon pour le retard, j'ai eu quelques soucis à régler

Mon problème n'est pas résolu, ça ne faisait en effet que "sembler" fonctionner.
Ma nouvelle routine, avant de passer à l'ancienne par un JMP comme abordé ci-dessus, appelle une procédure Y qui ... ne permet pas de revenir dans la routine pour la finir (un dispatcher).

Il faudrait donc que ma routine ne passe la main à Y que lorsqu'elle s'achève. Je pense qu'il est possible de manipuler la pile pour faire ceci, de sorte que le IRET m'amène à l'endroit voulu. Mais je dois me tromper dans mes essais, car cela plante ...

Comment pourrais-je manipuler la pile pour qu'à la sortie du JMP Ex08h, et seulement après, je passe à Y ?

Merci

[Obsidian]

Pardon pour le retard, j'ai eu quelques soucis à régler

Mon problème n'est pas résolu, ça ne faisait en effet que "sembler" fonctionner.
Ma nouvelle routine, avant de passer à l'ancienne par un JMP comme abordé ci-dessus, appelle une procédure Y qui ... ne permet pas de revenir dans la routine pour la finir (un dispatcher).

Ta routine Y a été écrite par qui ? Est-ce que c'est une autre interruption BIOS ou est-ce que c'est un sous-programme à toi ? La manière de l'appeler sera différente en fonction de ces deux cas.

Il faudrait donc que ma routine ne passe la main à Y que lorsqu'elle s'achève. Je pense qu'il est possible de manipuler la pile pour faire ceci, de sorte que le IRET m'amène à l'endroit voulu. Mais je dois me tromper dans mes essais, car cela plante ... Comment pourrais-je manipuler la pile pour qu'à la sortie du JMP Ex08h, et seulement après, je passe à Y ?

Il faut reconstruire ce qui est en principe empilé par l'interruption elle-même (matérielle ou via INT xx). Essaie d'empiler les flags (avec pushf) puis d'appeler la routine d'interruption habituelle avec un CALL FAR.