Stupid Thing to do on the Weekend #258

[richmond62]

Install LiveCode Community 7.1.4 for Windows on MacOS 12.7 with WINE:

https://archive.org/download/live-code- ... %2032-Bit/
-

Screenshot 2024-10-05 at 11.50.36.png (176.57 KiB) Viewed 2718 times

-

Screenshot 2024-10-05 at 11.53.39.png (183.71 KiB) Viewed 2718 times

-
This does NOT work with 'You Only'.
-

Screenshot 2024-10-05 at 11.54.13.png (188.03 KiB) Viewed 2718 times

[richmond62]

Screenshot 2024-10-05 at 11.55.16.png (178.33 KiB) Viewed 2717 times

-

Screenshot 2024-10-05 at 11.55.48.png (361.37 KiB) Viewed 2717 times

-
As the MacOS version of LCC 714 will NOT run on MacOS 12, this is not as daft as it seems.

[tperry2x]

As the MacOS version of LCC 714 will NOT run on MacOS 12, this is not as daft as it seems.

Yes, and as Kdjanz has already confirmed - when Apple stop allowing intel applications to run full stop, Whisky on Apple Arm processors will run LCC too.

[OpenXTalkPaul]

Why would you want to run v7 on macOS 12 instead of something newer, v8 or 9?

To my mind the only reason to run some older version is to run on an OS that doesn't support running v9, like macOS SnowLeo 10.6, but v8 (Intel 32bit/ or 64bit) has always run well on that for me! v6.5 still had PowerPC if I recall correctly, so that's useful for vintage PowerMacs.

[richmond62]

Just suppose you had a target demographic . . .

*Schools in Kerala running Macs running MacOS 10.4 PPC.

. . . and wanted to develop a series of stacks/programs for that, but had no access to a machine like those being used at the target.

(* Richmond pre-breakfast fantasy)

Of course it is perfectly possible to run LC 7.* in Linux with no emulation layer whatever.

[tperry2x]

Also suppose you had a transcript language purist who did not agree with the direction LC had gone with xTalk builder syntax and Widgets. (So want something pre-v8 of LCC, but debranded).
(Before you burn me, that's not me - I'm intrigued by Widgets & Builder syntax) - but I know such people exist.

[richmond62]

I'm only going to burn you if I can join you on the funeral pyre as I cannot be bothered with LCB ("Loads o' Crap Bro' ") or LCB widgets.

I was intrigued by LC's mention of xTalk-native widgets: but, as LC have demonstrated repeatedly, someone round those parts has no sticking power, so that idea went up in smoke like so many others.

Mind you, I was using LC 963 sans any LCB or widgets until I felt OXT Lite had 'matured' enough to handle my stuff.

[tperry2x]

Interestingly (or perhaps only interesting to a geek like me), is that LCC 7 on Linux was the only version out of the 'big 3' platforms to ever be in true 64-bit form. Both MacOS and Windows were 32-bit programs at that time.

Now, if only there was a way to run Linux programs on MacOS... (In theory, Windows 10 and Windows 11 can do this via WSL)

Windows Subsystem for Linux (WSL) is a feature of Windows that allows you to run a Linux environment on your Windows machine, without the need for a separate virtual machine or dual booting. WSL is designed to provide a seamless and productive experience for developers who want to use both Windows and Linux at the same time

https://learn.microsoft.com/en-us/windows/wsl/about

Now, I've never tried it - but it in theory means you can run a true 64-bit instance of LCC 7.x in windows this way. (If you were really that fussed).

I suppose it'd involve getting X11 window system up and running on MacOS via Homebrew, then once that's installed and working, running the OXT Linux binary via that...

Actually, just a thought - I wonder if X11 was installed for other distros (such as on Haiku) (Xlibe), if that would provide the necessary hooks for OXT Lite to run on there. I'll have to do some testing.

Now that's a 'Stupid Thing to do on the Weekend'.

[richmond62]

https://karton.github.io/
-

Screenshot 2024-10-11 at 16.08.56.png (50.76 KiB) Viewed 2362 times

[tperry2x]

https://karton.github.io/

That is interesting. Will add this to the list for the weekend. If I actually get a chance is another thing.

[tperry2x]

Now, if only there was a way to run Linux programs on MacOS... (In theory, Windows 10 and Windows 11 can do this via WSL)
https://learn.microsoft.com/en-us/windows/wsl/about
Now, I've never tried it - but it in theory means you can run a true 64-bit instance of LCC 7.x in windows this way...

