Repository files navigation

This binary allows other binaries running under Wine to communicate to Discord running on the host machine. This binary is designed to work only on 64 bit macOS host systems.

If you are using Wine 6.21 or higher (CX22 or higher), please see thewine6.21 branch.

Note: These instructions assume the usage of aWineskin wrapper.

1. Download thebridge.exe binary from thereleases page
2. Move the binary into the Wineskindrive_c folder
3. Invoke the binary before the main application with a batch script:

   start C:\<path>\bridge.exestart C:\<path>\<application>.exe

4. Change the Wineskin executable path to the batch script:

   "C:\<path>\execute.bat"

This fork is based on three other projects:

• https://github.com/0e4ef622/wine-discord-ipc-bridge
• https://github.com/koukuno/wine-discord-ipc-bridge
• https://github.com/goeo-/discord-rpc/blob/xnu-under-wine/src/connection_win.cpp

For general information on how the bridge operates see the mentioned projects. The rest of this section will discuss the specifics for bridging on macOS.

Thediscord-rpc project created bygoeo- is unfortunately outdated for two main reasons. The first is that Discord has deprecated thediscord-rpc.dll method of performing communication in favour of an integrated game sdk file. This makes it difficult to inject code that communicates with the host system rather than with Windows.

However, much of the code responsible for communicating with Linux and macOS is still valid (see brancheslinux-under-wine andxnu-under-wine). In fact, 0e4ef622's implementation directly splices the system call invocations for Linux into the bridging binary. For reference, Wine does not intercept system calls directly but instead replaces Windows API calls. This means that PE binaries can make system calls directly to the host system and it is this method that allows bridging to become possible.

The system calls used by thexnu-under-wine however cannot be used on modern versions of macOS as 32 bit code execution has been disabled. This includes 32 bit system calls which the handlers have not been specifically removed but remain disabled. These handlers can be enabled again by setting the boot argument:nvram boot-args="no32exec=0" but this option is impractical for most users as it requires booting into Recovery Mode. This branch uses 32 bit system calls which means that they cause a segmentation fault upon execution.

Fortunately it does not seem immediately difficult to change these into 64 bit system calls. Add the value0x2000000 to the call vector register (eax) and then change the invocation code fromint 0x80 tosyscall (https://filippo.io/making-system-calls-from-assembly-in-mac-os-x/). The new system call method also requires the arguments to be placed in registers according to the System V ABI. After these modifications are made, the executable can be recompiled.

However, after doing so the binary crashes on execution. Upon further inspection (by running the binary throughwine64 directly; note that Gcenx provides abrew tap that has a formula for running 32 bit applications on Catalina) it is discovered that it crashes on thesyscall instruction. This is because the compiler used for the original bridges generates a 32 bit executable that causes Wine to request the code be located in a 32 bit segment. This prevents thesyscall instruction from being executed under restrictions by the Intel processor and hence issues a fault.

Thankfully the fix is simple. Switch the compiler fromi686-w64-mingw32-gcc tox86_64-w64-mingw32-gcc and the toolchain will generate a 64 bit executable. Note that the registers in thesyscall instruction have been changed to their long mode form. Finally, note that the calling conventions for the system call wrappers have been changed using anattribute. These conventions can be found in GCC's manual and are compatible with mingw's.

• @jacksonrakena for migrating the bridge to Wine 6.21