Haiku API (BeOS API) as a framwework

Ultimately I’m programming a lot on Qt on Linux, not so bad but shouldn’t it be beautiful to can use Haiku/BeOs API on Linux (or Windows or OSX)?
This is not the usual proposal to port BeOS on a Linux Kernel, please not misunderstand me!
I’m absolutely contrary, to this as you know, but in a cert-sense is exactly the contrary make Linux better using Be API!
In the end is the same thing done by Nokia for QT and Sun for JAVA: a framework targeting a Virtual Machine that in this case is incidentally real(Haiku/X86).
In the end Haiku has advantages to this as applications developed for other OSes using this imaginary framework can run natively on it!

So we have:

  1. Command line applications works out the box in all OS
  2. GUI applications on Haiku works out the box as it is a normal application for it! (it uses libbe, Application Kit, etc...)
  3. GUI applications on Linux links the Haiku libraries compiled for Linux, Application Kit uses in some way native Linux APIs (GTK and so on...)
  4. GUI applications on Mac OSX links the Haiku libraries compiled for Mac OSX, Application Kit uses in some way native Cocoa APIs
  5. GUI applications on Windows links the Haiku libraries compiled for Windows, Application Kit uses in some way native Win32 APIs

If you want you can think to do something similar to that Google done per NACL:

that is, we can create our “runtime”, our gcc, our unified posix library, our ABI (that is the Haiku/Be ABI); that is in Linux not use system printf() but our own implementation for example, so in the end we can obtain a marvelous result:
I create an APP on Windows and it runs without recompiling (!) works out-of-the-box on Linux (and Win32, MacOSX, etc…) and NATIVELY in Haiku!

It will be fantastic and I suppose very possible, if we want :slight_smile:

And we can imagine to do the same pass of PNACL, targeting an Haiku on immaginary and then jitting (compilin just-in-time after during the runto the native CPU) using LLVM for X86, ARM, PPC, MIPS…

What you think?

That doesn’t make much sense, though: first of all the Haiku API is not a cross-platform API, and is not designed as such. It supports Haiku features like queries and attributes that are not found on other systems. Furthermore, it’s not a very complete API by today’s standards – for cross platform development, you are much better suited by using Qt, which is even available for Haiku as well.

Well leaving out Haiku specific’s things (that will be beautiful have in other OSes, too, in the end), the Haiku (BeOs) API I find it is more coherent than Qt API…

For example you cannot add an integer to a QString, banally as you can do with BString (as you can do simply by << operator)…

There’s simply no sensate way a part the ugly arg() method to add a number to a QString… and this is only a simple example, there are other “glitches” in Qt API, that Haiku [API] has not!

I think that can be difficult, but not so impossible… the API in the end is written in simple (and clear, too, compliment!) C++ and compiled with the simple GCC and could compile on Linux, straightforward on OSX and with little difficult on Windows.
The major difficulties that I see are 2:

  • Application Kit there are needed "translation" to "Picasso Like :-) call at native call
  • As you remembered me, rightly, Storage Kit is heavenly connected with BFS queries and so on... it is feasible to leave some functionality alone for now, waiting to have an way to "emulate" BFS query on other OSes... and implement more simple functionality as Open, Close, etc on top of the real native OS API

The results are BIG! You can have a lot applications created not essentially for Haiku, but that work on Haiku out-of-the box :slight_smile:

Basically from what I understand, you want to convert the Haiku API into a cross-platform framework from which to build applications, right? I doubt this is even possible(but try if you want, who knows you may prove me wrong). Sounds like you want to use the Haiku/BeOS API to create a universal application framework where Apps compile for the new Haiku/Be OS framework and run on every OS! Problem is if it could be done, someone else would have done it already!

I played around with a similar idea years ago, but I figured out it had already been done(in a sense) with Java! With Java you can write an app and have it run essentially on every platform. If you want to write an app that will run on every hardware and software platform(that Java supports which is most) you can!

Next we need to get Java support in Haiku!

Isn’t this kind of what Gobe Productive uses to run on windows?

Yes, I forgotten GOBE demonstrated it is possible (the port if I remember correctly was for Linux, too)!

And no, it is a little difference respect JAVA… the code is written in C/C++ so faster JAVA can always do, for the OS it’s a native application linking some particular library nothing else…

If you go forward with imagination you’d think something similar to Google’s NACL and in the end we’ve something really similar to JAVA, compile once & run everywhere, but is native (for X86 a least!).

P.S In your opinion is possible ask GOBE the source of this sort of “glue” code? I suppose they not use it anymore, but for us can be precious :slight_smile:

P.S In your opinion is possible ask GOBE the source of this sort of “glue” code? I suppose they not use it anymore, but for us can be precious :slight_smile:

GOBE Productive is probably the single largest piece of software ever written for BeOS. Yes, when it was ported to Windows there was a ‘porting’ layer that mapped BeOS UI calls into Windows. Unfortunately the code base is really, really huge. It was written specifically to port Productive. It wasn’t written to be a nice, friendly, general purpose GUI toolkit like QT.

But can’t be a start?
A sort of inspiration?

You’ve the sources (or have seen them), right?

I had discussions with the original developers. The source is not open at this point.

I think the difference (and the problem) is related to the level of the API. QT is an abstraction riding above the regular API and c lib, and on each system can be recompiled with fewer issues for that reason. (Still non trivial though) The lower level API is more likely constricted by issues related to the specific implementation of the c library, syscalls, etc, along with issues such as are described here:


Maybe to re-try and approach them again now in 2014-2015?

There are Haiku developers who have access to the source code. But It is a large effort to remove the 3rd party code that is licensed under an NDA. To have general access to this code, it would require several man-months (this is guess estimate) of coding to isolate and remove that code. FYI, it is mostly spell check code but possible other code as well.

Right now there are now developers to take on this task.

Well, it would be great to have an Haiku-based platform indipendent “toolkit” (aka libraries) !

Something like JUCE:


…of course a collaboration could be also interesting, IMHO.

The closest we’ve had to that besides the Gobe for Windows port was flyab, which was an effort to port yab applications to the FLTK toolkit. I see it recently got added to HaikuArchives, but I have no idea in what sort of condition it is.