Re: [FreeDOS-32-dev] fd32/drivers/dpmi/src chandler.c,1.6,1.7 int10.c,1.6,1.7 int33.c,1.2,1.3 rmint.c,1.9,1.10

[Salvo I. <sa...@em...>]

Hi Hanzac,
got rid of the [freedos-32-commit] label in the subject, because my mail 
client put these mails in the message folder of the commit list ;-)
(I know I could use better filters, but I'm so lazy...)

On Sunday 27 February 2005 12:34, Hanzac Chen wrote:
> I won't do that, I'm just playing with some open DOS-32 programs to see
> how's FD32's ability/level now. Maybe some day we should write an list
> of programs' executable status. It will be interesting for both
> developers and users. ;-)

Of course it would be. If you like, you could start writing such a list, and 
post it here, so that others may add other applications. Next I'd put it on 
the site. BTW, we already have a FAQ about the programs known to run, that 
could link the list.

> > If the executable (as I suppose) includes its own decompressing stub, and
> > if that stub is a DPMI application, it may work, but I feel it will try
> > to EXEC inside a program. Can't remember if the wrapper has been updated
> > to cope with this issue.
>
> I think it has its own decompression stub, but I tested it but not
> workable, got a exception directly without printing some messages
> that notify us lack of certain INTERRUPTS. I have no clue why it's
> wrong. SAD ...

I'm inventing: maybe the decompression stub is real-mode code?

> >>1. Try to use int21_handler in chandler.c, Don't sure if it's OK?
> >
> > Not sure I got the problem. Is the application invoking INT 21h directly
> > in protected mode, without going through the "Simulate real mode
> > interrupt" service of INT 31h?
>
> Definitely, I've got the INT 21 AX=0x3000 service outside the DPMI
> server (It's check version service), besides I noticed there's
> already one INT 21 service in chandler.c 's case 0x21, which is
> for returning to DOS.

IIRC, the DPMI specifications state that INT 21h AH=4Ch (terminate program 
with return code) can be called directly, without going through the "simulate 
real mode" service (don't remember the number). This is also true for, IIRC, 
1Ch and ... oh, can't remember but there's another one. I thought all other 
interrupts should go through "simulate real mode interrupt", but I may be 
wrong. Anyway, since your app behaves this way, I suppose we should call our 
soft-interrupt handlers also directly, shouldn't we?

Bye,
   Salvo
-- 
 

 

 --

 Email.it, the professional e-mail, gratis per te: http://www.email.it/f

 

 Sponsor:

 Calzature moda sport. Da Oliviero.it le ultime novità autunno-inverno 2004/2005: Nike, Puma, Adidas....

* 

 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2846&d=27-2