Crossing things off the "Stupid things to do on the weekend" (It's raining - as usual, so I spent some time on this).
Yes - I can confirm it's definitely possible to run the Linux version of OXT Lite (in 64-bit mode) through WSL. In theory, the same is true for LCC as well, but I'm not really interested in that.

oxt-lite-on-wsl.png (355.27 KiB) Viewed 2326 times

[tperry2x]

Looks a bit naff though, granted. Kind of jarring because it's a Linux program running in Windows (I suppose no more odd than a Windows program running in Linux) - I'm just not used to seeing it the other way around.

I have been looking at Karton, and honestly - it's such a pain to get going. I don't see this as a viable alternative at the moment of running anything non-native on MacOS. I know it's possible, but it seems like a total headache.

[richmond62]

but it seems like a total headache

Just so: that's why, in a fit of sadism, mentioned it to you rather than try it out myself.

[OpenXTalkPaul]

Just suppose you had a target demographic . . .

*Schools in Kerala running Macs running MacOS 10.4 PPC.

. . . and wanted to develop a series of stacks/programs for that, but had no access to a machine like those being used at the target.

(* Richmond pre-breakfast fantasy)

Of course it is perfectly possible to run LC 7.* in Linux with no emulation layer whatever.

It is possible to run macOS 10.6.x ( I believe it must be 'server edition'), or 10.7+ in a VM like Parallels or VMWare, I've seen it. You could run LC CE 6.5.2 in that and then compile PowerPC standalone binaries with that. It would have to be a version around 6.5.2, not 7.x because PowerPC support was dropped by LC team around 6.6.x.

...Unless we hack a newer version of standalone builder to include the PowerPC binary deploy again. That could be done the same way as with 32bit binary, except PowerPC would require stacks be down-saved to earlier, pre-widgets, pre-full-unicode support, v5/6 stack format.

With PPC old, you could build it with HyperCard, SuperCard, Dan's Serf, Oracle Media Card or whatever and run on 10.4 with 'Classic', heck you could write it in RunRev 2.x on Basillisk or SheepShaver OS 9 emulation too. But if you're after a carbon 'native' binary I think you'd need a later version of RunRev (or SuperCard if someone was into that).

[OpenXTalkPaul]

I suppose it'd involve getting X11 window system up and running on MacOS via Homebrew, then once that's installed and working, running the OXT Linux binary via that...

I don't think that would work, because of being different Application Binary Interface (ABI) I think it would need to be recompiled. But you CAN definitely install an X window server, and compile and run X11 apps on macOS X, I've done it. MacOS X used to come with 'X11.app', now it's off on its own and been renamed XQuartz:(https://en.wikipedia.org/wiki/XQuartz)

[OpenXTalkPaul]

Karton does look interesting https://karton.github.io But it looks like that project has gone dormant for a few years now.
Also it's "Based on Docker containers." and all of the given examples they're compiling executable from .c source code. The concept seems very similar to .AppImage

[tperry2x]

Also it's "Based on Docker containers." and all of the given examples they're compiling executable from .c source code. The concept seems very similar to .AppImage

On MacOS, isn't mostly everything supposed to be contained in the .app bundle anyway, so I don't see the point of docker at all on MacOS, or Linux - where you already have appimage and snap packages.
Perhaps the only one it would make sense for is Windows, but given you can simply place any dll in the same folder as the executable, even that's a bit of a moot point.

[OpenXTalkPaul]

Also it's "Based on Docker containers." and all of the given examples they're compiling executable from .c source code. The concept seems very similar to .AppImage

On MacOS, isn't mostly everything supposed to be contained in the .app bundle anyway, so I don't see the point of docker at all on MacOS, or Linux - where you already have appimage and snap packages.

For cases where you may be using some common frameworks that aren't Apple's, like SDL or a bunch of Homebrew installed things like FFMPEG and all of its dependencies, or perhaps you're using an interpreter engine like Python with a UI toolkit like Qt, or Java VM as your 'app engine' runtime, and then you want to distribute as an all-encapsulating standalone .app (bundle), but maybe not include the 'fat' multi-architecture binaries for all of them ('lipo'd for reduced file size).

.AppImage author has said he was inspired by the idea of NeXT/Apple bundle format.