Serial ports and DOS emulation

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
 
Y

Yves Leclerc

You can still re-direct LPT ports to Com port. The command is "net use" but
I do not know more than that.

Y.

Roger Leigh said:
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

--
Roger Leigh

Printing on GNU/Linux? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848. Please sign and encrypt your
mail.
 
R

Roger Leigh

Yves Leclerc said:
You can still re-direct LPT ports to Com port. The command is "net use" but
I do not know more than that.

Thanks, but that part it working just fine. It's disabling the serial
port buffering (within NTVDM.EXE) that's proving to be impossible.

We've managed to kludge around this, but overall I'm rather
unimpressed with NTVDM, due to it's almost complete lack of
documentation and configurability, unlike other DOS emulators
e.g. DOSEMU/DOS-C. I did ring MS technical support about this, but
they were a complete joke (they knew less about the issues than I did,
and I'm a Linux coder most of the time, and am not in any way a
Windows expert...).


Thanks for your time (and apologies for the rant--I've wasted three
days trying to get the *&%! thing to work!)

Roger
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top