Fix for macOS Sonoma

[tperry2x]

The Advantage with 9.6.1 is that it can make 32-bit Mac standalones.

build.png (75.83 KiB) Viewed 2360 times

OpenXtalk lite 0.92, which is based on LC 9.6.3 community, can make 32bit and 64bit standalones, (https://www.openxtalk.org/forum/viewtop ... 3713#p3713) and I was just curious to see if the link I sent you Richmond now runs on Sonoma?

I mean, unfortunately - unless you are on MacOS 10.14 Mojave and lower, you most likely won't be able to run any of the 32bit standalones as this has been pruned from the OS by Apple.

I'm just curious as to what Sonoma does to it, but I'm hoping the 64bit standalones it makes at least run without issue.

[richmond62]

Fantastic.

The problem, now, is portativity.

[richmond62]

I was just curious to see if the link I sent you Richmond now runs on Sonoma?

2 Questions:

1. Is that already patched?

2. If so, how is it bundled so it doesn't 'go sour' over the network?

[tperry2x]

It is already patched, but you might want to try Tom's terminal commands regarding ad-hoc signatures. Worst case, allow apps to run from anywhere with the command I mentioned.

Try

Code: Select all

codesign --remove-signature /path/to/OpenXTalk.app

You should be able to right-click and open.

Or, if you are completely sick of gatekeeper and these warnings (I'm aware of what I'm running, thank you), then you can disable it completely with:

Code: Select all

sudo spctl --master-disable

It's 7z compressed, but also inside a DMG so Google can't mess with it.
No installer. Just drag into wherever you want to run it.
Link was by private message.

Thanks Richmond

[tperry2x]

The problem, now, is portativity.

How so? I don't quite follow.

[tperry2x]

Well, it runs in Sonoma:

Screenshot 2023-10-23 at 14.33.06.png (1.75 MiB) Viewed 2283 times

Of course, no dark mode - but at least it functions.

[richmond62]

Super.

I am sorry, last night I had to drive halfway across Bulgaria, and back, to help a friend in serious trouble.

[tperry2x]

I am sorry, last night I had to drive halfway across Bulgaria, and back, to help a friend is serious trouble.

Don't be sorry.
There's a lot more important things going on in the world at the moment, and this really does not matter compared to all of that.

Real world stuff always comes first, so please don't feel that any apologies are necessary.

I just wanted to merely say that from the OXT Lite point of view, it all seems good and thanks to Tom again for his help in getting this working for those on Sonoma.
(which won't be me, as the iMac i'm trying it on in this picture is absolutely suffering with Sonoma - check out the CPU usage!).

Anyway, I will replace the Mac builds on my site with this one soon enough as it behaves nicely under 10.9 to 10.15 that I'm able to try it on normally. At least we can mark the Sonoma compatibility issue off.

Screenshot 2023-10-23 at 15.17.02.png (892.05 KiB) Viewed 2276 times

[richmond62]

I will run your version on my 2018 Mac Mini (8 GB RAM) by Wednesday night at the latest.

Although, come to think of things: WHERE should I download the thing from?

Please post a direct link here.

[tperry2x]

Please post a direct link here.

No problem:
https://drive.google.com/file/d/1fZNOXb ... NvLNZ/edit
(it had to be in Google as my site does not have enough space to host it).
After spinning around for a while, it'll say it can't preview it. That's fine, just hit the download button

meh.png (6.08 KiB) Viewed 2269 times

You shouldn't have to log in or anything.

Correction to my earlier post, it's zipped using MacOS built in compression program, then 7zipped for good measure to get the size down and to stop google f!%$*(g with it.

[micmac]

tperr2x... looking into the resources of the latest posted

no 86-64?

... and more

Mic

Skærmbillede 2023-10-23 kl. 22.40.47.jpg (287.88 KiB) Viewed 2257 times

[tperry2x]

Hi Mic, yes - the standalone will report as 9.6.1, but that's because I mixed and matched parts of the 9.6.3 and 9.6.1 standalones together when re-enabling 32bit standalone builds. (9.6.3 kills off support for 32 bit builds, so the standalone is based on 9.6.1, but with 9.6.3 changes incorporated using diff and compare).

So even though this is labelled as x32 when you peek into the subfolders in the finder, it will build x64 too.
You can test that by building a 64 bit Mac standalone, then running it. Open activity monitor, and you'll see it's 64-bit.
Also. You'll note that MacOS 10.15 won't run 32bit apps, but will run x64 apps generated with this no problem.

You have reminded me of another job I still have to do though, which is change the standalone icon and versioning so it further removes all LC branding. The 9.6.1 versioning is incorrect because I haven't got around to changing it yet. as is the icon, which I'll make my next task.

[OpenXTalkPaul]

I have modified the latest available community version of LiveCode to run smoothly on macOS Sonoma. Since I am probably not allowed to publish it unchanged (with the LiveCode trademark included), here is how you can patch it yourself.

(For those who can afford it, I think it would still be a good idea to buy a licence from LiveCode to support further development. That way you also get an Apple Silicon native version of the program.)

I applied the patch directly to the machine code of the original application and did not bother to download and recompile the source code. If anyone wants to fix the bug in the source code, just drop me a line. I guess it should not be too difficult to find the corresponding places in the source code.

1. Download LiveCode Community 9.6.3 and install it by copying it to your Applications folder.
2. Open LiveCode from the Applications folder once to get Gatekeeper out of the way.
3. Quit LiveCode again (on Sonoma, it will crash automatically for you )
4. Download the attached zip file and unpack it.
5. Put patch1.hex and patch2.hex on your desktop. One contains the fixes for the IDE itself, the other one ensures that the standalones you create work correctly.
6. Open a terminal.
7. Copy and paste the following command into your terminal and press the Return key:

   Code: Select all

   sudo xxd -r ~/Desktop/patch1.hex /Applications/LiveCode\ Community\ 9.6.3.app/Contents/MacOS/LiveCode-Community

   You will have to enter your password (nothing will be displayed on the screen) and press Return again.
8. Now copy and paste the command for the second patch into your terminal and press the Return key:

   Code: Select all

   sudo xxd -r ~/Desktop/patch2.hex /Applications/LiveCode\ Community\ 9.6.3.app/Contents/Tools/Runtime/Mac\ OS\ X/x86-64/Standalone.app/Contents/MacOS/Standalone-Community

9. Now LiveCode is fixed (you can now delete the patch files), but it will not work because macOS will eventually notice that it has been modified. So we need to re-sign the modified application. Run these two commands in your terminal. Copy and paste one command at a time and press Return after each command:

   Code: Select all

   sudo codesign -f -s- --deep /Applications/LiveCode\ Community\ 9.6.3.app/Contents/Tools/Runtime/Mac\ OS\ X/x86-64/Standalone.app

   If you don't have the necessary developer tools on your Mac, macOS should ask you at this point if you want to download them. Just click "Install". Wait until the installation has completed (this can take quite some time), then don't forget to run the above codesign command again before entering the second one.

   Code: Select all

   sudo codesign -f -s- --deep /Applications/LiveCode\ Community\ 9.6.3.app

10. That's it! You're ready to go again.

Woohoo! Bravo! Amazing! Cheers!
Patching the executable binary should be fine but yes, please, we'll need to know exactly what this patch patches to enabled it to run on Sonoma. Was it something to do with NSMenu? We will need to patch this in the source code so when we eventually recompile the macOS binaries it will have the fix.
Thanks!

--- EDIT ---
Now that I'm caught up on the thread...
OK great! We know exactly why the Menu stuff was taking a dump! I will have to read up on new AutoFill menu.

I imagine fixing this in the source will probably involve editing this file:
https://github.com/livecode/livecode/bl ... u.mm#L1272

LC CE 9.6.1 32 bit Standalone binary does NOT need to be patched for this Sonoma menu-crash fix, since that binary is 32bit, it won't run past Mohave 10.14 anyway. Until we can recompile from source, I suggest we have the macOS Standalone builder only build either Legacy 32bit (using 9.6.1 sa binary), or current 64bit (using 9.6.3 binary), and discard any 32+64bit fat building (which DPE was using the un-Lipo'ed 9.6.1 binary for). Not sure about the backDrop fix (personally I I never use the backdrop anyway).

