DDS Tools: Running 16 bit tools under Windows

Almost all Dunfield tools were developed in-house for our own use. Due to
reliability concerns, we avoid using Microsoft Windows, hence most of our
tools are compiled as 16 bit executables which allows them to run on many
different platforms (see FAQ).

Most of our tools will run under Windows with no special concerns. The
tools do not employ "tricky" programming techniques or other devices which
would make them specific to any particular operating system.

Here are some notes regarding various versions of Windows:
(In general each note also applies to Windows versions listed further
 down in the file)


Windows 95/98/ME:
-----------------
Since these versions of windows are DOS based, there are virtually no
issues with running DDS tools. The only known issue is due to the fact
that Windows does not provide a true real-time environment, which may
affect some of our tools which rely on high cpu/polling speeds, such as
PCLA or DLM. To operate these tools at their very highest capture speeds,
you may need to reboot in pure DOS mode.

NOTE: All versions of Windows seem to do a poor job of allocating real
time, especially to network device drivers. I have observed that certain
network operations can cause all Windows platforms to "freeze" for 100's
of milliseconds. You don't notice this in a word processor, however many
events can be lost to real-time applications like PCLA.
Disabling the network can help.

Also, nearly every Windows software package you install "attaches" itself
to the operating system, installing device drivers and loadable modules
which include themselves in the message loops. The net effect of this is
that the more and more programs you install, the more and more "hidden"
background tasks will be active (even if you are not using the application
which installed them). Each one makes your system less and less real time
stable.


Windows NT/2000:
----------------
These versions of windows run as a true 32 bit protected mode operating
system, and do present some challenges to certain DDS tools:

PARALLEL PORT: WinNT/2K does not permit a DOS application to take direct
control of the parallel port. This prevents DDS tools which use the parallel
port as a general I/O device from working. These include: PCLA, AVRLOAD,
I2CE and LINSCOPE. There are some 3rd party tools available which claim to
provide direct Parallel port access from the WinNT/2k DOS-box, however I
have not evaluated them.

SERIAL PORT: WinNt/2K does not permit a DOS application to directly access
the serial port(s), however it does provide a virtual serial port emulation
which works fairly well. Performance is degraded over a real serial port, it
can sometimes take a few 10's (or even 100's) of millisconds before a
character received by the physical uart is reported down to the DOS box
application. You may notice that certain serial operations take longer than
they do under Win9x/ME, but generally everything works.

CPU: Like Windows 95/98/ME noted above, WinNT/2K does not provide a true
real-time environment. This effect tends to be greater than the DOS based
windows. Most DDS tools are not affected by real time, however things like
DLM may not be able to operate at high capture rates under WinNT/2k. Closing
other applications and disabling the network can help.

VIDEO: WinNT/2K's DOS box has "weird" default window charactistics. You may
find that running applications "Full Screen" results in only the top half of
the screen being used. You can fix this by changing the video properties of
the DOS box to a physical and logical size of 80 columns by 25 rows.


Windows XP:
-----------
Microsoft continues to abandon DOS compatibility in Windows XP. All of
the NT/2K notes apply, as well as:

TIMERS: WinXP does not automatically maintain the BIOS timer tick that is
used by most 16 bit applications which must perform timing. You can however
enable it by checking the "Compatible Timer Emulation" box under the program
properties.

SERIAL PORT: The serial port emulation in the WinXP DOS box is seriously
broken. I have observed that WinXP often takes 8-10 SECONDS to report a
character down to the DOS-box application after it has been physically
received by the UART. This breaks most retry timers and counters in the
application software, making the XP serial port virtually unusable from
a DOS-box application. Even if you make the timeouts very long, the serial
transfers are far to slow under XP to be useful.

Through experimentation, I have come up with one work around for this
behaviour. The slow serial-port response only happens if the application
has appeared on the screen in a "window" or minimized (the two systems
are so related!) In other words, as long as the application opens in
"Full screen" and does not switch to a window, the serial port works much
better (about the same as WinNT/2K). Unfortunately, if you switch the
application to display in a window, the serial port will stop responding
correctly, and will not recover, EVEN IF YOU SWITCH THE APPLICATION BACK
TO FULL SCREEN DISPLAY.

Unfortunately, asynchronous events from other applications will sometimes
switch the display to a window or minimize it. These include messages from
other applications, screen savers, network traffic etc. Once this has
happened, the only way to recover the DOS-box serial port is to close the
DOS application (all the way back to windows - not just to the DOS box
command prompt), and re-open it in full-screen display mode.

So, you **CAN** run serial DOS-box applications under WinXP, however you
can do so reliably only in "full screen" display mode, and you must be
very careful NOT to allow any windows display to appear while you are
using the application. Sorry, but I have been able to find no other
solution - as noted above, WinXP's DOS-box serial emulation is broken.

