is wimp_starttask() ever the wrong thing?
Willard Goosey (5119) 257 posts |
So, I’m 32-bitting and otherwise cleaning up the old xlisp21 interpreter. One of the commands the Acorn-specific code gives it is (system “string”) which calls C’s system()… which is a horrible hack. (xlisp runs in its own window, but is a single task itself. WIMP-aware programs that were called via system() worked fine, but a CLI program’s output simply disappeared.) I changed it to call wimp_starttask() and I’m very pleased with the result, but I’m new to RISC OS so are there any cases where it would be better to actually use system()? RO 5.24, ARMv7 Pi2 |
Andrew Rawnsley (492) 1420 posts |
Many years ago, I used system() because that was the recommendation of the various tutorials, examples and guides to C programming that I had read (books, articles etc). However, at various points I ran into trouble, and soon learned to go with wimp_starttask(). Another question is whether to call things with “Run xxxx” or “Filer_Run xxx”, or indeed FilerHRun (module). It’s late, I have a headache, so perhaps that’s one for another day ;) Edit – another tip if you need to run a series of system commands is to create (fopen, fprintf etc, fclose) an obey file in pipefs. This will be discarded automatically after execution via wimp_starttask(). |
Steffen Huber (91) 1945 posts |
ISTR that Filer_Run was not a good idea for general purposes, because it interprets the Shift key state, so if the user has Shift pressed, the file ends up inside your favourite editor (i.e. StrongEd :-)). |
Rick Murray (539) 13425 posts |
The Wimp_StartTask command should be called from a Wimp task (a newer call TaskManager_StartTask will work for other situations such as a module starting a task). This call gets the Wimp to actually set up and start a new task, leaving your task as-is. system(), on the other hand, does a lot of messing around – it needs to move the current task up in memory (to leave space for the command/task to load itself in at &8000 as would be expected), and then move itself back down again afterwards. Unfortunately there’s quite a lot of stuff that can cause it to blow up, so your original task never comes back. You may need to use system() in a single tasking application as RISC OS has no concept of multiple processes. In the desktop environment, the starttask call is better, even for single tasking programs, as it leaves the calling task alone, simply suspending it until the called program finishes or polls. But note that starttask messes with the command line a little, so as said by Andrew it may be better if you need to run commands with parameters to build an Obey file and get starttask to run that. |
Willard Goosey (5119) 257 posts |
It sounds like wimp_starttask() is indeed what I want! Thanks guys! I admit I hadn’t considered what starttask might do to a complex command line, but I think a note that such things should be put in an obey file will be sufficient. ;-) |
nemo (145) 2437 posts |
And this is one of the many reasons why I’ve long argued that the task-management part should be separated from the user interface part of the Wimp. |
Steve Pampling (1551) 7957 posts |
I could swear I’d read something about someone rewriting that, amongst other currently interconnected/intertwined items. PS. There’s a problem with BREXIT1 you could take a look at too :) 1 Replies to THAT in Aldershot, or possibly more appropriately scribbled on San Izal and flushed. |
Andrew Rawnsley (492) 1420 posts |
I believe Filer_Run was modified on RISC OS 5 to default to not checking for shift somewhere around 5.20 or 5.22, unless you specifically include -shift (or something – check the help). However, if you’re writing code to run on older OS versions too (including earlier RISC OS 5) you probably want FilerHRun which has that capability as one of its “selling points”. It’s by Musus Umbra originally, and can be found here http://www.zen22994.zen.co.uk/musus/miscfw.htm – it should be safe on modern machines. As to which you want, (Run/Filer_Run/FilerHrun) at least part will depend upon whether you want to have control returned to you whilst the other program runs. Obviously that requires a multitasking program, or a taskwindow. I’m afraid I tend to experiment a bit until I get the desired results. |
Chris Hall (132) 3511 posts |
and if the thing you are running calls OS_Exit when it terminates, then starting it with run (rather than start task) will mean that your application that called it is terminated when it finishes. For example ps2pdf. |
Rick Murray (539) 13425 posts |
Ideally, the kernel should be aware of the basic concept of a task. Even if hell will freeze over before multiple command line tasks get to run at the same time (outside of the desktop), it would be nice if running a command to start a subtask could at least unmap the current task from memory, swap in some replacement memory, and start the task there. No more of this tedious nonsense shuffling things around in a fixed memory space and, basically, crossing fingers and hoping it doesn’t blow up.
OMG – I remember that – the only bomb proof toilet paper I’ve ever come across.
Is something pathologically broken? The C runtime should surely set up an exit handler which reinstates the previous one on the way out, which ought to point to the system() code which ought to restore the previous task….? |
Willard Goosey (5119) 257 posts |
I was looking through some BBC BASIC stuff… What about the things that BASIC calls OSCLI for? (system “POINTER 1”) ??? OK that does work, but opens a new window that has to be clicked in to make it go away… Perhaps Xlisp needs (system…) and (starttask…)? Or would an (swi…) call cover all the use cases? |
Chris Hall (132) 3511 posts |
The C runtime C, what’s C? I have a multitasking BASIC application which needs to call ps2pdf to convert a ghostscript file to a pdf. I have to use rather than OSCLI.
OK that does work, but opens a new window that has to be clicked in to make it go away unless you add { > null: }. I find that if I add a debug PRINT … statement to my multitasking programme then it doesn’t open a window (because it is multi-tasking) but if it is single-tasking (i.e. not running as a Wimp task) it does, which can be very useful. |