DOS ain't dead - TripleFault

DOS386

13.08.2007, 06:46

TripleFault (DOSX)

use32 ; 32-bit PM, flat ZERO-based memory, DPMI32 or Win32, CPL&YOPL irrelevant (!) cld sub esp,8 mov ebp,esp sidt [ebp] mov edi,[ebp+2] mov ecx,32 xor eax,eax rep stosd ud2

Enjoy :lol3:

- Immediately and securely reboots from DPMI applications (there used to be some requests about this in the past ... anyone still interested ?), even if running in MEVDM :lol3:
- Possibly fails on NT ... if anybode has a solution for this please post it :hungry:
- This "invention" is actually "accidental" - but too good to be kept private :lol3:
- See also my other IDT thread please

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

Japheth

Germany (South),
13.08.2007, 08:24

@ DOS386

TripleFault

Post reply

> - Immediately and securely reboots from DPMI applications (there used to
> be some requests about this in the past ... anyone still interested ?),
> even if running in MEVDM :lol3:

does it still work with HDPMI32 if it is started with option -s?

---
MS-DOS forever!

DOS386

13.08.2007, 08:37

@ Japheth

TripleFault [2]

Post reply

> does it still work with HDPMI32 if it is started with option -s?

NO :surprised: - it raises a Page Fault :lol3:

Is there a way to test whether the IDT is writable before actually writing ? VESAMTRR seems to do so ( "Ring0 is inaccessible" , no crash ) but couldn't find the test in the source :-|

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

Japheth

Germany (South),
13.08.2007, 11:41

@ DOS386

TripleFault [2]

Post reply

> Is there a way to test whether the IDT is writable before actually writing
> ? VESAMTRR seems to do so ( "Ring0 is inaccessible" , no crash ) but
> couldn't find the test in the source :-|

VESAMTRR doesn't need write access to GDT, just read-access. And it is easy to find since int 31h, ax=203h | ax=212h are the only - legal - ways to set an exception handler in DPMI.

---
MS-DOS forever!

DOS386

16.08.2007, 10:09

@ Japheth

TripleFault [3]

Post reply

> > Is there a way to test whether the IDT is writable before actually
> writing
> > ? VESAMTRR seems to do so ( "Ring0 is inaccessible" , no crash ) but
> > couldn't find the test in the source :-|
>
> VESAMTRR doesn't need write access to GDT, just read-access. And it is
> easy to find since int 31h, ax=203h | ax=212h are the only - legal - ways
> to set an exception handler in DPMI.

Thanks ... this is documented this way and I write into IDT only ... but VESAMTRR seems not to use INT $31 to deal with exceptions ... it seems to give up because the GDT/LDT search fails somewhat :-|

But is there a good way to verify accessibility or writability of the IDT (or just any address), besides the touch-and-get-burnt strategy ?

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

Japheth

Germany (South),
17.08.2007, 10:56

@ DOS386

TripleFault [3]

Post reply

> Thanks ... this is documented this way and I write into IDT only ... but
> VESAMTRR seems not to use INT $31 to deal with exceptions

Sure it does. Search for "203"!

> But is there a good way to verify accessibility or writability of the IDT
> (or just any address), besides the touch-and-get-burnt strategy ?

No.

---
MS-DOS forever!

DOS386

19.08.2007, 07:36

@ Japheth

TripleFault [4] | 80686 -> 80486 -> 80386 -> 80286 !?!?

Post reply

> Sure it does.

YES. In latest version only ... previous versions didn't ...

> Search for "203"!

Incredibly easy to find ... as long as you have the correct source and not an obsolete one :no:

Seems to work - prevents (visible) PageFault with HDPMI32 -s and NTVDM Exception ... yeah :lol3:

But seems you "protect" the GDT/LDT search only ... and assume IDT will be accessible and writable if the search (for what exactly ?) runs in a success ?

