DOS ain't dead

Okay, so I've been reading up on SSE/SSE2 (32-bit) somewhat, but the problem is that it needs OS support (e.g. Linux 2.4, Win98). It seems that you have to enable the CR4 bit 9 (OSFXSR) as well as enable CR0's MP (bit 1) but disable CR0's EM (bit 2). Then you have to actually FXSAVE [512_byte_area], do your thing, then FXRSTOR [512_byte_area]. (And of course CPUID check, then CPUID, first before trying to run any of this stuff.)

I am testing a program written by someone else, but it seems to not work in pure DOS.

I finally seem to get it to run w/ SSE2 in QEMU, but only if running HIMEMX (e.g. real mode) and with PMODETSR (ring 0, no paging) since it's a DJGPP-compiled program (needs DPMI).

Japheth, is this normal? Do you know what I'm doing wrong or if there's an easy way to correct it? (That's assuming you know anything about this stuff, which you must, at least vaguely.)

http://rugxulo.googlepages.com/paq8-sse.7z (w/ src + .EXE, etc.)

N.B. This is not a great hack of mine or anything, just piecing it all together really. Any help is welcome.

P.S. I really wish I could test under Vista, but it still has that bloomin' 32 MB DPMI limit! (Help me, SP1, you're my only hope!)

---
Know your limits.h

> Okay, so I've been reading up on SSE/SSE2 (32-bit) somewhat, but the
> problem is that it needs OS support (e.g. Linux 2.4, Win98).

Really ?

> It seems that you have to enable the CR4 bit 9 (OSFXSR) as well
> as enable CR0's MP (bit 1) but disable CR0's EM (bit 2).

And the problem is - why don't you do this ?

> I finally seem to get it to run w/ SSE2 in QEMU, but only if running
> HIMEMX (e.g. real mode) and with PMODETSR (ring 0, no paging) since it's a
> DJGPP-compiled program (needs DPMI).

You compiled a DGJPP port ? The source seems to access those bits - did you add this code ? Anyway, all CR's are privileged resources, thus you will need a Ring0 DPMI host (like CWSDPR0 or WDOSX) or a host emulating CR accesses (HDPMI32). Or did you try with the greatest CWSDPMI only and didn't work ? Is this the problem ? But why related to JEMM386/HIMEMX ?

> I really wish I could test under Vista

Vista is the best DOS ?

You didn't really describe the problem.

P.S.: SSSSSE5 was released recently. SSE/SSE2 is obsolete

TEST: OK, all what I get from your port is a Page Fault

Hint: write a small test prog using FASM with or without enabling the CR bits and executing just 1 SS instruction ... based on USEDPMI.ASM or my DOS/32A example. BTW: Why bother with Causeway, DOS/32A reportedly enables SSE also

PPSS: FB graphics

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

> I finally seem to get it to run w/ SSE2 in QEMU, but only if running
> HIMEMX (e.g. real mode) and with PMODETSR (ring 0, no paging) since it's a
> DJGPP-compiled program (needs DPMI).
>
> Japheth, is this normal? Do you know what I'm doing wrong or if there's an
> easy way to correct it? (That's assuming you know anything about this
> stuff, which you must, at least vaguely.)

I don't know what you are doing, but for Jemm it's a non-issue, since it supports the VCPI API for CR0 access and additionally emulates all moves to/from special registers (by writing to CR0/CR3 you can easily crash Jemm ).

---
MS-DOS forever!

> > It seems that you have to enable the CR4 bit 9 (OSFXSR) as well
> > as enable CR0's MP (bit 1) but disable CR0's EM (bit 2).
>
> And the problem is - why don't you do this ?

For one thing, I don't really know what I'm doing, it's a bit out of my league. Anyways, even if I ignored this, it works under XP. But my goal is to work (also) under pure DOS.

> You compiled a DGJPP port ? The source seems to access those bits - did
> you add this code ?

Yes. PAQ8o8 is the latest PAQ8 series compressor/archiver, and I made it automatically detect NOASM/MMX/SSE2 instead of requiring a recompile or separate .EXE.

> Anyway, all CR's are privileged resources, thus you
> will need a Ring0 DPMI host (like CWSDPR0 or WDOSX) or a host emulating CR
> accesses (HDPMI32).

I didn't try with HDPMI32. Actually, I was using XP, and now I'm using Vista. I'm somewhat limited in what cpus I can try at the moment.

> Or did you try with the greatest CWSDPMI only and
> didn't work ?

Under QEMU, it reports a page fault. But PMODETSR (from my disk #2) seems to work, at least with HIMEMX.

> Is this the problem ? But why related to JEMM386/HIMEMX ?
>

I need to try in real DOS (eventually), but in QEMU, trying SSE2 w/ PMODETSR under JEMM386 crashes QEMU! (Doh!)

> > I really wish I could test under Vista
>
> Vista is the best DOS ?

I wish I could use the same DOS binary under Vista that works fine under XP. Oh well.

> You didn't really describe the problem.

Problem: SSE2 doesn't work without OS support (e.g. which DOS doesn't implicitly have). I weakly tried, but I'm not sure I did it correctly.

> P.S.: SSSSSE5 was released recently. SSE/SSE2 is obsolete

SSE5 is AMD's latest, to be implemented in 2009. SSE4.1 and SSE4.2 are Intel's crud to be released sometime next year (??). SSSE3 is only supported on Intel's Core 2. But my AMD Athlon64x2 supports SSE, SSE2, SSE3 (as opposed to Athlon XP only supporting SSE). From what I've been told, 3dnow! was AMD's answer to MMX, and SSE2 is actually what SSE should've been (and SSE2 obsoletes MMX in most/all ways).

