Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

macOS 10.15 Compatibility #384

Open
DomenicBianchi01 opened this issue Sep 7, 2019 · 13 comments

Comments

@DomenicBianchi01
Copy link

commented Sep 7, 2019

Are there any plans to update OpenBVE to be able to run on macOS 10.15 (Catalina)? Currently the program crashes on start up. Seems like it's because it is using the 32-bit version of Mono but macOS 10.15 no longer supports 32-bit frameworks/programs.

@s520

This comment has been minimized.

Copy link
Contributor

commented Sep 7, 2019

@leezer3

This comment has been minimized.

Copy link
Owner

commented Sep 7, 2019

Interesting question.

On Windows (for legacy reasons) we're stuck on 32-bit.

I was under the impression that Catalina only removed some default 32-bit libraries, as opposed to totally killing 32-bit support dead.
The build cpuld be switched to 64-bit if Mono gets a fully working 64-bit winforms stack.

I'd be intetested to see the error text to start with.
I don't have a real Mac, let alone one with Catalina so this may be an issue, bit it can certainly be looked into.

@DomenicBianchi01

This comment has been minimized.

Copy link
Author

commented Sep 7, 2019

@s520 macOS 10.15 no longer supports 32-bit architectures at all.

@leezer3 When I try to open OpenBVE I get the following error in the console: Unsupported 32-bit executable: "/Library/Frameworks/Mono.framework/Versions/Current/bin/mono32"

@leezer3

This comment has been minimized.

Copy link
Owner

commented Sep 7, 2019

Ouch, that's not good at all; They've definitely dumped 32-bit entirely (terminally stupid, but there we go...)

I'm surprised mono didn't provide a 64-bit shim for mono32 though :(

Digging around in the Mono issues also gives me a link to this:
tilmanginzel/alfred-bluetooth-workflow#9
That suggests that unless Gatekeeper is disabled (not simply bypassed), we'll also dump out, as we're not code-signed.

I will try the x64 version of Mono on a Linux box some time next week and see if we can at least launch with that, but the main menu makes heavy use of legacy winforms, which means that might be problematic at best.

TLDR:

  • I suspect Catalina compatibility will not happen any time soon, sorry :(
  • None of our code requires 32-bit, but on Windows we are tied to this for legacy reasons, which means it's rather hard to change.
  • Any 64-bit support under Mono would require a working Winforms implementation. Last time I looked, Mono didn't have this. .Net Core 3.0 might get this, but that's not current yet.
@DomenicBianchi01

This comment has been minimized.

Copy link
Author

commented Sep 7, 2019

@leezer3 Regarding the code-signing issue you linked, you can actually bypass that. You just have to go to System Preferences -> Security and in there is a button to tell macOS it's ok to open this program.

I think Apple said someday everything will need to be code-signed but that day has not come yet.

@s520

This comment has been minimized.

Copy link
Contributor

commented Sep 11, 2019

I tested with macOS 10.15 Beta 8.
When I try to start mono32, the error "zsh: bad CPU type in executable: mono32" occurs.
.NET Core 3.0 winforms seems to be Windows only, so we may need to use a framework other than winforms ...

@leezer3

This comment has been minimized.

Copy link
Owner

commented Sep 18, 2019

Related- This seems to be the official Mono standpoint at present:
mono/mono#16890

I'm afraid nothing is likely to change significantly in the near future at our end without someone stepping up to rebuild the main menu in an alternate manner :(

For version 1.8, the target will likely to be to move the main sim code to x64 via the PR I've linked above or a variant upon it, but the main game start menu is a very complicated bit of Windows forms code.
We might be able to produce a simplified openGL main menu to allow loading of routes and trains etc. but it wouldn't have anywhere near the polish of what we have at present.

@s520

This comment has been minimized.

Copy link
Contributor

commented Sep 18, 2019

Creating a menu with OpenGL will not be easy.
I suggest Xamarin.Forms as the migration destination.
This is easier to make menus.

@DomenicBianchi01

This comment has been minimized.

Copy link
Author

commented Sep 20, 2019

@leezer3 @s520 It's probably worth noting that OpenGL is deprecated as of macOS 10.14 (Mojave). For now Apple hasn't announced any plans to remove OpenGL from macOS, however, since it is deprecated it is very likely Apple will be removing it (in favour of Metal) within the next few years.

As a result, I think it would be wise to not use OpenGL (just to avoid creating more work at a later date).

PS. I appreciate the time you've spent looking into the macOS 10.15 compatibility issue. Thank-you!

@leezer3

This comment has been minimized.

Copy link
Owner

commented Sep 21, 2019

Now that is insane :/
If openGL goes, at present we're stuffed.
Some progress has been made, and I think we've now got much of the foundations in place for alternate render paths, but at the minute we're heavily reliant on openGL intermediate mode, and I can't see that changing soon......

TBQH it's no big deal investigating something like this, as if nothing else it provided the kick to start thinking about getting x64 in place properly.

Xamarin.Forms vs. openGL-

Been doing a little playing with this. The Xamarin forms seem to be a little easier to implement in the short term, but require a Mac to actually run the preview successfuly and test, which I don't have constant access to. It also means that a Mac would require a 100% Mac specific build, as it's somehow building an embedded Coaco app that does the window drawing.

openGL has the major advantage that it'll work on anything, but requires considerable work to be anything close to usable.
A simple route selector can be hacked together using the current menu code, but this isn't brilliant. Will try and stuff up a branch with this on.

@s520

This comment has been minimized.

Copy link
Contributor

commented Sep 21, 2019

No.
If you use Xamarin.Forms.Platform.GTK, you don't need a macOS specific build.
https://docs.microsoft.com/en-gb/xamarin/xamarin-forms/platform/other/gtk?tabs=windows

leezer3 added a commit that referenced this issue Sep 21, 2019
@leezer3

This comment has been minimized.

Copy link
Owner

commented Sep 21, 2019

Interesting, that could well work.

Will still play with the openGL menu idea though.
With the commit above (It fixes some generic enough issues to go into the mainline builds), and some minor hacking in the gamewindow init code, I've got the in-game menu working as soon as the program loads.
Sure, that isn't too helpful as it stands, but we can define and pop menus at our leisure. Will keep playing :)

leezer3 added a commit that referenced this issue Sep 25, 2019
@leezer3

This comment has been minimized.

Copy link
Owner

commented Sep 25, 2019

The openGL idea is starting to take shape.

This branch is where I'm working at the minute:
https://github.com/leezer3/OpenBVE/compare/OpenGLMenu

Functional:

  • Lists CSV / RW route files.
  • Allows browsing up and down the folder structure on the same drive.

TODO:

  • Hook up so that we can actually launch a route.
  • Train selector- Likely to be similar to the route selector. e.g. a list of available folders / files.
  • Left-align the menu to half-screen width to allow for the fancy business.

Fancy business (later!):

  • Route / train images (not too difficult)
  • Route description if possible. (Text wrapping in openGL may be a PITA)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.