Several Updated Modules

I’ve recently found myself digging through the source code for several of my old modules. In the main these were assembled using ExtBasAsm, and for several years this has meant firing up RISC OS 4.02 on RPCemu in order to do any work on them: as a result, most of the copyright dates showed 2003 when they were 32-bitted for the Iyonix…

Anyway, to make them a bit more maintainable, I’ve started converting the sources over to ObjAsm/Asasm format. At the same time I’ve fed the code through ARMalyser, and also looked for any other obvious ARMv7 issues; on some I’ve also started fixing longstanding old bugs and making improvements to the code.

All of the new builds are currently in “test” status; I’ll do proper releases once I’ve worked through the longish list of unfixed bugs and issues, and given people chance to feed back any issues. I’ve given most things a cursory test on a Beagleboard, but if anyone else would like a play they can be found here (along with source code which, like most of my other stuff, is supplied configured for use in the GCCSDK): http://www.stevefryatt.org.uk/software/test/

Feedback welcome; I’ll be updating the archives as and when I make changes to the code (as well as adding other things if I find any more source code lurking on the Iyonix’s disc)…

• FilerDirPatch is a small module to make clicks on ‘New Directory’ in the Filer’s menu create a new directory called ‘Directory’.

• Fortune displays a fortune cookie before the desktop launches.

• MsgMon feeds details of Wimp Messages into Martin Avison’s Reporter.

• PC Keyboard fiddles with the Backspace, Delete, End and Home keys to help ‘legacy’ applications match the RISC OS 5 style. Optionally, it can also be used to turn the whole of RISC OS 5 back into RISC OS 4 style, for those who don’t use RISC OS alongside real computers.

• WinScroll provides a “window panning widget” whenever a Ctrl-Menu click is detected.

I’ve also transferred IcnClipBrd’s source into the GCCSDK environment to make it easier for me to build in the future; that’s also on the page, but there aren’t (AFAIK) any changes compared to the last stable release.

Fortune displays a fortune cookie before the desktop launches.

A few years ago (July 2009, according to my ‘Sent mail’ folder), I sent you a small update to this module, which counted the number of lines in the fortunes file instead of relying on the user manually updating a system variable, and also fixed an (admittedly unlikely) bug in the error handling. I’ve been using my modified version ever since then with no problems, so I think it’s safe to say it works.

BTW, could the source archives have proper RISC OS filetypes set?

A few years ago (July 2009, according to my ‘Sent mail’ folder), I sent you a small update to this module, which counted the number of lines in the fortunes file instead of relying on the user manually updating a system variable, and also fixed an (admittedly unlikely) bug in the error handling. I’ve been using my modified version ever since then with no problems, so I think it’s safe to say it works.

Indeed; as I wrote in the first post, the ExtBasAsm requirement has meant updating things has been a serious pain in the past. I only came across the conversion idea by accident while looking at getting something else to build, and decided to complete it when it became apparent that it wouldn’t actually take that long to do. However, now that it’s done, I might actually make changes given that I don’t have to spend half an hour faffing around before I can start…

I was actually going to add your fixes in, until I found that I have the entire chain of emails apart from the first one with the actual attachment. If you’ve still got the changes to hand, feel free to resend them — note that you would be contributing code to a different licence now, though, as I’ve taken the opportunity to relicense the old freeware code as proper open source.

BTW, could the source archives have proper RISC OS filetypes set?

Not easily, no. The zips are all generated on Linux, and while the build environment sets the correct filetypes in the “user” archive, there’s no sane way that I’m aware of to do that for the source without splattering ,xxx extensions all around my files.

Just in case you weren’t aware, the zip that comes with GCC/GCCSDK supports filetype extensions – you do need the ,ffb or whatever extensions, but then zip -, (zip space dash comma) will create a RISC OS format zip with filetypes. You need the autobuilder’s zip on your path to do this (run /home/riscos/env/ro-path or similar)

If you don’t want the ,ffb on your files, try making a directory of symlinks pointing to your files and zipping up that. zip doesn’t support symlinks, so it might get the destination files instead.

There’s a package in the GCCSDK autobuilder which will do the reverse – preserve RISC OS filetypes to ,xxx when unzipping on Linux. You build the native-unzip package, and then you do “unzip -F” to retain types (the -F flag has actually been in mainline zip since the 1990s but only some distros enable it, hence native-unzip builds a special unzip with it turned on).

Just in case you weren’t aware, the zip that comes with GCC/GCCSDK supports filetype extensions – you do need the ,ffb or whatever extensions, but then zip -, (zip space dash comma) will create a RISC OS format zip with filetypes. You need the autobuilder’s zip on your path to do this (run /home/riscos/env/ro-path or similar)

Yes; that’s how the “user” archive is created.

If you don’t want the ,ffb on your files, try making a directory of symlinks pointing to your files and zipping up that. zip doesn’t support symlinks, so it might get the destination files instead.

Wouldn’t that mean that I’d need to maintain two “sets” of source files: the real ones, and the symlinks with RISC OS type extensions? That sounds like a lot of hassle (and would Subversion preserve that setup?)…

What might fix things would be to change the default type used by zip when the -, parameter is used: if it were text, then that would solve most of Martin’s problems immediately. Maybe I need to have a look at GCCSDK’s zip sources when I get a bit of free time.

There’s a package in the GCCSDK autobuilder which will do the reverse – preserve RISC OS filetypes to ,xxx when unzipping on Linux. You build the native-unzip package, and then you do “unzip -F” to retain types (the -F flag has actually been in mainline zip since the 1990s but only some distros enable it, hence native-unzip builds a special unzip with it turned on).

Interesting; I wasn’t aware of that one. Thanks!

Wouldn’t that mean that I’d need to maintain two “sets” of source files: the real ones, and the symlinks with RISC OS type extensions? That sounds like a lot of hassle (and would Subversion preserve that setup?)…

Nothing that can’t be solved with a bit of ‘find’ magic . Or, more sensibly, the lns tool (and then a script to rename stuff)

I just tried zipping up such a symlink tree and it seems to work.

What might fix things would be to change the default type used by zip when the -, parameter is used: if it were text, then that would solve most of Martin’s problems immediately. Maybe I need to have a look at GCCSDK’s zip sources when I get a bit of free time.

Looking at the source patch it would seem to do that already, so I’m not quite sure what’s happening here?

Interesting; I wasn’t aware of that one. Thanks!

It appears that Debian 7 (squeeze) and Ubuntu 12.04 (precise) support ‘unzip -F’ out of the box but CentOS 5 doesn’t, so if you’re on a Debian-based distro you don’t need to install anything.