Problems Running DOS Programs Under Windows NT 4.0

The information in this document (Article) was obtained while trying to run several true DOS applications in a DOS shell (actually a Virtual DOS Machine - VDM) under MS Windows NT 4.0.

The primary sources for this information were the Microsoft Knowledge Base, and the built-in Windows NT 4.0 help. Additional sources are identified as appropriate.

Windows NT 4.0 provides two ways to execute DOS applications.

cmd.exe		This is the NT command prompt. Everything which the user can do from the GUI can be done from here, including executing DOS commands. This is a 32-bit application.
command.com		This 16-bit program provides an alternative method to run DOS applications.

PIF Files

autoexec.nt and config.nt

order of execution

Environment Variables

Both DOS and NT use environment variables to specify machine and user specific values.

The basic DOS bat-file syntax for setting environment variables is

   set variablename=value 

There are several differences in how the environment space is managed in real DOS, NT cmd.exe, and NT command.com.

Amount of Available Environment Space

Real DOS allocates a fixed amount of space to store environment variables. The default size is only xxx bytes. Adding the following command to c:\config.sys increases the available environment space to the value after /e:, 4000 bytes in this case.

    c:\command.com /e:4000 

Some DOS programs check the amount of available environment space and will refuse to execute unless there is enough space available. [check the DOS interrupt which gives this]

In Windows NT 4.0, placing this command in config.nt has no effect. In Windows 95, the PIF dialog box has a field to specify the amount of environment space that the application requires. This field is also available for the application's shortcut dialog box, but it has no effect. To paraphrase the NT 4.0 built-in help -

This field is not functional. It is left in only so that the interface looks like the Windows 95 interface. This will somehow make NT 4.0 more user friendly and easier to learn. However, it does not work. In fact there is no way to control the size of the environment space. May you enjoy many hours troubleshooting why this do nothing field is present.

The actual help text follows:

Specified the number of bytes of memory reserved for the NS-DOS Command Interpreter (Command.com). This setting also applies to batch files having the extension .bat.

If set to Auto, the initial size of the environment is determined by the SHELL= line in your Config.nt file.

This feature is only in effect when the program is run under the Windows 95 operating system.

As you have no doubt noticed, most of the fields in the properties dialog do nothing. They exist simply to simplify the interface. (yeh, right!)

The only way that we could get one of our applications to run was to place

    c:\winnt\system32\command.com e:/2000 

on the command line of a shortcut .

Printing

c:\dos\print.exe is a 16-bit TSR whereas 
c:\winnt\system32\print.exe is a 32-bit device driver.

If a local printer is physically connected to LPT1, 
an infinite loop can be produced by 

    net use lpt1 //<Name of this computer>/<share_name_of_printer_on_LPT1>


When the DOS application writes to LPT1, 
the network drivers will capture the output and send it 
to the indicated print driver. 
The driver will then try to send the job to LPT1, 
but the output will be captured again and once more sent to the driver. 
This will continue in an infinite loop with no data 
ever actually reaching the printer.

This action can be observed by opening the appropriate print spooler. 
As the print job is sent to the printer, a new job is sent to the spooler. 
After the job is sent, it is deleted, leaving the newly spooled job. 
This is repeated indefinitely. 
If a separator page is defined for that printer, 
it is attached to each job as it is sent to the printer. 
Therefore, the size of the print job will increase a few bytes 
each time the spooler tries to print it. 
Eventually, all the memory on the hard drive will be consumed and 
the system will crash.

Slow Applications

According to the MS KB Q103406, when an MS DOS application is running 
in full screen mode, and there is no current keyboard input, 
NT may assume that the application is idle and will reduce 
its execution priority. This is observed by slow screen redraw times. 
Edit the PIF file to disable 
Advanced Options / Multitasking / Detect Idle Time. 
(NT 3.51 - c:\winnt\system32\pifedit.exe & pifedit.hlp)

Other

The 16-bit doskey.exe TSR not available under command.com. 
A 32-bit version is available under cmd.exe.

EMM=RAM - only certain versions of NT 4.0

Glossary


 
VDM - Virtual DOS Machine
 
TSR - Terminate and Stay Resident



Problems Running DOS Programs Under Windows 95
Print problems

I have a situation where DOS applications need to print 
on both local (lpt1) and network printers. 
However, the applications are old and only print to lpt1. 
If nothing is done, the applications print to the local printer; 
the net use command is used to re-direct the output 
to a network printer. 
The problem occurs when I try to disconnect the network printer and 
use print.exe to write to the local printer. 
There is never a problem if copy is used.

   print /d:prn
   net use lpt1: //xx/cc
   net use lpt1 /d

   print autoexec.bat


fails. A dialog box opens and clicking OK closes the DOS window.

However, if you copy a file to lpt1 before using the print command, 
it works.

   print /d:prn
   net use lpt1: //xx/cc
   net use lpt1 /d

   copy autoexec.bat lpt1
   print autoexec.bat


and if print is not run until after net use lpt1 /d 
it also works.

How to get a CD-ROM drive to work under DOS

Format.com Problem

OK from a DOS prompt but fails when called from an application


Does not recognize the disc as formatted. 

format /q for quick format.

File Locking

When running a DOS application in DOS, 
the program is able to copy files from the floppy 
to the hard drive, over writing all of the files. 
When the same program is run from a DOS shell, 
some of the files are locked and can not be over written. 
This was verified by using Explorer to try to delete 
the same files while the application was running in a DOS window.