New Macs – Unzip Omnis

Michael Mantkowski, September 28 2017 10:49:26

New Macs – Unzip Omnis

Thanks Bas,

I don’t think this would be the issue as I am adding the xcomps from a working version on my development system directly into the Packages application.

I received an email from Michael at Brainy Data last night that stated that it may be that the newer versions require the newer Mac OS. He is going to check into that when he gets back from vacation.

Thanks for the information on the Mac Quarantine. I am going to see if I can find google info on it so that I can understand it better.

*********************************************************************
Michael Mantkowski
ClienTrax Software
1-614-875-2245
*********************************************************************

—–Original Message—–
From: omnisdev-en [mailto:omnisdev-en-bounces@lists.omnis-dev.com] On Behalf Of Bastiaan Olij
Sent: Wednesday, September 27, 2017 9:47 PM
To: omnisdev-en@lists.omnis-dev.com
Subject: Re: New Macs – Unzip Omnis

Just in case this hasn’t been mentioned yet, it may not be relevant at all.

Any zip file downloaded from the internet gets earmarked since 10.8 (I
think) and when you unzip executables within (including xcomps) they get marked with the attribute com.apple.quarantine which will prevent the OS and thus Omnis from loading them.

Open up terminal, cd to the location of your xcomps and run:
xattr *

If you see your xcomp come up with the com.apple.quarantine mark, that’s your problem.

You can remove the attribute with:
xattr -d com.apple.quarantine my.xcomp

But it requires admin rights to run that from the terminal.

If this is your problem it’s important to check if the xcomp was already earmarked before it got zipped as part of your installer. Downloading brainy datas zip files, to no fault of Michael, will result in them being earmarked, and when you then zip up the resulting xcomp, it just perpetuates. You need to clear the earmark, then zip it up for your installer.
Or if the earmark is introduced when downloading your DMG, which can only be prevented by codesigning the DMG.

Cheers,

Bas

On 28/9/17 4:53 am, Doug Easterbrook wrote:
> all fair. we like to let people use stuff that is old as well. Sooner or later, it costs you more to support them than to just buy them a new computer.
>
> I not advocating that .. but if it isn’t obvious what the issue is.. and you have declare minimum standards for each new version you release — then they can stay back, or move forward with you.
>
> we are going to face that big time when we go studio 8 and next version of OSX (after high sierra) says — no more 32 bit. so we are preparing customers now that that need to think about their workstation platforms and upgrades of OS in the next while.
>
>
> we can’t afford to have two code bases, especially when there are great things in Studio 8 . I imagin a number of others are in the same boat – and if they haven’t sketched out a plan of informing users… its probably good to do so.
>
>
>
> now, back to studio 4 and owrite — I think you know it works on OSX 10.5.8 — because you know the version that did work. and packages can ‘not’ replace things. for certain versions of the OS. (I like packages, its very cool).
>
> I think thats where you are stuck.. and so you have to add feature detection to your software to say ‘if person has old OS and doesn’t want to update’, then feature A and B is disabled and I’ll tell them if they try to use it’.

_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com

New Macs – Unzip Omnis