Otter Browser and QupZilla - Javascript JIT enabled

Thanks, Doug, but really it is Lee Noar and the like who deserve the credit. I just put the jigsaw-pieces together the best I can :)

Keeping shared libraries in the same directory as the executable has spread to Linux too—especially for development versions of software. The “AppImage” format is a typical example—it appears to the user as if it were a single file much like Mac (or RISC OS!) apps do.

Linux being Linux, there is also Flatpak and Snap…

Just to comment on Otter Browser—if I keep the list of fonts down (currently reduced to pretty much the minimum; I use Fontastic as a font manager), Otter actually starts up quite quickly (although the display isn’t too pretty). Unless I’m missing something though, you can only have the window full screen or the default size.

Isn’t the simple solution to embrace package managers?

If we did that, then the problems of library versions and how to download and install these complex things would just go away, wouldn’t it?!

Funny you should say that. In the early days of package managers, I tried at least one of them a bit, and I read all the messages about them. They seemed so prescriptive that they appeared to cause at least as many problems as they solved. I have avoided using them ever since.

I’m left wondering what I should do now in order to have a working copy of Qupzilla at least. Do I have to delete my copy of !SharedLibs? If I do, what else will break because they are now absent?

One of the qualities of RISC OS that we have all valued for decades is the easy installation process for apps – copy the app to where you want it, maybe update !System, job done. No faffing about like Windows (jeepers, when developing Windows apps, we spent almost as much time on the installer as on the apps themselves). But if Qupzilla has to have an installer – even a generic one – we’ve lost something.

And if we’ve got apps with their own private copies of shared libraries, that’s an oxymoron.

And if we’ve got apps with their own private copies of shared libraries, that’s an oxymoron.

Within RISC OS the system variables for two parallel apps seem to get easily crossed. Often I have just rebooted to clear the variables properly so the intended copy works. I think if you wanted to use two copies of !SharedLibs, neither should be booted/run at start up.
In the linux gccsdk autobuilder, I have to have different library sets, depending on which processor you target.
I did this by making the library a changeable symlink pointing to the different sets. The good thing about this, is that each lib can have it’s own processor descriptive name, but at build time the original gccsdk name is found so job gets done.
I have a script that changes the symlink to suit.
RISC OS doesn’t natively have symlinks, however unixlib built programs work with (soft) symlinks, one example is inside !SharedLibs itself.
When getting into pathnames that do or don’t work (won’t go into this) in RISC OS using unixlib, I take a step back and give the unixlib program unix paths, It is a timesaver in the long run. I even made a small utility that converts a RISC OS path variable to the unix path (RISC OS) variable, so the (small) job can be done in the app’s obey file.
I found that the native !GCC could reliably use such a variable enclosed in <> for paths on the gcc command line also, but don’t normally have difficulties with !GCC.

One of the qualities of RISC OS that we have all valued for decades is the easy installation process for apps

One of the qualities that I like about RISC OS is that attention is paid to backward compatibility. When a module in System is updated, it does all that the old one did, and more.
On Linux, it’s something that they never really appeared to care much about. Things seem to be statically linked to specific versions of libraries, that is one doesn’t link to “blahlib” but one links to “blahlib.4.2.0.1”. Hell, even my old PVR (a closed system) had several versions of the generic C library (two actual, the rest being symlinks to one or the other).
Couple this with the numerous incarnations of .Net or Java that don’t incrementally upgrade each other, but rather coexist side by side. And how Python 3 is better than but not directly compatible with Python 2…

It seems that our system’s inability to differentiate modules by anything other than name has forced us to care about backwards compatibility. That it is utterly unacceptable and broken to upgrade a module and have its API change.

Something it seems, the rest of the world, simply doesn’t care about.

That’s the only reason that I can think of for why shared libraries are now being placed within an application, instead of… you know… shared.

But if Qupzilla has to have an installer

Sometimes simple installers can make things easier for the user. Consider Zap. It isn’t hard to install, but a bit goes here and a bit goes there and the app itself goes somewhere else.

Funny you should say that. In the early days of package managers, I tried at least one of them a bit, and I read all the messages about them. They seemed so prescriptive that they appeared to cause at least as many problems as they solved. I have avoided using them ever since.

