[comp.windows.ms.programmer] Looking for a COM DLL

nak@cbnews.cb.att.com (neil.a.kirby) (06/27/91)

I'm looking for a serial communications DLL.  I can't be the only one...

I would not mind coming across a DDE TSR that would manage the com port,
but a DLL should do the job - I just don't want to write the thing.

Neil Kirby
nak@archie.att.com

ole@edb.tih.no (Ole Nymoen) (06/27/91)

In article <1991Jun26.204757.19291@cbnews.cb.att.com>, nak@cbnews.cb.att.com (neil.a.kirby) writes:
>I'm looking for a serial communications DLL.  I can't be the only one...

What functionality in addition to what Windows already provides are You
looking for?

Ole

hans@pine.circa.ufl.edu (Hans van Oostrom) (06/28/91)

In article <1991Jun26.204757.19291@cbnews.cb.att.com>, nak@cbnews.cb.att.com (neil.a.kirby) writes...
>I'm looking for a serial communications DLL.  I can't be the only one...
> 
>I would not mind coming across a DDE TSR that would manage the com port,
>but a DLL should do the job - I just don't want to write the thing.
> 

A TSR is definitly not the way to go.  Windows has interrupt driven 
serial I/O drivers build in, and they work pretty good if you don't do 
high baud rates.  The following functions are part of the SDK:

Communication Functions

Function	    Description
BuildCommDCB	    Fills a device control block with control codes.
ClearCommBreak	    Clears the communication break state from a 
		    communication device.
CloseComm	    Closes a communication device after transmitting the 
		    current buffer.
EscapeCommFunction  Directs a device to carry out an extended 
 		    function.
FlushComm	    Flushes characters from a communication device.
GetCommError	    Fills a buffer with the communication status.
GetCommEventMask    Retrieves, then clears, an event mask.
GetCommState	    Fills a buffer with a device control block.
OpenComm	    Opens a communication device.
ReadComm	    Reads the bytes from a communication device into a 
                    buffer.
SetCommBreak	    Sets a break state on the communication device.
SetCommEventMask    Retrieves and then sets an event mask on the 
		    communication device.
SetCommState	    Sets a communication device to the state specified by 
		    the device control block.
TransmitCommChar    Places a character at the head of the transmit queue.
UngetCommChar	    Specifies which character will be the next character 
		    to be read.
WriteComm	    Writes the bytes from a buffer to a communication 
		    device.

You can write a DLL to interface with some or all of these functions 
if you really need a DLL.  Otherwise just use them in your program.

Hans van Oostrom
PO Box J-254, JHMHC                 hans@ufpine                (BITNET)
Gainesville, FL  32601, USA         hans@pine.circa.ufl.edu    (INTERNET)
>>>          Hoe ver je ook gaat, overal zie je landgenoten           <<<

nak@cbnews.cb.att.com (neil.a.kirby) (06/28/91)

In article <4q7gtgqe2C@humpty.edb.tih.no> ole@edb.tih.no (Ole Nymoen) writes:
>In article I write:
>>I'm looking for a serial communications DLL.  I can't be the only one...
>
>What functionality in addition to what Windows already provides are You
>looking for?

I *think* what I'm looking for can be found in /windows/system/comm.drv.
I rechecked the SDK doc and found that DRVs are a form of DLL.  Of course,
this happens after I post to the net...  Now all I have to do is get the
messages from the DLL into Actor... (anybody out there bite on that one?
The DRV either uses PostMessage or I have to poll it, I haven't found out
which yet)

Thanks to all

Neil Kirby

testurm@immd4.informatik.uni-erlangen.de (Torsten Sturm) (06/28/91)

hans@pine.circa.ufl.edu (Hans van Oostrom) writes:

>A TSR is definitly not the way to go.  Windows has interrupt driven 
>serial I/O drivers build in, and they work pretty good if you don't do 


It is not true, that the comm.drv is real interrupt driver commdriver.

I have the source code of it.

If you call writecomm(), windows make a while-loop, calling for 
each (!) character in the buffer a call to the driverfunction
$SNDCOMM. This is not what I would call an interrupt-driven way to
send characters. This is additionally the reason, why you cannot run
at high baud rates.

Torsten.
---
Torsten Sturm 
tnsturm@faui09.informatik.uni-erlangen.de
tnsturm@faui40.informatik.uni-erlangen.de
testurm@faui41.informatik.uni-erlangen.de
testurm@faui43.informatik.uni-erlangen.de
storm@faui80.informatik.uni-erlangen.de