R
Roger Leigh
Hello,
I'm trying to run our old DOS application on Windows XP. We want to
use XP to take advantage of its much better networking than the DR-DOS
PNW networking we are currently using. In addition, it will allow our
users to run modern software alongside it, without needing a separate
machine (and network).
So far, I've got the application working, networked, just fine. It's
far faster than running natively on DOS, on the same machine!
However, I have a few issues I'd like to solve before its usable. If
I can't solve these, I'll have to continue to use DR-DOS.
Firstly, the application (a Point of Sale program) uses two COM ports
to send data to a pole display and a receipt printer. It doesn't talk
to them directly, it uses LPT2 redirected to COM1 to talk to the
printer, and spawns COMMAND.COM (echo) to send data to the pole
display, so there is no problem with direct hardware access, AFAICT.
However, there's a 30 second delay when printing a receipt, and trying
to send data to the pole display freezes the program.
For both of these cases, I can send data to both devices simply using
"echo foo > com[14]" from a COMMAND.COM shell. If I quit the
application before the 30 secs is up, the data is immediately flushed,
presumably when the device is closed.
What I'd like here is to /completely/ disable all buffering of COM1
and COM4 data, so that the emulated DOS COM ports are behaving simply
as a passthrough to the Windows COM ports. Is this possible?
Ideally, I'd like the Windows COM1 and COM4 open all the time, and the
emulator to allow opening and closing of the emulated COM1 and COM4
without causing an open/close of the "real" port.
My other problem is running the program in full-screen mode. Most of
the time, when I start the program (using a shortcut) the program
starts in a fullscreen 80x25 display. However, it sometimes starts
compressed vertically by a factor of two (i.e. like 80x50 with a black
band on top and bottom). What causes this behaviour, and how can I
prevent it?
Many thanks,
Roger
I'm trying to run our old DOS application on Windows XP. We want to
use XP to take advantage of its much better networking than the DR-DOS
PNW networking we are currently using. In addition, it will allow our
users to run modern software alongside it, without needing a separate
machine (and network).
So far, I've got the application working, networked, just fine. It's
far faster than running natively on DOS, on the same machine!
However, I have a few issues I'd like to solve before its usable. If
I can't solve these, I'll have to continue to use DR-DOS.
Firstly, the application (a Point of Sale program) uses two COM ports
to send data to a pole display and a receipt printer. It doesn't talk
to them directly, it uses LPT2 redirected to COM1 to talk to the
printer, and spawns COMMAND.COM (echo) to send data to the pole
display, so there is no problem with direct hardware access, AFAICT.
However, there's a 30 second delay when printing a receipt, and trying
to send data to the pole display freezes the program.
For both of these cases, I can send data to both devices simply using
"echo foo > com[14]" from a COMMAND.COM shell. If I quit the
application before the 30 secs is up, the data is immediately flushed,
presumably when the device is closed.
What I'd like here is to /completely/ disable all buffering of COM1
and COM4 data, so that the emulated DOS COM ports are behaving simply
as a passthrough to the Windows COM ports. Is this possible?
Ideally, I'd like the Windows COM1 and COM4 open all the time, and the
emulator to allow opening and closing of the emulated COM1 and COM4
without causing an open/close of the "real" port.
My other problem is running the program in full-screen mode. Most of
the time, when I start the program (using a shortcut) the program
starts in a fullscreen 80x25 display. However, it sometimes starts
compressed vertically by a factor of two (i.e. like 80x50 with a black
band on top and bottom). What causes this behaviour, and how can I
prevent it?
Many thanks,
Roger