DOS ain't dead

Found 2 nice (one is a bit older ) things coded in FASM:

http://board.flatassembler.net/topic.php?t=6773 LOGO.EXE
http://board.flatassembler.net/topic.php?t=7478 CLOCK

Under HX both fail with crash in DGDI32 ... both on exactly same address ... maybe they could be fixed easily ?

Well, 2nd point, slightly worse:

After the thing crashes, and I touch the mouse, I get a GPF in Ring 0 !!!
With hard freezer or some "invalid opcode 2345 4634 5800 0000" junk

YES, I had exactly the same bug with Blo*ek some months ago ... and it was considered as fixed both in Blo*ek AND HDPMI32 ... and now this Regression ? Tested with HX 2.10 -> same bug !!! (some additional missing imports, crash in DKRNL32 instead, but exactly same GPF in Ring 0) ... no regression ... no idea why I never got (and nobody else) this bug before ... when testing all the not working GUI apps

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

> Well, 2nd point, slightly worse:
>
> After the thing crashes, and I touch the mouse, I get a GPF in Ring
> 0 !!!
> With hard freezer or some "invalid opcode 2345 4634 5800 0000" junk
>
> YES, I had exactly the same bug with Blo*ek some months ago ... and
> it was considered as fixed both in Blo*ek AND HDPMI32 ... and now
> this Regression ? Tested with HX 2.10 -> same bug !!! (some
> additional missing imports, crash in DKRNL32 instead, but exactly same GPF
> in Ring 0) ... no regression ... no idea why I never got (and nobody else)
> this bug before ... when testing all the not working GUI apps
>

Is this sort of a bug report?

---
MS-DOS forever!

> Is this sort of a bug report?

YES. Please note that this late bug discovery made me angry ... but not about you of course

> some minor bugfixes (other thread)

LOGO works now (see shot) ...

CLOCK doesn't (strange, it used to crash on exactly same addr ), and the GPF's in Ring 0 persists

It's NOT a regression of HX ... and also not because of CTM 2.1 ... no idea why I couldn't discover it before if this bug is really old

Also, the minor MessageBox bug got fixed (see shot)

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

> CLOCK doesn't (strange, it used to crash on exactly same addr
> ), and the GPF's in Ring 0 persists

CLOCK should work now. Very nice app! It's using a non-supported mapping mode, but apparently that doesn't hurt.

btw, there is a bug in the FASM windows includes which confused hx and caused the GPFs: in FASM, there is

CW_USEDEFAULT equ 8000h

OTOH, the MS platform SDK defines it as

#define CW_USEDEFAULT 0x80000000

apparently, windows accepts the 8000h as well (as does hx now), but it is not documented.

--------------------------------------

about the mouse problem: this almost certainly is due to the mouse event proc not being reset. dkrnl32 uses raw DPMI functions to set the mouse event proc, which has the advantage that it works with any DPMI host, but has the disadvantage that the host cannot clear the event proc on its own if an unhandled exception occurs and the host is terminated the hard way ("terminate s/erver").

--------------------------------------

P.S: and please, don't write "GPF's", write "GPFs" instead! Our admin is very sensible and such things do hurt him physically.

---
MS-DOS forever!

> P.S: and please, don't write "GPF's", write "GPFs" instead! Our admin is
> very sensible and such things do hurt him physically.

I agree with no ' for plurals, but it's widely used by native Anglophones, in respectable publications. rr: Eat something sweet every time you see one of those naughty 's (''s?). You will soon love them.

> in respectable publications. rr: Eat something sweet every time you see one
> of those naughty 's (''s?). You will soon love them.

I'll just kick you all out, if I have enough.

---
Forum admin

> CLOCK should work now. Very nice app! It's using a non-supported mapping
> mode, but apparently that doesn't hurt.

YES

> btw, there is a bug in the FASM windows includes



> about the mouse problem: this almost certainly is due to the mouse event
> proc not being reset. dkrnl32 uses raw DPMI functions to set the mouse
> event proc, which has the advantage that it works with any DPMI host, but
> has the disadvantage that the host cannot clear the event proc on its own
> if an unhandled exception

"unhandled" - handled by DKRNL32 instead HDPMI32 ?

> occurs and the host is terminated the hard way ("terminate s/erver").

I didn't terminate the host the "hard way" - the problem occurs after an application crashed in DKRNL32 or DGDI32 and was terminated by DKRNL/DPMILD for this. Drops back to DOS, all seems OK, one can even uninstall/reinstall mouse driver (it "helps" ), but if I touch the mouse without "fixing" the driver before, the GPF in Ring 0 occurs - then "terminate s/erver" offer appears, but it's too late: either no reaction to keypress at all, or some garbage is reported then (low mem corruption ?) - freezer, reboot

Does this mean the problem is unfixed and not easy to fix ?

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

> I didn't terminate the host the "hard way" - the problem occurs after an
> application crashed in DKRNL32 or DGDI32 and was terminated by
> DKRNL/DPMILD for this. Drops back to DOS, all seems OK, one can even
> uninstall/reinstall mouse driver (it "helps" ), but if I touch the
> mouse without "fixing" the driver before, the GPF in Ring 0 occurs - then
> "terminate s/erver" offer appears, but it's too late: either no reaction
> to keypress at all, or some garbage is reported then (low mem corruption
> ?) - freezer, reboot
>
> Does this mean the problem is unfixed and not easy to fix ?

I don't have this problem. Does it appear if HDPMI is installed temporarily (without "-r")?

---
MS-DOS forever!

> LOGO works now (see shot) ...

Yeah, it apparently works, even in DOSBox 0.71, with the latest HXRTD.ZIP.

However, I wish people would mention if "... works" but also mention with what external dependencies (e.g. MSVCRT.DLL, like in this case). Kinda annoying to try it only to not have that file. (Sorry, I'm just paranoid about violating some obscure Windows license. Can you blame me?)

> CLOCK doesn't (strange, it used to crash on exactly same addr
> ), and the GPF's in Ring 0 persists

There's already a DOS clock that looks and acts very very very similar (as well as yet another Win32 one written in VC++, which probably uses MSVCRT.DLL, go figure).

http://board.flatassembler.net/topic.php?p=61031#61031

Actually, that's only the FASM port of this.

---
Know your limits.h

> I don't have this problem.

Strange

> Does it appear if HDPMI is installed temporarily (without "-r")

YES. With latest HXRTD, it freezes silently, however, if not resident.

Test:

http://www.unet.univie.ac.at/~a0503736/php/drdoswiki/uploads/Main/X.zip

CRACKED.EXE

Re-Uploaded nice P15 shot:



Less nice shot showing cosmetic mouse arrow bug:

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