!Apps autoupdate and more

Upgraders often seem to get created quickly at the end of a project with little in the way of planing. An upgrader must be as bomb proof as possible while giving the user sensible options if something does go wrong.

Before I retired, the last major project I worked on had an installer that seemed to need as many man-hours as the application it was installing or upgrading. I know Windows is more complicated than we’re used to, but the general lesson is that an installer is very much a non-trivial project in itself.

It would be interesting to see whether it is possible to generalise an installer/upgrader. It may have to copy files over existing earlier ones, and/or delete files,, and/or copy new ones in. It needs to know where to install or upgrade to.

Choices with an application are a bad idea, as we know, but the simplest solution seems to me to ship with a new choices file that has been given a very old file date, so it won’t be copied over a newer one that the user has customised. But even that will fail if the new file has content that older ones didn’t…

anything to work around configuration files etc? Many programmes out there still do not use ‘Choices’

That is definitely a responsability of the App developer, not my Package manager.

If reading and writing a config file from <Choices$Dir>.MyApp is too much for a developer, then they probably shouldn’t be writing Apps to distribute to other people.

Choices with an application are a bad idea

Everything centralised with RISC OS (given the fragility of the file system and OS) is a bad idea, even spending time trying to write apps for RISC OS is a bad idea when someone could do the same for a different platform and have a larger audience and/or make more money.

Doing stuff for RISC OS is something that has nothing to do with good or bad ideas, it has to do with people just expressly wanting to do it.

Distributing software to others however, this is where things get a little sticky btw, requires to ensure that the process of installing, uninstalling, upgrading and using the software is smooth even for less trained users. This is where the communication, the Style Guide etc. come into play.

What is certainly a bad idea always (regardless of using Chocies or an App local directory), is keeping a configuration file open during an update.

A configuration file may require what is called “migration” to a more recent format if it’s an update/upgrade process, or require an installation from zero if it’s an installation action. All of this can be handled by RiscPkg format and LibPkg, so this will work exactly in the same way it works already with PackMan, zero differences (also because I am trying to keep the two perfectly compatible with each other).

Before I retired, the last major project I worked on had an installer that seemed to need as many man-hours as the application it was installing or upgrading.

This is true still to this date (not for all applications thought), but an App that, for example, relyes on data files that may be altered by a user, will require a migration process (this is what my !Launchpad does if it needs to update the user configuration and applications DB).

That is something that the installer won’t manage for a user, because it’s specific to an App and the data files (and their format) that it uses.

It would be interesting to see whether it is possible to generalise an installer/upgrader.

It is possible to generalise an installer/upgrader. But that is about the actions that needs to be performaned aka tell a developer’s specific code that we are in an upgrade vs installation time, however, the specific upgrade process isn’t that abstractable, because a developer my desing their Apps in a complete unpredictable way. So, a specific migration process has to be coded on purpose.

It may have to copy files over existing earlier ones, and/or delete files,, and/or copy new ones in.

This simpler actions are easy to be abstracted in a scripting language (both in imperative or declarative form). I would not rely on dates thought, what if a user has no access to the internet and system clock is screwed or mis-configured?

Normally, a developer should think in “states”, the state the app is in and the state it has to be when the process is completed.

Starting state is (for example) verison 1.0.0, while state at the end of the upgrade should be verison 2.0.0 and that means existsing and well identifiable user-owned files (aka configurations, avatars etc.) are migrated to version 2.0.0 while developer’s owned files (code normally, but also other potential files) are replaced by the new version of them without forgetting anything.

My 0.5.c

Waiting for someone to contact me wrt CDBurn/CDVDBurn and its homebrew updater application and its insistence of storing the user settings inside the application…

The thing is, unless something goes wrong, how many people actually look to see where stuff gets stored? “Does it work?” is the primary criteria. If it works, fine, let it be.

What config file?

The one the previous error log asked for.
Given it segfaults when I make a fake config file (Choices:NSTheme.Config), I’m suspecting it’s actually something else failing. All I know is that it dies silently, leaving the hourglass on, and a log recorded in an stderr file.

I have NSTheme 0.02 (21 Mar 2005)

That’s what the template file says. The executable makes no mention of version, though the !RunImage is stamped 22nd March 2005 so it’s probably the same one.
Strange.

It’s straight RISC OS 5.29 (11th August) on a Pi 3B+. It’s a segfault, so not a case of SWP or the like. More like a messed up memory access.

