Calling Ghostscript from BASIC

26 views
Skip to first unread message

Rob Hemmings (News)

unread,
Jun 8, 2020, 10:22:22 AM6/8/20
to
It is ages since I've been programming so apologies if this is a silly
question.

Is there a way to call GhostScript from inside a BASIC program and return
control to the BASIC program afterwards? I've just tried invoking
GhostScript from a program using an OSCLI command but although
GhostScript then runs correctly it does not hand back control to the
BASIC program which just ends. I think I understand why it is happening
but is there any way to get around it?

--
-------------------------------------------------------------
Rob Hemmings Southport

rhn...@dsl.pipex.com

Harriet Bazley

unread,
Jun 8, 2020, 10:39:21 AM6/8/20
to
On 8 Jun 2020 as I do recall,
Rob Hemmings (News) wrote:

> It is ages since I've been programming so apologies if this is a silly
> question.
>
> Is there a way to call GhostScript from inside a BASIC program and return
> control to the BASIC program afterwards? I've just tried invoking
> GhostScript from a program using an OSCLI command but although
> GhostScript then runs correctly it does not hand back control to the
> BASIC program which just ends. I think I understand why it is happening
> but is there any way to get around it?
>
Wimp_StartTask will launch a program from within BASIC, and will return
the task handle in R0 if successful.

SYS"Wimp_StartTask",cmd$ TO handle%


In Infozip, in order to avoid freezing the desktop I launched the
'child' task in a taskwindow, recorded the task handle as child%, then
listened in on Wimp_Poll for the Wimp message &400C3 (TaskCloseDown)
being broadcast in order to detect when the child had finished. This is
a fairly crude approach which only allows for one child task to be
running at a time.

--
Harriet Bazley == Loyaulte me lie ==

The attacker must vanquish; the defender need only survive.

Rob Hemmings (News)

unread,
Jun 8, 2020, 10:52:37 AM6/8/20
to
In article <20b36f7d5...@bazleyfamily.co.uk>,
Thanks Harriet, that is very helpful.

Steve Fryatt

unread,
Jun 8, 2020, 11:35:07 AM6/8/20
to
On 2020-06-08, Harriet Bazley <har...@bazleyfamily.co.uk> wrote:

> Wimp_StartTask will launch a program from within BASIC, and will return
> the task handle in R0 if successful.
>
> SYS"Wimp_StartTask",cmd$ TO handle%

Yes, this is pretty much how it works.

> In Infozip, in order to avoid freezing the desktop I launched the
> 'child' task in a taskwindow, recorded the task handle as child%, then
> listened in on Wimp_Poll for the Wimp message &400C3 (TaskCloseDown)
> being broadcast in order to detect when the child had finished. This is
> a fairly crude approach which only allows for one child task to be
> running at a time.

