Rich Mellor 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. > > Trouble is Per, that you cannot do all this within a device driver because > it is running in supervisor mode. > I also understand that a non-directory device cannot open a channel to a > file.... > > This is why the THING was envisaged
I KNOW, and this is a way round the problem. NO channels are opened inside the driver - just as shown above. And whether a Thing or a Job is used to manage the different stages of the printing utility doesnt really make a difference. Jobs are more universal (Hot_rext is required for Things as its not part of Qdos) and the only Things that actually do any unsupervised work anyway are EXECutable Things - ie jobs. > > > > > 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. > > > > Different protocols are needed to handle different QL programs and add > extra functionality. Not really too much trouble to add support for > different protocols - its more a question of whether the filters are > written to support them You seem to forget that straight ASCII is understood by ESC/P2, so you could LIST a Basic program to the device driver/printer utility that only supported EAS/P2. Other application programs will usually come with their own printer drivers. If these are all configured to use ESC/P2 then there is no need to support any other protocol. Graphics programs will have drivers that provide the codes required to show that it is not just outputting plain text. Again, if the ESC/P2 driver were chosen then that would simplify the whole design of this project by cutting out another unnecessary middleman! Per _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