LC CE 8.x does have the advantage of being able to run on Snow Leopard (10.6) while still supporting some newer things like LCB, v8 had widgets and builder extension libraries ( but not the FFI capability). The only other older build versions I think are important (at least for retro-Mac use) are v6.x as there was still PowerPC support and v6.5.2 was the last version I'm aware of that could still import HyperCard stacks without crashing the IDE.

[OpenXTalkPaul]

I use the 'preview post' first to make sure attachment actually attached (its wonky, needs fix).

[OpenXTalkPaul]

I am wondering about the legality of putting patched versions inside DMG images and making them publicly available.

BUT I will defer to FourthWorld first.

I am no lawyer but I don't see why a patched executable of a GPL'd released binary should be a problem, since we have here exactly what the changes do to the execution and 'source' hex patch for how to reproduce said changes to that binary, a binary which is reproducible from GPLv3 source, and which we should be able to update to produce the same outcome in future binaries. Does it matter that the same techniques used are also employed for reverse engineering copy protections? I mean this isn't 'cracking' a commercial app here.

I had actually thought maybe patching could be used to avoid the damn embedded registration stack in a similar way, changing a pointer somewhere, or stripping the whole embedded stack out of the binary completely (and we have the 'source' stack for pattern match), but then I thought working towards re-compiling from source would be better use of time (if I had any).
NOTE to self, I really need to read up on memory debuggers and dissemblers (probably said that like 20 years ago too, lol).

