RISC OS 5.18 and Filer-

Hi,

I’ve been using Filer- for ages by now – a right click on a drive icon opens a menu with the root of the disc and directories/applications show a submenu with the contents etc. I arranged my applications an data on my harddisc in a sensible manner and Filer- is the quick and nice way to reach all the stuff with no need to use application docs or something like that.

Long ago I did some work on it to make it run on the IYONIX pc (http://www.gag.de/riscos/FilerMinus300.zip). There is one limitation: Names of files, folders and applications must not be longer than 12 chars since they are put into the menus without indirection… But that is not the issue at hand (though perhaps worth working on).

Since RISC OS 5.18 it fails… partially. For discs, files and normal folders it works fine, for applications on the other hand it simply fails. Opening a submenu for an app (or clicking on the entry to launch the app) results in an error message stating that some path is invalid and the path shows an invalid leaf name.

I took a good look at the code and what is a bit irritating is that it does not work. I see a menu path that looks absoluely perfect on screen but the Wimp_DecodeMenu call does not return correct values. If e.g. I point to the path Folder1.Folder2 and then click it or open the submenu (resulting in a MenuWarning message) the DecodeMenu returns Folder1.Folder2 as path; but if I point to Folder1.!App1 then the MenuDecode returns Folder1. followed by some garbage (usually just one character).

To me it looks a bit like the Pling ! at the beginning of the menu entry might have some meaning now… (or has so ever since but now shows impact).

Any hints are welcome.

Some more analysis – first checking the OS_Heap calls. All nice, word-aligned and size multiples of 4 (well since space for menu entries is allocated the multiples of 4 are no surprise).

Then I added code to dump the menus created and they look good so far to me – the dump shows the same menu entries as I see on-screen. The list of menu entries seleced (i.e. the entry number list that is passed to Wimp_DecodeMenu) when I click or a menu warning arrives is correct, i.e. the numbers fit nicely the display on-screen and the menu dumps.

But for some reason I did not yet discover the Wimp_DecodeMenu does NOT return the correct values sometimes (BTW this happens for folders too, not only apps so the ! is not the issue). It has nothing to do with the menu depth either since for some paths I can go down pretty far, for others it fails… The Wimp_DecodeMenu should return the list of menu entries, searated by full stops; in case of failure the last entry in that list is crap; often just one strange byte instead of the real text of the menu entry in question. That it fails for entries with names longer than 12 chars is built-in since those files and folders are truncated to 12 chars in the menus (not easy to fix thanks to the pretty weird code but on my list) – the error happens with short names.

The fact that just the sub menus are all created after a MenuWarning message arrived and are thus somewhere in memory but not linked to the main menu makes debugging a bit more difficult…

Looks like I have to go back to 5.16 to compare the behaviour with 5.18.

Found the bug… well it is OS_Heap related. The code tried to figure out where the next heap block will be allocated to preset the submenu pointers for the next menu to come. Looks much like now the next block can be a bit closer than before (4 byte instead of 8 byte boundary).

After I adjusted the code it seems to work fine with RISC OS 5.18 (meaning it worked for a moment). But it will probably not work with 5.16 or others anymore. I guess I’ll need to revise this part in a more sensible manner (i.e. preallocate the block for the next sub menu header to get the real address instead of the code “guessing”).

It would have helped a lot if the original author would not have reused variables over and over again and loved short variable names (one letter ones).

Nice one…

Now Filer- is well-behaving since instead of “guessing” where the next OS_Heap block will be allocated it simply allocates a small block to get the address and then frees it again. With this change it works fine.

Version 3.10 is thus available at http://gag.de/software/FilerMinus

That looks dodgy, too. OS_Heap could allocate a small block from space that has been released, but would need to allocate a large block at the end of the heap. However, if you own the heap and never release any blocks it would give the appearance of working. That is until the program is changed and starts to release blocks.

Could you not claim a block that is bound to be big enough for the menu and then reduce its size to the accurate figure when the menu has been constructed. This would leave the address the same, because OS_Heap does not move a block in this circumstance. Unfortunately, it might lead to more fragmentation.

It seems it’s still unable to handle leaf names of more than 12 characters.