Is it possible to reverse engineer BeOS to add into Haiku?

There’s WINE project that is going very smoothly.

I don’t see any project that is trying to reverse-engineer BeOS R5. Of course, there aren’t many infos circulating that often on Haiku these days.

Forgive me if I’m wrong but I hope Haiku could make use of reverse-engineering efforts to make Haiku complete.

BeOS is several years more advanced than Microsoft OSes at that time. Too bad that it is dead.

I’m guessing you don’t already realize that Haiku runs most of BeOS R5 software already without any need to recompile it.

Wow I’m back and I didn’t really intend to mock Haiku or BeOS in my previous entries here. Forgive my unintended rudeness. Maybe there are insufficient information about Haiku and BeOS today, so people like me are prone to misunderstand what this project called Haiku is.

There is some helpful information on Wikipedia :slight_smile:

http://en.wikipedia.org/wiki/Haiku_(operating_system)#Compatibility_with_BeOS

Actually, there is no need to reverse-engineer BeOS. There is almost nothing in BeOS that can benefit Haiku.

Firstly, basic features of Haiku are almost complete. There are some problems with drivers and several codecs (namely, “Indeo”), but they are irrelevant to Haiku at this point; besides, Haiku announced dropping of Indeo video codec.

Secondly, BeOS is dead for 8 years now. It’s true that in the end of 1990-s it was way ahead of other OSes, but is it still true now? I’m not sure that design decisions made in mid-1990-s are still strong enough to hold today. Maybe dropping BeOS and developing Haiku from scratch should be seen as opportunity to re-design the OS with modern technologies in mind? (Which Haiku developers perfectly did).

Thirdly, porting applications is a woe. Instead of developing an application from the basics, porter must deeply analyze the application she intends to port, adopt it to another environment (which is almost always a complex task) and rewrite 30%-60% of application’s code, usually requiring 60%-100% of the time for developing this application from scratch. Along with the bugs of development, the porter drags also the bugs of original application; therefore the quality of ports can’t be better then of original application. (There are some exceptions, though, but in general this is the case).

Reverse-engineer BeOS and use this knowledge for Haiku actually means porting parts of BeOS into Haiku. With all the troubles mentioned earlier: deep analysis of BeOS (for which you don’t have source codes, therefore the efforts will be even greater), adopting the code to existing Haiku release, recompiling and dragging all the poor decisions and bugs that BeOS’ developers made. (Who said that they never erred? One of the problems with porting Mozilla to BeOS was that BeOS didn’t deal effectively with lots of requests to allocate and free small chunks of memory).

As you can see, reverse-engineering of BeOS is useless.

Well in many ways Haiku is already a reverse engineered BeOS. We have a compatible API when using gcc 2, and many of the servers and kits speak the same protocols from BeOS because they were indeed reverse engineered.

But Alex Hitech makes a good point that a lot of aspects of BeOS are no longer useful, and Haiku has moved forward in several interesting ways: vector icons, GUI layout API, more modern GUI, kernel improvements, better built-in applications, etc.

But of course the core of what made BeOS great is still in Haiku, because after all BeOS did inspire the creation of Haiku.

Well, reverse engineering BeOS is almost usesell.

BTW I would ask Palm - that switched to Linux for webOS - to release their Be codes under an open source license (GPLv3, IMHO)…

LOL, GPL3? Most of Haiku is licensed under the MIT license, so I don’t think that’s such a good idea…

Please… must this be re-hashed so often?

  1. Palm doesn’t own the BeOS code, ACCESS does.

  2. They’ve already indicated that the effort it would take to release the code is way more expensive than it would ever be worth. There are even large portions of the code that they cannot legally release, making it even more complicated, costly, and useless.

[quote=umccullough]Please… must this be re-hashed so often?

  1. Palm doesn’t own the BeOS code, ACCESS does.
    [/quote]
    Sorry, I didn’t know it.

Uhm, sounds like the same situation of IBM with OS/2…
VERY BAD.

I hope that this mistakes let them understand why closed source is bad: when the focus of licensing is not the evolution, the (innovative) product can die.

Marco Ravich

Forward Agency

In progress we (always) trust.