Attempting to Build Devawriter with OXT Lite

[richmond62]

So, I wonder if you can copy the standalone out of LCC and put it in OXT Lite, and give that a go?

You'll have to explain that in a detailed way for me . . . sorry.
-

TAB.jpg (5.46 KiB) Viewed 2285 times

[tperry2x]

No problem.
My theory is it's to do with the standalone runtimes, and those being patched.
To test this (which I also aim to do this evening):

a.png (39.78 KiB) Viewed 2281 times

Find a fresh copy of LCC 9.6.3 and 'Show Package Contents'

b.png (27.47 KiB) Viewed 2281 times

Navigate to this folder inside the LCC package

c.png (45.74 KiB) Viewed 2281 times

Right-click on the 'Runtime' folder and choose 'Copy'

d.png (55.08 KiB) Viewed 2281 times

Now find your OXT Lite application, right-click that and choose 'Show Package Contents'

e.png (33.13 KiB) Viewed 2281 times

Navigate to this folder, so you can see the 'Runtime' folder

f.png (31.14 KiB) Viewed 2281 times

Rename the Runtime folder to something else 'Runtime-OLD' in this example. (you can delete this folder if this works)

g.png (96.81 KiB) Viewed 2281 times

Now remaining in that window, click an empty area and choose 'Paste Item'

h.png (133.87 KiB) Viewed 2281 times

It'll copy the Runtimes from LCC to OXT Lite (you then have fresh runtimes that aren't patched)


Please then try building devawriter again with the unpatched ones and see if that works.
If it does, great - except for the fact that if you add a custom menu to your standalone, we have the unexpectedly quit error again on recent versions of MacOS.

[richmond62]

I made a hacked version of OXT Lite as per your instructions and the Standalone settings would NOT allow me to select for a Mac 64 build.

[tperry2x]

Okay, please can you give this version a go.
The link I shared with you previously via dropbox, file is called "DWPro-build-OXT-Monday.zip"

Devawriter Pro exp.png (32.51 KiB) Viewed 2258 times

footnote: It might seem strange to some people that we are investing this much time on something (at first glance) unrelated to OpenXTalk, but it's very much related to OpenXTalk: If I identify the problem, I'll be happy and it'll result in a more solid mac build in some ways... To coin some 'corporate-speak', "it's a great vehicle for testing" - now please excuse me while I go and be ill in a bag

[richmond62]

Presumably the file called "DWPro-build-OXT-Monday.zip" . . . should "go rockabilly" on MacOS 12.

Well, I'm at home now so I'll give it an initial whirl on MacOS 12:
-

Screenshot 2024-04-29 at 21.10.44.png (54.78 KiB) Viewed 2231 times

-
Blast!

Although I am not at work tomorrow I shall be popping down to the town, and while I am there I'll "kidnap" my Mac Mini running MacOS 14 for the holidays . . .

To coin some 'corporate-speak'

Yeah, yeah; been there, and had what north of the border is called a bad case of the "dry boak": I think my lowest point was describing the xTalk standalones I knocked up for kids to practise English Grammar and Vocab, as 'Applications for Content Delivery and Reinforcement.'

[tperry2x]

For the love of god I hate macs. Please allow apps from anywhere, then right click and choose open.
That's because it's now an unsigned app because I had the nerve to modify the standalone. Shock horror!

To fix this, I'd have to modify the codesigning. I'm not worried about that at the moment, I just want to see when it opens, if the images load.

The first barrier seems to get it to open!
If you are unsure how to allow apps from anywhere, please use the 'read me first' (with a yellow warning triangle icon), that I included in the OXT Lite v1.03 build.

a.png (52.08 KiB) Viewed 2216 times

b.png (41.14 KiB) Viewed 2216 times

c.png (15.98 KiB) Viewed 2216 times

[richmond62]

Very, very droll:
-

Screenshot 2024-04-29 at 21.31.06.png (97.62 KiB) Viewed 2221 times

-
"OXT Lite v1.04 build."

That's funny, I didn't know you had released a 1.04 version.

[tperry2x]

