How I return from dword call in genuine real mode
How I return from dword call in genuine real mode
Let say I execute JMP DWORD (CS:)12345678h, then I execute CAL DWORD 00000025h, now, how I load the old EIP I pushed with the dword CALL and keep in higher RAM? I prefer to do it with a RET if possible, but I think I cant code dword RET in real mode, can I?
-
thepowersgang
- Member
- Posts: 734
- Joined: Tue Dec 25, 2007 6:03 am
- Libera.chat IRC: thePowersGang
- Location: Perth, Western Australia
- Contact:
Re: How I return from dword call in genuine real mode
As far as I know, that jump should either fail with a segment limit violat, or be truncated to 16-bits. In either case, you will never end up with that high address on the stack.
Read the intel manuals to confirm this.
Read the intel manuals to confirm this.
Kernel Development, It's the brain surgery of programming.
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc
Acess2 OS (c) | Tifflin OS (rust) | mrustc - Rust compiler
Currently Working on: mrustc
-
Octocontrabass
- Member
- Posts: 5524
- Joined: Mon Mar 25, 2013 7:01 pm
Re: How I return from dword call in genuine real mode
In genuine real mode, the jump will cause a general protection fault.
In unreal mode, you might be able to do it. (Probably "O32 RETN".) However, you really should be using protected mode.
In unreal mode, you might be able to do it. (Probably "O32 RETN".) However, you really should be using protected mode.
Re: How I return from dword call in genuine real mode
Damn I forgot completely about the segment limits...
because I cant give to my virtual machine too much RAM, I could try that instructions only with negative jumps, that way I confirmed that this instruction is totally executable and the whole part of the dword offset is used in the address calculation. Why the virtual machine didn't hanged when I executed that jmp 123455...?! Anyway, because I used that instruction for test purposes and it worked I assumed they would do what they are made for, to jump dword away and forgot about segment limits. Sometimes the logic of Intel is confusing me. Like the RETD instruction. I can read about that in the manuals and know how it behave, but then I am asking myself, why should I want to load EIP from the stack on IRET when I cant push it on INT, I searched, there is no way to code a "dword INT xxh" and push 12 bytes to stack, why dword iret is valid then?
All this is very confusing. It would be enough for me to repeat the instructions for my emulator, and let the emulated code have the guilty if something goes weird, but often I wish to know why are those rare conditions present and how the emulated code could use them-to mess with the system?! to make it hang?! I wish to know some reason for that instructions to be there.
Maybe they are a not removed legacy from the unreal mode? Like designers of CPU thought like: we will not deactivate dword calls when in real mode, who on earth could use them if not in unreal mode. hmmmm I'm not blaming anybody, oh, how could I?! I am new, and I am wannabe, but it's all very confusing or me.
PS: First time I coded jmp dword for the emulator I put a comment on the side like:
;I will code the case of dword jump too if somebody is executing it like 066h, 0E9h, 34h, 12h, 00h, 00h where last 0-s doesn't matter and it would be like coding 0E9h, 34h, 12h, 90h, 90h, 90h instead a NOP fill.
because I cant give to my virtual machine too much RAM, I could try that instructions only with negative jumps, that way I confirmed that this instruction is totally executable and the whole part of the dword offset is used in the address calculation. Why the virtual machine didn't hanged when I executed that jmp 123455...?! Anyway, because I used that instruction for test purposes and it worked I assumed they would do what they are made for, to jump dword away and forgot about segment limits. Sometimes the logic of Intel is confusing me. Like the RETD instruction. I can read about that in the manuals and know how it behave, but then I am asking myself, why should I want to load EIP from the stack on IRET when I cant push it on INT, I searched, there is no way to code a "dword INT xxh" and push 12 bytes to stack, why dword iret is valid then?
All this is very confusing. It would be enough for me to repeat the instructions for my emulator, and let the emulated code have the guilty if something goes weird, but often I wish to know why are those rare conditions present and how the emulated code could use them-to mess with the system?! to make it hang?! I wish to know some reason for that instructions to be there.
Maybe they are a not removed legacy from the unreal mode? Like designers of CPU thought like: we will not deactivate dword calls when in real mode, who on earth could use them if not in unreal mode. hmmmm I'm not blaming anybody, oh, how could I?! I am new, and I am wannabe, but it's all very confusing or me.
PS: First time I coded jmp dword for the emulator I put a comment on the side like:
;I will code the case of dword jump too if somebody is executing it like 066h, 0E9h, 34h, 12h, 00h, 00h where last 0-s doesn't matter and it would be like coding 0E9h, 34h, 12h, 90h, 90h, 90h instead a NOP fill.