With speed up in processors we probably need something to introduce some less efficient code…

However, we don’t know whether a “Rewritten in C” WIMP will really be less efficient (efficient in what sense, one might wonder? CPU cycles? Memory consumption? Time needed for maintenance? Time needed for adding features?) than what we have now unless someone writes it and we can compare :-)

This is not the time (it was probably 1995) but I would very much like to split WindowManager into three, putting the task management and messaging into TaskManager, the GUI management in a leaner WindowManager and the GUI rendering in a new module. WindowManager would retain the existing API for compatibility.

comparing 0 with &80000000 gives NzcV.

Aha. Because CMP doesn’t actually compare. It’s a SUBS that throws away the result.

I would very much like to split WindowManager into three

That makes sense. We ought to start, I guess, by rearranging the existing code so the modules reflect what’s going on. The original code is Wimp-then-a-number with all sorts of junk in each. There’s a vague theme, but as you’ll see it’s more a “serving suggestion” than “window stuff here, menu creation here, icons here”.

As for actually splitting it up as you suggest, it would be quite interesting to have the GUI and the rendering separated – this might make it easier to implement such things as skinning or remote desktops?

Another one to add to your huge todo list. ;-)

We ought to start, I guess, by rearranging the existing code so the modules reflect what’s going on.

Oh joy. Following the code of simple things like a keypress to bring up the help¹ on a selected item is an excursion around numbered files already.

Another one to add to your huge todo list.

kick shin one direction (NW), cuff ear² in other (SE).

¹ F1 – matches lots of things
² NW style with tyre iron? Or “friendly” with length of 2×4

kick shin one direction (NW), cuff ear in other (SE).

No thank you. At the age of 44, having cycled up the lane and back a billion times, yesterday I pulled on the brakes as usual and next thing I knew I was on the ground having landed heavy on my wrist around the thumb. I now have three weeks off work and a sort of not-cast of black velcro stuff. Not entirely pleasurable. So no, leave this gormless twat alone…

You are (comparatively) lucky. I have a friend who, from a standing start, managed to slip and land on his wrist, resulting in such a bad fracture that he needed two 4" titanium rods screwed into his bones. At least you were moving at the time.

Further to the bug: It was introduced in RO3.80, WindowManager 3.99.

Unfortunately the checkhandle routine does have to preserve (the other) flags – there is at least one usage that requires it. However, the fix is trivial and can be patched in place.

The routine has always been bugged – it’s in the 26b versions too. This requires a patch for all versions… I’ll knock one up.

such a bad fracture that he needed two 4" titanium rods screwed into his bones.

Oh, that sounds horrendous. Was it on ice?

At least you were moving at the time.

There seems to be an accumulation of gravel at the end of the driveway. I am guessing I slipped in that (and judging by my other hand, landed in it). The thing is, I applied the brakes and then I was sideways on the ground vaguely aware of the bike landing on me. That bit in between… I don’t actually remember. But, then, I’m 75kg of gloopy rice and Mars bars so I guess gravity did its bit pretty quickly. :-)

The routine has always been bugged

I guessed that would be the case, CMP hasn’t changed its behaviour.

However, the fix is trivial and can be patched in place.

Nice, the in situ patching should help with the closed-source-never-to-be-touched-again Wimps.

Good detective work, there, Holmes. :-)

I have patches for the following versions:

What other 5.xx have been released? 5.25 and 5.23? LazyWeb: Whence these?

Once I have Patched All The Things I’ll release a Patch file – is !Patch still supported on RO5?

What other 5.xx have been released? 5.25 and 5.23?

5.24 is coming “real soon now” (tomorrow?) and apparently has WindowManager 5.61. [Edit: Confirmed]

What other 5.xx have been released? 5.25 and 5.23? LazyWeb: Whence these?

For the past few years the convention has been that even-numbered OS versions are stable builds, and so have a modicum of post-release support (e.g. updates & patches), while odd-numbered OS versions are development builds (no patching, just upgrade to a newer dev/stable build which has the bug fixed). Also, ROOL’s motto is that every (desktop) RISC OS 5 machine ever released can always be upgraded to the latest version of RISC OS 5, so there isn’t much of a reason to actively support RISC OS 5 releases which are older than the current stable release. Perhaps this also explains why they don’t offer old versions for download.

If you want to see what module versions went into any particular stable release, you can look at the (non- “Dev”) products files in CVS. But since the products files don’t capture the DDE version I’m not sure how reliable it would be to use that info for producing patches.

Once I have Patched All The Things I’ll release a Patch file – is !Patch still supported on RO5?

Nope – it was never 32-bitted. The ROOL way of doing things would probably be to softload a newer Wimp during the boot sequence (which the boot sequence will already do, for 26 bit OS’s at least)