Shame, that, because had you looked again, you would have found that PackMan is quite happy to let you install applications wherever you want them on your disc – so long as if you move them again later you do so in a way that lets it know that you have done so.

The system resources can’t be moved, but you can’t move them anyway. ROOL are looking at pushing updates to !Boot via package management, I think — which would ironically solve your problems with keeping AcornSSL up to date by ensuring that new versions were downloaded when they became available.

One of the qualities of RISC OS that we have all valued for decades is the easy installation process for apps – copy the app to where you want it, maybe update !System, job done. No faffing about like Windows (jeepers, when developing Windows apps, we spent almost as much time on the installer as on the apps themselves). But if Qupzilla has to have an installer – even a generic one – we’ve lost something.

You must have led quite a sheltered life with this, because I can think of many RISC OS apps that have required installation via an opaque installer. Going back to the early 90s it was the norm for the commercial software that I’ve owned. At least one active software house still uses them for several products, AFAIK.

Couple this with the numerous incarnations of .Net or Java that don’t incrementally upgrade each other, but rather coexist side by side. And how Python 3 is better than but not directly compatible with Python 2…

To pick just one topical example, DeskLib and Desk…

It seems that our system’s inability to differentiate modules by anything other than name has forced us to care about backwards compatibility. That it is utterly unacceptable and broken to upgrade a module and have its API change.

Something it seems, the rest of the world, simply doesn’t care about.

Sometimes, it can be a better way to do things, though. Otherwise you end up with whole swathes of API nuance depending on whether an “unlikely” magic number was or was not present in an unused register when an earlier SWI was called. Allegedly. I can’t think of any OS that would do something as nasty as that.

I’ve just added some functionality to one of my shared libraries, and to maintain backwards compatibility I’ve ended up with a nasty hack where two function calls are required to achieve something that in all other parts of the API would take a single function call. I gave serious consideration to updating all of the code that I have which calls the original function, but concluded that there was simply too much.

That’s the only reason that I can think of for why shared libraries are now being placed within an application, instead of… you know… shared.

Yes. The problem here is that both titles are coming from the same software house, if I’m following correctly. Sure, the long term goal should be using the same shared libraries, but if that’s not possible, then isn’t it just a compiler flag to statically link the libraries for now until the problem has been addressed? Why is that not being done?

What we have instead is a situation where we have set up a world of pain for future developers, now that users have different copies of standard library files splattered around their machines. I would put money on the fact that 100% of them won’t clean this up when the problem is resolved, and it will bite some of them later (and probably some unrelated developer who gets the bug reports, too).

Yes. The problem here is that both titles are coming from the same software house, if I’m following correctly. Sure, the long term goal should be using the same shared libraries, but if that’s not possible, then isn’t it just a compiler flag to statically link the libraries for now until the problem has been addressed? Why is that not being done?

Iris and Otter use different libraries because they use different ABIs. Otter and its dependencies are compiled with GCC 4.7.4 which uses abi-2.0 for its shared libraries. Iris is built with GCC 8.2.0 which uses armeabihf. So the libraries are not compatible. There were a number of reasons why I decided to go with a different ABI for my port of webkit, mostly for compatibility with existing libraries that contain chunks of hand written ARM code that are difficult to rewrite for GCC 4.7.4, and for compatibility with a possible future port of the JIT in webkit.

Another reason was that I found that the size of the webkit library caused relocation overflows during linking due to the stack extension code.

It is possible for both to use the same !SharedLibs application. The one supplied with Iris is the latest and contains the latest SOManager module. With both sets of libraries installed alongside each other, ie, !SharedLibs.lib.abi-2.0 and !SharedLibs.lib.armeabihf and both dynamic linkers in !SharedLibs.lib, then the system can load both.
Admittedly, this hasn’t been thoroughly tested; I haven’t actually run both browsers together, but I have run GCC 4.7.4 and GCC 8.2.0 one after the other without issue.

Static linking isn’t really feasible due to the large number of libraries, and with webkit and javascriptcore weighing in at over 50MB between them, the final binary would be well over 100MB. I suspect the linking would be problematic too, not to mention the debug cycle. It’s tedious just waiting for webkit to transfer to RISC OS after every edit.

that PackMan is quite happy to let you install applications wherever you want them on your disc