> TEST: OK, all what I get from your port is a Page Fault

Under real DOS? QEMU or BOCHS? CWSDPMI or other DPMI host? JEMM386 or HIMEMX?

> Hint: write a small test prog using FASM with or without enabling the CR
> bits and executing just 1 SS instruction ... based on USEDPMI.ASM or my
> DOS/32A example.

There's already a FASM example, and it works in pure DOS, but it's pretty simplistic. I want it to work under DJGPP. (Most of my problems are lack of cpus to test. QEMU is probably not 100% accurate/reliable.)

> BTW: Why bother with Causeway, DOS/32A reportedly enables SSE also

Well, the .ASM part doesn't work with OpenWatcom (yet) because of different calling conventions which I'm too dumb to understand so far.

> PPSS: FB graphics

I know, I know.

---
Know your limits.h

> I don't know what you are doing, but for Jemm it's a non-issue, since it
> supports the VCPI API for CR0 access and additionally emulates all moves
> to/from special registers (by writing to CR0/CR3 you can easily crash Jemm
> ).

Would it be so horrible for JEMM386 or even HDPMI32 to automagically enable SSE and FXSAVE/FXRESTORE for us? Maybe as an extra JEMM386 "SSE" option so as not to force it on anyone??

---
Know your limits.h

Okay, I updated it, hopefully fixed a few things. It seems to run in WinXP, QEMU/FreeDOS, and pure FreeDOS on this P4 "Northwood" (at least). Feel free to test.

http://rugxulo.googlepages.com/paq-jan4.7z

I also made a pre-built FreeDOS image which includes the above (and a few other things) for testing. This is what I tested under QEMU with. You can also try it on a real machine if you prefer.

http://rugxulo.googlepages.com/sse_dos_boot.7z

---
Know your limits.h

> hopefully fixed a few things.

Not really

> It seems to run in WinXP, QEMU/FreeDOS, and pure FreeDOS

Great ... but

HDPMI32: same PF

