Developing serial protocol modules

Serial protocol modules are DLLs, with a single entry point, which returns a factory object which is capable of creating one or more objects that actually implement serial services.

Comms server modules have a .csy extension and a UID2 of 0x10000049.

Serial protocol modules can access all operating system components including network protocols, files, stores, and info print message amongst others.

Due to the nature of the comms architecture, it is important that a serial protocol module never performs a synchronous operation on any other object which may, in time, cause a further request on another serial-like object. In general, this could mean any comms server module that does not communicate exclusively and directly through a device driver. Any protocol stack used by a CPort may eventually make a request on a serial port. If this happens, the whole of the comms subsystem will deadlock because the comms server is blocking and cannot respond to the new request. This means that great care must be taken when writing a comms server module: for example, one must always call StartProtocol() which is asynchronous before calling RSocket::Open() which is synchronous, but may cause an RComm class to be instantiated. Similarly the CPort::Destruct() function is present because a standard C++ destructor must run synchronously, but this is not permissible for serial protocol modules that may have some shutdown code involving RComm classes.