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:
Command line applications works out the box in all OS
GUI applications on Haiku works out the box as it is a normal application for it! (it uses libbe, Application Kit, etc...)
GUI applications on Linux links the Haiku libraries compiled for Linux, Application Kit uses in some way native Linux APIs (GTK and so on...)
GUI applications on Mac OSX links the Haiku libraries compiled for Mac OSX, Application Kit uses in some way native Cocoa APIs
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
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…
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…
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
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!
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
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
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.
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:
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.
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.
