Is it fixing a hidden flaw or an improvement?

Xojo devs experienced that recent versions like 2022r2 became unusable on macOS with the latest security update installed.

In accordance with Xojo Inc’s policy 2022r2 will not be fixed. Does 2022r4 fix a hidden flaw in the product or is it an improvement customers can be charged for?

https://tracker.xojo.com/xojoinc/xojo/-/issues/72644

When Apple started doing Rapid Security Response tests in the betas, it broke Xojo’s System.Version implementation. As I understand, Xojo was parsing a string that Apple says not to try to parse. This was right around the time that 2022r4 came out; a quick 4.1 “fixed” this.

Now that Apple has released a mainstream RSR, it seems that the “fix” hasn’t held for everyone, at least in some localizations. So maybe they’re still parsing, because they know better.

1 Like

Doesn’t really matter if it’s a bug fix or an improvement, old versions don’t get updated.

1 Like

And don’t expect a “free fix” unless Xojo releases the “fixed” version during your active license period. Otherwise YOU pay not them.

Years ago, there was some major flaw, they released a fix 2 weeks after my license expired… I politely asked them to do the right thing, they told me to go to … well you get the idea.

This would clearly be a hidden flaw in the product.

2 Likes

Indeed, Xojo has never patched an existing version; however, there have been 1-2 instances where they removed an older broken version from the market.

https://www.xojo.com/download/archives.php

In other words, version 2016r2.1 still exists, but version 2 has vanished. At one point, I faced a setback because a plugin didn’t work with version .1, and the required Xojo version was no longer available. Brilliant. So I was forced to pay for an updated version of the plugin w/o any real need for it.

Yes, that’s unfortunately a behavior that’s just not acceptable, that’s just bold and cheeky.

it was also my last transaction with Xojo… I walked away, and not back since (or ever)

And it didnt actually fit it anyway :slight_smile:

There are new bug reports that they once again say “fix” the issue
I guess customers will find out for sure if they finally do it the right way or just continue to patch bad string parsing

Sucky as this is it IS actually understandable why not
Certainly more so since code signing came to be required
The volume of stuff you have to archive to be able to rebuild that old version is significant (and I dont mean just in terms of disk space)
And you probably need hardware that can boot the old versions of macOS, run the old Xcode, VS, gcc etc
And you can’t make “patches” any more, where they actually rewrite part of the exe, like you could way back when. That would break the signatures OR some how you have to resign the exe ON the users computer ? Thats not going to happen either.

And even if they did archive everything, which I’m sure they dont, there’s no certainty they’d be able to sign it any more. Apple likes to break that as well :frowning:

Digital distribution set ups have basically moved everything to getting a whole new install every time
:frowning:

I didn’t questioned that :wink:

Let me clarify a tiny bit
I really dont recall if they did way back in the old MacOS 9 days or not since it was possible to ship patchers then
But I dont think they ever did
At least not that I recall

Ok… I get the idea of archiving the build resources and such…
and that “patching” (in the old sense) is no longer viable…

BUT why can’t Xojo

a) patch a copy of the compiled app.
b) re-sign it
c) deploy it

basically what a user would have done (sans the sign part)

This entire Discussion shows one thing: if they would have one stable Version as LTS and one Work in progress Version or let me say Work in Progress Version life would be much easier. I can’t get why they do not understand but I can see that it costs them customers and makes it nearly impossible to do professional work with it.

Since nobody wants to rewrite always between the versions I would expect that the users would be happy to change exactly that in the release cycle. And Android would be out for a long time as work in progress. Not like it was now: work in progress for years.

But that is the inc. Nobody can even speak with them to change it. They know it possibly but: they don’t want it. And in this situation there is one thing missed: a production version which becomes more and more stable and reliable.

Hiding all wrong decisions under new wrong decisions makes no decision more correct but it ruined the product and the usability.

Dont get me wrong
I’m not saying they CANT do something like LTS
Just they dont
And, based on what I knew they did when I last worked there, I understand why

But they embrace change
Right ? :rofl:

possibly you could tell me why so I can possibly understand it. Cause I can’t get that.

In a theoretical world I suppose this might be possible

What I cant speak to is how easy / difficult it might be to create the patch
I expect they’d have to use the same versions of tools to create that in the first place to be able to successfully get the right patching code

Almost seems to me more risky

  1. they arent set up to do it
  2. they have to make the time to alter their entire build process to handle LTS builds
  3. theyd have to spend at least as much time testing their back patches as they do their current code
  4. I doubt anyone there is set up to be able to boot old versions of macOS, Windows, Linux to do any testing/work on those old versions
  5. do they have appropriate hardware TO put a restored dev environment on for this ?
  6. and Apple, MS, etc MAY no longer permit signing the binary since it would appear to be build with old versions of Xcode etc

there seem to me to be plenty of hurdles

Dont get me wrong I’d rather they tried to than just “Oh shoot we did this really wrong then but pay us to update anyway to get that critical fix”

BUT that IS their MO and I really dont expect them to say “Mea Culpa we screwed this one up and here’s an update for anyone that might need it”

Here’s the documentation for the string that I think they’re parsing (edit: they may be getting it from somewhere else, like IOReg or even SystemProfiler, but that’s more work to get this string).

Discussion

The operating system version string is human readable, localized, and is appropriate for displaying to the user. This string is not appropriate for parsing.

Right next to the string value API is the structure value API, which is what they actually want (and many of us already use).

The thing is, make the mistake once, it happens, but to double down on the mistake and apply more Bubblegum (as @tim would say) is just idiotic. It’s not like they were not warned or provided with the correct documentation. They just continued as if they know better than their customers, which they should, but at this point, we all know they don’t.

1 Like

This string is not appropriate for parsing.

This can’t be misunderstood, plus the warnings. Incompetence and/or hubris on Xojo’s side.

1 Like

Exactly. It illustrates that something at Xojo is seriously wrong, my gut tells me it is inexperience coupled with arrogance.