My progress on Haiku compatibility layer for Linux

Development
#1

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:

image
image1923Ă—1055 221 KB

Architecture

HyClone consists of three parts:

  • 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,…)

The source code and detailed installation instructions can be found here:
trungnt2910/hyclone: A runtime environment for Haiku applications. (github.com)

If you have any feedback, bug reports, or feature requests, please let me know!

26 Likes
#2

image
image1923Ă—1055 197 KB

Tracker? Yes.
HaikuDepot? Of course.

10 Likes
#3

This looks interesting. Is an output outside a browser possible or planned so it would act somehow like Wine from an user point of view?

#4

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.

1 Like
#5

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?

1 Like
#6

Quoting the documentation:

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.

1 Like
#7

image
image1923Ă—1055 214 KB

ProcessMoniter? Why not?

4 Likes
#8

So, this is a qemu-like emulator that runs a complete haiku build? but can’t run individual apps like Wine?

#9

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:

image
image1614Ă—927 211 KB

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:

image
image1614Ă—927 49.3 KB

(grep is Linux grep)

Or:

image
image1614Ă—927 61.8 KB

(So we can cross-compile without using a cross-compiler)

You can also analyze the mappings of a HyClone process:

image
image1614Ă—927 144 KB

As you can see many Haiku binaries are mapped directly onto Linux’s address space.

2 Likes
#10

doesn’t that implicitly require compositing?

#11

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.

#12

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.

#13

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 :slight_smile:

#14

How much change would it need to provide separate window support for remote app_server?

#15

Nice!!

I see you have some zombie processes there that probably should be cleaned up, I guess it is on a rather long TODO list?

1 Like
#16

They are supposed to be daemons spawned by launch_daemon but runs into stubs really early in initialization.

As the number of stubs reduce the process should run correctly without zombifying.

As for the POSIX method of reaping child processes (wait), HyClone has support for that.

1 Like
#17

You are misremembering, it takes over a full workspace and runs its own window management inside one host window there. Unlike X11.

We should probably change that? Opening individual windows (and providing clipboard integration with the host, etc) seems more useful.

2 Likes
#18

If there are plans to change this, I would love to help.

#19

image
image1923Ă—1055 307 KB

The Terminal you know and love, running Linux apps like a pro.

image
image1923Ă—1055 298 KB

Love Windows PowerShell? No problem.

And no, there is no ssh trickery here.

12 Likes
#20

Very cool. Would it be possible to just run an application like Wonderbrush, without a full desktop? Have you tried running BeOS applications?

1 Like