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

Hi all, some replies on the "above" thread:

> >Do you mean that the only free program that can put the 
> >machine in V86 mode is Free-emm386? 
> The FD-EMM386, I guess.
> To my understanding, Freemm386 is a different (possibly abandoned?) 
> project...

FD emm386 is the only GPL program that can use v86/protected mode to
generate UMBs and EMS. BUT DR emm386 is free for noncommercial use and
Quarterdeck emm386 is abandonware in most versions... Freemm386.org is
a project that tries to do everything from scratch without help from
external sources. For this reason, they will take ages :-(. But they
will learn a lot.
If you need protected mode AND umb, try any of the cousins of UMBPCI,
and if none works, help improving them so that they work for your motherboard
chipset.

To say things about self modifying code and code on stack:
In protected mode, you cannot modify code, unless you explicitly
have a data segment pointing to the same RAM as your code segment.
If your operating system is paranoid, it will NOT let you execute
code on the stack. But you do not need to despair here: You will
not need all 256 interrupts normally. For example, I use msdos()
which is very likely to have an "int 21h" hardcoded.
My problem is not only about porting DRL to protected mode. My real
problem is as follows:

mov [opcode+1], interrupt number
opcode: int 00

May lead to int 0 instead of int "interrupt number" being triggered,
or the other way round, in case the v86 monitor slightly changes the
behaviour of the prefetch mechanism of your processor.

Preparing an INT on stack is certainly good for ROM ability, but it is
even better to just:

pushf
cli
call far "where the vector of interrupt number xyz points to"

Because this will work very good in all real mode / v86 mode environments.
The worst that can happen is that you call a DOS int that would have been
directly going to the protected mode host of your v86 task normally. This
is why in emm386, the int 67 vector points to an "int 67" instruction.

The reason for this is that if somebody calls int 67 by pushf+farcall,
the int 67 -inside- emm386 will be reached. The "int 67" command as a
normal command then gets caught by emm386 for handling inside protected
mode. I mean, emm386 means to take over control when "int 67" occurs in
a way that DOS cannot understand :-). I hope you understand my explanations
about it.

So in short: My version of DRL does not use any self modifying code, stack
tricks or anything, it just uses "int 16" and "int 21" instructions in the
way they are meant to be used. The above is only for those among you who
want to have a generic int(number,regs) to be compatible as hell.

By the way, DRL does not use any objects, so no need to use the free-in-
French version 7 of Borland Turbo Pascal or Borland Pascal here :-).

And it does not use the CRT library anymore, so no need to patch it even
when you compile it with a buggy version 7.

To repeat some of the above:

> Or simulate an INT with PUSHF/CALL (may not work if the V86 monitor needs
> to trace this interrupt call).

The only interrupt that causes troubles for emm386 type v86 monitors is
int 67h ($67, 0x67, as you like :-)), and for this, there is the elegant
solution mentioned above already implemented in almost all emm386 drivers.

Eric