Re: [Freedos-devel] 32RTM Bug Found, no good fix

2004-08-13 Thread Alain
Hi Michael,
Thanks very much for the debugging...
IMHO this is a case of needed bug for bug compatibility :(
I say needed because there are _A_LOT_ of Borland programs around. It 
would not be needed if it happened only in an obscure rarely used program.

I can even argue that FreeDOS is Beta, that is because things may 
change, this is as good an example as anyone can get.

Alain
Michael Devore escreveu:
[Sorry, this is going to be long. I can't describe the problem properly 
otherwise.  I'm cc'ing to devel since the problem isn't really in the 
kernel and affects all Borland 32RTM users.]

The 32RTM problem where 32RTM executing under FreeDOS without the -X 
option generates an exception is a Borland bug.  And the bug only shows 
up with FreeDOS because MS-DOS does something slightly different, 
although the FreeDOS method is perfectly valid.

The problem occurs in this code segment in 32RTM:
 push bp
 sub sp,32h
 mov bp,sp
 mov word ptr [bp+1ch],3400h
 mov word ptr [bp+20h], 3202h
 mov word ptr [bp+30h],0
 mov word ptr [bp+2eh],0
 mov ax,300h
 mov bx,21h
 mov di,bp
 push ss
 pop es
 int 31h
Briefly put: when the int 31h (DPMI interrupt) occurs, 32RTM generates 
an exception under FreeDOS.  Basically what is happening in this code 
segment is that 32RTM sets up a stack frame to hold a real mode call 
structure pointed to by ES:DI for calling INT 21h through the INT 31h 
DPMI interface.  It sets the AX value to 3400h, for get InDOS function.  
The 3202h value is the flags register.  And the 0 in the other two stack 
frame values indicates that the DPMI server should use its own internal 
stack.  Everything other real mode register is don't care.  The ax,300h 
simply is the DPMI function for simulate real mode interrupt, here to 
call INT 21h function 34h.  Okay, hope that's clear.

People who use DPMI functions might notice one small omission here.  No 
CX register value is set.  Well, CX is an important register for the 
300h function, it is the number of words to copy from protected mode to 
real mode stack when the interrupt is issued.

So I looked further back in the 32RTM code to see where CX register is 
getting set and falling through to this routine.  Amazingly enough, the 
CX value used is the one that is returned from an earlier real mode INT 
21h function 30h get DOS version call.  The return value of CX from that 
function is the lower 16-bits of the user serial number, whatever the 
heck that is.  Unfortunately, FreeDOS returns a serial number of 101h in 
CX.  MS-DOS appears to return a value of 0.  By a fluke, MS-DOS is 
returning a CX value which allows the above DPMI call to function 
without problems.

So what happens with the FreeDOS 101h value in CX?  It copies 514 bytes 
of crap to the real mode stack during the INT 31h.  That blows the DOS 
stack right there, and if it doesn't, it sure blows the internal DPMI 
stack.  Hard to say what important internal data gets shot down with the 
copy.

How do I know this is the problem?  I tested it two different ways:
First, I in the debugger I dynamically patched the:
 mov word ptr [bp+30h],0
 mov word ptr [bp+2eh],0
instructions in the code fragment to:
 xor cx,cx
 mov [bp+30],cx
 mov [bp+2eh],cx
with NOP padding. 32RTM happily went resident without exception, since 
no bytes were copied to and from the real mode stack.

Second test: while in the debugger, after the 30h get DOS function call 
in 32RTM, I changed CX return value from 101h to 0.  Once again, 32RTM 
went resident without problems.

There you have it folks.  A dumb bug in a Borland product that by purest 
happenstance fails under FreeDOS and not MS-DOS.  I don't have any idea 
how to gracefully fix the problem other than to have FreeDOS change its 
serial number.  And it shouldn't have to do that.


---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink  Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel


---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink  Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel


Re: [Freedos-devel] 32RTM Bug Found, no good fix

2004-08-13 Thread Steve Nickolas - Using Windoze
Alain wrote:
Hi Michael,
Thanks very much for the debugging...
IMHO this is a case of needed bug for bug compatibility :(
I say needed because there are _A_LOT_ of Borland programs around. It 
would not be needed if it happened only in an obscure rarely used program.

I can even argue that FreeDOS is Beta, that is because things may 
change, this is as good an example as anyone can get.

Alain
Problem is that register is part of the kernel version code in DOS-C and 
FreeDOS...

-uso.
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink  Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel