DOS ain't dead

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

- 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
- Possibly fails on NT ... if anybode has a solution for this please post it
- This "invention" is actually "accidental" - but too good to be kept private
- 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 ***

> - 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

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

---
MS-DOS forever!

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

NO - it raises a Page Fault

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 ***

> 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!

> > 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 ***

> 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!

> 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

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

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

;--- 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 ***

> 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

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.)

> 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.

> > 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

Rugxulo wrote:

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

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

> (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).

??? 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

> 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

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

> ??? 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

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.

> > 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

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.

---
Know your limits.h

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 ***

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

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