I don’t think the early versions did, which might have coloured people’s opinions? I have PackMan, with some managed packages, but I also have a number of things that I’ve pulled directly from the site and installed manually.

ROOL are looking at pushing updates to !Boot via package management […] by ensuring that the user is notified of new versions were downloaded when they became available.

There, fixed that for you.

It is, actually, a notable omission from the !Store application. When I start !Store, I don’t actually give the remotest inkling of a poop what has been added to the list (and it seems rather arbitrary anyway).
What I care about is what I have that has been updated.
And !Store does not help here.

Really, it should track versions of things downloaded and notify you (with a highlight on the relevant entries) of things that have updates available.
Plus there should be a public API for a program to retrieve version information from the website so that a simple GetURL request can pull the info and have the program itself notify if there’s an update (akin to how Manga does it in beta-track mode).

RISC OS shouldn’t be stuck in the early ‘90s. Updates are possible, are available, and it’s only right that users be notified by a mechanism a little more reliable than “a post on a forum/newsgroup”.

many RISC OS apps that have required installation via an opaque installer.

Oh, sure. Ovation, Impression, PhotoDesk… possibly ArtWorks?

Now, how many of these products actually need to have an installer, and how many have installers simply as an excuse to stuff in the “registration/locking” mechanism?

To give three examples:

1. Ovation (the original) had a complicated installer that locked it to making two discs. You could uninstall (+1 disc) and install (-1 disc).
   It went severely tits up when RISC OS 3 came along (possibly the UpdateMEMC, 64, 64 trick?) and both the installer and the product itself both stiffed the machine.
   I sent my original disc back to Beebug asking for an update. Ages later, it came back with a simple copy of Ovation on it. Drag’n’drop it wherever I wanted.
   [note: the installer was a Beebug addition]
2. A contemporary package (no name) uses techniques such as the machine identity (etc) in order to create some data to lock the product to the machine. This is performed by the fancy installer. Which, let’s be honest, does little more than pulling the program files out of an archive and making the registration data. If it wasn’t for the registration, it could be a zip file.
3. And now for the sensible way to do it. OvationPro, by Mr. Pilling. It’s the program. An archive. Dump it wherever you want. Multiple copies if you feel like it.
   All (registered) versions come with a little bit of data that encodes your name and address, and this is shown at start-up. So by all means pass along copies to your friends, so long as you don’t mind a very visible reminder of who gave out their copies and who needs to get their ass kicked for the copyright infringement.
   This is a good method. It’s an effective visual deterrent that does not depend upon weird installers or complications getting in the way of what is ‘normal’.

To pick just one topical example, DeskLib and Desk…

DeskLib != Desk.

It is an evolution, certainly. But it has its own name and its own namespace, given that it was a breaking change. We could use it, or not, as we saw fit.

Note how I maintain a version of DeskLib and GCCSDK maintains a version of DeskLib. Did anybody actually ever transition to using Desk? Is Desk even available in a 32 bit form?

Otherwise you end up with whole swathes of API nuance depending on whether an “unlikely” magic number was or was not present in an unused register when an earlier SWI was called. Allegedly. I can’t think of any OS that would do something as nasty as that.

It’s a fair point. The Wimp is a horrible example of magic values versus “just set some flags”, and some of the palette calls can take the value “TRUE” if you want actual colour values. Two examples that come to mind.

But, really, while this is not ideal, is it not a better way of extending an existant API than simply throwing the API away and having a dozen different versions of the same thing? Because, you know, you still have to deal with magic values in knowing which versions of the libraries provide which APIs.

In the case of needing hacks to provide newer APIs, one could argue that this is where new API calls ought to be used. Consider ReadLine vs ReadLine32 (which is actually a bad example as both get marshalled through ReadLineV which is a mess), but you get the idea. Perhaps DiscOp vs DiscOp64 would be a better example?

isn’t it just a compiler flag to statically link the libraries for now until the problem has been addressed? Why is that not being done?

I’d think it’s probably more a linker flag. ;-)
Why it isn’t being done is obvious.
The browser executable is already stupid-large (in RISC OS terms), and it’s supported by a hundred megabytes of libraries.
Leading to a final application size of what?
Oh, and don’t forget – shared libraries don’t need to be swapped. Application workspace does.

now that users have different copies of standard library files splattered around their machines

Yeah, it’s not ideal is it?

