Bill H wrote:

> Heres another thought - have you tried using remote desktop,
> pcanywhere or radmin? I could see 2 machines that are sing the
> full screen doses being accessed as windows on a third machine
> using one of these programs.

If my PB app can't write to two VGA screens simultaneously, and if XP
can't run two full-screen DOS sessions independently, simultaneously,
each writing to their own screen on a two-monitor system, then in order
to have a two display solution I must operate a slave PC with it's own
monitor.

In order to modify my PowerBasic app to output the data to a slave
system, the com port seems to be the most straightforward solution.
This solution was implimented and it works if both systems have been
booted into DOS.

However, when the Master system has been booted into XP (as it must be
when this solution is being used by the client) the communication data
rate is about 10% of what it is when the Master system has been booted
into DOS.

This is maddening, as other PC's acting as the Master do not show this
drop to 10% when the app is running under XP. I cannot use those other
PC's because their motherboard does not have ISA slots.

If there is some other way I can have my PB app send data to another
system, via some other communications channel, I don't know what that
could be. Perhaps a bi-directional printer port. I haven't explored
data transfer in PB using the printer port.

I've discovered that having a CPU with either dual-core, or
hyperthreading, results in good (or at least normal) com port
performance for a dos app running under XP.

I had been looking at why the com port performance of my app was ok on
some machines and not others. One variable I didn't take into account
was the CPU. Even on a PC with a 3.2 ghz celeron, the com port
performance was about 6% of theoretical maximum, but on a 3 ghz Pentium
with HT it rose to about 85%.

That lead me to look at why the ntvdm behaves this way. Some mention of
it emulating a very primative uart (8250 ?) with no transmit and receive
buffer capability.

It looks like I'll have to use direct port reading and writing to the
uart (and use something like port-talk) as well as uninstall the com
port under XP (so that ntvdm doesn't intercept com port I/O - maybe?).