OS_ChangeDynamicArea sends wrong value to Service_Memory

Symptom:
When outside the desktop (i.e. WindowManager not active), can’t start a BASIC Wimp program in single-tasking mode (e.g. try Resources:$.Apps.!Chars, or start BASIC and try SYS"Wimp_Initialise",0), you get a data abort because the application slot gets resized to 0.

Cause:
In OS_ChangeDynamicArea, routine AreaShrink issues Service_Memory with a positive value (the sign was flipped at the start of that routine), but it should be sending a negative value. As a result, BASIC thinks a harmless grow is happening and so gives it the go-ahead.

This only happens when starting as single-tasking because for the first task the Wimp does SYS"OS_ChangeDynamicArea",6,&3FFFFFFF (enlarge free pool as much as possible) which results in the attempt to shrink the app slot.

Obviously a BASIC Wimp program works if it is not being started as the first task; the difference is that for the first task the Wimp calls OS_ChangeDynamicArea as above, but for subsequent tasks it calls Service_Memory directly itself with the correctly signed value.

Assuming this gets fixed, you should see a “Invalid Wimp operation in this context” error from Wimp_Initialise, and consider yourself to be thoroughly told off for being outside the desktop.

I’m looking into this now. Service_Memory was easy to fix, but then I found a couple of other bugs of mine which are turning out to be a bit more stubborn. All of these look like they were introduced when I added the PMP support. D’oh!

The OS_ChangeDynamicArea problems should be fixed now – thanks!

https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/merge_requests/30

I <3 PMPs