DOS application running under Windows

[Gunther]

I'm back from my journey to CERN. On the long train ride I could think about a lot and I've probably found a way, to use AVX and AVX2 with a plain DOS program. A first quick and dirty hack showed me that the idea works fine.

I must now make it more bullet proof to provide the code inside the forum (writing procedures, writing comments and excluding side effects). Therefore, I need a simple method to check, if the program is running inside the Windows DOS emulation. My first idea was, to inspect the environment of the application, but that's a bit awkward. Does anyone know another easier way? Any help is welcome.

Gunther

[FORTRANS]

Hi,

   One way would be to call a function supported by a real mode
DOS environment that is not supported by the NTVDM.  On my
systems this include BIOS interrupt 15H function 86H, "Wait".
With Windows it does not wait.  With DOS it does wait.  It will
wait in an OS2 VDM, but that's not a concern for most people.
I think function 83H "Event Wait" has similar problems, but I don't
remember the specifics.  Untried, but function 89H "Switch to
Protected Mode" sounds like Windows would hate it as well.

   The HLT instruction behaves differently under a Windows NTVDM
and real-mode DOS as well.  Basically in real mode it waits for
(usually) the timer interrupt and causes a delay.  With Windows it
does not delay.  There was a discussion in the Soap Box when I
wrote a register visualization program that needed to lower CPU
usage on that effect.

   I might have some other notes on Windows problems with my
DOS programs, but those two are the ones that gave me the most
frustration.  I can check for others if you want.

HTH,

Steve N.

[nidud]

I assumed this was a safe way of testing:

Code: [Select]

mov ax,1680h
int 2Fh

in most plain DOS versions this will not be supported

Code: [Select]

DOS version: 06.22

mov ax,1680h ; MS Windows, DPMI, various
int 2Fh ; - RELEASE CURRENT VIRTUAL MACHINE TIME-SLICE
; 00h if the call is supported
ax: 1680 ; 80h (unchanged) if the call is not supported

DOS version: 07.10
ax: 1680 ; 80h (unchanged) if the call is not supported

FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]

DOS version: 06.20
ax: 1680 ; 80h (unchanged) if the call is not supported

it should be supported in emulated software

Code: [Select]

Microsoft Windows XP [Versjon 5.1.2600]

DOS version: 05.00
ax: 1600 ; 80h (unchanged) if the call is not supported

Windows 98 [Versjon 4.10.2222]

DOS version: 07.10
ax: 1600 ; 80h (unchanged) if the call is not supported

however, it seems like DOSBox do not support this

Code: [Select]

DOSBox version 0.74. Reported DOS version 5.00.

DOS version: 05.00
ax: 1680 ; 80h (unchanged) if the call is not supported


[Gunther]

Hi Steve,

your proposal is a way. I'll think about it.

Hi nidud,

yes, the multiplex interrupt could be a chance. We'll see.

Gunther

[nidud]

they should have cleared AL here

dosbox-0.74\src\dos\dos_misc.cpp:

Code: [Select]

case 0x1680: /*  RELEASE CURRENT VIRTUAL MACHINE TIME-SLICE */
//TODO Maybe do some idling but could screw up other systems :)
return true; //So no warning in the debugger anymore
case 0x1689: /*  Kernel IDLE CALL */
case 0x168f: /*  Close awareness crap */
   /* Removing warning */
return true;


[MichaelW]

For what it's worth, back in the day for TSRs that would not work under Windows, after trying multiple methods I settled on this code (in the C booster, only the resident parts were done in assembly):

Code: [Select]

        // Return error if Windows (3.10 or 3.11) running
        // Function will return ax == 0 if supported
        reg.x.ax = 0x160a;                  // Identify Win Version and Type
        int86 (0x2f, &reg, &reg);
        if ( ! reg.x.ax)
        {
            ShowMsg (" cannot be installed from Windows");
            exit (-1);
        }


[Gunther]

Michael,

thank you for sharing the code. It detects Windows 3.x. I hope that I've found a similar way to detect Windows NT and successors.

Gunther

[redskull]

BOP code 60 gives you the 'version' of ntvdm that's running (well. whichever antiquated version of SoftPC it's based on).  Install a trap handler for invalid opcodes, and then execute c4/c4/60.  If you get the version, probably 3.0, you're probably under NTVDM, and if you enter your trap handler, then you probably aren't.  Obviously this wouldn't work for DosBox et al

-r

[Gunther]

Hi redskull,

BOP code 60 gives you the 'version' of ntvdm that's running (well. whichever antiquated version of SoftPC it's based on).  Install a trap handler for invalid opcodes, and then execute c4/c4/60.  If you get the version, probably 3.0, you're probably under NTVDM, and if you enter your trap handler, then you probably aren't.  Obviously this wouldn't work for DosBox et al

-r

yes, that would work. I've found another way. Did you read this and this thread?

Gunther