Serial communication in DOS apps

[Jarek Kucypera]

I have problems to make some legacy DOS application communicate
over serial port while it's doing fine under all other windows versions
including W2k.
The application performs direct access to UART and it seems to me that the
problem
is in DOS emulation in XP - maybe it can be tuned or patched somehow (SP1
does not
help) ?

J.K.

 

[Wislu Plethora]

-----Original Message-----
I have problems to make some legacy DOS application communicate
over serial port while it's doing fine under all other windows versions
including W2k.
The application performs direct access to UART and it seems to me that the
problem
is in DOS emulation in XP - maybe it can be tuned or patched somehow (SP1
does not
help) ?

Most MS-DOS apps can be coaxed into running under XP,
except for those that want direct access to hardware.
I think you're SOL, my friend.

 

[Jarek Kucypera]

Most MS-DOS apps can be coaxed into running under XP,
except for those that want direct access to hardware.

... including those accessing some standard hardware as COM1, COM2.
NTVDM intercepts access to particular io ports and amulates
behavior of UART. I think the problem is the M$ boys
(and/or girls decided to improve some piece of quite well
working code and "fixed" the UART emulation

I think you're SOL, my friend.

Pardon ?

J.K.

 

[Alex Nichol]

I have problems to make some legacy DOS application communicate
over serial port while it's doing fine under all other windows versions
including W2k.
The application performs direct access to UART and it seems to me that the
problem
is in DOS emulation in XP - maybe it can be tuned or patched somehow (SP1
does not

XP will absolutely prohibit programs from direct control of hardware in
such a way. You could set up a dual boot to (say) a Win98 in a separate
FAT 32 partition, but you will not do it from XP

 

[Si Ballenger]

XP will absolutely prohibit programs from direct control of hardware in
such a way. You could set up a dual boot to (say) a Win98 in a separate
=46AT 32 partition, but you will not do it from XP

Something definately changed in XP, as my quick basic application
cannot communicate with the com port. On the other hand, the
below line in a batch file will send a string of "a"s to com1 on
my XP pro machine.

echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >com1

 

[E.P. van Westendorp]

You could download and try "UserPort" from below page.
http://www.embeddedtronics.com/design&ideas.html

 

[Alex Nichol]

Something definately changed in XP, as my quick basic application
cannot communicate with the com port. On the other hand, the
below line in a batch file will send a string of "a"s to com1 on
my XP pro machine.

echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >com1

That though is going through one of the Command interpreters into the
*windows* emulation of the DOS environment, which is writing to the port
through Windows. It is where a DOS program tries to go around DOS and
manipulate IO areas, and send hardware commands itself that you are cut
off

 

[E.P. van Westendorp]

You could download and try "UserPort" from below page.
http://www.embeddedtronics.com/design&ideas.html

<QUOTE>
UserPort is a simple kernel mode driver for Windows NT/2000/XP that will
give programs access to I/O ports.
This makes it possible to access the hardware I/O ports directly under
Windows NT/2000/XP just like 95/98/ME.
Under XP, you may have to set the compatibility mode for the executable
to "Windows 98" mode.
<\QUOTE>

 

[Jarek Kucypera]

You could download and try "UserPort" from below page.
http://www.embeddedtronics.com/design&ideas.html

<QUOTE>
UserPort is a simple kernel mode driver for Windows NT/2000/XP that

[cut]

I've used a similiar tool from
http://www.beyondlogic.org/porttalk/porttalk.htm
and it didn't help.
My speculation is NTVDM makes some delay in the flow of data
from UART to the 16-bit app. As direct access to io-ports is given,
the problem must occur in calling the app's IRQ routine, I think
NTVDM delays calling the routine and the communication breaks
beacuse of timeout (the app uses some time-based protocol with
the other side of the serial cable).

J.K.

 

[Si Ballenger]

Exactly, and the problem is how to make the old,
legacy apps run under XP.

J.K.

I use userport to get user level access to my parallel port and
such, but it doesn't seem to be of use in getting my quickbasic
com port program to run on XP. Seems XP won't/can't open a
comport the old way by treating it some what like a text file in
a quickbasic type of application. If you find an easy answer,
post it up.

 

[Jarek Kucypera]

If you find an easy answer,
post it up.

I've found a solution for my app: www.direct-io.com
(I think I was right speculating about IRQs .
But I don't think it helps in the case of "file-like"
access to serial ports. On hte other hand it costs
just some time to try .

J.K.