A while ago I noticed the striking similarity between Haiku binaries and Linux ones: Both are ELF and uses the SysV ABI. I therefore had an idea of trying to apply minimal patches to existing Haiku binaries and run them on Linux, and started the HyClone project.
After nine months of development, HyClone now supports more than half of all Haiku system calls and is able to run many CLI apps and a few GUI apps:
haiku_loader, a Linux executable that loads runtime_loader.
Modified libroot.so and runtime_loader: libroot.so and runtime_loader contains some raw Haiku system calls, which are unavailable on Linux. HyClone removes all occurrences of these raw syscall instructions and replace them with emulated implementations.
hyclone_server, a Linux daemon process that stores various shared process states. This is how many Haiku APIs such as ports, semaphores and areas are implemented.
Features
Run various build tools like g++ and make, making HyClone a good compilation environment. (haikuporter support is on the way).
Seamlessly share files between Linux and Haiku. HyClone can be a good test environment for cross-compiled binaries without having to copy them to and from a VM.
Run some GUI apps and Haiku-specific tools (strace, pkgman, listattr,…)
Due to limitations of Haiku’s app_server it is not possible to seamlessly integrate Haiku windows on the host’s desktop like X forwarding. app_server only sends vector drawing instructions to the remote client, it does not send any information about windows and widgets.
It is however possible to directly connect to the TCP port using a native client instead of having to use the WebSocket browser-based solution if the renderer code is ported to generate output on a native canvas.
I think this isn’t quite true. The RemoteDesktop application, to connect to remote app_servers directly within Haiku, opens individual windows for each remote window, I think…? Or am I misremembering?
The RemoteDesktop is a fullscreen window, there is no “rootless” mode. You can, however, have local windows shown above it.
There is also some text saying something about redirecting on a “per-application basis”, but this only means that an app can either choose to have all of its windows stay on the local screen or have them sent to the remote client. According to the docs, it’s impossible, for example, to have one Terminal window open on the local screen and forward another one to the remote screen.
No, it’s a WINE-style compatibility layer. All HyClone teams are separate Linux processes. HyClone team ids are the same as Linux PIDs. They are also visible in Linux’s ps:
Many other system resources/information are also shared to some extent, like the filesystem, UID/GID, sockets,…
HyClone GUI apps cannot be run individually because HyClone does not have a native graphics driver and app_server cannot render Haiku GUI apps natively, but has to go through a remote desktop protocol. This protocol does not support forwarding individual app windows.
CLI apps, on the other hand, run standalone just fine. So you can do things like this:
Remote app_server protocol have no concept of windows, instead it allow to create multiple drawing states, setup clipping etc. for each state and send drawing commands to specific drawing state. Window decorator is yet another draw state.
Remote app_server protocol may introduce concept of windows and send drawing commands to each window instead whole screen so remote desktop client may show individual windows. It do not require compositing on computer that provide remote desktop access. Remote desktop client may or may not use compositing.
Ah, yeah you are right.
I suppose this depends also on if the remote server, like x11 would decorate haiku native windows or not (for damage areas)
unless the client can send some too
