An Xlib compatibility layer implemented on top of the Haiku API, in order to run X11 applications on Haiku without an X server.
Xlib‘s API is relatively low-level, but it is just high-level enough that it can be emulated on top of a higher-level API like Haiku’s.
At present, it provides “most” commonly-used Xlib APIs, but many of them are stubbed or incomplete implementations. (GTK, with some hacks, can compile, link, and open a window before it runs in to missing functionality.)
This is crazy person work by Haiku developer waddlesplash. He also posted continuously updated progress thread on the Haiku website, which provides a lot more detail about the process, the current state, and possible future plans.
Haiku deserves developer coding videos like SerenityOS has.
It would be great for it to get more exposure that way, and let people get intimate with the project without being full blown coders themselves.
Shout out to Andreas – love your work! :^)
Holy hell, this is awesome work! This potentially brings Haiku into the realm of daily driver capability and I’m here for it. Trying not to hold my breath too much as it’s early and obviously not complete yet, but excellent work nonetheless Waddlesplash!
Looking forward to the WINE port. If Haiku had a WINE port, i’d likely switch to Haiku as my daily driver OS.
How is WINE implemented? If over Xlib, this work could see your request answered.
tanishaj,
I would think that WINE needs more than just Xlib, but then I have no idea what level of compatibility Haiku has reached with the linux capabilities that WINE requires.. There may be some special handling for loading windows binaries that Haiku can’t yet support.
IMHO supporting foreign software is a mixed blessing. While it’s obviously handy to have access to more software, developers can end up committing their limited resources to supporting software that doesn’t take advantage of native APIs or advance their cause. It’s the same dilemma as indy devs building more POSIX clones. I’d like to see their effort go into building something much better than POSIX, but then they’re very unlikely to get any software.
Very few people get portability and none of the so-called portability layers out there really get it either. You need to code for compiler quirks and OS SDK quirks and then abstract. (Don’t forget all versions back to the yeardot and now abandoned compilers too.) On top of this layer there have been proof of concept native interface projects but nothing complete. The reason why is you have to code for compiler and OS quirks and abstractions and GUI and GUI design tools from the beginning. Once this is done you can do almost anything with it. Simultaneous releases are trivial.
I’m not bugged by foreign software running on Haiku. It adds to its usability and that’s all end users care about. Native is better but for a platform like Haiku which lacks 10-20+ years of applications it’s no big deal. You only need a few big applications like LibreOffice and suchlike to show the way.a bigger problem is “if I code for Haiku first will I lose marketshare on other platforms”. That’s where coding in a portable way helps. If you do it really isn’t a bother.
As we move forward cross-platform may become more dominant as businesses and nation states policies try to avoid lock in for competition and security reasons as well as social and economic reasons.
HollyB,
Ok, but you never explained why writing your own portability layer is better than using an existing open portability layer that has much more community support while solving the portability problem. There may be times when it can make sense to write a custom library, but for most developers reinventing the wheel costs a lot of redundant time & energy and also they probably wouldn’t do it as well either. Sometimes I roll my own too, but IMHO it’s not always the right answer for every developer & project.
I disagree with you on that. Unless it’s for hobby, I can’t see any reason to roll back to abandoned compilers for professional & commercial software development. Granted you may have a specific niche requirement that requires you to go back and that’s one thing, but in general I’d tend to say good riddance to unsupported compilers.
Obviously I’m not trying to tell you what’s best for you, only you can decide that. But what is your rational for selling others on writing their own portability layers when they already exist as FOSS?
Isn’t this another reason to use existing FOSS portability libraries? Most software devs aren’t going to ever target small platforms including Haiku natively, but by targeting a standard portability library there’s a good chance the portability library itself will be natively ported resulting in possibly thousands of applications becoming Haiku compatible in one go instead of porting them all one at a time.
@Alfan
I told you about three times or more and never got a professional response to the technical reasons or explanations of anyone including you. I even pointed people at Abrash’s book which is a free download. (A supplementary to the book is a website which contained a working example.) I’m not explaining again.
You really do not get the topic or the why’s and wherefore’s and I’m not spending any more time with anyone on this topic who isn’t positive and open and cannot see or appreciate the possibilities.
Nobody got the topic of cross-platform native GUI and editing kit either until a proof of concept was published as a topic. My code baked this in without hacks from day one as I said. (My code could switch between them or use a custom drawn GUI, and project it on the desktop or on a graphics surface which was also switchable between OpenGL/Direct 3D/Whatever. There’s a proof of concept out there for this too if you look hard enough.) You have to do it from day one. You cannot retrofit it later and expect to have good code.
None of the major portability libraries have any of this (quirks and features of multiple compilers and platforms and versions, or switchable native and custom drawn interfaces, or native or draw surface) baked in. Not one. They don’t even make the effort.
You can also use a codebase like this as a complete desktop environment…
As some extra history and context I actually began work on that project before the GeForce II was released and shaders become a thing. Back then you had applications like Renderman which did shaders in software or games like Quake 3 which had a primitive form of shaders but nothing like today. I remember even the most insightful of users couldn’t see beyond a few hundred shaders and 60Hz at best. Nobody took me seriously when I said they were thinking small and it would be thousands of shaders and, of course, the 60Hz myth persisted for years. Other technologies like VM’s bytecode and JIT and compile to native are now a thing and embedded in your browser. Game engines used for architectural modelling (I actually tried to start a business doing this only there was zero market at the time and all you got was WTF off everyone like I tried to get a VC friend interested in opening a TV/movie production studio locally as a community redevelopment project which he didn’t get now they’re springing up like daffodils) and now used to produce entire virtual studios actors can walk around in. The CGI versus practical debate. Cross-fertilisation between games studios and movie studios which back then was a silo’d nightmare of duplication and ignorance now everyone takes this for granted. All of this stuff has the main impetus beginning 20 years ago…
Sometimes you have to imagine the future. That’s where I get my creative buzz. I’m not the only one. There’s plenty of people around who do and some who produce extremely good work even if the dead hand of careerists and seat filler and cynics and moaners gets in the way. The ones I hate are the shitbags who are nowhere to be found when the work needing doing but who turn up with the silver plated scissors to cut the yellow ribbon like they were the singular vision who drove it all. You know the type.
Anyway, I no longer code nor am I especially interested in business projects. I spend more time watching make up videos than thinking about that.
HollyB,
All I did was ask you a simple direct question : Why is writing your own portability layer better than using an existing open source library that not only solves the portability problem but provides community support and expertise?
You always say your code is better. Well ok…but can you give even a single specific example? You frequently allude to things but refuse to back them when questioned, just like here. You can only do that so many times before people assume you are simply making things up. I really do want to give you the benefit of doubt and don’t want to assume you’re lying, but please give concrete links and examples!!! I don’t want to be mean about it, but I also think it’s 100% fair to criticize arguments lacking evidence.
Yes I agree it’s amazing how far the hardware & software evolved to CGI becoming capable of photorealism. The hardware we have today is capable of delivering an experience that our own eyes & brains can perceive as realistic.
I’ve seen what you are talking about as well. especially with project managers who take the credit for what low level coders actually came up with. I am probably biased here because I have a couple gripes about it based on personal experiences.
Yea I can’t relate to that at all.
In the latest versions Qt needs Xcb so this won´t run it.
Mmm… but what about porting Xorg as a rootless server? Like XWayland. It would be much easier because all the work is already done, and, AFAIK, it only needs to implement a handful of functions.
I’m guessing it’s because BeOS and Haiku aren’t Unix clones.
But doesn’t Haiku have a Posix compatibility layer? Without it, why do you want X11 if you wouldn’t compile X11 programs?