Initial Blackbox port on Haiku

[X512]

Recently I finished initial Blackbox port to Haiku.

It is mostly independent from existing Linux port. Most of Haiku API is C++ only, so Itanium C++ ABI compatible declarations with mangled names have been created (HaikuCpp, HaikuCppUtils, HaikuBeDecls). Haiku intensively use threads and some things can't be done without using multiple threads, so mechanism for safe accessing to Blackbox environment by multiple threads was introduced (HostThreadSections). Details are provided in Github readme.

Github
Screenshot

[adimetrius]

Sounds awesome!

Tried to try it, but I'm lost... I installed Haiku, git-cloned the repo... now the readme tells me to open Tools.odc - can't do it, 'cause can't run BlackBox in Haiku. Am I missing some cross-compiling step?

[X512]

You need to download and unpack binary release from https://github.com/X547/BlackBox-Haiku/releases (latest release for now is Blackbox-rev6.zip, note that separate directory should be created before extraction). Blackbox executable is "Blackbox.so", it can be opened with double click. After installing binary release you can overwrite source files from repository and rebuild.

[X512]

If someone interested, this distribution also includes my raster image editor RasterViews and graph plotter TestPlots. It also has native raster image decoders/encoders (TestImgBmp/Png/Gif/Jpeg). BMP and PNG have write support. GIF and PNG (APNG) have animation support.

[adimetrius]

Thanks for the directions, I've downloaded the binary release and was able to start BB in Haiku. Pretty cool!

Looks like you've done A LOT of work! It seems after reading README.md that the biggest challenge was to 'translate' single-process architecture of BB into an inherently multi-threaded archutecture of Haiku.
* When you say 'BlackBox environment', are you refering to global variables of imported modules? Or does it also include the dynamic variables?
* I could't tell from the description if you were able to do the needed adaptations 'transparently': that is, did the non-host-specific modules of BlackBox have to be changed at all? Is it still possible to write Module.var := something

I saw that RasterModels is a wrapper around GuiFills.Bitmap; so, is Raster Haiku-dependent?

I tried to compile my own project, but, alas, it depends on BlackBox 1.8a interfaces; maybe I could make a 1.7-1.8 transitional module, and then try again.

And a final question: why Haiku? is it a hobbyist interest, or commercial, or educational?

[X512]

* When you say 'BlackBox environment', are you refering to global variables of imported modules? Or does it also include the dynamic variables?

Native environment includes module global variables and heap memory. Heap memory should be not accessed outside of native section because garbage collector will temporary change heap object tag and pointer values.

I could't tell from the description if you were able to do the needed adaptations 'transparently': that is, did the non-host-specific modules of BlackBox have to be changed at all?

Native code do not require any changes because only one thread can access native environment at specific moment. Using global variables to exchange data between modules is safe. Main consequence of multi-threaded environment is that it is unknown in which thread native code will be executed, there are no main thread and main loop anymore. But native code don't care, it have no concept of TLS etc..

I saw that RasterModels is a wrapper around GuiFills.Bitmap; so, is Raster Haiku-dependent?

GuiFills, GuiRasterizers etc. implements platform-independent software rasterizer and drawing. Because Blackbox Ports.Rider interface don't support raster graphics, platform-specific code should be used. GuiVidBufViews[2] provide platform-independent abstraction for drawing on raster buffer. GuiHostVidBufViews is platform-specific driver for it. There is a Windows version of that driver.

I tried to compile my own project, but, alas, it depends on BlackBox 1.8a interfaces

What interfaces exactly? I keep my own Blackbox distribution and I port some Center changes to my distribution. I can port new changes if needed.

And a final question: why Haiku? is it a hobbyist interest, or commercial, or educational?

Mostly hobbyist interest. I like Haiku, it think that it is the best open-source OS, but unfortunately it lacks many software and driver support. It is also well written and easy to understand, I learned a lot about OS architecture while reading Haiku source code. Unlike Linux, Haiku is consistent OS providing environment and API for desktop computing. Linux distributions are a mess of unrelated components that are working together by force. Many components of Linux ecosystem are unstable, for example GTK3 was introduced making GTK2 Blackbox port obsolete. Developers make crazy changes like renaming API with no good reason and breaking compatibility with applications. Haiku introduce new features without breaking API and ABI, for example anti-aliased sub-pixel graphics and gradients were introduced so web pages can be natively rendered with Haiku API. Compared to Haiku, Linux desktop environments have a lot of small issues like broken shortcuts, limited windows and focus manipulation, inter-application communication, file associations with lack of some features etc. Modern Windows is terribly bloated, Blackbox on Haiku is running much faster, than on Windows.

[adimetrius]

Thank you very much for the clarifications. I am excited that BlackBox is ported (though in initial stage) onto another platform.

It seems that some compiler changes would make linking to C++ APIs of Haiku easier. So, in BBCP the Platform-Specific-Issues document specifies the procedure sysflag [ccall] to interface to C ABI, and in like manner [cpp] could indicate a C++ calling convention. (It would probably require a deeper and more serious ananlysis than this, it's just my first impression).

After looking at Haiku, I was impressed with how compact it is: just under 2GB! I am using Ubuntu 16, and it requires times more space (and is shipped with LibreOffice that I never use haha).

The most essential native apps I run are the browser and BB. If BB/Haiku were in fact platform-transparent/independent and didn't require code changes switching between Linux/Windows/Haiku, it would, well, be amazing and awesome; and I would consider using Haiku as the host os for my notebook that i take out to coffee shops and parks ). Eventually I hope BB can be ported to the browser and the mobile.

So, my project that I wanted to try in BB/Haiku is a simple platform-independent editor extension github.com/adimetrius/Ed. The 1.8a dependencies that it has are for the modules Unicode and Utf of the BBCP - BlackBox CrossPlatform blackbox.oberon.org.