Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Hi! 15-Авг-2004 20:24 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: >> - lr.BH = OEM_ID; >> - lr.CH = REVISION_MAJOR; /* JPP */ >> - lr.CL = REVISION_MINOR; >> - lr.BL = REVISION_SEQ; >> + lr.BX = (OEM_ID << 8) | REVISION_SEQ; >> + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes BO> tabs?). There's also a pointless "optimization", that the compiler can do BO> for us as well. "Can" != to "will" and/or "my". Yes, Watcom (but not, say, Borland) (sometime) may join adjacent memory writes into memory, but there writes into BX are interspersed. Also, to make more readable code, I add macro MK_UWORD(): "lr.BX = MK_UWORD (OEM_ID, REVISION_SEQ);". --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Hi! 15-Авг-2004 21:59 [EMAIL PROTECTED] (Bart Oldeman) wrote to [EMAIL PROTECTED]: BO> BC isn't a target for freedos optimizations; there's one and only one BO> target to optimize for : WATCOM. BO> so BC specific optimization is a waste of time (ours and yours) BO> This just being tom's opinion but I still agree -- I agree too, but _small_ optimizations, like discussed joined write into lr.BX, _may_ be applied, because they (may) help for other compilers too. BO> I even agree more than BO> I did a couple months ago, that's why I rejected my own idea of using BO> "_seg *" pointers. I played for a while again with Turbo C++ back then but BO> in the end decided that the difference was just too big. After my playing with _seg (you may see its usage in "unstable" branch through MK_SEG_PTR()) I see the noticeable code reduction for Borland. Though, Borland contains bug also there, it related to conversion literal values to far pointers. :( --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
On Sun, 15 Aug 2004, Luchezar Georgiev wrote: > Hallo Bart, > > > There's also a pointless "optimization", that the compiler can do for us > > as well. > > Will Watcom (the only compiler you recognise) do this? Of course, I'm not going to state this without checking. > Borland won't, I'm sure. So my optimisation is NOT pointless. We'll make a deal. If Borland fixes their bug in 32RTM as part of open sourcing their old 16bit targetting compiler (even lower than the chance that RBIL will be updated) I'll go for it ;) I do recognize other compilers but... http://marc.theaimsgroup.com/?l=freedos-kernel&m=106373357329924&w=2 " re: BC optimizations: BC isn't a target for freedos optimizations; there's one and only one target to optimize for : WATCOM. so BC specific optimization is a waste of time (ours and yours) tom " This just being tom's opinion but I still agree -- I even agree more than I did a couple months ago, that's why I rejected my own idea of using "_seg *" pointers. I played for a while again with Turbo C++ back then but in the end decided that the difference was just too big. Bart --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Hallo Bart, whatever, now we have 2035, 2.0.35, 1.1.35, and 0.0.35 all as version numbers ;) ...and 2035, 2035a (why not rename them to STABLE?) and 2035a-UNSTABLE releases ;) Just have to send Ralf Brown another email as my previous mod to interrupt.f will be obsolete. ...in the hope that the probability of releasing the next version of the RBIL is greater than the probability of releasing the next version of the GPL (and neither of them is zero ;-) Anyway most references other than RBIL tell that the serial number isn't used as such. True. Moreover, the IBM PC-DOS 7 technical reference update (http://www.redbooks.ibm.com/redbooks/pdfs/gg244459.pdf) says: = start quote = 30H — Get DOS Version Number Purpose Returns the DOS version number. Examples PUSHCX ; CX destroyed in call PUSHBX MOV AH,30H ; Function Call – Get PC DOS 7 ; Version INT 21H ; Issue request to DOS MOV MajorVersion,AL ; Save Version MOV MinorVersion,AH MOV DOS_Running_From,BH ; POP BX POP CX - MajorVersionDB ?; X of X.YY MinorVersionDB ?; YY of X.YY DOS_Running_FromDB ?; 0 = DOS not running in ROM DOS_Running_FromDB ?; 8 = DOS running in ROM Comments On entry, AH contains 30H. On return, CX is set to 0. AL contains the major version number. AH contains the minor version number. BH contains 8 or 0 for DOS running or not running in ROM. If AL returns a major version number of 0, you can assume that the DOS version is pre-DOS 2.00. Use function call 33H AL=6 (Get or Set System Value) to get the true version number. = end quote = Not that it says "On return, CX is set to 0". So, the RBIL is just one of the references - not to be absolutised. www.htl-steyr.ac.at/~morg/ pcinfo/hardware/interrupts/inte2zlc.htm That URL doesn't work. The correct URL (without the extra space) is: www.htl-steyr.ac.at/~morg/pcinfo/hardware/interrupts/inte2zlc.htm tells us that " - the OEM serial number is a rarity, though some older OEM DOS versions implemented this feature". Most likely 32RTM wouldn't run on those older OEM DOS versions either then. Yes. This patch won't apply without manual tweaks Lucho, please fix your email client. I can't fix Opera - it's closed source ;-) Lines were wrapped and indentation also messed up (hard tabs?). Sorry. From now on, I'll enclose my eventual patches as plain text attachments. They'll work then. There's also a pointless "optimization", that the compiler can do for us as well. Will Watcom (the only compiler you recognise) do this? Borland won't, I'm sure. So my optimisation is NOT pointless. By the way, Bart, as an OpenWatcom contributor, would you please post news here and on fd-devel when version 1.3 is officially released? Thanks. Regards, Lucho --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
On Fri, 13 Aug 2004, Luchezar Georgiev wrote:
> Sure. But since it's easier to make the kernel return a serial mumber of 0
> as MS-DOS does than to patch each and every copy of 32RTM.EXE, I changed
> our function 30h to return 0 in CX. I tested this change and now 32RTM
> works without -X as Michael wrote indeed! So I uploaded a new unstable
> kernel binary at http://linux.tu-varna.acad.bg/~lig/freedos/kernel/ along
> with a comulative patch (CVSPATCH.TXT) for the unstable branch consisting
> of the Eduardo's NLS patch and the following patch. Thus, regrettably
> we're back to version 0.0.35 now (as reported by the FreeCOM's VER /R ;-)
whatever, now we have 2035, 2.0.35, 1.1.35, and 0.0.35 all as version
numbers ;) Just have to send Ralf Brown another email as my previous
mod to interrupt.f will be obsolete.
Anyway most references other than RBIL tell that the serial number isn't
used as such.
www.htl-steyr.ac.at/~morg/ pcinfo/hardware/interrupts/inte2zlc.htm
tells us that
" - the OEM serial number is a rarity, though some older OEM DOS
versions implemented this feature".
Most likely 32RTM wouldn't run on those older OEM DOS versions either
then.
> --- cvs/kernel/kernel/inthndlr.c 2004-07-25 20:12:50.0 +0200
> +++ src/kernel/kernel/inthndlr.c 2004-08-13 12:05:56.0 +0200
> @@ -698,10 +698,8 @@
> case 0x30:
> lr.AL = os_setver_major;
> lr.AH = os_setver_minor;
> - lr.BH = OEM_ID;
> - lr.CH = REVISION_MAJOR; /* JPP */
> - lr.CL = REVISION_MINOR;
> - lr.BL = REVISION_SEQ;
> + lr.BX = (OEM_ID << 8) | REVISION_SEQ;
> + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes
> stack! */
>
> if (ReturnAnyDosVersionExpected)
> {
>
This patch won't apply without manual tweaks Lucho, please fix your
email client. Lines were wrapped and indentation also messed up (hard
tabs?). There's also a pointless "optimization", that the compiler can do
for us as well.
So here's my version:
--- inthndlr.c 25 Jul 2004 08:04:54 - 1.89
+++ inthndlr.c 15 Aug 2004 08:15:32 -
@@ -704,9 +704,9 @@
lr.AL = os_setver_major;
lr.AH = os_setver_minor;
lr.BH = OEM_ID;
- lr.CH = REVISION_MAJOR; /* JPP */
- lr.CL = REVISION_MINOR;
lr.BL = REVISION_SEQ;
+ lr.CX = 0; /* do not set this to a serial number!
+32RTM won't like non-zero values */
if (ReturnAnyDosVersionExpected)
{
Bart
---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Hello Luchezar, >> 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. Another one who whishes to congratulate Michael for finding this bug, and thanks. > --- cvs/kernel/kernel/inthndlr.c 2004-07-25 20:12:50.0 +0200 > +++ src/kernel/kernel/inthndlr.c 2004-08-13 12:05:56.0 +0200 > @@ -698,10 +698,8 @@ > case 0x30: > lr.AL = os_setver_major; > lr.AH = os_setver_minor; > - lr.BH = OEM_ID; > - lr.CH = REVISION_MAJOR; /* JPP */ > - lr.CL = REVISION_MINOR; > - lr.BL = REVISION_SEQ; > + lr.BX = (OEM_ID << 8) | REVISION_SEQ; > + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes > stack! */ and that's a patch I can peer review, understand it's implications, and merged into my boring rock solid (as stone) kernel branch ;) tom --- 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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] 32RTM Bug Found, no good fix
Thank you very much, Michael, for your discovery of the 32RTM bug!
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.
Sure. But since it's easier to make the kernel return a serial mumber of 0
as MS-DOS does than to patch each and every copy of 32RTM.EXE, I changed
our function 30h to return 0 in CX. I tested this change and now 32RTM
works without -X as Michael wrote indeed! So I uploaded a new unstable
kernel binary at http://linux.tu-varna.acad.bg/~lig/freedos/kernel/ along
with a comulative patch (CVSPATCH.TXT) for the unstable branch consisting
of the Eduardo's NLS patch and the following patch. Thus, regrettably
we're back to version 0.0.35 now (as reported by the FreeCOM's VER /R ;-)
I guess 32RTM now stands for "32 times Read The Manual!" ;-)
Do you see now what I meant when I wrote that MS-DOS has a better "bug
compatibility"? ;-)
Regards,
Lucho
--- cvs/kernel/kernel/inthndlr.c 2004-07-25 20:12:50.0 +0200
+++ src/kernel/kernel/inthndlr.c 2004-08-13 12:05:56.0 +0200
@@ -698,10 +698,8 @@
case 0x30:
lr.AL = os_setver_major;
lr.AH = os_setver_minor;
- lr.BH = OEM_ID;
- lr.CH = REVISION_MAJOR; /* JPP */
- lr.CL = REVISION_MINOR;
- lr.BL = REVISION_SEQ;
+ lr.BX = (OEM_ID << 8) | REVISION_SEQ;
+ lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes
stack! */
if (ReturnAnyDosVersionExpected)
{
---
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-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] 32RTM Bug Found, no good fix
[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-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
