FM> I think you treat it like Borland has with their TStream object. (I
FM> don't know whether they provide this (class?) in C; as you know I write
FM> Pascal.) A TStream is an object which has 14 methods, plus Init
FM> (constructor) and Done (destructor). A TStream is an abstract class
FM> which doesn't do anything, but its descendent classes are useful. In
FM> their standard (Pascal) library they provide descendants TDosStream and
FM> TEmsStream, and TBufStream as a descendent of TDosStream.

FM> You might have a TCommsStream descended from a TStream, with, perhaps,
FM> TZmodemStream descended from that. Obviously some methods would be
FM> irrelevant to a zmodem stream; Seek for example should return an error.
FM> (Hmmm, maybe not in am TZmodemStream.) You would implement the
FM> constructor and destructor, and at least TZmodemStream.Read &
FM> TZmodemStream.Write. Others may also be relevant.

That's a very interesting approach.  Do you have a way of
integrating bidirectional support in there though?

FM> Obviously I've used Pascal notation, I'm sure you can see how that would
FM> be done in C, but I find the "dot" notation more explicit.

Yeah, at the high level design, I don't care what notation or
language is used.

FM> I don't know whether your Borland C package provides these objects, if
FM> not let me know & I'll try and post the relevant bits from the help
FM> file.

There's heaps of add-in stuff with Borland, but I wouldn't
touch any of it, because of the portability considerations.
And with the high-level design you have explained, I don't
need any more info from Borland.  

I'll have to think about what you and Rod said and come up with
a new design.  Thanks + bye.  Paul.
@EOT:

---