However…

With both sets of libraries installed alongside each other, ie, !SharedLibs.lib.abi-2.0 and !SharedLibs.lib.armeabihf and both dynamic linkers in !SharedLibs.lib, then the system can load both.

If this is the case (and it needs testing to check it is!), then there’s no reason not to have the mess hidden away within !SharedLibs and have it magically work.

It is, actually, a notable omission from the !Store application. When I start !Store, I don’t actually give the remotest inkling of a poop what has been added to the list (and it seems rather arbitrary anyway).
What I care about is what I have that has been updated.
And !Store does not help here.

Really, it should track versions of things downloaded and notify you (with a highlight on the relevant entries) of things that have updates available. /bq.

Rick if you become a registered user of !Store, it provides a list of the software you have downloaded from the point of registering in your personal “My Software” section and will flag any newer versions available for the software you have previously downloaded. It works here without issue.

t is, actually, a notable omission from the !Store application. When I start !Store, I don’t actually give the remotest inkling of a poop what has been added to the list (and it seems rather arbitrary anyway). What I care about is what I have that has been updated. And !Store does not help here.

Um. Yes it does. My copy lists all of the things that I’ve downloaded, and highlights which ones have new updates available.

You do need to be logged in to your account for it to track this, however.

Updates are possible, are available, and it’s only right that users be notified by a mechanism a little more reliable than “a post on a forum/newsgroup”.

Well, yes. Castle had it working with the IyoUpdate on the Iyonix.

Oh, sure. Ovation, Impression, PhotoDesk… possibly ArtWorks?

Messenger Pro.

It is an evolution, certainly. But it has its own name and its own namespace, given that it was a breaking change. We could use it, or not, as we saw fit.

Which is how other platforms view breaking changes in shared libraries. You change the filename, and push it out as an ongoing option until no-one cares any more (or, more accurately, until nothing in your package management depends on it).

Note how I maintain a version of DeskLib and GCCSDK maintains a version of DeskLib.

Which isn’t entirely helpful, given that all we’re talking about is the compiler used to build the library. It’s more crazy than other platforms’ situations, when you start to think about it…

If this is the case (and it needs testing to check it is!), then there’s no reason not to have the mess hidden away within !SharedLibs and have it magically work.

Indeed. I don’t understand Andrew’s explanation.

Other platforms manage the “different versions of the same shared library” thing by putting the different versions in the same folder and giving them different names. Andrew seemed to be implying that somehow, we had ended up with two incompatible versions of the same library with the same name and no way to differentiate them, hence the copies in each of the two browsers.

And that it was considered OK to ship to users, albeit early adopters.

The double standards are curious. :-(

What I care about is what I have that has been updated.
And !Store does not help here.

Oh, yes it does!

Any software that you have on your machine is highlighted in !Store’s catalogue in green if it has been updated since you last downloaded it.

Which isn’t entirely helpful, given that all we’re talking about is the compiler used to build the library.

Actually, it’s the same sort of issue as with SharedLibs – it’s a different ABI. ELF vs ALF.

It’s more crazy than other platforms’ situations, when you start to think about it…

Oh, I don’t know. Can Microsoft’s VisualC, Borland TurboC, GCC, OpenWatcom, and lcc all share libraries?
Given we’re talking 16 bit, 32 bit, and 64 bit – I somehow doubt it. :-)

Any software that you have on your machine is highlighted in !Store’s catalogue in green if it has been updated since you last downloaded it.

Nice to know it can actually do it.
I’ll await a convincing explanation of why one must be signed in for the product tracking to work. You are downloading product ‘x’ to machine ‘y’. The program fetches the archive, thus it knows that you are on machine ‘y’ and you have just requested to download product ‘x’. That should be sufficient.

The only requirement to sign in should be for getting updates to commercial software (to verify your entitlement). But the basic “has updates” tracking? There’s no reason why this needs to involve accounts at all. This is RISC OS, not Android…

BTW, I have a login for uploading data to the store via the website. Do the same credentials work in the app? I can’t test it myself because COVID… no, wait, wrong excuse… because idiot farmer.
[to write this, I’m sitting outside with the tablet, using my phone as a hotspot]