This isn't a great idea, however, as it fails with at least one of the
popular TaskWindow providers (and ISTR that InfoZip has this problem,
although I'm not 100% certain). There's no guarantee when calling
Wimp_StartTask with *TaskWindow that the returned handle will be for the
task that you're interested in.

The better way is to check the handle returned from Wimp_StartTask to
make sure that it isn't zero, which tells you that something has
happened. Then listen out for Message_TaskInitialise, and check the names
of new tasks to see if they match the one that you're expecting to start
up. When you find it, you know the task handle from the sender field of
the message block.

The problem with taking the handle from Wimp_StartTask is that if the
registered TaskWindow provider is Zap, and Zap isn't running,
Wimp_StartTask returns the handle of another task, whose purpose seems to
be to get Zap up and running. This task starts the task that you're
after, and then exits immediately.

If you're listening for Message_TaskCloseDown, so that you can clean up
after the process, and match on the task handle from Wimp_StartTask, you
do the clean up just as your task is getting going. PrintPDF deletes the
intermediate PostScript file from the queue, and until I changed to the
more long-winded approach, it deleted the file just as GhostScript was
starting to read it if Zap wasn't loaded at the time.

--
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

Martin Wuerthner

unread,
Jun 8, 2020, 2:22:19 PM6/8/20
to
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:

> On 2020-06-08, Harriet Bazley <har...@bazleyfamily.co.uk> wrote:
>
> > Wimp_StartTask will launch a program from within BASIC, and will return
> > the task handle in R0 if successful.
> >
> > SYS"Wimp_StartTask",cmd$ TO handle%
>
> Yes, this is pretty much how it works.
>
> > In Infozip, in order to avoid freezing the desktop I launched the
> > 'child' task in a taskwindow, recorded the task handle as child%, then
> > listened in on Wimp_Poll for the Wimp message &400C3 (TaskCloseDown)
> > being broadcast in order to detect when the child had finished. This is
> > a fairly crude approach which only allows for one child task to be
> > running at a time.
>
> This isn't a great idea, however, as it fails with at least one of the
> popular TaskWindow providers (and ISTR that InfoZip has this problem,
> although I'm not 100% certain). There's no guarantee when calling
> Wimp_StartTask with *TaskWindow that the returned handle will be for the
> task that you're interested in.
>
> The better way is to check the handle returned from Wimp_StartTask to make
> sure that it isn't zero, which tells you that something has happened. Then
> listen out for Message_TaskInitialise, and check the names of new tasks to
> see if they match the one that you're expecting to start up. When you find
> it, you know the task handle from the sender field of the message block.

That might be better, but there is still more guesswork involved and less
control than using the TaskWindow protocol, which was specifically designed
to allow tasks to control their TaskWindow children. Using this protocol
also makes you independent of any registered TaskWindow provider since your
application itself becomes the TaskWindow provider.

The key point is to launch the child by passing
TaskWindow <command> -wimpslot <slot> -name <name> -quit
-task <my_task_handle> -txt <arbitrary_id>
(obviously, all in one line) to Wimp_StartTask.

Then, you listen for the messages that TaskWindows sends to the given handle
(i.e., to your application since you passed your own task handle), most
notably TaskWindow_Ego, which tells your application the handle of your
child. If you run several children, you can distinguish them because the Ego
message quotes the arbitrary id you passed. TaskWindow_Morio tells you that
your child has died. While the child runs, you can suspend it, resume it and
kill it by sending messages TaskWindow_Suspend/Resume/Morite to your child
handle. By listening to TaskWindow_Output you can receive the output of your
child, e.g., any error messages from Ghostscript.

That is how GView (http://www.mw-software.com/software/gview/gview.html)
calls Ghostscript.

--
Martin Wuerthner MW Software http://www.mw-software.com/

------- RISC OS Software for Design, Printing and Publishing --------

Harriet Bazley

unread,
Jun 8, 2020, 4:24:07 PM6/8/20
to
On 8 Jun 2020 as I do recall,
Martin Wuerthner wrote:

[snip]


> The key point is to launch the child by passing
> TaskWindow <command> -wimpslot <slot> -name <name> -quit
> -task <my_task_handle> -txt <arbitrary_id>
> (obviously, all in one line) to Wimp_StartTask.
>
> Then, you listen for the messages that TaskWindows sends to the given handle
> (i.e., to your application since you passed your own task handle), most
> notably TaskWindow_Ego, which tells your application the handle of your
> child.

Ah, that looks *much* more elegant than hacking around by doing literal
string comparisons (which sounds like a recipe for obscure bugs in the
future)... except that from the StronHelp manuals it sounds rather as
if you need to duplicate all functionality of the Taskwindow handler
yourself, e.g. when the child task produces output, you need to display
the data. :-(

The zip utilities, for instance, not only display progress messages but
sometimes prompt for input, and implementing an entire scrolling
input/output display is the sort of reinvention of the wheel that using
a taskwindow to handle command-line utilities was supposed to avoid.


--
Harriet Bazley == Loyaulte me lie ==

Old Programmers never die. They just terminate and stay resident

Rob Hemmings (News)

unread,
Jun 8, 2020, 6:37:09 PM6/8/20
to
In article <mpro.qbmdp5006x...@mw-software.com>,
Martin Wuerthner <spam...@mw-software.com> wrote:
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:

> > On 2020-06-08, Harriet Bazley <har...@bazleyfamily.co.uk> wrote:
> >

[Snip]

> That might be better, but there is still more guesswork involved and
> less control than using the TaskWindow protocol, which was specifically
> designed to allow tasks to control their TaskWindow children. Using
> this protocol also makes you independent of any registered TaskWindow
> provider since your application itself becomes the TaskWindow provider.

> The key point is to launch the child by passing
> TaskWindow <command> -wimpslot <slot> -name <name> -quit
> -task <my_task_handle> -txt <arbitrary_id>
> (obviously, all in one line) to Wimp_StartTask.

> Then, you listen for the messages that TaskWindows sends to the given
> handle (i.e., to your application since you passed your own task
> handle), most notably TaskWindow_Ego, which tells your application the
> handle of your child. If you run several children, you can distinguish
> them because the Ego message quotes the arbitrary id you passed.
> TaskWindow_Morio tells you that your child has died. While the child
> runs, you can suspend it, resume it and kill it by sending messages
> TaskWindow_Suspend/Resume/Morite to your child handle. By listening to
> TaskWindow_Output you can receive the output of your child, e.g., any
> error messages from Ghostscript.

> That is how GView (http://www.mw-software.com/software/gview/gview.html)
> calls Ghostscript.

Thanks very much indeed to both Steve and Martin for the very thorough
and helpful explanations. Really useful although I'm going to have to do
some more reading of my Programmer's Reference Manuals!

druck

unread,
Jun 9, 2020, 5:58:57 AM6/9/20
to
On 08/06/2020 21:15, Harriet Bazley wrote:
> On 8 Jun 2020 as I do recall,
> Martin Wuerthner wrote:
>> Then, you listen for the messages that TaskWindows sends to the given handle
>> (i.e., to your application since you passed your own task handle), most
>> notably TaskWindow_Ego, which tells your application the handle of your
>> child.
>
> Ah, that looks *much* more elegant than hacking around by doing literal
> string comparisons (which sounds like a recipe for obscure bugs in the
> future)... except that from the StronHelp manuals it sounds rather as
> if you need to duplicate all functionality of the Taskwindow handler
> yourself, e.g. when the child task produces output, you need to display
> the data. :-(

You don't have to display the TaskWindow's task's output in a scrolling
window. If you are calling a program to process a file (as in this case
with Ghostscript) the only output you are interested in is error
messages, and you can capture this output and display in an error box.

---druck

Harriet Bazley

unread,
Jun 9, 2020, 10:26:44 AM6/9/20
to
On 9 Jun 2020 as I do recall,
Yes, but from Infozip's point of view I'm launching a program which can
potentially prompt the user for input (and will hang mysteriously if it
fails to get it). Unfortunately detecting the identity of the child
with TaskWindow_Ego doesn't sound as if it will work, if I can only do
that by taking over the entire taskwindow handling myself.


--
Harriet Bazley == Loyaulte me lie ==

It is better to be deceived by a friend, than to suspect him.

Ronald

unread,
Jun 12, 2020, 9:01:43 PM6/12/20
to
In message <54d9f07d5...@bazleyfamily.co.uk>
I'd like to be able to use return codes from a unixlib program
but when called from an Obey file.
It looks like the only way to do this would be to have either a BASIC
or C wrapper/shell to do the running.
The only advantage would be that it could set a system variable that
an Obey file could read for any programs return code, avoiding setting
the system variable in every individual (ported) program.
Don't know how well this would work or if it would help Harriets case.

Ronald


druck

unread,
Jun 13, 2020, 7:03:58 AM6/13/20
to
On 13/06/2020 02:01, Ronald wrote:
> I'd like to be able to use return codes from a unixlib program
> but when called from an Obey file.
> It looks like the only way to do this would be to have either a BASIC
> or C wrapper/shell to do the running.
> The only advantage would be that it could set a system variable that
> an Obey file could read for any programs return code, avoiding setting
> the system variable in every individual (ported) program.

RISC OS already does this, Sys$ReturnCode should be set to the result
from the program, but note that not all programs return a non zero code
in the case of an error.

---druck

Ronald

unread,
Jun 13, 2020, 9:29:53 AM6/13/20
to
In message <rc2bqu$8mt$1...@dont-email.me>
So it does, looking forward to using it.
Important failures can be acted upon loudly now.

Ronald

Ronald

unread,
Jun 14, 2020, 12:38:32 AM6/14/20
to
In message <587d6e2a...@dsl.pipex.com>
"Rob Hemmings (News)" <rhn...@dsl.pipex.com> wrote:

> It is ages since I've been programming so apologies if this is a silly
> question.
>
> Is there a way to call GhostScript from inside a BASIC program and return
> control to the BASIC program afterwards? I've just tried invoking
> GhostScript from a program using an OSCLI command but although
> GhostScript then runs correctly it does not hand back control to the
> BASIC program which just ends. I think I understand why it is happening
> but is there any way to get around it?
>

Without going into the heavy Taskwindow stuff, one way is to filer_run
an obey file containing whatever, could even be a Taskwindow command
running yet another obey file with desired actions for within the
taskwindow.

The main consideration is that the BASIC file will continue to
the end unless you put have a wait routine straight after.

I guess checking for a file or system variable to be set with
some sort of wimp poll so it's not grinding away in a loop.
I've been experimenting with pause%=INKEY 2000
any key press will stop the wait, useable to a degree.

Ronald

Steve Fryatt

unread,
Jun 14, 2020, 2:55:05 AM6/14/20
to
On 14 Jun, Ronald wrote in message
<d5bc4f8058.beeb@-.->:

> I guess checking for a file or system variable to be set with some sort of
> wimp poll so it's not grinding away in a loop. I've been experimenting
> with pause%=INKEY 2000 any key press will stop the wait, useable to a
> degree.

If you don't want to do the Message_TW_* stuff, then Message_TaskInitialise
and Message_TaskCloseDown, as I originally posted. That way, there's no
polling and no ugly time delay stuff: you just get messages sent in when
there's something new to test against.

Rob Hemmings (News)

unread,
Jun 14, 2020, 3:48:15 AM6/14/20
to
In article <mpro.qbwl7i01...@stevefryatt.org.uk>,
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> On 14 Jun, Ronald wrote in message
> <d5bc4f8058.beeb@-.->:

> > I guess checking for a file or system variable to be set with some sort of
> > wimp poll so it's not grinding away in a loop. I've been experimenting
> > with pause%=INKEY 2000 any key press will stop the wait, useable to a
> > degree.

> If you don't want to do the Message_TW_* stuff, then Message_TaskInitialise
> and Message_TaskCloseDown, as I originally posted. That way, there's no
> polling and no ugly time delay stuff: you just get messages sent in when
> there's something new to test against.

The TaskWindow and messaging approach was fairly easy to set up once
Martin had explained it and does work very well.

I just wish I could resolve the issue I have with GhostScript as easily!

Ronald

unread,
Jun 14, 2020, 4:27:34 AM6/14/20
to
In message <mpro.qbwl7i01...@stevefryatt.org.uk>
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:

> On 14 Jun, Ronald wrote in message
> <d5bc4f8058.beeb@-.->:
>
> > I guess checking for a file or system variable to be set with some sort of
> > wimp poll so it's not grinding away in a loop. I've been experimenting
> > with pause%=INKEY 2000 any key press will stop the wait, useable to a
> > degree.
>
> If you don't want to do the Message_TW_* stuff, then Message_TaskInitialise
> and Message_TaskCloseDown, as I originally posted. That way, there's no
> polling and no ugly time delay stuff: you just get messages sent in when
> there's something new to test against.
>

So where is the waiting done, with Message_TaskCloseDown sitting there
with the task handle (+4) you've asked for?
Initially looks easy enough, the StrongHelp doesn't explain where
you would get the information for Message_TaskInitialise +20 +24 +28

Not saying it wouldn't be worth the effort, it does sound like
a job that a pre-existing library could do so you can just
run what you want without delving into wimp offsets.
The Zap complication hopefully will get fixed by Zap people.

Ronald

Steve Fryatt

unread,
Jun 14, 2020, 5:15:03 AM6/14/20
to
On 14 Jun, Ronald wrote in message
<1cb5648058.beeb@-.->:

> In message <mpro.qbwl7i01...@stevefryatt.org.uk>
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>
> > If you don't want to do the Message_TW_* stuff, then
> > Message_TaskInitialise and Message_TaskCloseDown, as I originally
> > posted. That way, there's no polling and no ugly time delay stuff: you
> > just get messages sent in when there's something new to test against.
>
> So where is the waiting done,

Nowhere.

My suggestion is that your task does nothing, thereby allowing the
processing task to do as much work as possible, until the processing task
ends. The Wimp will then send it a message to let it know.

> with Message_TaskCloseDown sitting there with the task handle (+4) you've
> asked for? Initially looks easy enough, the StrongHelp doesn't explain
> where you would get the information for Message_TaskInitialise +20 +24
> +28

You start your task:

TaskName$ = "MyTaskName"
TaskHandle% = 0
command$ = "TaskWindow MyTask 256k -name """ + TaskName$ + """ -quit"
SYS "XWimp_StartTask", command$ TO handle%
IF handle% = 0 THEN PRINT "Failed to start"

and then return control to Wimp_Poll(Idle)

Your Message_TaskInitialise handler:

PROCmessage_task_initialise(message%)
LOCAL name$

SYS "XOS_GenerateError", message% + 28 TO name$
IF name$ = TaskName$ THEN TaskHandle% = message%!4
ENDPROC

Your Message_TaskCloseDown handler:

PROCmessage_task_close_down(message%)
IF TaskHandle% <> 0 AND message%!4 = TaskHandle% THEN
TaskHandle% = 0
PROCdo_something_useful_when_task_exits
ENDIF
ENDPROC

> Not saying it wouldn't be worth the effort,

The code is above; less than 20 lines. Untested, as I work mainly in C these
days, but it's a translation into BASIC from what PrintPDF does.

> it does sound like a job that a pre-existing library could do so you can
> just run what you want without delving into wimp offsets.

Whilst a pre-existing library is a Very Good Idea, the code above is all
that you need (plus the usual to register interest in the two messages with
Wimp_Initialise, and the usual to identify the incoming messages and call
the handler procedures).

> The Zap complication hopefully will get fixed by Zap people.

Who be they, then? :-)

Harriet Bazley

unread,
Jun 14, 2020, 10:56:56 AM6/14/20
to
On 14 Jun 2020 as I do recall,
Ronald wrote:

[snip]


> The Zap complication hopefully will get fixed by Zap people.
>


I imagine that the Zap attitude is 'the task may *expect* to receive the
handle of a child taskwindow from the registered taskwindow handler, but
this is not actually specified by the relevant WIMP protocols, and provided
the taskwindow is eventually created the handler can implement the actual
creation however it likes'.

Short version: 'tasks should not rely on undocumented behaviour' :-P

--
Harriet Bazley == Loyaulte me lie ==

A man's best friend is his dogma.

Harriet Bazley

unread,
Jun 14, 2020, 10:56:56 AM6/14/20
to
On 14 Jun 2020 as I do recall,
Steve Fryatt wrote:


[snip]


> Whilst a pre-existing library is a Very Good Idea, the code above is all
> that you need (plus the usual to register interest in the two messages with
> Wimp_Initialise,

Note that you *will* need to do this, otherwise your task will mysteriously
fail to receive the messages at all... ask me how I know ;-p

--
Harriet Bazley == Loyaulte me lie ==

Confession is good for the soul, but bad for the career.

Ronald

unread,
Jun 14, 2020, 10:51:55 PM6/14/20
to
In message <ecf786805...@bazleyfamily.co.uk>
Harriet Bazley <har...@bazleyfamily.co.uk> wrote:

> On 14 Jun 2020 as I do recall,
> Steve Fryatt wrote:
>
>
> [snip]
>
>
> > Whilst a pre-existing library is a Very Good Idea, the code above is all
> > that you need (plus the usual to register interest in the two messages with
> > Wimp_Initialise,
>
> Note that you *will* need to do this, otherwise your task will mysteriously
> fail to receive the messages at all... ask me how I know ;-p
>

Two places I can think of that you might run binaries from BASIC would
be AppBasic and Confix is predisposed for BASIC scripts.
Actually AppBasic seemed to call a binary OK.
The FilerHRun module is not mentioned much these days but it may
have had this type of usage in mind.
It can run a binary directly from BASIC, but once again you have to
perform a wait. Haven't checked to see if SYS$RETURNCODE is possible.

I'm putting PDF's on my chromebook, quite a fast startup,
not a bad pdf viewer, can do it in bed! (Winter here)
I think the PRM's need a separate index built so you can get to
where you want quicker. For one thing the pdf page numbers differ.

Ronald

druck

unread,
Jun 15, 2020, 3:56:02 AM6/15/20
to
On 15/06/2020 03:51, Ronald wrote:
> The FilerHRun module is not mentioned much these days but it may
> have had this type of usage in mind.
> It can run a binary directly from BASIC, but once again you have to
> perform a wait. Haven't checked to see if SYS$RETURNCODE is possible.

It wont be. Sys$Return code is only valid if you explicitly run a
program via OSCLI. Any sort of FilerRun, TaskObey or other Wimp
mechanism will usually return to you straight away, and queue the
program to be run when they get the next Wimp Poll. Only they will be
able to read Sys$Return code when the program exits and you can't rely
on this variable once Wimp Poll is called, as something else may have
exited.

---druck

Ronald

unread,
Jun 15, 2020, 5:03:50 AM6/15/20
to
In message <rc79ih$h23$1...@dont-email.me>
OK, getting back to being better running the binary in an Obey
for that kind of simplicity then.
My Fetchmail program is in an obey file called by a Taskwindow.
It is well suited for Sys$ReturnCode it can range from O to 16 or so.
0 for mail received, 1 for no mail to retrieve, and higher numbers
reflect various authorisation or network faults.
Thanks
Ronald
Reply all
Reply to author
Forward
0 new messages