Wolfgang Lenerz writes:
Or skip the Thing altogether and make its fuctionality part of the PFF device driver:
On the Open call the PFF device driver's primary functions are decode the name check the details set up and configure a channel definition block If all of the above are ok then, on exiting, set the calling job's program counter to a subroutine that starts an independent job that opens any channels and keeps things moving, ie a Driver JOB, and then returns to the calling job, where it left off, with a channel ID.
The Driver Job could then set up the appropriate Filter Program for that protocol (is this really needed?) and provide it with an input pipe which would be connected with the driver at the other end and operated like a queue via normal serial IO.
A device driver can never setup a job.
This scheme has no support for multiple protocols though that could be built in somehow).
The filter programs would need to know whether to get data from pipe or file. This would either require configuring both driver and program of having a second "read printer data" device which is used by the filter program (which is the other end of the pipe for the "write printer data" PFF device).
Joachim
_______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
