DOS ain't dead

Japheth wrote (IIRC, something like, in old, now deleted forum) :

> The main benefit of running a DPMI application in Ring3 rather than Ring0
> is, that if a dead loop with decreasing stack pointer occurs (very stupid
> and very popular bug), in Ring0 it unavoidably runs into a TripleFault,
> while with application in in Ring3 the DPMI host easily can clean up the trouble.

I found a very interesting (critical/criminal) BUG in Ladsoft's INFOPAD , occurring if an external DOS based DPMI host on "raw" is present. CWSDPMI raises a PageFault - see shot:



Done in BOCHS (2.3.0). In BOCHS I could type the "dir" after, but didn't work, natively there is a hard freezer - no chance to type anything.

With HDPMI32, the bug becomes even more mallicious :

========================================================================
                        Bochs x86 Emulator 2.3
              Build from CVS snapshot on August 27, 2006
========================================================================
00000000000i[MEM0 ] 32.00MB
00000000000i[MEM0 ] rom at 0xffff0000/65536 ('BIOS')
00000000000i[MEM0 ] rom at 0xc0000/38400 ('VGAB')
00000480000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8
00000778154i[BIOS ] ata0-0: PCHS=59/16/63 translation=none LCHS=59/16/63
00154790896i[CPU0 ] can_push(): expand-up: SP > limit
00154790896i[CPU0 ] decrementESPForPush: push outside stack limits
00154790896i[CPU0 ] can_push(): expand-up: SP > limit
00154790896i[CPU0 ] can_push(): expand-up: SP > limit
00154790896i[CPU0 ] protected mode
00154790896i[CPU0 ] CS.d_b = 32 bit
00154790896i[CPU0 ] SS.d_b = 32 bit
00154790896i[CPU0 ] | EAX=00000000  EBX=00000000  ECX=00000000  EDX=00000000
00154790896i[CPU0 ] | ESP=fffffff8  EBP=00000000  ESI=00000000  EDI=00000000
00154790896i[CPU0 ] | IOPL=3 id vip vif ac vm RF nt of df if tf SF zf af pf CF
00154790896i[CPU0 ] | SEG selector     base    limit G D
00154790896i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00154790896i[CPU0 ] |  CS:0020( 0004| 0|  0) ff801000 00006787 0 1
00154790896i[CPU0 ] |  DS:00e7( 001c| 1|  3) 00000000 000fffff 1 1
00154790896i[CPU0 ] |  SS:0028( 0005| 0|  0) 00026380 000ffffe 1 1
00154790896i[CPU0 ] |  ES:00e7( 001c| 1|  3) 00000000 000fffff 1 1
00154790896i[CPU0 ] |  FS:00ff( 001f| 1|  3) 00000000 0000ffff 0 0
00154790896i[CPU0 ] |  GS:00e7( 001c| 1|  3) 00000000 000fffff 1 1
00154790896i[CPU0 ] | EIP=000000b8 (000000b8)
00154790896i[CPU0 ] | CR0=0x80000031 CR1=0 CR2=0x00000000
00154790896i[CPU0 ] | CR3=0x01fff000 CR4=0x00000200
00154790896i[CPU0 ] >> push ds : 1E
00154790896e[CPU0 ] exception(): 3rd (12) exception with no resolution, shutdown status is 00h, resetting
00154790896i[SYS  ] bx_pc_system_c::Reset(SOFTWARE) called
00154790896i[APIC0] local apic in CPU 0 initializing

Seems that something (damaging HDPMI code in low memory ?) pushes HDPMI into such a self-destructive activity

It is a bug a INFOPAD, but posting here because 1st CC386 forum is almost dead and 2nd it's a very interesting DOSX/DPMI issue

Any ideas what could be the reason of the bug ? Low memory corruption ?

No bug symptoms without CWS/H-DPMI, no bug symptoms with EMM386.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Japheth wrote (IIRC, something like, in old, now deleted forum):
>
> > The main benefit of running a DPMI application in Ring3 rather than Ring0
> > is, that if a dead loop with decreasing stack pointer occurs (very stupid
> > and very popular bug), in Ring0 it unavoidably runs into a TripleFault,
> > while with application in in Ring3 the DPMI host easily can clean up the trouble.

But that's YOUR typical style ...