Well, had to apply 2 cracks before it "worked" in NTVMD ... first cracked off the "TRUE" DOS test -> MTRR's not supported !!! Why ? INT $31/$400 returns 3 in NTVDM (!!!) ... MEVDM used to return 4 ... and DOS/HDPMI correctly returns 6 of course :-) ... and next generation Vi$ta NTVDM MS-DOG subsystem probably reports itself as 80286 ... to be verified ASAP :hungry:

;--- running on NT? bdone: mov ax,$3306 ; GET "TRUE" VERSION NUMBER int $21 ; Result in BX ; cmp bx,3205 ; MS-DOG NT and ebx,$FFFF mov eax, ebx call sshex32eol ;--- MTRRs supported? mov ax,400h int 31h ; Result in CL ; cmp cl,4 ; must be at least a 80486 and ECX,$FF mov eax, ecx call sshex32eol pushfd push 200000h popfd pushfd pop eax popfd test eax,200000h ; CPUID supported? jz @f ; Failure, no CPUID mov eax, $FFFFFFFF ; OK @@: call sshex32eol mov eax,1 xor edx, edx cpuid test edx, $1000 jz @f ; Failure mov edx,$FFFFFFFF @@: mov eax,edx call sshex32eol mov ax,$4C00 int $21 sshex32eol: mov ecx,8 @@: mov dl,0 shld edx,eax,4 shl eax,4 push eax cmp dl,10 jb qq1 add dl,7 qq1: add dl,$30 mov ah,2 int $21 pop eax ; POPE it back loop @b sseol: mov dl,13 mov ah,2 int $21 mov dl,10 int $21 ret

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

Rugxulo

Usono,
21.08.2007, 03:04

@ DOS386

TripleFault [4] | 80686 -> 80486 -> 80386 -> 80286 !?!?

Post reply

> Well, had to apply 2 cracks before it "worked" in NTVMD ... first cracked
> off the "TRUE" DOS test -> MTRR's not supported !!! Why ? INT
> $31/$400 returns 3 in NTVDM (!!!) ... MEVDM used to return 4 ... and
> DOS/HDPMI correctly returns 6 of course :-) ... and next generation
> Vi$ta NTVDM MS-DOG subsystem probably reports itself as 80286 ...
> to be verified ASAP :hungry:

int 2Fh,1687h returns CL=4 on WinXP (though I did test int 31h, 400h in DOS/32a with CC386's inline asm, but CX and DX seem to be mostly?? filled with garbage, so I'm skeptical that CL=3 is really an accurate result).

I've heard of people running Win95 on a 486, but XP?? (Doubt it, probably implemented as such for some weird compatibility reason.)

Matjaz Maribor, Slovenia, 21.08.2007, 11:07 @ Rugxulo	TripleFault [4] \| 80686 -> 80486 -> 80386 -> 80286 !?!? Post reply
	> I've heard of people running Win95 on a 486, but XP?? (Doubt it, probably > implemented as such for some weird compatibility reason.) XP needs at least Pentium 1 but win98 can run on 386 See the LINK.

Rugxulo

Usono,
22.08.2007, 00:19

@ Matjaz

TripleFault [4] | 80686 -> 80486 -> 80386 -> 80286 !?!?

Post reply

> > I've heard of people running Win95 on a 486, but XP?? (Doubt it,
> probably
> > implemented as such for some weird compatibility reason.)
>
> XP needs at least Pentium 1 but win98 can run on 386 :-) See the
> LINK.

Very interesting (even without ich spraching Deutsch or whatever)! But isn't that horribly slow? I mean, even Win 3.1 chugs along on my 486, so I can't imagine Win98 on a 386 with such low RAM!! (Good to know that it supports it, though. Kudos to them for that!)

EDIT: Forgot to mention that WinXP, running on my Pentium 4, returns CL=4 (for a 486), which is odd. So that is probably only for some weird software compatibility (I guess).

---
Know your limits.h

DOS386

25.08.2007, 02:31

@ Rugxulo

