jlh@loral.UUCP (The Happy Hacker) (01/06/88)
Hi, its me again. As it looks like there's a better than even chance
I'm gonna have to write a communications package for an ibm pc (yeech) I
need some info. The following packages offer some kind of communications
support, ranging from device drivers written in assembly to complete
libraries with C source. If you have any experience with either the
package or the company I'd really like to hear about it. I'd also
appreciate info on anything not listed here and advice on what to do and
what not to do for this project.
Below I've listed the packages I've found, the company offering it, and
their phone number. If you want more info on a particular package let
me know and I'll send what I can to you. I can also post a summery if
enough people ask me to, or one person threatens me bodily harm if I don't.
Abraxas emslib $139
Abraxas Software Inc.
503-299-0116
Asynch Manager $175
Blaise Computing Inc.
415-540-5441
The Greenleaf comm library $185
Greenleaf software Inc
214-446-8641
No Limit $129
MEF Environmental Inc
512-251-5543
PforCe $395
Phoenix Technologies ltd.
617-769-7020
C Power Pack 3 $149
Software Horizons Inc
617-273-4711
Blackstar C function library $99
Sterling Castle, Inc
800-7CASTLE
Jim
Happiness is lots of little things. Green, about 2 1/2" by 6.
--
Jim Harkins
Loral Instrumentation, San Diego
{ucbvax, ittvax!dcdwest, akgua, decvax, ihnp4}!sdcsvax!sdcc6!loral!jlhpete@octopus.UUCP (Pete Holzmann) (01/07/88)
In article <1516@loral.UUCP> jlh@loral.UUCP (The Happy Hacker) writes: >.... The following packages offer some kind of communications >support, ranging from device drivers written in assembly to complete >libraries with C source. If you have any experience with either the >package or the company I'd really like to hear about it. I'd also >appreciate info on anything not listed here and advice on what to do and >what not to do for this project. [list of several libraries] The first and foremost thing that a set of communications subroutines must do is to implement *Interrupt Driven* serial I/O. Without this, you are guaranteed to have trashy serial communications under almost any real world conditions. The MS-DOS BIOS does not provide this capability. That's the whole reason why simply opening COM1 or COM2 doesn't work right. I have just finished checking on PforCe and BlackStar/Sterling Castle. Neither one of these libraries provides interrupt driven serial I/O (they just call the BIOS). Don't waste your money on these libraries if you need serial I/O routines. Blaise' package works, and works well. Slightly clunky, but not too bad. Don't know about the other commercial packages you listed. A couple of 'async' routines came out over the net a while back. They blow up under various conditions. (This does *not* include Tim Pozar's recent posting- I haven't tried to kill it yet). Dr. Dobb's Journal published a set of routines recently. They work pretty well, as long as you are using them to control all serial ports on your machine. Problems occur if, for example, you try to use one COM port for a serial mouse (controlled by microsoft mouse library) and the other port for some other serial device controlled by the DrDobb routines. The mouse interrupt handler gets wiped out and things go downhill from there. The 'FOSSIL' drivers (mentioned by Tim in his posting) seem to work well. I am not sure about their Public Domain status, nor have I seen good programmer documentation for them. Having just about given up on finding a truly good PD serial communications library, I'm about ready to sit down and write it myself. Gee, something else I can do to avoid working on my accounting! :-) (I *hate* the overhead junk-work associated with being a consultant. Sigh.... (mumble... mumble... slink back into hole and calm down again...) -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746