Support MacOS ARM

[gravit0]

The Discord Game SDK now has a macOS ARM build. Link: https://dl-game-sdk.discordapp.net/latest/discord_game_sdk.zip Discussion: https://github.com/discord/discord-api-docs/discussions/3229 I would like to see support for MacOS ARM natively in this project

[JnCrMx]

Assigned this to a milestone. I will be working on it in the next month. Should be relatively straightforward, just a compiler tool chain to add and some enums to correct, as it is a huge upgrade in terms of SDK version number.

[JnCrMx]

Well, change of plan. As I am working on the pure-Java implementation, platform specific binaries will most likely no longer be needed. Unless there is a good reason to keep maintaining the version with native binaries, of course.

[letorbi]

Hi JnCrMx,

what is the current state of the java-impl branch? I've just tried it, but it doesn't seem to work, yet. At least not for setting an activity. Is this right or am I missing something?

I also had a minor issue when compiling the java-impl branch. A test failed, but after commenting the line Core.init(new File(discordLibraryPath)); in /src/test/java/de/jcm/discordgamesdk/DiscordTest.java the compilation succeeded.

Apart from that I also tried to use the the lib with the latest Discord Game SDK (3.2.1) and it seems to work well without any additional changes (tested on Linux and Windows, but just for activities). Unfortunately I was not able to cross-compile for Mac yet, but I am optimistic that it is possible to compile the MacOS binaries for amd64 and aarch64 as well.

Maybe it is faster to provide the aarch64 binary for now, instead of re-implementing everything in pure Java? I am willing to help with the compiling and testing once I have more knowledge about the required toolchain for OSX (see also #57).

Cheers, Torben

[JnCrMx]

Hi,

the java-impl branch is currently still work in progress. At least on my Linux system setting an activity does seem to work tho. I just pushed a few more commits, maybe they will fix it for you :D

On other operating systems, I still need to figure out how Discord communicates with the game. On Linux there is an UNIX socket and I assume on macOS it will be similar, but I still need to spin up my old macOS VM to figure that out. On Windows, I have no idea how the communication works and I will probably have to peek around a bit with Wireshark & co.

Another issue with the Java implementation is that it currently relies on Java 16+ in order to use UNIX Sockets. I will see if I can find a library to make it work for older Java versions.

If you manage to find a reliable way of cross-compiling the binary for aarch64 and macOS, I would gladly include it and I really appreciate the help. However I remember that setting up cross-compiling for amd64 macOS was already quite the journey, so the Java implementation might be a bit quicker.

[letorbi]

Thanks for the update. I will check the new java-impl branch this evening. With a bit of luck, Discord uses Unix Domain Sockets on Windows as well, as they are available there since 2017 (https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/). Apart from that there is also a pure Rust implementation of the Discord Game SDK (https://github.com/EmbarkStudios/discord-sdk), maybe their code gives you some insight in how the communication works on Windows.

Maybe we can split our efforts here: You continue the work on the pure Java implementation and I try to (cross-)compile for Apple Silicon.

[letorbi]

Hi again,

I didn't have the time to figure out the cross-compiling, but I've tested the updated java-impl branch. After removing import de.jcm.discordgamesdk.lobby.LobbyTransaction; from the file src/main/java/de/jcm/discordgamesdk/DiscordUtils.java, I was able to compile it with mvn install -DskipTests -Dmaven.antrun.skip=true -Dmaven.javadoc.skip=true. Setting an activity worked on Linux, but not on Windows - most probably because no Unix Domain Sockets are used in this case (see attached image). My code failed on MacOS as well, bit I think this is due to a bug in my code and not in yours.

I had to skip the tests, because some required the permission to send you messages via Discord, which I don't have. JavaDoc threw a number of errors due to missing comments and AntRun was not required, because there is no need to compile the binaries anymore. In the end I've removed the compile instructions from the pom.xml file, so that I did not have the add the -Dmaven.antrun.skip=true argument.

You can see the all changes I did to compile the java-impl branch in pull request #58.

Here is the error message, when I try to set an activity on windows. Unfortunetely I was not able to get more information :(

[JnCrMx]

Heyo, it's very good to know, that it works on other Linux machines as well. For Windows we most likely have to change at least the path to the socket. Currently the path of the Discord UNIX socket is hardcoded to /run/user/1000/discord-ipc-0.

This of course won't work on Windows and also not on a Linux system with multiple users or users whose UID is not 1000 (as they get assigned /run/users/$UID). On Linux this can be easily fixed by using $XDG_RUNTIME_DIR (which always points to the directory used for sockets, etc.). However, to support Snap and Flatpak we might need to look into some alternative paths that can be used.

For Windows netstat might help us to figure out how Discord communicates with other programs. I just that the same protocol as on Linux is used. We probably need some kind of abstractions to support both whatever Windows uses and the UNIX sockets for macOS and Linux.

[letorbi]

Lucky that the ID of my local user is also 1000 ;) Anyway, I've browsed a bit though the code of the Rust implementation and will now try to port their way of locating the socket file.

BTW: You're right. Pushing the Java implementation seems to be way more efficient that trying to compile the binaries for Silicone ;)

[letorbi]

I was able to get it working on Windows :fireworks: See PR #59 for details.

[gravit0]

Hi! What is the current status?

[letorbi]

My PR got merged and the java-impl branch contains the latest changes. I am using that branch for a little project of mine, and it is working fine so far.

You can use JitPack to include the java-impl branch of the library into your project.