but the general lesson is that an installer is very much a non-trivial project in itself.

Indeed. One needs to try to get an application up to date without unduly screwing stuff up.

It would be interesting to see whether it is possible to generalise an installer/upgrader.

Of course. On Windows, I used to use the ClickTeam installer creator, because the default one that Microsoft supplied with VisualBasic was “pooh”.

On RISC OS, David Pilling has “Freshen” which can update applications.

It may have to copy files over existing earlier ones, and/or delete files,, and/or copy new ones in. It needs to know where to install or upgrade to.

Generally, files are added/replaced, they don’t tend to get deleted unless uninstalling.
Where to install to? On Windows it can read that from the registry. On RISC OS, it can look to see if App$Path is set, and if not, prompt the user.
Well, it should prompt anyway, but it’s best to try to be at least semi-smart. Less legwork for the user.

but the simplest solution seems to me to ship with a new choices file that has been given a very old file date

No!
The simplest solution is for the app to contain within itself some default settings that it will use in the absence of any choices files. Don’t ever supply one (with or without an old date). Would it be respected if something upsets the clever installer so the user drag-saves the application manually?

An app should cope with the absence of settings. Even if that means “create them”.

But even that will fail if the new file has content that older ones didn’t…

Again, if the app has built in defaults, it only needs to read what it can and it can use the defaults for the rest.

It’s harder if your file is a binary rather than something that is parsed, but it’s not insurmountable. Just work out what sort of file it is (old or new) and load as appropriate. I mean, you will be supporting the older file when revising it, right? Right? Right? ;)

then they probably shouldn’t be writing Apps to distribute to other people.

To be fair, I do wonder how many offenders are “quick hacks I threw together that might be useful to other people”.
Yes, it’s wrong. But in the context of booboos, it’s not that big a deal.
[and anyway, look how much stuff Vista’s UAC broke because, hey, everybody does it!]

even spending time trying to write apps for RISC OS is a bad idea when someone could do the same for a different platform and have a larger audience and/or make more money.

If fame or cash is what someone is interested in, the door is that way. Bye bye.

Around here, it’s mostly done these days because we like the OS, we like how it works, and we’re scratching personal itches rather than delusions of being bought by Meta for a billion bucks.

it has to do with people just expressly wanting to do it.

Yup. I wanted to have a crack at making a simple MIDI sequencer. So I sat down a few weekends (and the past two days when “off sick”) and did it.
Because I wanted to.

It’s on my blog. I expect it’ll be used by exactly one person, but hey, that’s who I’m writing it for.

requires to ensure that the process of installing, uninstalling, upgrading and using the software is smooth even for less trained users.

I want to know what software is too complex to “use SysMerge (!Boot → System) to update the system resources” (if necessary) and then “drag this app to where you want it to be installed”.
All this talk of installers, one of the great things about RISC OS is that for the vast majority of apps, dragging the app from the archive to a chosen directory was about as much installation as was required.
As for updating, drag the new one over top of the old. Job done.

A configuration file may require what is called “migration” to a more recent format if it’s an update/upgrade process,

If the file format changes, the app should be capable of loading/handling the older format for at least a few releases to ensure that everybody is updated. It’s fine for it to be a one-way process (load as old, save as new).

So, a specific migration process has to be coded on purpose.

Yup – the app should be capable of at least loading the older format files, even if it cannot save them.
In this way, nothing needs to be migrated using add-on software (because more fingers in the pie means more chance of data corruption).

what if a user has no access to the internet and system clock is screwed or mis-configured?

Good point. Don’t some machines revert to 1992 or something?

My 0.5.c

In Britain, it’s tuppence worth. I think it came from the expression “a penny for your thoughts” (a way of asking somebody what they’re thinking) and the sarcastic response “I said a penny for your thoughts and got tuppence worth” when, well… ;)

Your expression 0.5c – an anachronism? Euros don’t have half centimes, and Francs/Lira/Pesetas were all quite a bit smaller than a euro, meaning a centime would be ridiculously tiny.

Unless the joke is in the implied usefulness of half a centime?

In Britain, it’s tuppence worth.

Yes, and the American version (I worked for a very very long time for US based software/hardware companies btw), is 2c (2 cents) which also appears to be used in Australia, just as a note. My 0.5 is something I added to mean it’s worth even less that a 2c. In other words it’s just my opinion and nothing I want to force on others.

