Filer_Boot doesn't return

If an application hasn’t been booted previously, calling Filer_Boot via SWI OS_CLI doesn’t seem to return. Is that normal?

I’m trying to add specific applications to the known apps list, to prevent games auto booting as you mount the floppies. What I ideally need to do is directly call AddApplicToApplicList but as far as I’m aware, Filer_Boot is the only interface to it.

It should return, but if you’re calling it from an application (or a module app?) then it’s possible you’re running into this bug where the Wimp accidentally wipes your memory when *Filer_Boot issues *WimpTask to run a !Boot file.

One workaround for the bug is to use Wimp_StartTask to call *Filer_Boot, as is the suggested way of doing things with Repeat (i.e. Repeat -tasks). I think that Wimp bug has been around since the dawn of time, so using a workaround is probably your best bet.

Being called from a module, I tried both individual calls and using Repeat -tasks, neither returned back to the instruction following the SWI OS_CLI, if the app hadn’t previously been seen.

My first thought was to use Wimp_StartTask instead, except that only works under a WIMP app so didn’t work either.

I’ll post a repro when I get a chance.

My first thought was to use Wimp_StartTask instead, except that only works under a WIMP app so didn’t work either.

Yes, it looks like Repeat gets around this by temporarily registering itself as a task.

A repro would be nice to see – I suspect you’re running into some quirk of the way environment handlers work. If you were using C then I’d suggest trying system(), as that should set up the right environment handlers to ensure control returns to you once the command is finished.

Repro below. Ensure you have a RAM drive then run it, on the first run it doesn’t return to execute the OS_Write0, run it again and it does.

DIM Z% 256
FOR A%=0 TO 2 STEP 2
P%=Z%
[OPT A%
STMFD R13!, {R14}
ADR R0, filer_boot
SWI "XOS_CLI"

ADR R0, filer_boot
SWI "OS_Write0"
LDMFD R13!, {PC}

.filer_boot
EQUS "Filer_Boot ram::0.$.!TestApp"
EQUB 0
]:NEXT

*CDir ram::0.$.!TestApp
SYS "OS_Find",&80,"ram::0.$.!TestApp.!Boot" TO A%
SYS "OS_GBPB",1,A%,"|do nothing",1
SYS "OS_Find",0,A%
*Settype ram::0.$.!TestApp.!Boot Obey
CALL Z%

Yep, I can recreate the issue here.

It fails for BASIC both when issuing a SWI from assembler, and when using OSCLI. It works from a standard C app when using system(), but not when using swix(OSCLI,…), so it looks like it’s definitely related to which environment handlers are (or aren’t) set up by the calling environment.

I suspect this issue has been around since the dawn of time (and may be either a bug or a feature, depending on who you ask), and that there’ll be a BASIC library somewhere which shows how to work around it, but I can’t think of any examples offhand. Or if you’re not intending to use BASIC for the finished thing, you should probably be setting up the correct environment handlers yourself.

Wow. Filer’s approach is convoluted! [sends itself a message, picks this up and deals with it in SussApplic and tries to WimpTask Run the !Boot file, and that’s only the beginning]

Just for what it’s worth, wrapping the call in skeleton Wimp code magically makes it work, it’s as if the Filer never considered Filer_Boot to be called by non-Wimp code…

DIM Z% 256
FOR A%=0 TO 2 STEP 2
P%=Z%
[OPT A%
STMFD R13!, {R14}
ADR R0, filer_boot
SWI "XOS_CLI"

ADR R0, filer_boot
SWI "OS_Write0"
LDMFD R13!, {PC}

.filer_boot
EQUS "Filer_Boot ram::0.$.!TestAppX"
EQUB 0
]:NEXT
 
*CDir ram::0.$.!TestAppX
SYS "OS_Find",&80,"ram::0.$.!TestAppX.!Boot" TO A%
SYS "OS_GBPB",1,A%,"|do nothing",1
SYS "OS_Find",0,A%
*Settype ram::0.$.!TestAppX.!Boot Obey
SYS "Wimp_Initialise",200,&4B534154,"TestAppX",0 TO ,th%
CALL Z%
SYS "Wimp_CloseDown", th%

It is grotty, but I’ve had to abuse Wimp_Initialise now and then just to get a simple task done. ;-) Luckily the Wimp “just does it” without throwing hissy fits.

IIRC Gerph mentionned in his ramblings something about system() doing stuff like shifting memory up on entry and back down on exite to avoid that the current application memory being overwritten by whatever is started by the system() command. So, I suspect that your application gets overwritten by whatever is started by the Filer_Boot command.

Yes, system() both copies the app to the high end of application space and installs a bunch of environment handlers in order to allow it to restore everything once the *command returns.

Taking another look, if you change the *Filer_Boot for a “*WimpTask Run” of the !Boot file then for the BASIC/OS_CLI case you get an abort on data transfer within the Wimp (looks like application space was shrunk to zero?), while system() continues to work fine. So maybe there is another wimp bug here?

[sends itself a message, picks this up and deals with it in SussApplic and tries to WimpTask Run the !Boot file, and that’s only the beginning]

Note that it actually tries to process the request straight away, and only queues the message if the attempt failed (the OS_CLI has to return a Wimp error code). If it always queued the request, then for this case I think everything would be fine!

I suspect this issue has been around since the dawn of time

It has, it’s reproducible down to RO3 and possibly lower.

and may be either a bug or a feature, depending on who you ask

I expect it’s a side effect of the way Filer_Boot launches the file. As you say, it’s probably relying on the exit handler to deal with it. Why the behaviour is different to *RUN I don’t quite understand though.

if you’re not intending to use BASIC for the finished thing, you should probably be setting up the correct environment handlers yourself.

The final code is in the ADFFS module and is called just before it opens a mounted floppy filer window. I’m using it to prevent badly written apps from doing bad things in !Boot (Gribbly’s Day Out being an example where !Boot launches 26bit code, or RTFM games that launch on boot)

I’ll try the WIMP wrapper method as a workaround.

EDIT: A WIMP wrapper has resolved the issue