Joachim Van der Auwera writes:
> >>A device driver can never setup a job.
> >
> > You didnt read my algorithm: It doesnt. All it does is to CAUSE the
calling
> > job to do that. This is an accepted tequnique in Qdos.
>
> Don't think so. I would like to know the details about how that would be
> done.
How detailed do you want it?
When the Open call is entered the system is in SV mode.
The job making the call is the current job
The current job's ID is known
Current job is known to be alive and is not removable during the call
Find its JCB entry
Find its SP and increment it by four
Put its PC into the location pointed to by its SP (top of its User Stack)
Put the initialisation code's address in its PC
Exit the Open call, ie return control to the calling program
It, quite unconciously, will continue executing the next instruction
which happens to be our initialisation code
The initialisation code is now being executed under the auspices of
our calling program (the application)
It saves all registers it uses
Sets up the Printer utility job
Opens an input pipe for Proforma
Connects the input pipe with the output pipe from the application
Activates the Printer utility job
Restores registers
Exits via rts thus handing control back to the application
Now I can forsee there might be a problem if the calling job is in SV mode
when it makes the Open call, as it would first have to exit SV mode before
it could set up jobs, open channels and things, but it must sooner or later
exit that mode, and the execution will procede as described.
The driver will have to set a flag in the CDB to indicate that
initialisation is not yet complete and no data may pass through it before
the Printer utility job has initialised. This would only be a problem if the
calling job, ie the application opening the PFF device, were in SV mode
during the Open call, and then proceded to squirt out data without coming up
for air in the mean time. A rather unlikely scenario?
> > To simplify matters (the cheapest way of writing code) only a queue
(pipe)
> > would need to be used between the PFF device driver and the page
rendering
> > program (ie Proforma or Ghostscript). The page rendering program would
be
> > instructed how to output the data by the printer utility job based on
> > settings found in the channel definition block [CDB] of the PFF driver.
>
> If it was that simple there would be no discussion.
>
> PROforma is not a page rendering program, it is just a library. If you
> call the library, there is no need for the device.
>
> Ghostscript is a program which requires a specific input format
> (Postscript). If you can modify the software to generate the specific
> format, then you can just as well call Ghostscript directly, and there
> is no need for the device.
>
> The filter programs are needed to support existing format and render
> using an existing library (we are discussing using PROforma)
Right, so I misunderstood the functionality of Proforma (Ive just downloaded
it and am working through the documentation, ditto Ghostscript). It doesnt
really matter: Only a single intermediary protocol needs to be used, ie from
ESC/P2 to Proforma and this could be performed by the device driver. If one
wants Ghostscript support (instead) then the driver would have to support
ESC/P2 to Postscript. If you wanted to have both, then either the driver has
to support both or the driver could load and register additional modules, eg
as part of its loading-and-initialisation process (ie during LRESPRing of
the driver).
>
> When this is used, to support ancient programs, you need the device.
>
> When this is written, you could use this mechanism in more recent
> programs to make it easier to produce fancy output (hence the native
> PROforma intermediate format).
<>
Per
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
