search

ptitSeb / box64

Box64 - Linux Userspace x86_64 Emulator with a twist, targeted at ARM64 Linux devices
https://box86.org
MIT License
3.9k stars 288 forks source link

Loading x64 libraries from arm64 code #1273

Open Rosentti opened 9 months ago

Rosentti commented 9 months ago

Hi. I make an application (OpenSteamClient), which is build with dotnet and C#. This supports being natively compiled for arm64, x64 and lots of platforms. However an underlying library is only available as 64-bit or 32-bit (works the same regardless).

Can box64/box86 be used with a native app to load a non-native library and have it work?

Sorry if this has been asked before, couldn't find anything on the topic.

ptitSeb commented 9 months ago

It can, but not directly. Create a special wrapper for a lib is possible, as long as you now the API. It's not straightforward for now, but if you have the libs in question and it's API to wrap, I can work on that, OpenSteamClient looks like an interesting project.

Rosentti commented 9 months ago

Well that might be a problem. We don't know it's api 100%, and all the interop is done through C#. Are there docs for that feature anywhere?

ptitSeb commented 9 months ago

No, no doc.

Basicaly, the idea is to build box64 as a library that expose the needed API, and wrapped calls to execute the underlying x86_64 code. If the API is C (and not C++), that can be done. If the API get enriched later by other function call, that's not an issue, but it would need code change and new build. I still need to create the mecanism, but never did it becasue I never had a concrete lib to wrap...

Rosentti commented 9 months ago

So libbox64 (as a library, let's call it libbox64 for now), could expose, say:

If it's possible, that'd effectively be enough for our use case.

The first function we call from the lib is called CreateInterface (via dlsym/dlopen), which returns a pointer to a C++ class with a specified name (as const char*).

The actual calling of the functions in the C++ class is done with some math to calculate each function's offset in the vtable, so no problem there with box64?

The second one is a callback system (also retrieved with dlsym), called rapidly every ~5ms. This returns a struct to some callback data. I presume this is also not an issue with box64, since the data comes from the lib.

I know one possible problem area though, the lib spawns other x64 (and in some cases x86) processes for some (optional) features, like shader management.