One of the issues with communicating on a forum, is that some people may feel others with a different opinion like a “menace” or a source of contrast that needs addressing at all costs (sometimes even a 0.5c!). So, by adding it to some of my posts, I try to avoid such reaction. Yes, many people posts on forums just to correct others, it’s the eternal problem of forums and socials (and probably I’ll never be able to fix this). Here, for instance, I am personally interensted only in getting RISC OS to a point that is the lowest friction possible we can reach for users and developers, mostly because I want to reduce such friction for myself (remember I am my main user for everything I do on RO).

Why is it something that seems to trigger your reaction (or at least your attention) all the time?

Don’t some machines revert to 1992 or something?

I think so yes, others, with battery, just stay behind or in the future.

My apologies. Above, I said:

Choices with an application are a bad idea

This should have been “within”, but I didn’t notice my mistake until after my posting had been replied to.

The simplest solution is for the app to contain within itself some default settings that it will use in the absence of any choices files. Don’t ever supply one (with or without an old date).

An app should cope with the absence of settings. Even if that means “create them”.

The simplest way to create them is to copy a settings file (from within the app, to the Choices location), rather than create them programmatically.

But obviously you only do that if the settings file is absent.

(or at least your attention) all the time?

Because I’m boring and have no life?

Seriously, though, I’m sure there are loads of discussions I’ve not paid any interest in.

rather than create them programmatically.

It isn’t that hard to do stuff like:

   config.explode = FALSE;
   config.work    = TRUE;
   (etc)

It has the benefit over using a copy of a config file in that it is always known to be correct.

Let’s agree to disagree. ;)

PS: I wouldn’t bother trying to fix “social media”. Much of it is a cesspool of the worst humanity has to offer, angry people all shouting at each other like a big echo chamber of the clinically insane.

What is certainly a bad idea always (regardless of using Chocies or an App local directory), is keeping a configuration file open during an update.

Keeping any file open on RISC OS for any reason is a no no. In the mere blink of a Wimp poll someone else may close the file, and given RISC OS’s complete lack of resource protection, open and entirely different file with which is given the same 8 bit handle. On return from the Wimp poll the application is now corrupting someone else’s file.

This really is still happening in 2023.

PS: I wouldn’t bother trying to fix “social media”. Much of it is a cesspool of the worst humanity has to offer, angry people all shouting at each other like a big echo chamber of the clinically insane.

Just refer to it as anti-social media and you’re more accurate.

Rather like AI standing for Artificial Stupidity.

Artificial Incompetence

If reading and writing a config file from <Choices$Dir>.MyApp is too much for a developer, then they probably shouldn’t be writing Apps to distribute to other people.

Part of the problem is that it is considered bad practice to read from <Choices$Dir>.MyApp as well as to write to <Choices$Dir>.MyApp.

Hopefully the correct use of Choices: to read and Choices$Write to write are documented somewhere.

Hopefully the correct use […] are documented somewhere.

Yup, in that book that nobody ever reads.

Page 92, to be exact.

Yup, in that book that nobody ever reads. Page 92, to be exact.

I fear that the number of people looking for such information in a book called “Style Guide” might be single digit.

Well, I just read page 92 and beyond, but I can’t say that everything is clear to me now. The text speaks about network administrators, for example, who may or may not have set company wide settings or order elements in the path, which evocates an environment that the RISC OS version that I know is not exactly familiar with.

Moreover, it describes Choices$Write and Choices$Path, but nowhere mentions Choices$Dir that I use to read and write information from and to. Does that mean that I’m disrupting our system then? (Spoiler: it works.)

I’m surprised no one, particularly Rick, highlighted the bit about not saving choices in the application

Given the variety set out in the section entitled Storage medium on page 90 it is clear that you must not save user choices within the application itself as these would
conflict with other users in a multi user environment, or fail if the media is write-protected.

BTW. I’m pretty sure there’s a missing hyphen in “multi-user environment”

Moreover, it describes Choices$Write and Choices$Path, but nowhere mentions Choices$Dir that I use to read and write information from and to. Does that mean that I’m disrupting our system then?

Yes, you are.

You should always read your choices from Choices$Path, with something like this:

handle% = OPENIN("Choices:MyAppFolder.Choices")

This allows the choices to be found wherever they might be stored (including read-only sets of defaults on a network or something like that).

When writing, you write to Choices$Write, like this:

handle% = OPENOUT("<Choices$Write>.MyAppFolder.Choices")

so that they are written to the system’s writeable choices store.