Anyway, the new executable would not be signed with LiveCode Ltd. sig. I've stripped all of the 'meta data' type info from these binaries (the windows binarie(s) too). As separate as can possibly be made (so far. still chipping away) from LCs thing (and they seem to be headed in a different direction anyway)... but as you touched on, there's not really any avoiding all of the baked-into-the-code references anyway, like all of the reverse-dns-style identifiers on most ever extension/widget/script/resource library that make up the IDE, and there is indeed references to RunRev and MetaCard in the source / stack scripts as well.

Officially, LC say they're proud of their 'open source' legacy, and we're pretty much that right here! They've even publicly pointed out the existence of OXT recently...righteous!

[tperry2x]

Here we go, this is a bit better for the standalone:

info.png (143.08 KiB) Viewed 2216 times

Testing this on MacOS Monterey (12.6.9) which I'm sure you know, can't run 32 bit apps, so everything that runs is pure x64 bit. It doesn't even like fat binaries, so these are slim(?) x64 builds.

a.png (686.42 KiB) Viewed 2216 times

b.png (644.03 KiB) Viewed 2216 times

c.png (706.13 KiB) Viewed 2216 times

As you can see, the built mac app is 64 bit (otherwise it also wouldn't be running)

[richmond62]

I am no lawyer but I don't see why a patched executable of a GPL'd released binary should be a problem

OK: I'll upload a DMG containing Sonoma patched LC 963 to the archive this coming weekend.

I shall include a note that the patching was performed by 'someone else'.

Unless . . . FourthWorld 'catches' me first.

[OpenXTalkPaul]

I am no lawyer but I don't see why a patched executable of a GPL'd released binary should be a problem

OK: I'll upload a DMG containing Sonoma patched LC 963 to the archive this coming weekend.

I shall include a note that the patching was performed by 'someone else'.

Unless . . . FourthWorld 'catches' me first.

If you're going to do that then you should probably include the hex patch files + info too, that way people can apply the patch to the original binaries themselves if they want to for some reason.

I've tested the 9.6.3 patches on macOS 11 (Big Sur), with binary stripped of code signing and running OXT DPE with it (in darkMode of course) with no obvious (new) problems.

[FourthWorld]

I shall include a note that the patching was performed by 'someone else'.

Unless . . . FourthWorld 'catches' me first.

I am neither an employee of LiveCode Ltd or an attorney. Nothing I write can be construed as the position of that company or as legal advice.

[OpenXTalkPaul]

I shall include a note that the patching was performed by 'someone else'.

Unless . . . FourthWorld 'catches' me first.

I am neither an employee of LiveCode Ltd or an attorney. Nothing I write can be construed as the position of that company or as legal advice.

I think Richmond was mostly looking for your knowledgeble opinion.