Haha, I would probably have done - but finding this issue put the brakes on that (and rightly so) - I'd want to fix that first, so I'm kind of glad we caught this. (Edited to 1.03 as that's what I meant - and put in pictures for anyone 'following along at home' )

I've been staring at a lot of splash screens that say v1.04 as of late, and have done a lot of testing - It's only a small incremental version jump, but it would seem v1.04 is indelibly etched into my subconscious now.

[richmond62]

anyone 'following along at home'

-

HOIME.jpg (7.68 KiB) Viewed 2214 times

-
Got any wire coat hangers, loo paper rolls, sticky back plastic, or rubber solution glue?

finding this issue put the brakes on that (and rightly so)

Yes: image corruption is a serious issue that is effectively a show stopper for anyone wanting to build Mac Apps with OXT Lite.

Over the next few days, when I find the time I'll run off a Mac standalone with OXT "Heavy" and see if there is any difference.

[tperry2x]

Yeah, it's not quite Blue Peter, and creating 'Tracy Island' in multiple episodes, but it does feel like it sometimes.

[tperry2x]

Over the next few days, when I find the time I'll run off a Mac standalone with OXT "Heavy" and see if there is any difference.

You might (that's a big might) find there's a size difference, as I know there's a few more libraries included in heavy (RC4 at least that I played with made larger ones) - Paul could confirm as I don't want to get that wrong (It's not my project, so not really my place to comment - but I know it has more audio functions and such built in than OXT lite does)... There's probably a lot more than just that in there, but I don't know what else there is.

I can confirm my mods I made here in OXT Lite 1.04 *unreleased as of yet* do allow for x32 and x64, non-fat (slimline?) builds independently. That hasn't changed: I don't like 'fat binaries'.

Anyway, that 'monday' build I sent you: I tested it on 10.9 and 10.15, and I can't find any issues with loading images.... so I have my fingers crossed it works for you too. Now that you have the 'allow apps from anywhere' option on, I'm really hoping it will work and you see what I see here (all the screens as intended).
Yes, I have the code signing to sort out if it does, but that's an issue for me to go and have 'fun' with another day...

I'll sign it with the same certificate as OXT Lite, as that seemed to work lately. It's not really a good user experience to expect each and every mac user to turn on 'allow apps from anywhere' with that above method. Okay for testing and dev stuff, but would be frowned upon in non-dev circles I'm sure.

[OpenXTalkPaul]

I wonder if these problems with embedded images is related to the problem with windowShape masks image not being embedded in standalone in a way that works with newer macOS versions. The workaround was to re-place the mask image from the original image file again in the stack and then resave the stack and standalone. Which worked to fix my missing window-shape image issue with my Virtual Bass Guitar standalone on BugSur+.

Also can you try using a copy of the images in different graphics file format, like resave image as JPEG if it's currently a PNG and doesn't need alpha channel for transparency or if it does resave as GIF, and then see if that changes your results?

[OpenXTalkPaul]

Over the next few days, when I find the time I'll run off a Mac standalone with OXT "Heavy" and see if there is any difference.

You might (that's a big might) find there's a size difference, as I know there's a few more libraries included in heavy (RC4 at least that I played with made larger ones) - Paul could confirm as I don't want to get that wrong (It's not my project, so not really my place to comment - but I know it has more audio functions and such built in than OXT lite does)... There's probably a lot more than just that in there, but I don't know what else there is.

I'm not sure if I pruned a lot of extra stuff from RC4 (can't look right now), but I have in the build I'm currently running (RC5). One thing I had in earlier versions was a bunch of SoundFonts musical sound-sets that were fairly large (25mb+), I've since reduced that cache to a single tiny (4mb) sound set, just to have a fall-back sound set if there isn't one available in the OS (which is not a problem on macOS or Windows as they both come with one).
I think I may have also left an un-minified copy of the Emscripten Engine .js in there, which is only for developing purposes, along with the minified version that gets deployed. The Un-Minified version file is >50MB.
The only other significant size content things I've added were about 5mb worth of extra SVG Icon Glyphs data, which is totally worth the space usage IMO.

[tperry2x]

I don't want to speak too soon, but I think I've isolated what the issue is.
(certainly seems that way from my tests - demo video) - this is the 'monday' build as I'm calling it.
I'm just going to try this on another mac (a 10.15 mac that it's never been on before) and will do a video test for that one too...

edit: Here's a test with the monday build, this time on Catalina.

[tperry2x]

...can you try using a copy of the images in different graphics file format, like resave image as JPEG if it's currently a PNG and doesn't need alpha channel for transparency or if it does resave as GIF, and then see if that changes your results?

Further up this thread, I think Richmond tried replacing images here, there and everywhere - only for them to disappear at random. He swapped things as gifs, pngs and jpegs, but they seemed to randomly disappear.

I'm hopeful he can try those tests on something other than 10.9 > 10.15 (perhaps MacOS 11 Big Sur > MacOS 13 Ventura), - having first 'allowed apps from anywhere', - I really just want to know if the images all render properly under newer MacOS than I have here. I mean, I'll try and do this - but I won't get the opportunity until mid-week / end of this week.

I'm not sure if I pruned a lot of extra stuff from RC4 (can't look right now), but I have in the build I'm currently running (RC5).

I think we might have been talking cross-purposes here. What I meant (and what I think Richmond meant if I've got my facts right), was ultimately the size of the standalones when created. I don't know what RC4/RC5 will do - does it make a 'fat' version, and does it add in extra libraries and stuff do you know compared to the 'monday' build I made with OXT lite v1.04? - I guess the only way would be to do a size comparison.

Before all this happened, I had wondered about one day trying to reduce down the size of the standalones that OXT creates. The only way I think I could do this though would ultimately be at the compiling stage of the engine (as that's when the standalone 'runtime' folders get built), but as I can't get the Mac version to compile (nor the Windows version to compile at acceptable run speed), then this is something I haven't been able to touch.

I'll await Richmond's further results from his testing before I move on with anything further. Once I have this ironed out, I can release 1.04 of OXT lite.

Oh, while I am on the topic of standalones - I note that you mentioned before that Windows can't build a working MacOS standalone. They don't run, even though they appear to build correctly. I wondered, it might as well be an idea to delete the MacOS runtimes in the Windows build of OXT lite as it would save a lot of MB of space, and I could put up a message on the standalone builder stack, saying something like "Sorry, to build for MacOS - you will need to build this within the MacOS or Linux version of OXT Lite". - I found that Linux can also make perfectly runnable MacOS standalones today too. It just seems to be the windows build that can't.

[OpenXTalkPaul]

Further up this thread, I think Richmond tried replacing images here, there and everywhere

Must have missed that.
I haven't had the image corruption problems like Richmond is getting.

I think we might have been talking cross-purposes here. What I meant (and what I think Richmond meant if I've got my facts right), was ultimately the size of the standalones when created. I don't know what RC4/RC5 will do - does it make a 'fat' version, and does it add in extra libraries and stuff do you know compared to the 'monday' build I made with OXT lite v1.04? - I guess the only way would be to do a size comparison.

AH, I'm using the unpatched 9.6.1 standalone engine for the mac 32bit, since that will never be runnable past 10.14. when 32 bit support was dropped completely. My standalone builder stack doesn't add anything extra.. I mean beyond OXT branded icon (as default), and the Sonoma patch for Mac 64bit engine, It should be identical in size (or close to it) to standalone produced by LC CE 9.6.1 produced 32bit and 9.6.3 produced 64bit respectively.
.

Oh, while I am on the topic of standalones - I note that you mentioned before that Windows can't build a working MacOS standalone. They don't run, even though they appear to build correctly. I wondered, it might as well be an idea to delete the MacOS runtimes in the Windows build of OXT lite as it would save a lot of MB of space, and I could put up a message on the standalone builder stack, saying something like "Sorry, to build for MacOS - you will need to build this within the MacOS or Linux version of OXT Lite". - I found that Linux can also make perfectly runnable MacOS standalones today too. It just seems to be the windows build that can't.

I would bet that if you copied such a Windows or Linux-built Mac standlone over to a Mac and then used the terminal command to set the excitable bit (there's still BSD in there) on the mach binary within the app bundle, then Mac standalone built on Windows would run on Mac. Also the Mac standalone does not include CEF so it's not nearly as big file size-wise as Win/Linux SA engines are... So... with that said.... do whatever you want!
It doesn't make any sense to me to build a Mac app on Windows and then have to copy it over to mac, then run terminal commands to get it executable, just so you can test a build that you will probably have to build again after you test it. I can't really think of a situation where it would make sense to do that.
I had rearranged the IDE repo directories to consistent of one big directory with everything included, a merged MacOS,Win,Linux IDE folder, I didn't build for other individual platform builds until I tried making it into that .AppImage build. But at that point I had considered removing stuff like that, and also the iOS standalone engines since I'm pretty sure you can't make iOS IPA packages without Apple's dev tools installed (which means Mac required).

[tperry2x]

I haven't had the image corruption problems like Richmond is getting.

I'd never experienced it before, but it only happens on built x64 bit standalones involving lots of images.
I can replicate it here, but I'm pretty sure I've identified why. More on that at the bottom of this post.

I would bet that if you copied such a Windows or Linux-built Mac standlone over to a Mac and then used the terminal command to set the excitable bit (there's still BSD in there) on the mach binary within the app bundle, then Mac standalone built on Windows would run on Mac.

I'm absolutely going to try this later. It's probably a niche case(?), but for people who only have a Windows PC to develop on, but also want to offer their build to MacOS users

Edit: Yes, you can create standalones on Windows for MacOS X (x32 and x64 ones), just have to set the executable bit as you said. Also can do this on Linux, but don't need to set the executable bit there.

mac-build-works.png (272.76 KiB) Viewed 2016 times

Speaking of which,
I was able to test Devawriter on Monterey today (which is modern by my standards!) - worked fine with the 'monday' build. No missing images.

[richmond62]

That's fantastic, if you lob me that standalone and/or you "1.04 beta".

[tperry2x]

That's fantastic, if you lob me that standalone and/or you "1.04 beta".

That is the same 'Monday' one I've been testing, as above - with the dropbox folder I shared to you already.
(I mentioned it a bit further up this thread)

You'll have to turn on "Allow apps from anywhere" until I sort out the codesigning issue, which I'll try and do next. Then, all being well, I'll release 1.04 of OXT lite.

Please can you test that "Monday" build though, just to confirm you are happy and it works for you. Preferably on MacOS 12, or MacOS 14.

Once I know that works, I can finish creating 1.04 of OXT Lite (no point releasing it with that still broken).

I haven't publicly shared the link as you asked if it could only be shared between yourself and me.

[OpenXTalkPaul]

You'll have to turn on "Allow apps from anywhere" until I sort out the codesigning issue, which I'll try and do before the end of the week.

https://disable-gatekeeper.github.io

This can also be done via shell commands (unless they've changed it recently)
Run the following command:
sudo spctl --master-disable
Enter your administrator password when requested.
Gatekeeper is now disabled permanently.

Run the following command to unset quarantine bit for individual selections:
xattr -dr com.apple.quarantine /path/to/Application.app
The path is case-sensitive and must point to the application bundle. (You can use Tab to complete file paths.)

This will strip ALL extended attributes from a file/bundle/folder:
xattr -cr /path/to/your/program.app

You can strip any previous code signing, make a backup of binary first. (Part of apple's Dev tools IIRC):
codesign --remove-signature /path/to/Application.app/contents/MacOS/binaryExeName
There's also a 'deep' flag to do this recursively into sub directories in case you have signed code add ons (externals, extensions, standalone engines , etc.)

There's this CLI tool too.
https://github.com/alexzielenski/optool

If you want to get really risqué you could even disable System Integrity Protection (SIP):
csrutil disable
https://developer.apple.com/documentati ... protection

https://apple.stackexchange.com/questio ... s-on-macos

Just now found this info:
https://forums.developer.apple.com/forums/thread/673057

Better solution that doesn't involve disabling SIP:
spctl developer-mode enable-terminal
This shouldn't need to be done in recovery mode.
Then go to System Preferences -> Security & Privacy -> Privacy, and scroll down till you see an entry for "Developer Tools". Authenticate, tick the checkbox next to Terminal, and done!

Hmm, look what was already there in Dev tools:

security.jpg (93.18 KiB) Viewed 2104 times