Re: DRL updated! -- please stop that INT discussion!

X-Comment-To: Eric Auer

Hi!

23-Окт-2002 18:05 [email protected] (Eric Auer) wrote to [email protected]:

EA> To say things about self modifying code and code on stack:
EA> In protected mode, you cannot modify code, unless you explicitly

     But V86 (real mode inside protected mode) is not equal to PM.

EA> have a data segment pointing to the same RAM as your code segment.
EA> If your operating system is paranoid, it will NOT let you execute
EA> code on the stack. But you do not need to despair here: You will
EA> not need all 256 interrupts normally.

     General purpose library can't know which interrupts calling will be
required and can't (shouldn't) restrict this.

EA> For example, I use msdos() which is very likely to have an "int 21h" hardcoded.

     But this works only for INT 21 and you can't use it for calling BIOS,
for example.

EA> My problem is not only about porting DRL to protected mode. My real
EA> problem is as follows:
EA> mov [opcode+1], interrupt number
EA> opcode: int 00
EA> May lead to int 0 instead of int "interrupt number" being triggered,
EA> or the other way round, in case the v86 monitor slightly changes the
EA> behaviour of the prefetch mechanism of your processor.

     V86 monitor not changes prefetch mechanism, but there is another
trouble with your code above: syncronization prefetch queue with cache was
implemented only in Pentium, so you should divide modify instructions with
modified code by a lot of other instructions and/or by jump.

EA> Preparing an INT on stack is certainly good for ROM ability, but it is
EA> even better to just:
EA> pushf
EA> cli
EA> call far "where the vector of interrupt number xyz points to"

     This is _not_ better, because they have different behavior under PM -
AFAIK, call instruction can't be trapped by monitor and it can't then insert
its own actions there if required.

EA> Because this will work very good in all real mode / v86 mode environments.
EA> The worst that can happen is that you call a DOS int that would have been
EA> directly going to the protected mode host of your v86 task normally. This

     Yes.

EA> is why in emm386, the int 67 vector points to an "int 67" instruction.
[...]
EA> So in short: My version of DRL does not use any self modifying code, stack
EA> tricks or anything, it just uses "int 16" and "int 21" instructions in the
EA> way they are meant to be used.

     But now you code will be less portable, because some compilers may
present INTR() function, but not inline asm.