D3X (world's first executable): starts, but other bugs (for example you append the dest ext to src filename, "file not found" , and, for DOS you of course should truncate ".paq8blah8junk8dfjhgdf" to ".PAQ" or ".PQ8"

> For one thing, I don't really know what I'm doing, it's a bit out
> of my league. Anyways, even if I ignored this, it works under XP.
> But my goal is to work (also) under pure DOS.

Anyway, to brew an EXE working both under Windaube and DOS, the way is MINGW and a Win32 executable, and HX , rather than DGJPP and NTVDPMI

> PAQ8o8 is the latest PAQ8 series compressor/archiver, and I made it
> automatically detect NOASM/MMX/SSE2 instead of requiring

Great ... but the bugs should go away first

> I didn't try with HDPMI32. Actually, I was using XP, and now I'm using
> Vista. I'm somewhat limited in what cpus I can try at the moment.

Tried to install DOS besides XP or Vista ?

> Under QEMU, it reports a page fault. But PMODETSR (from my disk #2) seems
> to work, at least with HIMEMX.
> need to try in real DOS (eventually), but in QEMU, trying SSE2 w/
> PMODETSR under JEMM386 crashes QEMU! (Doh!)

QEMU bug ...

> wish I could use the same DOS binary under Vista that works fine under XP

MINGW + vice-versa, see above ...

> Problem: SSE2 doesn't work without OS support (e.g. which DOS doesn't
> implicitly have). I weakly tried, but I'm not sure I did it correctly.

Question of just 3 bits in CR registers ? And you call this "OS support" ?

> SSE5 is AMD's latest, to be implemented in 2009. SSE4.1 and SSE4.2 are
> Intel's crud to be released sometime next year (??). SSSE3 is only supported
... blah ... blah ... blah

Remember the MMX "revolution" ? The "new high performance" FPU of 80387 ? The "new great" FPU of 8087 ? And finally the 8080 dealing with just bytes, no FPU at all

> Under real DOS? QEMU or BOCHS? CWSDPMI or other DPMI host?

HDPMI32 (as written above, CWSDPMI seems not to emulate CR accesses, and I don't like it too much anyway), and, native pure DOS (isn't it natively slow enough ? )

> JEMM386 or HIMEMX?

NO.

> Most of my problems are lack of cpus to test.

Lack of DOS installations / lack of effort to install DOS

> QEMU is probably not 100% accurate/reliable.

Indeed. QEMU is known to neglect intentionally various "protection" checks

> doesn't work with OpenWatcom (yet) because of different calling conventions

OK, when you compile with WATCOM, there is DOS/32A

> Would it be so horrible for JEMM386 or even HDPMI32 to automagically

I see definitely no point for JEMM386, and little point for HDPMI32. Last but not least, as you wrote above, your DGJPP executable requires DPMI, not XMS or even worse EMS, so your complaining about JEMMEX is not really helpful here, just leave it aside

Anyway, from your bug symptoms, I think I have "found" the bug, it's indeed a page fault, no way related to SSE, caused by a faulty memory access, that's why I/you get no PF with paging-inactive DPMI hosts without EMM386, because PF's simply don't exist then

And, with buggy code, occurrence of PF's indeed can depend from HIMEMX or EMM386, thus if you get such "random" PF's then you have a corrupt memory access or "wild" pointer BTW, I also had similar problems (but without DGJPP) in the past Finally, presence of HIMEMX or JEMMEX MAY NOT AFFECT the availability of SSE (or RDMSR/WRMSR or whatever) from DPMI - you get what the DPMI host gives you (Ring0 or Ring3, CR emulated or not), EMM386 can only "push" a paging-inactive host to use paging and allow a PF to occur and point you to your bug

You should add some debug info: "Now will CPUID" - "CPUID done, result:" ... - "Now try to enable SSE, writing CR's" - "SSE enabled" to see where your bug is (probably NOT in SSE at all).

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

> Would it be so horrible for JEMM386 or even HDPMI32 to automagically
> enable SSE and FXSAVE/FXRESTORE for us?

HDPMI does it. And Jemm intentionally touches only those bits in CR4 which it needs for its own purposes (VME, PGE).

If you need it in DOS with Jemm, run a DEBUG script:

a
mov eax,cr4
or ax,200
mov cr4,eax
mov ah,4c
int 21

g
q

---
MS-DOS forever!

> HDPMI does it.

Evidence, please

;*** server initialization when first client starts
;--- DS=DGROUP, ES=FLAT

                @ResetTrace

_init2server_pm proc near

                pushad
                assume  ds:DGROUP

                @strout <"#init2server_pm enter",lf>
if _LTRACE_       
        test fMode, FM_CLONE
        jz @F
        @waitesckey
@@:
endif
    test byte ptr dwFeatures+3, 2 ; Is SSE supported?
    jz @F                 
    @mov_eax_cr4
    or ah,2                       ; or ah,2 -> or ax,$0200 -> bit 9
    @mov_cr4_eax
@@:

if ?KDSUPP
if ?EARLYDBGINIT eq 0
                call    initdebugger_pm
endif
endif

Less beautiful (but working):

;--- the lgdt,sgdt,lidt and sidt opcodes
;--- are CS Default bit dependant!
;--- in 16bit code segments the highest byte of the address
;--- is *not* loaded without prefix 66h!

@lgdt   macro x
                db 66h
                lgdt x
                endm
@sgdt   macro x
                db 66h
                sgdt x
                endm
@lidt   macro x
                db 66h
                lidt x
                endm
@sidt   macro x
                db 66h
                sidt x
                endm

@mov_eax_cr4 macro
;       mov eax, cr4
                db 0Fh,20h,0E0h
                endm

@mov_cr4_eax macro
;       mov cr4, eax
                db 0Fh,22h,0E0h
                endm

@cpuid  macro
;               cpuid
                db 0Fh,0A2h
                endm

But seems I found a (critical/criminal) bug:

   Additionally, some privileged opcodes are emulated:   
   - HLT (F4)
   - MOV reg,CRx (0F 20 xx) - using ESP for <reg> will not work!
   - MOV CRx,reg (0F 22 xx) - using ESP for <reg> will not work!

but

?CMPCR3       = 1  ;std 1: 1=improves performance by 2-3%
?EMUMOVREGCRX = 1  ;std 1: emulate mov reg, crX (req. by 32rtm!)
?EMUMOVCRXREG = 1  ;std 1: emulate mov crX, reg
?EMUMOVCR0REG = 0  ;std 0: emulate mov cr0, reg
?EMUMOVREGDRX = 0  ;std 0: emulate mov reg, drX
?EMUMOVDRXREG = 0  ;std 0: emulate mov drX, reg
?SUPP32RTM    = 1  ;std 1: support int2f, ax=168a, "VIRTUAL SUPPORT"
?CATCHREBOOT  = 1  ;std 1; catch ctrl-alt-delete

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

> > HDPMI does it.
>
> Evidence, please

HDPMI is so nice it activates this SSE2 bit and leaves it activated even after it has terminated. That's why Rug's lovable program runs ok after one HDPMI program has been launched (VESAMTRR in CONFIG.SYS for example). Without such a run PAQ8o8z.exe just reboots the machine in plain DOS!?

> But seems I found a (critical/criminal) bug:
>
>    Additionally, some privileged opcodes are emulated:   
> - HLT (F4)
> - MOV reg,CRx (0F 20 xx) - using ESP for <reg> will not work!
> - MOV CRx,reg (0F 22 xx) - using ESP for <reg> will not work!
>
> but
>
> ?CMPCR3       = 1  ;std 1: 1=improves performance by 2-3%
> ?EMUMOVREGCRX = 1  ;std 1: emulate mov reg, crX (req. by 32rtm!)
> ?EMUMOVCRXREG = 1  ;std 1: emulate mov crX, reg
> ?EMUMOVCR0REG = 0  ;std 0: emulate mov cr0, reg
> ?EMUMOVREGDRX = 0  ;std 0: emulate mov reg, drX
> ?EMUMOVDRXREG = 0  ;std 0: emulate mov drX, reg
> ?SUPP32RTM    = 1  ;std 1: support int2f, ax=168a, "VIRTUAL SUPPORT"
> ?CATCHREBOOT  = 1  ;std 1; catch ctrl-alt-delete

Finding something in the source which looks suspicious to you is not a valid bug report. You'll have to provide a test case.

---
MS-DOS forever!

> P.S. I really wish I could test under Vista, but it still has that
> bloomin' 32 MB DPMI limit! (Help me, SP1, you're my only hope!)