Once I have Patched All The Things I’ll release a Patch file – is !Patch still supported on RO5?

Nope – it was never 32-bitted.

It’s in $.Utilities.!Patch on my computer. Where you looking?

It’s in $.Utilities.!Patch on my computer. Where you looking?

At the wrong component in CVS! PatchApp != PatchesPatch.

5.24 is coming “real soon now” (tomorrow?) and apparently has WindowManager 5.61.

5.61?

Presumably not the 5.61 (23 Apr 2004) that shipped with RO4.39?

No one is even trying to make version numbers make sense any more are they?

For the record, WindowManager 6.61 (13 Nov 2009) is what shipped with RO6.20.

Regardless of the game of ‘one potato two potato’ that led to the major version number arms race, can we all agree that releasing two different builds with the same version number renders RMEnsure rather less useful than intended?

Patches: RO4 has the very nice ROMPatch module that it inherited from RO3.5 – that’s the ideal fix for all 26bit OSes, as I can supply a single ROMPATCH file that fixes all of them.

In RO4 it’s in !Boot.Utils.RO4Patches (at least it is on mine, but I can never remember what I’ve changed). Can someone confirm that it is somewhere in the RO6 !Boot?

I suppose there is no ROMPatch for RO5?

5.61?

Apparently the next increment after 5.60

Presumably not the 5.61 (23 Apr 2004) that shipped with RO4.39?

Always going to be dificult to cope with and the RMEnsure problem has existed for years for many items that ROL took through an increment jump or five. Toolbox is fun too.

Regardless of the game of ‘one potato two potato’ that led to the major version number arms race

There’s so many comments we could all make on that¹, lets just carry on and hope that we get to a set of numbers that are past the “six” quagmire people keep getting stuck in some time soon.

¹ Since the comments all come down to an essay on “yah, boo, sucks” lets not bother.

There is a module PatchApp in !Boot.Utils together with two patches directories RO4Patches and RO6Patches

There is a module PatchApp in !Boot.Utils together with two patches directories RO4Patches and RO6Patches

That’s the RO6 !Boot not the RO5.2x !Boot which is what Jeffrey and Spow were talking about.
That said Nemo doesn’t need to do a patch to cover any current/future version of RO5.2x+ as the source can be amended and the fix is then in all future releases. Patching all the legacy OS revisions (OS <5.0)¹ is nice for those users though.

¹ “Six” is 4.39+potato as nemo reminded us.

No one is even trying to make version numbers make sense any more are they?

That’s likely the only logical outcome of when two branches don’t talk to each other… Especially since one chooses to skip an entire version number (add one potato) to make a point that few people were really interested in, leaving a legacy of buggered up RMEnsure versioning.

My preferred version of testing for recent(ish) things is to look first to see if it’s a HAL kernel. If so, test for versions and stuff. If not, tough titty…

My point is that it is possible to cope, in isolation, with 5.62 being a more recent version of 5.60 while 5.61 is an entirely different branch. (It’s not good, but it can be done).

Whereas, if we have two completely different builds that both happen to claim to be 5.61, then even combining RMEnsure WindowManager with RMEnsure UtilityModule is no help, as someone may have softloaded a WindowManager on another OS (and hence, the ‘wrong’ UtilityModule).

WindowManager is mostly stand-alone and I CAN’T BELIEVE I’M HAVING TO EVEN SAY ANY OF THIS.

It’s not like somebody is charging for version numbers. Just don’t use one that’s already been used. I know they’ve put a climate change denier in charge of Nasa but this really isn’t rocket science EITHER.

Gwyn was kind enough to check:

There is a module PatchApp in !Boot.Utils together with two patches directories RO4Patches and RO6Patches

Right. I’d expect there to be a ROMPatch module inside RO4Patches, is there one in RO6Patches as well? Or is the ROMPatch module somewhere else now?

Rick mused

Especially since one chooses to skip an entire version number (add one potato) to make a point that few people were really interested in, leaving a legacy of buggered up RMEnsure versioning.

1. Everyone has been very silly
2. Saying RO5 is the only developed branch does not make the other versions conveniently disappear
3. There is still a certain degree of Pace-era “well it works for us” silo mentality going on

The RMEnsure ‘problem’ did not start with RO6, it has been going wrong since last century. For example, here is the version history of the !Help module:

I am not picking sides when I say that nobody should release different things with the same version number. Randomise the order if you must, but no doppelgängers!

ROMPatch module is in RO4Patches directory and not in RO6Patches directory. I have not checked to see if it is elswhere

OK thanks, it’s where it has always been. Fingers crossed it works on RO6 too.