This works, because Choices$Path will always be set such the the writeable location has highest priority in the search. So once local choices have been written, they will always be used in preference to network defaults or similar.

Edit to add:

The text speaks about network administrators, for example, who may or may not have set company wide settings or order elements in the path, which evocates an environment that the RISC OS version that I know is not exactly familiar with.

I remember using this stuff in a networked environment at school back in the 1990s, so it isn’t new!

Yes. you are.

All right, I believe you blindly and shall change my program(s) accordingly.

But what is Choices$Dir for then? On my system, Choices$Write, Choices$Path and Choices$Dir all point to the same location, while it looks like Choices$Path also points at the RO520Hook directory.

But what is Choices$Dir for then?

To answer my own question, could it be used to create and open directories in Choices:MyAppFolder? Or should I use Choices$Write and Choices$Path for that too, respectively?

To answer my own question, could it be used to create and open directories in Choices:MyAppFolder? Or should I use Choices$Write and Choices$Path for that too, respectively?

An application should never ever use Choices$Dir in my opinion. If you want to “write” something which includes creating your own app’s directory for the user settings, use Choices$Write. Whenever you read something, use the Choices: path.

Choices$Dir is most probably only for internal use to construct the various paths in the different !Boot (including network boot and Select-like multi-user environment) situations.

Possibly it is also something from the past (pre “!Boot as a container for everything”) that is kept for backward compatibility – as you found out, in typical single-user single-machine contexts, it works just fine.

Okay, I’ll remove Choices$Dir completely from my program. Thanks for the information.

One more time about Choices$Dir, Choices: and Choices$Write…

I fear that the number of people looking for such information in a book called “Style Guide” might be single digit.

I wasn’t aware of that, but there is also a small section in PRM5a that explains things for application authors on how to handle user settings. See page 5a-543 “Storing application choices”. So there’s your authorative source.

Certain styles of the Style Guide raise questions in my mind.

datestamp vs. date stamp
timestamp vs. time stamp
writable vs. writeable
leafname vs. leaf-name
ie vs. i.e.
toolpane vs. tool-pane

and… my keyboard has a Print Screen keycap and no trace of a Print Scrn

raise questions in my mind.

Probably mine too, but I’ve never really read it. Just sort of skimmed and started to get annoyed at how little of it Acorn’s own apps ever followed. (like, lead by example, huh?)

timestamp vs. time stamp

I think a rough rule of thumb can be:

• Nouns are spaced.
• Verbs are hyphenated.
• Adverbs run together.

Don’t ask the internet, leftpondian does it differently of course.
Oxford says “timestamp” is a single word. Merriam-Webster says it’s two.

Since we’re speaking proper English, timestamp it is.

If in doubt, just do what looks visually pleasing to you. Grammar of compound words is a mess…

writable vs. writeable

Both are correct.
The first is common American use, the second is common British use.

We Brits like extra letters. Like the U in colour, and don’t mention “aloominum”.

toolpane vs. tool-pane

Uh, tool pane? Two words no hyphen?

leafname vs. leaf-name

Leafname, probably, to be consistent with filename and pathname.

and… my keyboard has a Print Screen keycap and no trace of a Print Scrn

I think the RiscPC era keyboards said “Print Scrn” and below that “SysReq” or something. Can’t be arsed to go in my room and look. The older Archimedes era keyboards I think just said “Print”.

It’s probably not worth getting hung up on minor differences. I have one keyboard that says “Shift”, one that has up pointing arrows, and the one I’m using on the older Pi right now has arrows and says Shift.

Speaking of keyboards, I feel I should point out that in the world of RISC OS, they never really noticed that elsewhere there is actually a difference between the Alt and AltGr keys (exact difference depends on OS).

Just as a side note: I think the issues with open files stands also if they are stored in Choices$Write.

A file, regardless where is being stored, should NOT be kept open, unless it’s strictly necessary. And, surelly has to be closed before starting an update process.

With that said, yes the best place to store an application configuration should be Choices$Write, however, there are situation where a user may wish to create multiple configurations for a single application, for instance emulators that supports multiple hardware and also multiple OS for a given emulated hardware.

In these peculiar cases, IMHO, CHoices$Write is still the place to use, however the application should allow a user to use one of them multiple specific configurations. So, I tend to say this is a developer responsability. And because to handle this it’s going to be more code, some developers will choose to store a single configuration in the App and, if a user wants multiple configs, then ask the users to create multiple copies of such an app.