If MS is your last hope then you're lost. I bet that this error will NOT be fixed in SP1. IMO the only thing which is reliable is that the quality of the DPMI implementation in NTVDM will continue to decrease. The times when MS was interested in compatibility are long gone.

OTOH, this issue can possibly be fixed by a self-written VDD. It's not at all hard to do, it's almost trivial if you have some DOS and Win32 knowledge.

---
MS-DOS forever!

> If MS is your last hope then you're lost. I bet that this error will NOT
> be fixed in SP1. IMO the only thing which is reliable is that the quality
> of the DPMI implementation in NTVDM will continue to decrease. The times
> when MS was interested in compatibility are long gone.
>
> OTOH, this issue can possibly be fixed by a self-written VDD. It's not at
> all hard to do, it's almost trivial if you have some DOS and Win32
> knowledge.

And how about missing NTVDM on x64 systems? And successor of Vista? They surely kick out support of legacy things... Same as with HW I see the future is black. Only possibility will be then emulators and real dos machines - a second older compatible PC. Similar like people use their 8bit - ZX, Commodore, etc. we will need 2 machines. It would be nice to design an add-on PCI/PCIE card which would contain whole PC - PC in PC :) (some kind of LV pentium or so) with 100% SB sound and VESA display. And it would be able to share data and some hw resources of your main PC - redirecting keyboard and mouse and graphics will be drawn to an overlay window of your host OS and sure some shared HD drive... Of course I have some older PCs around but they are big and for interconnection you need setup network and use kbd/mouse/monitor switch...

---
DOS gives me freedom to unlimited HW access.

> And how about missing NTVDM on x64 systems? And successor of Vista? They
> surely kick out support of legacy things...

Sorry, but we are talking about the crappy DPMI implementation in Vista's NTVDM here, not about the future of "everything".

---
MS-DOS forever!

> Sorry, but we are talking about the crappy DPMI implementation in Vista's
> NTVDM here, not about the future of "everything".

OK, sorry, I'm a bit upset about all of this things...
Of course I'll welcome every NTVDM enhancemens :)

---
DOS gives me freedom to unlimited HW access.

> > And how about missing NTVDM on x64 systems? And successor of Vista? They
> > surely kick out support of legacy things...
>
> Sorry, but we are talking about the crappy DPMI implementation in Vista's
> NTVDM here, not about the future of "everything".

It's actually an accidental Win2k3 "security" bug that at least one person says will be fixed in SP1:

> http://www.trnicely.net/misc/vista.html
>
> On 10/11 April 2007, I received an e-mail purporting to be from
> an employee of Microsoft, or one of its contractors or subcontractors.
> Following is the crux of the e-mail.
>
> > ...I work for 16 side of OS (NTVDM). First of all I would like to thank you
> > for pointing out a bug in 16 bit Memory allocation. To give some
> > background, this was not a regression. This was done to restrict some
> > apps from gulping huge memory in WIN2K3 timeframe, but nobody
> > objected then so it continued.
> >
> > Now that people are asking for this, We are planning to fix this in SP1 of
> > VISTA.
> >
> > Your inputs are very valuable to us, Help us to help you.
> >
> > Thanks,
> >
> > Subhash (Badri)

And BTW, there's no V86 mode under 64-bit "long mode" (non-emulation mode), so you have to emulate the 16-bit subsystem (like DOSEMU supposedly does).

---
Know your limits.h

> HDPMI is so nice it activates this SSE2 bit and leaves it activated even
> after it has terminated. That's why Rug's lovable program runs ok after
> one HDPMI program has been launched (VESAMTRR in CONFIG.SYS for example).
> Without such a run PAQ8o8z.exe just reboots the machine in plain DOS!?

The "Jan. 4" version works in WinXP and pure FreeDOS (HIMEMX only), both using SSE2. I manually enable the CRx bits needed but only if in ring 0. Otherwise, it seemed to crash on XP (which is not desired). It's possible that I did something dumb otherwise that prevents it from working under JEMM, but I need to test more. (Any explicit pointers are welcome.) It's only a preliminary version.

---
Know your limits.h

> HDPMI32: same PF

The FreeDOS floppy boot image I provided used HIMEMX only and D3X (ring 0 DPMI) built into the .EXE. It worked for me. I know that is could be "more compatible", though. It's not finished.

