I probably wouldn't advocate applying all the patches to a v7 build of LCC and expecting it to work. You'll likely end up with a broken mess. Having said that, what I would recommend if you wanted to produce a 32-bit version, happily enough LCC 9.6.3 was also available as a 32bit build, so you could probably expect that to work on your older 'buntu computers if you were to build it from there.
https://community.livecode.com/9_6_3/
As I have all the changes listed in my changes stack, it would be quite simple to apply them all in order, one after another. If I get a chance, I may make a 32-bit version for you and put it into the dropbox folder.
To pick up on the other points here, as I mentioned - I'm well aware that everything and everyone thinks 'web first' these days.
Yes, it's possible to wrap things in an Electron wrapper, but that is really slow. If you wanted something quick and responsive, you cannot beat native C+ code (well you can, assembly - but we aren't about to convert everything to assembly language either).
Personally I already consider MacOS builds imminently at a dead end. As I've mentioned, when Rosetta 2 is phased out, it'll mean the end of intel Applications / Programs (whatever you'd like to call them) - they won't open anymore.
Given that MacOS is being iOS-ified more and more with each update, I'd be quite happy to cease development of a Mac version.
This leaves Windows x64, which will be going for the forseeable future. (Server infrastructure still runs lots of x32-bit code) and Microsoft will no doubt continue to support x64 intel chipsets until I'm at retirement age.
Given that Windows can be found everywhere in Education, and then Linux boxes (because it's a good way of keeping old hardware running with security updates), macs are very much in the minority because of their closed nature, their various tie-ins to the app store, and the inherrent cost of them (unless you buy refurb, but even then you can get three capable i9 intel-based Radeon PCs for the cost of an equivalent iMac). I'm not overly phased if the Mac builds ceased to run tomorrow, since you can go and buy a new intel-x64 chipset based PC off the shelf today. It's a current architecture and one that won't be going away any time soon for the reasons I mentioned above.
This is why I would be looking to carry on with the desktop-only approach, non-web focussed (even if locally running as an instance, rather than running over the cloud), but the more sub-layers and abstraction seems like unnecessary baggage. I don't see why we couldn't use openxion with wxwidgets for a GUI layer (which is cross-platform and provides native interface controls across all platforms). This is then only two layers rather than involving multiple abstraction. I'm a big fan of the 'keep it simple' approach.
But, please don't see this as a comment to take away from anything you are doing Paul. I find it very interesting regarding what is possible with these versions that run through a web browser - I'd just like to have two angles of attack to the problem. A desktop instance
and a browser-based one.
As far as continuing with the LCC engine, I couldn't agree more on the point that pouring lots of effort into keeping it going is very much a dead end too. There will imminently come a time when I can only try and fix so much at stack level. Many of the issues I'm finding are to be found at the engine-level, and I do believe we need to switch away to something else.
However...
Whatever we switch to has to be something that is capable from the get-go. Something that you could take a .livecode stack or an .oxt stack and open it in directly, and expect everything to work - for all the xtalk syntax to be there already for compatibility with existing stacks and projects.
This is why I follow your browser-based versions with interest, as they are looking more and more capable, but there is a big elephant in the room as far as I'm concerned. How does someone start getting their teeth into all of this without first downloading github repositories, compiling, installing javascript or any other libraries that might be required, then the prospect of manually having to edit javascript files is an instant no-go for me. There's a reason we are all here, and that's because we are interested in xtalk as a language. If we wanted Java or any of the others, I guess we'd be forced to go and learn that.
This is why I was massively impressed to see the appimage format being used for the linux releases of the RCx versions - you double click it - it runs (okay, maybe you have to make it executable first), but you get my point. It's not rocket science to get started with it. You don't need to edit anything to get set up, you don't need to spend over an hour downloading extras, and you don't need to poke around in another language to get up and running.
From my point of view (and anyone else?) what we want is something we can double-click, it opens a native GUI interface with natively drawn controls, a tool palette that supports buttons, fields, interface elements (when is the last time someone actually tried to draw anything inside LCC/OXT? - just the ability to handle imported graphic objects such as PNG / JPG / SVG would suffice) and video support a bonus. Once we have this and an xTalk script editor up and running, then I'll gladly pour effort into designing a UI without the glitches of the inspector palettes (and more) that plague me with the existing engine.
It would be absolutely brilliant not to have to deal with all the legacy cruft from the LCC engine. (no more registration stack workarounds, tighter (seamless) integration with the UI elements for every OS, native light/dark mode support).
Going through the 'all guides' documentation as I am, as of late. There's no physical size limit in MB to a stack. (aside from the fact that 32-bit builds of OXT would only see 4GB of memory maximum). As stacks are loaded into memory fully at runtime, this means on 32-bit computers, you do actually have a maximum size of 4GB for stacks. But that is hefty. I've never seen a stack that big. Conversely, what stack size can the browser-based stacks support? Are they limited to 10MB? 20MB? - what the browser would allow in sandboxed mode? if so, I can see more complex stacks such as the 'all guides' and Richmond's Devawriter stack having problems. I'm sure there are lots of examples of large commercial stacks out there which this approach would not be suitable for. You mention Myst, but I once had a macformat DVD with a load of commercial supercard (allegiant?) stacks on that were 10+MB in size. I suspect they would all struggle to run under a web-browser instance as only a subset of the available hardware is made available through a browser.
this made me chuckle