Fix screensaver on MacOS 14

[CharlieFenton]

MacOS 14 again broke BOINC's screensavers. This is a workaround for that issue. It requires new logic in the BOINC screensaver and requires project applications to link their graphics apps with a new version of the BOINC graphic library libboinc_graphics2.a.

As of OS 10.13, app windows can no longer appear on top of screensavers, so we have used Mach comunication and IOSurfaceBuffer to display the graphics output of the child graphics apps in the screensaver's window. The default and project graphics apps have used the bootstrap_check_in() API to create the Mach port and the screensaver has used the bootstrap_look_up() API to connect to the port.

MacOS 14 added a security restriction to screensavers blocking the use of the bootstrap_look_up() API, but it still allows screensavers to use the bootstrap_check_in() API. For backward compatibility on earlier versions of MacOS with existing project graphics apps, this change first tries to use the old method (bootstrap_check_in() in the graphics app and bootstrap_look_up() in the screensaver.) If that fails, it tries the reverse approach: bootstrap_check_in() in the screensaver and bootstrap_look_up() in the graphics app.

This allows older versions MacOS (and older versions of BOINC's screensaver) to display graphics apps built with both the old and new libraries. It allows the new BOINC screensaver to display both graphics apps built with the new and old libraries on earlier versions of MacOS. Finally, it allows the new BOINC screensaver to display graphics apps built with the new libraries on MacOS 14.

IMPORTANT: this screensaver code checks the BOINC version number used to build the graphics libraries used for building the graphics app, so the libraries must be built with at least BOINC version 7.24.4.

[AenBleidd]

@CharlieFenton, I suggest to check for the 8.0 version since it's not released yet, and this is the version we will be releasing. Is this ok for you?

[CharlieFenton]

@CharlieFenton, I suggest to check for the 8.0 version since it's not released yet, and this is the version we will be releasing. Is this ok for you?

That is not a good idea, because although 8.0 has not been promoted to official release, it has been released as an alpha test version available to the public for downloading, and people may have downloaded it. It would cause confusion if we release a build with the same version number as the alpha version but built from different sources. Any time the source files are changed after we have made a version available for download, we must change the version number.

[AenBleidd]

Yes, but I mean, we will release it probably as 8.0.2. If you want - you can make the check for this (and higher) versions.
What I definitely don't want to do is to make a new minor release, and start the whole procedure again.

[CharlieFenton]

Yes, but I mean, we will release it probably as 8.0.2. If you want - you can make the check for this (and higher) versions.
What I definitely don't want to do is to make a new minor release, and start the whole procedure again.

OK, but unfortunately the minimum version number must be hard coded in the source code. I can change that to 8.0.2, but if the final release version is different, it won't work properly. How soon do you expect we will promote 8.0.x to recommended version?

[AenBleidd]

I expect to have it promoted before the end of this month

[CharlieFenton]

I wanted to get a hot fix out as soon as possible. Should I do a quick release of 7.24.4 for the Mac, then as a temporary measure?

[AenBleidd]

@CharlieFenton, sounds ok to me

[CharlieFenton]

OK, then once you have merged this, I'll cherry-pick it into the 7.24 branch and release it as 7.24.4

[AenBleidd]

@CharlieFenton, merged. Thank you for the hotfix. Please proceed with the hotfix release