> D3X (world's first executable): starts, but other bugs (for example
> you append the dest ext to src filename, "file not found" , and, for
> DOS you of course should truncate ".paq8blah8junk8dfjhgdf" to ".PAQ" or
> ".PQ8"

Well, I didn't write that, that's Matt's mess. It does work in DOS, though. I usually just type "paq8o8z doydoy *.cpp".

> Anyway, to brew an EXE working both under Windaube and DOS, the way is
> MINGW and a Win32 executable, and HX , rather than DGJPP and NTVDPMI
>

I don't have MinGW installed, and I'd rather not mess with yet another compiler. Besides, I have OpenWatcom (which built its latest Win32 stuff from MinGW because of old license issues). Anyways, I don't think MinGW (except with -static ??) would work with HX. At least, all the non-static MinGW .EXEs I tried under HX whined about MSVCRT.DLL (a requirement which defeats the purpose of HX, IMO).

> > PAQ8o8 is the latest PAQ8 series compressor/archiver, and I made it
> > automatically detect NOASM/MMX/SSE2 instead of requiring
>
> Great ... but the bugs should go away first

Believe me, it was worse. At least getting it to work in some circumstances is better than nothing. I will try tweaking it more eventually.

> Tried to install DOS besides XP or Vista ?

Yet another can of worms to open (ugh). Sometimes it's just too much to do all that. It's easier to just test between various computers (even if that takes longer).

> QEMU bug ...

Yes, but better than nothing.

> Question of just 3 bits in CR registers ? And you call this "OS support" ?
>

Yes, you have to enable that, which makes the chip assume you have OS support which calls FXSAVE and FXRSTOR when needed (although DOS single-tasking doesn't have to).

> Remember the MMX "revolution" ? The "new high performance" FPU of 80387 ?
> The "new great" FPU of 8087 ? And finally the 8080 dealing with just
> bytes, no FPU at all

I think you have to be a math guru to appreciate all these extensions.

---
Know your limits.h

Rugxulo wrote:

> The FreeDOS floppy boot image I provided used HIMEMX only and D3X (ring 0 DPMI)
> built into the .EXE. It worked for me. I know that is could be "more compatible"

But disabling paging to prevent the bug from triggering a PF is cca as smart as neglecting the existence of a bug and banning the reporting person to prevent further posts pointing to this bug

> I didn't write that, that's Matt's mess. It does work in DOS, though.

Not for me. The Win32 executable works (compiled by Matt ?), yours doesn't.

> the non-static MinGW .EXEs I tried under HX whined about MSVCRT.DLL
> (a requirement which defeats the purpose of HX, IMO).

Known issue. Probably easy to fix, but I'm not a C expert

> Believe me, it was worse. At least getting it to work in some
> circumstances is better than nothing. I will try tweaking it more eventually.

You should fix the page fault rather than shooting around with covered eyes in the hope to shoot the SSE2/CR4 issue

> > Tried to install DOS besides XP or Vista ?
> Yet another can of worms to open (ugh).

I had thought XP/Vi$ta would contain and attract worms, not DOS

> Yes, you have to enable that, which makes the chip assume you have OS
> support which calls FXSAVE and FXRSTOR when needed (although DOS
> single-tasking doesn't have to).

You should remove the CR4 code (since HDPMI32 cares), remove the V86 "code" (there is no "V86" in PM DPMI code) and fix the SSE-unrelated bugs. Maybe you introduced them, maybe they origin from Matt but he has the luck that they don't generate symptoms on Win32

PS: definitely NOT a JEMM386 issue

PPSS: PAQ9 is out

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

T.R.N. http://www.trnicely.net/misc/vista.html wrote:

> Proprietary compilers which inherently convert code to the Win32 API
> problem may be that Vista is treating any application that does not call the proprietary Win32 API

> and with or without the use of the DJGPP DPMI servers CWSDPMI
> (Charles W. Sandmann), CWSDPR0, CWSDSTUB, and PMODE/DJ (which are
> apparently ignored in any case, in favor of the native Windows DPMI

That's the same funny boy who caused irritation on FB forum in the past with this article. He meanwhile found out a few things (like existence of MinGW) and fixed some of the most horrible claims in his text, but still reamins quite silly Why not throw away Windows if proprietary is bad ?

Japheth wrote:

> I bet that this error will NOT be fixed in SP1.

M$ wrote:

> We are planning to fix this in SP1 of VISTA.

COOL, but this has exactly 0.0000000000000000000000 relevance for me

Rayer wrote:

> Of course I'll welcome every NTVDM enhancemens

I would welcome if future of DOS would no longer depend from M$ one day

Rugxulo wrote:

> there's no V86 mode under 64-bit "long mode" (non-emulation mode), so you
> have to emulate the 16-bit subsystem (like DOSEMU supposedly does).

I prefer 32-bit DOS from stupid emulated 16-bit subsystems

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

> It's actually an accidental Win2k3 "security" bug that at least one person
> says will be fixed in SP1:
>
> > http://www.trnicely.net/misc/vista.html

Ok, interesting. But you can also try this nice little program. It's a DOS TSR meant to run in XP NTVDM. It extends the crappy DPMI host with some of the more sophisticated DPMI v1.0 memory functions (int 31h, ax=504h, 506h and 507h). May be it also works well in Vista and allows to overcome the artificial 32MB memory limit, since the memory is allocated with the standard Win32 VirtualXXX functions. It's intended for HX's DKRNL32 mainly (where just the VDD is needed, not the DOS TSR), but who knows, it may work with DPJGG as well.

---
MS-DOS forever!

> > Of course I'll welcome every NTVDM enhancemens
>
> I would welcome if future of DOS would no longer depend from M$ one day
>

AFAIK M$ don't support and develop DOS in any way so I donn't understand what you mean with "depend". NTVDM is just a bonus helping windows users to run old DOS apps but M$ will not implement any new features to it - instead they are removing features and remove whole NTVDM.
As a partial windows NT-based user I like to have NTVDM instead nothing. So I like NTVDM enhancements too like VDM Sound and dgVoodoo and TAMEDOS which runs DOS apps under NTVDM better.

---
DOS gives me freedom to unlimited HW access.

> Ok, interesting. But you can also try
> this nice little
> program. It's a DOS TSR meant to run in XP NTVDM.

It does install correctly in XP (Home SP2).

> It extends the crappy DPMI host with some of the more sophisticated
> DPMI v1.0 memory functions (int 31h, ax=504h, 506h and 507h). May be
> it also works well in Vista and allows to overcome the artificial
> 32MB memory limit, since the memory is allocated with the standard
> Win32 VirtualXXX functions.

Vista Home Premium: "loading HXVDD.DLL failed"

Not a huge issue. I think I can get OpenWatcom/Win32 to compile it now.

---
Know your limits.h

> But disabling paging to prevent the bug from triggering a PF is cca as
> smart as neglecting the existence of a bug and banning the reporting
> person to prevent further posts pointing to this bug

Heh.

> Not for me. The Win32 executable works (compiled by Matt ?), yours
> doesn't.

BTW, his default-compiled Win32 .EXE whines about tmpfile access (when run as non-admin on Vista) unlike a manual OpenWatcom build. Weird. (And yet another issue is that his MinGW is 3.4.5, I think, slightly less ideal.)

> You should fix the page fault rather than shooting around with covered
> eyes in the hope to shoot the SSE2/CR4 issue

The problem was that I didn't know what was causing it. It turned out that three things (at least) were no-nos: mucking with CRx under Windows, non-16-byte-aligned SSE2 memory access, and accidental pointer misuse re: getenv() ... oops!

> You should remove the CR4 code (since HDPMI32 cares), remove the V86
> "code" (there is no "V86" in PM DPMI code) and fix the SSE-unrelated bugs.
> Maybe you introduced them, maybe they origin from Matt but he has the luck
> that they don't generate symptoms on Win32
>
> PS: definitely NOT a JEMM386 issue

Yeah, I think it works now (tested under QEMU):

http://rugxulo.googlepages.com/paq8o8z-jan6.7z

Of course, as you mentioned, CWSDPMI doesn't emulate CRx access, and even though I like HDPMI32, I preferred to go with the "all-in-one" solution (DPMI server + .EXE a la D3X). Seems to work (DJGPP output's CRC32 matched the Win32 one under HX under QEMU). Feel free to test it, though.

> PPSS: PAQ9 is out

But based on different stuff: two mixers, no external .ASM, meant to be (ideally, 2x) faster than LPQ1 (?) but portably supporting archives > 2 GB. Or something like that.

---
Know your limits.h

> Vista Home Premium: "loading HXVDD.DLL failed"

Did you put the VDD in the "system32" folder? I don't use Vista, but some times ago I red in a thread (I don't remember from which forum) that Vista loads the VDDs only if they are put there.

> > Vista Home Premium: "loading HXVDD.DLL failed"
>
> Did you put the VDD in the "system32" folder? I don't use Vista, but some
> times ago I red in a thread (I don't remember from which forum) that Vista
> loads the VDDs only if they are put there.

No, I didn't, but I'll try later.

---
Know your limits.h

> > Would it be so horrible for JEMM386 or even HDPMI32 to automagically
> > enable SSE and FXSAVE/FXRESTORE for us?
>
> HDPMI does it. And Jemm intentionally touches only those bits in CR4 which
> it needs for its own purposes (VME, PGE).
>
> If you need it in DOS with Jemm, run a DEBUG script:
>
> a
> mov eax,cr4
> or ax,200
> mov cr4,eax
> mov ah,4c
> int 21
>
> g
> q

I don't think that's correct (and won't work in MS' 8086-only debug, you obviously need FD debug or similar, heh). At least, from what I gather, you have to turn on the MP bit and turn off the EM bit in CR0 and then enable OSFXSR in CR4. Then, it works in DOS (even without the need for FXSAVE/FXRSTOR). However, you need either a Pentium 4 or a AMD64 to use SSE2 (but SSE should work on Athlon XP or Pentium 3).

P.S. I read (and have now seen) that some late model Pentium 2s (e.g. bro's Intel Celeron "Mendocino" 366 Mhz) have the OSFXSR feature yet don't have SSE. Anyone know any good reason why??

---
Know your limits.h

> Did you put the VDD in the "system32" folder? I don't use Vista, but some
> times ago I red in a thread (I don't remember from which forum) that Vista
> loads the VDDs only if they are put there.

That's an interesting hint, but if it's true it's also very annoying, because who resolves possible naming conflicts then? And it would require an evil installation procedure ... No!

---
MS-DOS forever!

> I don't think that's correct

It's a man's indestructible right to believe ... I believe that you are not correct.

> (and won't work in MS' 8086-only debug, you
> obviously need FD debug or similar, heh).

True! Thanks for this valuable hint!

> At least, from what I gather,
> you have to turn on the MP bit and turn off the EM bit in CR0 and then
> enable OSFXSR in CR4.

???. Sounds cool at least!

> Then, it works in DOS (even without the need for FXSAVE/FXRSTOR).

What do you mean with "without the need for FXSAVE/FXRSTOR"? These are simple application level instructions.

---
MS-DOS forever!

> As a partial windows NT-based user I like to have NTVDM instead nothing.

IIRC you have a multiboot

If someone still likes NTVDM, there is much to do for M$:

SP1: increase mem from 32 MiB to 64 MiB
SP2: increase mem from 64 MiB to 128 MiB
SP3: increase mem from 128 MiB to 256 MiB
SP4: increase mem from 256 MiB to 512 MiB
SP5: increase mem from 512 MiB to 1 GiB
SP6: increase mem from 1 GiB to 2 GiB
SP7: increase mem from 2 GiB to 4 GiB
SP8: apply PAE hack for > 4 GiB of RAM (see DOS/32A)
SP9: re-allow fullscreen VGA
SP10: re-allow fullscreen banked VESA
SP11: re-allow fullscreen linear VESA
SP12: re-allow sector access to HD via INT $21
SP13: re-allow sector access to HD via INT $13
SP14: re-allow exact timing
SP15: re-implement VCPI
SP16: re-allow full access to the hardware
SP17: re-allow true RM
SP18: re-allow unreal mode
SP19: re-increase XMS version from 2 to 3
SP20: reduce boot time from 1...30 min to < 2 seconds
SP21: reduce size from cca 10 GiB to less than 1 MiB
SP22: make it as incompatible with virii as DOS is

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

> > further posts pointing to this bug
> Heh.
> and accidental pointer misuse re: getenv() ... oops!

Better Heh-effect than WOW-effect Anyway, the effect did work, the PF-bug is fixed - it works now. The naming mess indeed origins from Matt - seems he brewed a Drug&Drop-compatible console EXE

> his default-compiled Win32 .EXE whines about tmpfile access (when run on Vista)

Not for me, "bug" specific to Vi$ta

> http://rugxulo.googlepages.com/paq8o8z-jan6.7z

> though I like HDPMI32, I preferred to go with the "all-in-one" solution
> (DPMI server + .EXE a la D3X).

Me too. There is a hack for DGJPP allowing this also with HDPMI32 called then "HDLD32" by Japheth

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

> If someone still likes NTVDM, there is much to do for M$:

But NTVDM is a pretty cool V86 emulation which offers full Win32 features for V86 software and acceptable speed. It's just the crappy DOS/DOSX implementation which has some "neutralizing" effects.

I like it, anyways!

---
MS-DOS forever!

> If someone still likes NTVDM, there is much to do for M$:
>
> SP1: increase mem from 32 MiB to 64 MiB
.
.
> SP21: reduce size from cca 10 GiB to less than 1 MiB

I'll tell Bill next time we have lunch together.

> SP22: make it as incompatible with virii as DOS is

DOS is incompatible with viruses?

> Did you put the VDD in the "system32" folder? I don't use Vista, but some
> times ago I red in a thread (I don't remember from which forum) that Vista
> loads the VDDs only if they are put there.

As Admin (only), I can put the .DLL into \WINDOWS\SYSTEM32\, and then the TSR loads, but it has no effect (DOS/DPMI apps still run out of memory).

---
Know your limits.h

> SP8: apply PAE hack for > 4 GiB of RAM (see DOS/32A)

Most people don't have that much. Granted, that's changing these days, but still, it's not that common or necessary or even beneficial is few OSes / apps support or need such. (Read this for some brief tidbits about CWSDPMI and the latest unofficial r6 "test".)

> SP9: re-allow fullscreen VGA

The new driver model is what is preventing this. As has been discussed before, you maybe could use old XP driver, but it disables Aero and stops some apps from running (Vista's chess game), so it's not that great a solution.

> SP12: re-allow sector access to HD via INT $21
> SP13: re-allow sector access to HD via INT $13

Most people don't want direct access available.

> SP14: re-allow exact timing

Probably due to multitasking.

> SP15: re-implement VCPI

Incompatible and not as good as DPMI. Many programs won't run under VCPI (which is just a superset of EMS, no?). Plus, it requires ring 0 access, which many people dislike (due to stability issues??).

> SP17: re-allow true RM

Impossible for multitasking and only allows 1 MB of memory anyways (unless you count the unreal mode hack??).

> SP18: re-allow unreal mode

Heh. AFAIK, only Intel, AMD, and Via/Centaur (says Lucho) support this, not some (early?) Cyrix (at least according to that dude on FASM's forum).

> SP19: re-increase XMS version from 2 to 3

It was v3 in Win98, dunno why it isn't now (XP, Vista). But as you know, less DOS compatibility, more stability. It's a tradeoff (but I dunno if that is mutually exclusive or not).

> SP20: reduce boot time from 1...30 min to < 2 seconds

Both XP and Vista boot fast, but Vista is more accessible immediately (unlike XP). And there's also ReadyBoost. But I'm not sure they recommend rebooting a lot. I think they expect us to sleep/hibernate and wake up instead. (See ACPI.)

> SP21: reduce size from cca 10 GiB to less than 1 MiB

Impossible.

> SP22: make it as incompatible with virii as DOS is

Vista's UAC is supposed to help. And virus scanners are ubiquitous (but yeah, viruses really really suck).

---
Know your limits.h

> > At least, from what I gather,
> > you have to turn on the MP bit and turn off the EM bit in CR0 and then
> > enable OSFXSR in CR4.
>
> ???. Sounds cool at least!

Turn off the Emulate Math bit and turn on the Monitor Processor bit (something about FPU WAIT or whatever). Then, turn on the OSFXSR bit (if available, to tell the cpu that the OS supports SSE).

> What do you mean with "without the need for FXSAVE/FXRSTOR"? These are
> simple application level instructions.

I think Windows does FXSAVE/FXRSTOR for you, hence the idea that the OS needs to support it. (At least, saving/restoring manually just slows it down a lot, at least under XP, because it's already doing so, at least from what I can tell under OpenWatcom's WD.)

---
Know your limits.h

> Turn off the Emulate Math bit and turn on the Monitor Processor bit
> (something about FPU WAIT or whatever). Then, turn on the OSFXSR bit (if
> available, to tell the cpu that the OS supports SSE).

(quoting Intel's 25366821.PDF, aka "Intel 64 and IA-32 Architectures
Software Developer's Manual Volume 3A: System Programming Guide, Part 1"):

"As on the Intel 286 and Intel386 processors, the MP (monitor coprocessor) flag (bit 1 of register CR0) determines whether the WAIT/FWAIT instructions or waiting-type floating-point instructions trap when the context of the x87 FPU is different from that of the currently-executing task. If the MP and TS flag are set, then a WAIT/FWAIT instruction and waiting instructions will cause a device-not-available exception (interrupt vector 7). The MP flag is used on the Intel 286 and Intel386 processors to support the use of a WAIT/FWAIT instruction to wait on a device other than a math coprocessor. The device reports its status through the BUSY# pin. Since the P6 family, Pentium, and Intel486 processors do not have such a pin, the MP flag has no
relevant use and should be set to 1 for normal operation."

This is in contrast to Causeway/CW402's source:

.586p
mov     eax,1
cpuid
and     edx,3000000h    ; only want SSE and FXSR bit status
cmp     edx,3000000h
jne     nosse           ; both bits required
mov     eax,cr0
and     al,NOT 6        ; clear EM and MP bits
mov     cr0,eax
mov     eax,cr4
or      ax,200h         ; set OSFXFR bit to allow SSE instructions
mov     cr4,eax

But Intel also says flags should be set as this for a 486 Sx (which has no FPU): EM (1), MP (0), NE (1).

> Floating-point instructions trap to emulator; WAIT/FWAIT and
> other waiting-type instructions ignore TS.

Okay, a bit out of my league, but I still found it interesting.

---
Know your limits.h

Forgot to mention that the "SSE" doesn't work ... or at least I failed to find a "good" enough PC to test:



Anyway, MMX against NOASM test:

MMX is 2 times faster. This is no evidence of usefulness of MMX at all - here MMX ASM competed against C++ mess. Rewriting the "NOASM" C++ stuff into optimized 80386 compatible ASM would possibly reduce MMX's benefit from 2 to a value dangerously close to 1

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

> Anyway, MMX against NOASM test:
>
> MMX is 2 times faster. This is no evidence of usefulness of MMX at all -
> here MMX ASM competed against C++ mess. Rewriting the "NOASM" C++ stuff
> into optimized 80386 compatible ASM would possibly reduce MMX's benefit
> from 2 to a value dangerously close to 1

Evidence? If true, then good news - programmers can keep using P90s or less, and stop bothering to learn C++.

> This is in contrast to
> Causeway/CW402's
> source:
>
> .586p
> mov        eax,1
> cpuid
> and       edx,3000000h    ; only want SSE and FXSR bit status
> cmp        edx,3000000h
> jne       nosse           ; both bits required
> mov       eax,cr0
> and    al,NOT 6        ; clear EM and MP bits
> mov     cr0,eax
> mov    eax,cr4
> or     ax,200h         ; set OSFXFR bit to allow SSE instructions
> mov cr4,eax

I tried it out today. Value of MP is irrelevant for SSE. EM must be cleared, though, else an Exc06 occurs. However, this bit is hardly set on any cpu running nowadays.

---
MS-DOS forever!

> Forgot to mention that the "SSE" doesn't work ... or at least I failed to
> find a "good" enough PC to test:

Okay, just for the record, you don't need to set SSE2, it should automatically detect whether available or not. "set PAQ8=sse2" overrides that detection, though (even on cpus that don't support it).

Anyways, yes, you're right, the latest DOS build doesn't work (I neglected to test) due to "fixing" the alignment in the Win32 build (go figure). You can always use the Win32 build under HX (yes!), but otherwise, just get the following (Causeway and DJGPP .EXEs only, no src for now, too busy):

http://rugxulo.googlepages.com/paq-jan9.7z (227k)

BTW, I'll have to work on it some more later. So it ain't "done" yet.

> Anyway, MMX against NOASM test:
>
> MMX is 2 times faster. This is no evidence of usefulness of MMX at all -
> here MMX ASM competed against C++ mess. Rewriting the "NOASM" C++ stuff
> into optimized 80386 compatible ASM would possibly reduce MMX's benefit
> from 2 to a value dangerously close to 1

Yes, I think "NOASM" could be improved a fair bit. The real question is "why isn't SSE2 lots faster?"

Pros:

+ SSE2 is 128-bit registers, double precision (vs. 3dnow! or plain SSE or FPU)
+ SSE2 can operate at same time as FPU (in theory)
+ SSE2 (vs. FPU) is random register access instead of stack-based

Cons:

- only P4 or AMD64 or better etc. support it
- rare compiler support (well, rarer)
- doesn't seem faster
- needs specific OS support (instead of overlaying on top of FPU)
- annoying alignment issues
- potentially only super useful for math buffs or gfx whores

---
Know your limits.h

> > As a partial windows NT-based user I like to have NTVDM instead nothing.
>
> IIRC you have a multiboot

Of course I have multiboot but it's not such comfortable to reboot as just run a commandline. And when need a true multitasking. I also use Win98SE which is quite good DOS multitasker with a GUI :) They run much more DOS apps compared to restrictive NTVDM (of course for worse security and stability but I can take this risk). But some apps don't run under Win98SE so I need also WinXP and also NTVDM. Fortunately I don't need to use any Vista-only prog yet.

> If someone still likes NTVDM, there is much to do for M$:

It's not perfect but faster than emulators and if you don't touch HW much it let your DOS progs live. AFAIK MS didn't opened sources to NTVDM so modifying it's code would be difficult so rather VDDs are made.

---
DOS gives me freedom to unlimited HW access.