TripleFault [5] | 80686 -> 80486 -> 80386 -> 80286 !?!?

Post reply

Rugxulo wrote:

> int 2Fh,1687h returns CL=4 on WinXP

For me too. And then INT $31/$400 returns 3 ... yeah :lol3:

> (though I did test int 31h, 400h in DOS/32a with CC386's inline asm,
> but CX and DX seem to be mostly?? filled with garbage, so I'm skeptical
> that CL=3 is really an accurate result).

??? :confused: In DOS ? For me it perfectly worked with both DOS/32A and HDPMI32 ... BTW, the "XP" machine returns (in DOS) CPU=$F, and not 6 ... Wilamette rulez :lol3:

> LINK

COOL. ;-) Someone should repeat the test with Loonix ... would be interesting ... OTOH it might rise big trouble ... since it possibly would bring up the final evidence that Loonix will never boot into anything below 400 MHz or 128 MiB ... and thus is much more CPU and memory hoggy than "Windows" - fully against the claims of some hard-core FSF/GNU geeks criticizing Vi$ta because of its excessive system requirements and CPU/memory hogging :lol3:

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

Rugxulo

Usono,
25.08.2007, 03:15
(edited by Rugxulo, 25.08.2007, 03:27)

@ DOS386

TripleFault [5] | 80686 -> 80486 -> 80386 -> 80286 !?!?

Post reply

> ??? :confused: In DOS ? For me it perfectly worked with both DOS/32A and
> HDPMI32 ... BTW, the "XP" machine returns (in DOS) CPU=$F, and not 6 ...
> Wilamette rulez :lol3:

No, not in DOS, I meant in XP, sorry.

Anyways, IIRC, my P4 returns "F24" for family / model / stepping via CPUID. But I think even AMD64x2 returns "F28" (or similar), so that confused me. :confused:

> > LINK
>
> COOL. ;-) Someone should repeat the test with Loonix ... would be
> interesting ... OTOH it might rise big trouble ... since it
> possibly would bring up the final evidence that Loonix will never boot
> into anything below 400 MHz or 128 MiB ... and thus is much more
> CPU and memory hoggy than "Windows" - fully against the claims of some
> hard-core FSF/GNU geeks criticizing Vi$ta because of its excessive system
> requirements and CPU/memory hogging :lol3:

The X11 server eats up a lot, as does multitasking in general, and moreso if you use a RAM disk. And GCC doesn't help (quite greedy), so you'll often have to swap a lot. Even Damn Small Linux uses about 20+ MB RAM minimum after boot (1 min. 30 sec. to boot DSL 3.3 on a P2 333Mhz) without doing anything. I still say that DSL's the best bet (AFAIK) for using Linux on an old machine ... unless you wanna use tomsrtbt: 1.7MB floppy (abandoned?? not updated in > 5 years), has DHCP, telnet, wget, kinda quirky especially for a noob like me but good for crawl.akrasiac.org at least. :-D

---
Know your limits.h

DOS386

31.08.2007, 07:09

@ Japheth

TripleFault [6] VERxx's NOP

Post reply

Japheth wrote:

> > is there a good way to verify accessibility or writability of the IDT
> > (or just any address), besides the touch-and-get-burnt strategy ?
>
> No.

There are VERR and VERW instructions for this (?) purpose. Unfortunately there seems to be no way how to pass the "hot" address to them so they seem useless :-(

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

DOS386

02.09.2007, 12:00

@ DOS386

TripleFault [7] VERxx's NOP | Crash via Ports

Post reply

I wrote:

> There are VERR and VERW instructions for this (?) purpose. Unfortunately
> there seems to be no way how to pass the "hot" address to them so they
> seem useless :-(

http://groups.google.com/group/comp.lang.asm.x86/b...thread/thread/5041b019fd2d0283/7343b9ba4693a7c1

http://groups.google.com/group/alt.os.development/...thread/thread/ada63b9cea85d9b0/2fff6635c0be1e2c

:lol3:

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