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