Re: [Freedos-kernel] Re: 32RTM bug
Hello Michael, I don't want to suggest basic things you've probably already thought of, but want to point out that the actual exception due to REP MOVSW in protected mode is significant. It's not a crash within FreeDOS or failure within the real mode INT 21h handler. Looks like a bad pointer to me. I tried int 0x21 ah=0x34 in both MS-DOS 7.10 and FreeDOS. In both, the returned offset in BX is 321h although the segment in ES is slightly lower in MS-DOS than in FreeDOS (C9h vs D2h). But in both cases, the memory location pointed to by ES:BX was 0. So, that pointer seems valid to me. I also tried to catch the real pointer value when called by 32RTM with STEPDOS. It didn't came to calling DOS function 34h at all! The latest DOS function I saw before it showed the Unhandled exception message was 2Fh (get DTA). The returned value by function 2Fh in ES:BX was 1376:80h. Of course, that bad pointer could have come about due to stack corruption real or pmode, stack overflow back into Borland's data storage, memory corruption, or changing an unexpected register, but RTM lives long enough to get back to the RTM code itself, presumably in the DPMI dispatch/return area. I don't think the actual ES:BX return value is the problem, because it's not had a chance to be used at the exception point. You may be right that it's a bad pointer in the context of the real call. Could you catch what pointer it returns when called by 32RTM? The returned value in ES:BX when I test it by int is D2:321h. I tried manually shoehorning my own GDT entry in the RTM GDTand overwriting RTM's IDT for exception 0DH so I could catch the exception without any luck other than a change in exception message, but I could try again if nobody has any idea why it's failing. Alas, this seems so, indeed... If you can see the pointer DOS function 34h returns (or even the byte pointed to by it) when called by 32RTM, this may help. Thanks, 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
[Freedos-kernel] Re: 32RTM Bug Found, no good fix
Hi, indeed an interesting problem... 32RTM fails to initialize CX (number of words to copy from stack) before a DPMI call, and instead, the CX of int 21.30 (get version) is used. So we need a version other than 1.1.35 (major, minor, seq): - lr.CH = REVISION_MAJOR; /* JPP */ - lr.CL = REVISION_MINOR; + lr.CX = 0; /* serial number must be 0 or buggy 32RTM thrashes stack! */ I would vote for lr.CH = 0 lr.CL = *letter* (BL is the seq number: 35, and BH is the OEM id: 0xfd) in that scenario, ver /r would display instead of 1.1.35 (classic 2035) 0.0.35 (2035 stable) and 0.1.35 (2035a), and so on. And we would finally have a way to distinguish a/b/c versions without having to use display kernel version string (YES it is accessible by an API and YES it is in RAM and YES that is a good thing to have). Even 2035z would still mean a sufficiently small CX value and 32RTM would work. PS Lucho: Please don't put the licensing conditions into the kernel! We strive for small size, don't we? Yes we DO want to mention the license! MENTION. Not display the whole 18k file, obviously. This increases the size in RAM by ZERO bytes and the size on disk by some really small number of bytes - and our kernel is very small on disk already anyway. So leave the banner message as is, thank you. Eric --- 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] Re: 32RTM Bug Found, copyleft message
Hallo Eric, Even 2035z would still mean a sufficiently small CX value and 32RTM would work. If CX is nonzero, 32RTM will *not* work. And CX *is* zero in *all* DOS version I've tested (MS-DOS, PC-DOS, ROM-DOS and DR-DOS). Michael, Tom and Alain are right. There's nothing else we could do but clear CX. What's more important after all - that FreeCOM shows 1.1.35 instead of 0.0.35, or that 32RTM works? I think that the answer is obvious for everybody. Yes we DO want to mention the license! MENTION. Not display the whole 18k file, obviously. That's exactly what I meant with my proposal (it fits on 2 lines despite the wraparound that my mail client will probably do): FreeDOS kernel build 2035a-UNSTABLE Copyleft 1985-2004 Pasquale J. Villani and The FreeDOS Project. NO WARRANTY. Licensed under the GNU General Public License This increases the size in RAM by ZERO bytes and the size on disk by some really small number of bytes - and our kernel is very small on disk already anyway. So leave the banner message as is, thank you. The current message does more than simply MENTIONING the GPL. That's why I think it's too long. Just MENTIONING the GPL is enough - most people nowadays already know it. It's not like it was back in 1991! 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] Re: 32RTM bug
Using the -X option bypasses the InDOS function call, so you don't see a problem when you use that 32RTM option. But the InDOS call just does: case 0x34: lr.ES = FP_SEG(InDOS); lr.BX = FP_SEG(InDOS); break; What could be wrong here? The InDOS flag value itself? Stack usage during the call? --- 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] Re: 32RTM bug
On Thu, 12 Aug 2004, Luchezar Georgiev wrote: [added by me]: Michael wrote: Using the -X option bypasses the InDOS function call, so you don't see a problem when you use that 32RTM option. But the InDOS call just does: case 0x34: lr.ES = FP_SEG(InDOS); lr.BX = FP_SEG(InDOS); break; What could be wrong here? Copy and paste is broken where you are. The InDOS flag value itself? with lr.BX = FP_OFF(InDOS); it would be correct. But that's what it does in my source so... Stack usage during the call? that's what I suspected. Eric suggested (in a private email) to make int21/ah=34 reentrant like we did for 25 and 35. However than it would completely execute on the user stack and that stack seemed to have been the problem (only 30 words?). Since you said commenting out calls to the int2a handler didn't help... The only other extra stack user is the macro for 386 registers. Perhaps compiling for 386 or pushing/popping these on the kernel stack would work around that. 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] Re: 32RTM bug
dos_crit_sect: mov [_Int21AX],ax ; needed! pushax ; This must be here!!! mov ah,82h ; re-enrty sake before disk stack int 2ah ; Calling Server Hook! pop ax ret I don't understand the comments here. Who wrote this code? Does re-enrty sake before disk stack mean that this code has to be executed on the user stack? Anyway, one could experiment by commenting out all call dos_crit_sects in entry.asm. Just tried what you suggested, Bart, but unfortunately the result is the same :-( Any other ideas? 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] Re: 32RTM bug
On Tue, 10 Aug 2004, Michael Devore wrote: Some way or another, it looks 32RTM is unhappy with what is going on with the stack on the call to function 34h. I don't think the InDOS pointer itself is what causes the failure because the exception can occur during or immediately after return from the Get InDOS simulate call. From your story it sounds that the int21 entry code uses too much space on the user stack. The only place I could find in entry.asm where this could be a problem is in - ; ; end Dos Critical Section 0 thur 7 ; ; dos_crit_sect: mov [_Int21AX],ax ; needed! pushax ; This must be here!!! mov ah,82h ; re-enrty sake before disk stack int 2ah ; Calling Server Hook! pop ax ret - I don't understand the comments here. Who wrote this code? Does re-enrty sake before disk stack mean that this code has to be executed on the user stack? Anyway, one could experiment by commenting out all call dos_crit_sects in entry.asm. 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] Re: 32RTM bug
At 11:12 AM 8/11/2004 +1200, Bart Oldeman wrote: On Tue, 10 Aug 2004, Michael Devore wrote: Some way or another, it looks 32RTM is unhappy with what is going on with the stack on the call to function 34h. I don't think the InDOS pointer itself is what causes the failure because the exception can occur during or immediately after return from the Get InDOS simulate call. From your story it sounds that the int21 entry code uses too much space on the user stack. Before someone invest too much of their life, I suppose the location could be an artefact of the debugger interacting with InDOS, but it doesn't look like it. After RTM goes into (16-bit) protected mode and installs a DPMI server, any breakpoints I place with 386SWAT wind up at an IRET (apparently because of the dual nature of what IRET does and confused real mode/pmode issues with the debugger). If I breakpoint right before the INT 31h simulate real call function, I get the expected IRET. Placing a breakpoint immediately after gets the exception and termination feedback. Can't see how it would be other than that INT 31h function which is the problem. I tracked down the actual exception location reported. It's on a REP MOVSW, as is very typical. Possibly occurs in the DPMI interface which copies values to/from low memory. Not much help, that. And for all I know, this could be a bug in RTM which is masked in MS-DOS because of a larger or differently structured stack, or other internal image difference. --- 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] Re: 32RTM bug
At 06:44 PM 8/10/2004 -0500, I wrote: At 11:12 AM 8/11/2004 +1200, Bart Oldeman wrote: On Tue, 10 Aug 2004, Michael Devore wrote: Some way or another, it looks 32RTM is unhappy with what is going on with the stack on the call to function 34h. I don't think the InDOS pointer itself is what causes the failure because the exception can occur during or immediately after return from the Get InDOS simulate call. From your story it sounds that the int21 entry code uses too much space on the user stack. Before someone invest too much of their life, I suppose the location could be an artefact of the debugger interacting with InDOS, but it doesn't look like it. Problem is definitely the INT 31h simulate real mode interrupt Get InDOS function. If I patch out the function to simply put a zero in the returned ES:BX pointer, 32RTM goes resident without kicking out an exception. Of course, it no longer uses the InDOS flag properly, assuming it ever does use it. Anyway, that's as far as I can go with what I see. It's a problem with INT 21h DOS function 34h when called from pmode through the Borland DPMI server via INT 31h. Hopefully a kernel person can either fix it or call shenanigans on Borland. --- 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] Re: 32RTM bug
Borland 32RTM 1.5 fails to work in FreeDOS but works in MS-DOS. Forgot the message: Unhandled exception 000D at 0020 034B ErrCode . This happens without EMM386. I haven't tried it with EMM386 in FreeDOS. --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com ___ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
