Either do Notarization for Apple Mac OS X or dump Mac OS X support

[joncampbell123]

Is your feature request related to a problem? Please describe. Apple is going to require notarization for everything in the next Mac OS X.

Describe the solution you'd like I'd like to know if enough people have interest in DOSBox-X for Mac OS X for me to waste $99 a year getting a developer ID and notarizing the releases. If not, there will be no more Mac OS X releases and users will have to compile it themselves.

See also: https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution?language=objc

[joncampbell123]

Apparently this will also require enabling the hardened runtime OR ELSE and require figuring out code signing.

Since DOSBox-X is not compiled with Xcode this means more work with the makefile.

[fuel-pcbox]

TBH, I'd have dropped support for macOS a while ago.

[joncampbell123]

@MoochMcGee I may have to resort to just making sure it compiles and runs as unsigned, with no new features, and let others who want it compile from source as long as that's allowed.

[joncampbell123]

@MoochMcGee There will supposedly be a way to turn it off, but like turning off Gatekeeper entirely, will require magic incantations from the Terminal that users would never do.

If it becomes impossible to turn off, then OS X development will stop and the OS X support code will be removed entirely when most OS X systems are unable to run it even if compiled from source.

[emendelson]

I'm not quite sure what the problem is here. I've been building and notarizing DOSBox-X from current code for the past six months. I just downloaded the current code, built and notarized, using the superb SD Notary utility (provided by one of the authors of Script Debugger. I wrote my own plist.info file, which may have helped. Jon, if you want to provide notarized copies, I'll be happy to provide them for each new release.

[joncampbell123]

@emendelson I appreciate that. My primary development is Linux first, Windows second, and I build OS X because it isn't too much extra work on my end currently. If you like I could direct users in the README file and change notes to your branch for OS X builds that are notarized.

[emendelson]

There's no need to send them to my branch, which turns off some things that game users will want. I'll be happy to build/notarize your original code and send you the notarized copies privately for you to post if you want. There are some questions I should ask about your preferences on some things, and it might be best if you could get in touch with me privately by visiting the feedback page on one of my sites: wpdos.org/feedback.html

[joncampbell123]

I'll at least see if DOSBox-X can compile with the hardened runtime at least, which is apparently required for notarization.

[emendelson]

One point: I built and notarized the SDL1 version. I just tried building SDL2 without success, but I'll restart my machine and try again.

I built the SDL1 code simply by running ./build-macosx without modifying anything. This is under a stock Mojave installation, but notarizing under Mojave enables the app under Catalina.

BTW, for notarizing, I used the some of the special options (allow JIT, etc.) that are available for notarizing; there are checkboxes for them in SD Notary.

[emendelson]

OK, after restarting my machine, I built and notarized unmodified current SDL2 code. There's no reason why DOSBox-X can't be notarized in either version.

[joncampbell123]

Poll results:

https://twitter.com/greatcodeholio/status/1184909328702046208

[emendelson]

Presumably this polls means that anyone who uses macOS wants macOS support, while anyone who doesn't use macOS doesn't care about it. It's a bit like asking: Should DOSBox-X support Australian users or drop Australia support? Many northern-hemisphere users would say to drop it - somewhat like the person who says, "I'm on board the lifeboat. Now we can pull up the ladder."

Those of us who use a Mac know that there's nothing remotely like DOSBox-X out there and that DOSBox itself can't match it in flexibility.

[joncampbell123]

DOSBox-X as previously compiled runs fine on Catalina, but compiling on Catalina shows that OS X broke OpenGL support again.

Apparently the NSView created for OpenGL, assigned to the OpenGL context object, now decided that since the display is a Retina display (high DPI), it's going to make a texture in pixels instead of logical units, causing DOSBox-X to render it's screen in the lower left corner instead of filling the window.

[joncampbell123]

SDL2 (at least the one already installed by Brew) is similarly affected, except that dragging the window eventually corrects it, which is very odd (output=surface or output=opengl).

I pushed a commit that corrects the issue for Catalina if compiled with the latest XCode. It should not change behavior if you're still on Mojave and using the older XCode.

[emendelson]

I'm traveling with my MacBook Air which only runs Mojave (though I can run Catalina in a Parallels Desktop VM). Before I check out the latest code, I should report that the 0.82.24 releases both fail to launch. The SDL2 fails because it can't find the SDL2 library:

Termination Reason: DYLD, [0x1] Library missing

Application Specific Information: dyld: launch, loading dependent libraries

Dyld Error Message: Library not loaded: /usr/local/opt/sdl2/lib/libSDL2-2.0.0.dylib Referenced from: /Users/USER/Downloads/dosbox-x.app/Contents/MacOS/DosBox Reason: image not found

and the SDL1 version fails with a segfault (I wonder if it's the same one I saw when I built the earlier code:

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_PROTECTION_FAILURE at 0x00007ffee201dff8 Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [5737]

VM Regions Near 0x7ffee201dff8: MALLOC_SMALL 00007f89f4000000-00007f89f4800000 [ 8192K] rw-/rwx SM=PRV
--> STACK GUARD 00007ffede81e000-00007ffee201e000 [ 56.0M] ---/rwx SM=NUL stack guard for thread 0 Stack 00007ffee201e000-00007ffee281e000 [ 8192K] rw-/rwx SM=ALI thread 0

However, as with my own SDL1 builds, the unix executable launches when I run it from the command line.

If I drag the two versions into my Catalina VM, the SDL1 version launches correctly (so something is very strange in my MacBook Air), but the SDL2 version fails because it can't find the SDL2 library.

Now I'll build the current source code under Mojave and report back, though this won't tell you anything you don't already know.

[joncampbell123]

The latest commit modifies build-macosx-sdl2 to just use the internal library.

[emendelson]

OK, I've built both versions of the current code under Mojave, and this time both versions run perfectly under Mojave. The SDL1 version, for whatever reason, runs perfectly when I use it to replace the executable in the 0.82.24 version.

Also, both work correctly when dragged into Catalina. Again, I built these in Mojave under Xcode 11.2. I won't be able to build under Catalina until next week.

[joncampbell123]

@emendelson Glad to hear that I didn't break anything! The change shouldn't cause any change in behavior unless compiled with the latest Xcode for Catalina.

[emendelson]

So this means that we CAN compile under the latest Catalina Xcode?

[joncampbell123]

I am able to compile from the Terminal as I normally do.

I had to run the xcode dev tools installer from the command line to restore working gcc, git, etc. commands, but after that, compiling worked.

The latest commit allows SDL1 to display properly.

SDL2 builds have a strange issue that every time the window is resized or on first create, the screen is drawn in the lower left corner, but it solves itself if you move the window around.

[emendelson]

That's what I meant - compile from the terminal. Strange about SDL2...!