Tagged: , ,

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #123201

    Richard S. Wright Jr.
    Senior Moderator

    Well…. THAT was fun. Today we've posted a brand new full installer for macOS. This works on any 64-bit Mac computer running macOS 10.12 or later and contains changes that are required by macOS Catalina and Apple's new security policies.

    I started life on CPM and DOS, and was an early adopter of the original 16-bit Windows OS. It was well after Win32 came along (I was at the original Microsoft Win32 Professional Developer's conference) that I started developing for the Macintosh (only a year really before joining Software Bisque). I really fell in love with the Mac for many reasons that I'll spare you. Developing FOR the Mac has been an interesting ride. Things are different, and Apple clearly cares about its users… and I might argue more so than their developers. They can be pretty tight on their developer policies, how they deprecate APIs and technologies, and how they in many ways “encourage” us to abandon tools, libraries, and even hardware that they want out of the way. It's progressive, and it has its place. It's different, and I have to admit it keeps the ecosystem all shiny and new.

    The transition to 64-bit has been pretty smooth really, and has been taking place on multiple platforms for us at Software Bisque. With the release of macOS Catalina (version 10.15) Apple has removed all support for 32-bit processes. I thought this would be the biggest headache moving forward, but it turns out that some of the new security policies being put into place has caused more problems than just the 64-bit transition. The two areas this has impacted us the most are in 3rd party plug-ins and support for the JavaScripting engine. Under the covers these are two areas where it is very easy for malicious code to worm its way into our software. While there is little concern that someone would want to take over your imaging run, getting into a running process on your machine opens a whole lot of doors you and I would prefer stayed closed to strangers intent on finding say, interesting financial information, photos of your children, etc. on your machine.

    What this means for us is that we've had to make some changes to our build process for macOS moving forward. To the end user, this will have little consequence other than making sure you have our latest full installer as the base for macOS before installing any future updates or daily builds. For third party plug-in developers there are a few tweaks we need to let you know about. TheSkyX application bundle is a signed, hardened, and notarized application. Any third party device plug-ins not distributed by us directly for macOS will also have to be codesigned and notarized or they will not load (the dreaded error 217). 3rd party developers are welcome to supply us with plug-ins and we'll include them in our updates and code sign them for you (after review and validation of course). Also, on macOS only, we've had to change the location of the device plug-ins. They are now in /PlugIns (not /PlugIns64), and they are a peer to the /Frameworks folder, as such:

    /Contents 


    /Frameworks
                             /MacOS
                             /PlugIns/
                             /Resources

    Both the libraries (.dylib) and user-interface (.ui) files and any other required support files need to go in the PlugIns folder (we are still using /CameraPlugIns, /FilterWheelPlugIns, /FocuserPlugIns, etc. as sub folders). No executable code of any kind is permitted under /Resources anymore. There are ways around this for now, but don't expect it to work forever. The device list text (.txt) files (cameralistVendorZ.txt, etc.) still need to go in /Resources/Common/Miscellaneous Files as before. If you're interested in developing device plug-ins for TheSky by the way, have a look here.

    Also, have a look in the /Frameworks folder for existing .dylibs and frameworks. We have a number of third-party plug-ins all using the libUSB .dylib, but expecting to find them in different locations (and some don't even include it in the installer). If a standard .dylib is already in /Frameworks, use otool to point your .dylib to look for it there. Also, if you write your own installer, we (as does Apple) recommend you put any additional dynamic libraries of frameworks that you need to distribute here.

    Well, with all that out of the way, I need to get back to a few loose ends elsewhere. We do have this little red box thingy we want to ship sometime soon…

    Richard

     

    #282213

    canyonlight
    Participant

    Thanks Richard for this helpful info. Appreciate all you do.

    #282661

    tferris
    Participant

    Thanks, Richard; good to know…

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.