flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
b1528932 07 Jan 2011, 22:34
wouldnt be easier to emulate int instead of putting handler to 0xff?
|
|||
![]() |
|
edfed 07 Jan 2011, 23:02
it is possible if:
jmp far[eax] at the end of the interrupt, but as i first want to use the original int9 management pior to read a scancode from 60h, it is the only way. |
|||
![]() |
|
b1528932 08 Jan 2011, 00:23
int = pushf + far call.
just install this hook by overwriting ivt, and new handler save arguments then far calls handler after pushf'ing flags, then you deal with arguments. |
|||
![]() |
|
edfed 08 Jan 2011, 00:44
yeah, why not, then, i will be forced to use a dword for irq1.saveold.
since i plan on the use of BDA for the irq1.code byte, the irq1.inc handler will be just code, no data at all. it will be easyer then to translate in protected mode. every technical choice have bad and good points. here, the bad point of my choice is the use of int 0FFh, but i nevr heard about the presence of any int 0FFh in any software, then, it is not a problem for me. |
|||
![]() |
|
Ninho 22 Jan 2011, 18:46
edfed wrote: yeah, why not, then, i will be forced to use a dword for irq1.saveold. Int FF is avoided for a good reason : the AT compatible BIOS uses the last bytes of the IVT for its stack while doing a "shutdown" return from protected mode, and will happily trash your interrupt vector in the process ! In case you're too young to remember that, have a look at Ralph Brown's good ol' interrupt list. And should you think this is old stuff, it is old indeed - should you assume it can be ignored, you're wrong. Even Intel's MP specification takes care to mention the "legacy" 80286-type shutdowns among the things that platform BIOSes must respect. |
|||
![]() |
|
edfed 23 Jan 2011, 01:05
then, use int 0F9h.
and frankly, only one thing is important, do something that woirks, not always refer to big brother indications. asm for me is freedom, everything possible, then, no need to become crasy for some limitations, just jump over them. PS: ninho, i don't know you enough to accept your aggresive criticism.. even in a pure technical domain, some personal respect should be the master word. |
|||
![]() |
|
revolution 23 Jan 2011, 01:40
edfed wrote: and frankly, only one thing is important, do something that woirks, not always refer to big brother indications. "Big brother"s do their thing, we might not agree with what they do but we still have to be aware of it so as to make sure our code will work. Being anarchistic is all well and good but not to the point of hurting ourselves with code that fails. |
|||
![]() |
|
Ninho 23 Jan 2011, 11:38
[quote="edfed"]
edfed wrote: ninho, i don't know you enough to accept your aggresive criticism.. even in a pure technical domain, some personal respect should be the master word. Edfed I agree entirely about (mutual) respect as a necessity. I'm uncertain what in my warning made you read disrespect, even less agressivity towards you. Such attitudes simply aren't mine, usually; maybe because English is not my native language, I like to keep "it" strictly technical, did the message /taste/ not too sweet ? I'm verily sorry. Also did you fail to grasp the "warning" was meant to inform not just your person, but every other reader who comes to this thread now or in the future and might not be aware of the possible consequences of the advice given by you ? Quote: and frankly, only one thing is important, do something that woirks, not always refer to big brother indications. As far as I'm concerned, I'm a grand father more than a big brother now ;=) As for the technical point above, methinks you should welcome the warning rather than take offence. Of course while experimenting for yourself, you are welcome to try things that will provably work on your own machines - it is /my/ right and possibly my duty also to warn you (in case you didn't know before) and others who never heard of shutdown returns and all that mess, about the known risks of your approach. /You/ are the one who mentionned, quote, education purposes, unquote :=) Like you said, use another vector - F9 might be safer. Not to be aggressive, but frank altogether, your approach is not one I would pick for interrupt hooking under DOS. Happy new year (if it's not too late for wishes) |
|||
![]() |
|
edfed 23 Jan 2011, 15:11
under dos, i remember, self modifiable code is possible.
very possible, then something like this Code: int9: cli call .pre ;call prefunction pushf ;simulate int .jmpfar@: call far dword0:0 ;simulate int call .post ;call postfunction sti iret .new: mov eax,[0:9*4] mov [.jmpfar@+1],eax mov ax,cs ror eax,16 mov ax,int9 mov [0:9*4],eax sti ret .old: cli mov eax,[.jmpfar@+1] mov [0:9*4],eax sti ret .pre: ret .post: ret thank you for advice, if 0FFh vector use can lead to a crash, it's sure it is not cool... Last edited by edfed on 14 Feb 2011, 21:42; edited 2 times in total |
|||
![]() |
|
bitshifter 23 Jan 2011, 18:42
You have two common choices when hacking irq1
Either jmp far into the old handler or shut up the PICs IR1 (out 20h,20h) and iret. Jumping into the old handler is more preferred since the BIOS stays informed. |
|||
![]() |
|
edfed 23 Jan 2011, 18:47
that's why i made it, because my own irq1 handler does not it, leading to some problems since i test it under real dos, with dpmi installed.
|
|||
![]() |
|
edfed 14 Feb 2011, 21:56
something like a generic way to overide interrupt would be possible, in order to have only 2 functions.
the far pointer to old interrupt to be saved in the dword just before new handler entrypoint. Code: dd ? ;FAR POINTER HERE int9: cli call .pre ;call prefunction pushf ;simulate int call far dword[int9-4] ;simulate int ... then, before to call the overider, pass interrupt vector offset with bx register, and new handler with si register Code: mov si,int9 mov bx,9*4 call newint ... mov si,int9 mov bx,9*4 call oldint ... newint: mov eax,[0:bx] mov [si-4],eax mov ax,cs ror eax,16 mov ax,si mov [0:bx],eax sti ret oldint: cli mov eax,[si-4] mov [0:bx],eax sti ret this would be interresting and i will probably use it in my code now. ![]() and for sure, it can be made fool compatible. ![]() |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.