News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

DOS application running under Windows

Started by Gunther, April 02, 2015, 11:39:57 AM

Previous topic - Next topic

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
You have to know the facts before you can distort them.

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

#2
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
You have to know the facts before you can distort them.

nidud

#4
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):

        // 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);
        }

Well Microsoft, here's another nice mess you've gotten us into.

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
You have to know the facts before you can distort them.

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,

Quote from: redskull on April 10, 2015, 10:31:48 AM
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
You have to know the facts before you can distort them.