Environment handler etiquette

What should happen is that you get a complete register dump, apart from R14, which will be &DEADEAD

I see a fix went in last night. Prompt service as ever Jeffery:-)

I hesitate to even point out a typo in a posting of yours but just in case someone stumbles across this in future shouldn’t that be two D’s as in the middle: &DEADDEAD

I hesitate to even point out a type in in a posting of yours but just in case someone stumbles across this in future shouldn’t that be two D’s as in the middle: &DEADDEAD

Correct.

Aha. <looks at diff> I see.
I guess the fact that this has only turned up something like fourteen years later shows how much love OS_BreakPt gets. ;-)

Thanks for the fix.

I’ve been looking into why 26bit Wimp apps randomly hang today and have noticed prefetch aborts occurring for the UpCall Environment handler whilst the task is paged out. I can trigger them by opening an Edit task window in the background and then select a window in the 26bit task that takes the focus, so it’s swapping between Edit and the 26bit app.

Ignoring that issue for a minute as I think it related to my next question, the documentation for OS_DelinkApplication states:

When an application running at &8000 is going to be swapped out, it must remove all vectors that it uses

How does an application get notified it’s about to be swapped out?

How does an application get notified it’s about to be swapped out?

It’s just about to call Wimp_Poll(Idle)?
[remember, this is RISC OS we’re talking about ☺]

Interestingly, neither TaskWindow nor Wimp2/WimpPatch bothered with Delink/Relink… which makes it look like one really should not OS_Claim in the app slot at all.

It’s funny how many things can’t be in the application slot – TIL that the Wimp’s Command Window title can’t be in the app slot… despite it only appearing when a non-task is writing text to WrchV.

Note also that until fairly recently, Delink/Relink were slightly bugged, and no one ever noticed until I examined the code. Not RISC OS’s most used API that.

It’s just about to call Wimp_Poll(Idle)?

There’s also Wimp_Initialise which does a message broadcast.

Other than those three obvious SWI’s, I’m more interested in how the OS notifies a task it’s about to be swapped without its knowledge, so it can delink correctly. An UpCall would be the obvious choice, but it doesn’t appear to have a “swapping” UpCall.

I suspect some of the other Wimp SWI’s will swap due to sending messages, and mouse focus changing must swap for it to pass the “focus” message around.

• First there was the BBC MOS, which was single-tasking
• Then there was Arthur + WindowManager 1, which was single-tasking
• Then there was RISC OS 2 + WindowManager 2, which was co-operative multi-tasking
• Then there was RISC OS 3 + WindowManager 3 + TaskWindow 0, which was co-operative and pre-emptive multi-tasking

Nothing important has happened since then.

Tasks have never been switched without their knowledge (except by Wimp2/WimpPatch, but that’s unofficial and was never really finished).

The task decides when to call Wimp_Poll, so the task decides when to call Delink (before Wimp_Poll) and Relink (after Wimp_Poll).

It was only once TaskWindow appeared in RO3 that the issue of a program (not a task) being pre-empted was raised… and the fact that TaskWindow doesn’t call Delink/Relink makes me think there wasn’t anything that anyone wanted to TaskWindow that needed it… after all, it was a long time before anyone knocked up a graphical TaskWindow – for years it was text only. So which text-only single-tasking program is it that calls OS_Claim? Obviously not much.

OS_Claim in the app slot is a very bad idea all round. Don’t do it. Judging by the huge number of support modules knocked up over the years, I think most people put the Fiddly Bits™ in a module and let the program deal with Events and UpCalls through the Environment Handlers (which are switched by WindowManager).

I suspect some of the other Wimp SWI’s will swap due to sending messages, and mouse focus changing must swap for it to pass the “focus” message around.

Nope. Wimp_Poll(Idle) is what does the context switch. Nothing else. Wimp_TransferBlock will faff with the memory paging while copying stuff, but there isn’t a context switch there.

While your task is running, all other tasks are stalled at their Wimp_Poll(Idle). That’s how it works. Various desktop message protocols require messages to ping-pong between two tasks without others getting a look-in. Without that, those protocols fail. This is why it is not possible to pre-empt the message-passing of RISC OS, and why the Wimp’s UI must be single-threaded.

I’ve been looking into why 26bit Wimp apps randomly hang today and have noticed prefetch aborts occurring for the UpCall Environment handler whilst the task is paged out

Rather bizarrely, the cause of the aborts appears to be due to the Wimp altering the Environment handlers during Wimp_Initialise and Wimp_Poll/Wimp_PollIdle. I can prevent the aborts by releasing and reclaiming the Environment handlers in Pre/Post Filters, but I think there’s a more fundamental issue in my code which is causing the Environment handler chain to either brake or become recursive.

The problem I’m trying to resolve is ensuring my Environment handlers remain at the top of the queue, so the Wimp has to call the 26bit handler in a managed way. The other issue I have to contend with is 26bit handlers calling the previous claimant directly, which also has to be managed.

The way I had implemented it, was to claim the handlers (6-12 and 16) when the JIT starts and internally handle Environment handler changes so they’re never passed to the OS. The problem with this method is the OS retakes the handlers at various points, so I have to keep reclaiming them – they’re then in an unknown state, as its not clear if the OS has added another link in the chain (eg BASIC, Obey etc), or collapsed it (Serious Error).

Does anyone have any bright ideas on how I can ensure entry and exit to 26bit handlers is managed in a way that doesn’t break the Exit and Error handlers, which need to release all handlers before reissuing OS_Exit/OS_ReportError?

I suspect you’d have to wrap the 26bit handler in your own 32bit veneer. You’ve trapped OS_ChangeEnvironment et al so you can apply such veneers transparently. 26bit app thinks it’s setting 26bit handlers, the OS sees 32bit handlers.