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]

deleted

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

deleted

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


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