I’ll await a convincing explanation of why one must be signed in for the product tracking to work. You are downloading product ‘x’ to machine ‘y’. The program fetches the archive, thus it knows that you are on machine ‘y’ and you have just requested to download product ‘x’. That should be sufficient.

At a guess, because it uses the same system to track the upgrades that you’re entitled to in a paid for sense to the general upgrades that are free to all.

Steve – for clarity, the issue here is that the software being provided is alpha/beta quality (with no disrespect to Lee intended – I’m merely indicating where in the project cycle we stand). Iris requires more recent components than are publicly available/in use.

Personally, I don’t think it is right to require a user to update their master !System and !SharedLibs (which are used by other software) with alpha/beta components (eg. SOmanager, SharedUnixLib etc) for use with Iris. If they find their system unstable (quite likely with alpha/beta software), unpicking it could be a nightmare. (Already experienced with SharedUnixLib test builds).

Instead, I enclosed everything within the application. It isn’t a perfect solution, but it ensures that a user can remove all traces of Iris or OWB merely by hiding or deleting the application.

Once we’re further along and closer to release, it should be possible to have things co-exist, and update master !SharedLibs and SharedUnixLib appropriately.

To give a specific example, latest Iris build needs SharedUnixLib 1.16. The public release of SharedUnixLib is 1.14. At least some of the intervening builds caused compatibility issues with other GCC apps like Netsurf. Should I be forcing people to update their !System with alpha/beta builds just to test Iris? Of course not.

As I say, if someone has a better solution right now, I’m all ears. I don’t see one. I repeat, this is not intended as a final release version solution.

the final binary would be well over 100MB.

Even stripped?

I’ll await a convincing explanation of why one must be signed in for the product tracking to work.

All that it does is to tell you the latest version you have downloaded. It doesn’t put the software anywhere, or onto any machine – that is your responsibility when you extract the software from the archive.

All that it does is to tell you the latest version you have downloaded.

It knows what you’ve downloaded and what version. That’s a form of product tracking. Obviously, given how it works, it won’t know where you’ve put the software, or even if you’ve put it at all, but it still ought to be able to tell you if there are updates without having to be signed in.

Rick – !Store’s software management is designed to be cross-machine, so that you don’t end up with different reports on different systems (particularly important on commercial applications, so you don’t end up buying an update twice). Thus, it needs to know this “centrally”, and that requires some communication with the server, hence the account.

I accept there’s an argument that software management is per-machine as you may be up-to-date on one system, and out-of-date on another. There isn’t a standardised way of RISC OS apps reporting version number though (unless a package manager is used to store that info separately – rather “un-RISC OS”) So, I suppose it is six-of-one and half-a-dozen of the other.

The vision for !Store was always that users should be trusted to install, move and muck around with their software as they saw fit, rather than !Store enforcing methods of installation etc. I felt this was how most existing users download and install software on their RISC OS kit, and would be the most natural fit for developers used to supplying their software on their own websites for download.

The idea was/is that users would build a centralised “my software” list of the programs they had downloaded or bought, and this can then be accessed on each machine to install latest versions of favourite programs from a personalised list of essential apps.

Note that !Store tells you about how it works when you download programs – you can choose to log in or not. It is pretty clear on the pros/cons.

However, I’m aware that !Store has limitations in terms of presentation, and agree that the catalogue could benefit from “recently updated” or “recently added” filters. Of course, then we need to figure out if this should be “since last use” or “since last logon” or “last 30 days” etc….

I think there are a couple of improvements that could be made to aid usability: -

1. Highlight new entries since the last time the catalogue was updated
2. Highlight new version numbers since the last time the catalogue was updated

I’ve got no problem with the need to log in to see that there are updates specific to the items that you have downloaded – that works fine for me, but it would be very useful to be able to glance through the catalogue list to see what’s been added and/or updated in general.

Thanks Grahame – yes, I do agree on this. The catalogue changes with every app update, though, so the question is to figure out how far back in time to go when reflecting changes. Some thought required.

I was thinking along the lines of what has been added/updated since the user last refreshed the catalogue.

but it still ought to be able to tell you if there are updates without having to be signed in.

No. It couldn’t!

I agree it could mark items as ‘updated’ in the general view (i.e. without logging on) but it would have no way of unmarking them as it would not know whether you, being logged in, had downloaded them. It could ‘time out’ of course but then you might miss an update.