> I found a very interesting (critical/criminal) BUG in Ladsoft's
> INFOPAD , occurring if an external DOS based DPMI host on "raw" is
> present. CWSDPMI raises a PageFault - see shot:
[snip]
> With HDPMI32, the bug becomes even more mallicious :
[snip]
> Seems that something (damaging HDPMI code in low memory ?) pushes HDPMI
> into such a self-destructive activity
[snip]
> Any ideas what could be the reason of the bug ? Low memory corruption ?

A crash in a real-mode callback (RMCB) is always somewhat dangerous, because the InDOS flag might be set, making a proper termination "impossible".

However, the most stupid contributor to the unrecoverable crash possibly is a "known" bug in CuteMouse. It doesn't "allow" an application to crash inside a mouse event proc. Did you also test without/another mouse driver? For example the very good one from Microsoft?

---
MS-DOS forever!

> But that's YOUR typical style ...

OH well

> A crash in a real-mode callback (RMCB) is always somewhat dangerous,
> because the InDOS flag might be set, making a proper termination "impossible".

Thanks.

> However, the most stupid contributor to the unrecoverable crash possibly
> is a "known" bug in CuteMouse.

Did you or anyone else write about it before ? I was not aware of it (OTOH that no version of CT or any other mouse driver is 100% bugfree, YES).

> It doesn't "allow" an application to crash inside a mouse event proc.

There was trouble with HX, Blocek, GVFM, ...

> Did you also test without/another mouse driver?

Good idea , results:

HDPMI32, no mouse driver: still TripleFault

CWSDPMI, no mouse driver: hey, seems to start and work ... just the mouse doesn't for unknown reason

CWSDPMI, LOGITECH driver 6.50: The very same PF in RMCB

Are RCMB's used in TEXT based mouse controlled apps at all ? I don't see any in INFOPAD's source

> For example the very good one from Microsoft?

I would rather eat a rat than use a >100 KiB rat driver from M$

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

> Are RMCB's used in TEXT based mouse controlled apps at all ?
> I don't see any in INFOPAD's source

It all depends on the application. The text-based (DPMI) Borland IDE's for example do, since they use Int33h/0Ch - Mouse Driver - Set Interrupt routine. Some graphical applications such as PQMagic, don't (and it shows).

> HDPMI32, no mouse driver: still TripleFault
>
> CWSDPMI, no mouse driver: hey, seems to start and work ... just the mouse
> doesn't for unknown reason
>
> CWSDPMI, LOGITECH driver 6.50: The very same PF in RMCB
>
> Are RCMB's used in TEXT based mouse controlled apps at all ?
> I don't see any in INFOPAD's source

It's obviously not a mouse problem then. Also, you wrote that the crash occurs in "raw" mode only. That's true, but it's just because in "xms" mode - and most likely "VCPI" as well, which I didn't test - the included dos extender doesn't use the external DPMI host.

edit: the triple fault's cause is a host stack overflow, that is, your application loops (real-mode -> real-mode callback -> prot-mode -> real-mode -> ...)

---
MS-DOS forever!

> edit: the triple fault's cause is a host stack overflow, that is, your
> application loops (real-mode -> real-mode callback -> prot-mode ->
> real-mode -> ...)

"set hdpmi=1" most likely will avoid the loop. It has been implemented exactly for those DOS extenders which behave paranoid: they except all interrupt and exception vectors and route IRQs from real-mode to protected-mode themselves - apparently they don't trust any external code. The latter thing is dangerous to do, because it's the DPMI host's job.

---
MS-DOS forever!

Thanks. Ladsoft just released 3.70 and reportedly fixed it. Test now

> "set hdpmi=1" most likely will avoid the loop.

YES. Old INFOPAD does no longer TripleFault

> It has been implemented exactly for those DOS extenders which behave
> paranoid: they except all interrupt and exception vectors and

Intercept ?

> route IRQs from real-mode to protected-mode themselves - apparently they
> don't trust any external code. The latter thing is dangerous to do,
> because it's the DPMI host's job.

Acceptable idea for interrupts, faulty for exceptions ?

Still strange why only INFOPAD had this bug

But it's indeed fixed in 3.70 release , no TripleFault with HDPMI=0, no RCMB Page Fault with CWSDPMI. Regrettably I'm banned from the CC386 forum so I can't ask there soon

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***