Porting: What does it entail and why is it so hard

Hello, I am a big fan of Haiku because it’s fast and it is looking at computing in a new way, but without a variety of good programs, it doesn’t really have any use for me. If it had Audacity or Kdenlive I could use it for just recording or video editing, but it doesn’t (to my knowledge). My question is: What does it take to port a program from linux or windows and what makes it so hard? There are programs that have “OS independent source code.” Are they making that up, or can it really work on all OS’s.

Please explain it in laymen’s terms because I am still learning.


Programmers like many professions rely a lot on re-using the hard work of other people who’ve gone before them. Not everything can be re-used but a lot of things can. For example, lots of different programs need to decode JPEG data into pixels that make up the recognisable picture. So very soon after the dawn of electronic computers there came into existence libraries of program code. At first they’d literally be written libraries on paper, that you could copy from, but quickly it became easier to store the code in some machine-readable form.

After a little while, some code was being used so much that programmers would always leave it on the computer. Even if the next person to use it was doing something quite different, he’d be sure to want that code. For example, perhaps the computer has a teletype attached, and this library code can print a message on the teletype. Well, even if your program calculates payroll and the next one is for estimating rocket thrust, they both want to print results. This sort of especially general purpose library code evolved into the first operating systems.

Once the libraries cease to be copied by hand from a book, programmers don’t need to actually read all the library code to use it. Instead they can learn the “application programming interface” or API, that is the names of functions, what parameters they take, and what they do. So now instead of learning precisely how a particular model of computer worked in hardware, a programmer only needed to learn the API. But the API would be different on computers from different manufacturers, in different models, and even on individual computers which had been customised, to suit that computer or sometimes just on a whim.

To make a program written for Windows work on Haiku the source code of the program needs to be adjusted to use APIs which are available on Haiku, whereas probably it will be using APIs for Windows. Sometimes this might just mean changing a name, or re-organising some parameters, but often it will mean extensive changes, even re-thinking how part of the program works.

Some operating systems have APIs in common, a program written for these APIs can be compiled to work on all the operating systems that implement the APIs, subject of course to any bugs in the program or in the operating systems themselves. For example, all the functions described at the end of Kernighan and Ritchie’s “The C programming language” are available with the C compiler on any modern operating system. Haiku implements most of the APIs described by the POSIX standards, which are the baseline of a UNIX® brand operating system, and you can also obtain a free implementation of POSIX to use with Windows. So a program which uses only the standard C library, and POSIX, can be compiled (using the source code) to run on the vast majority of computers in use today.

Many modern APIs like POSIX are public standards. Anyone can obtain precise documents for the API and provide their own library which implements it. There are popular standard APIs for parsing XML documents, communicating over TCP/IP networks, rendering 3D graphics and so on. In addition there are many de facto standards, the Win32 API although not entirely documented, is widely understood, and so in addition to Windows, it is also implemented partially by WINE.

Often though, even if there is a published standard, a particular API might not be included in the operating system you use, for example neither Haiku nor Windows implement the Xlib API described in manual 2 of the X Window System documentation. This means that programs written for Xlib, or for libraries which themselves require Xlib, won’t work directly. Sometimes you can download a third party program or library to work around this.

So, to make large sophisticated programs like Firefox “OS independent” the most common strategy is abstraction. That is, all the code which will have to be changed to run on a very different OS like Haiku is as much as possible contained in a small part of the program. Thus to “port” Firefox to Haiku is a much smaller task than if the whole thing had been written to be “non-portable” that is, to use the APIs of the operating system it is aimed at without regard to how things might be different on another OS.

The work to port such a program depends upon which features in Haiku are different, which are missing altogether and must be implemented and which are just the same as on other systems where Firefox already works. For example, the Haiku project has gone to some lengths to implement more POSIX APIs than BeOS did, so that programs & libraries which use these APIs can be more easily ported to Haiku.

Wow, that was very informative.

I have a few questions:
Is there an advantage to having one API over another? If there wasn’t, wouldn’t you want to have another OS’s so you could use their programs?

Is there a way to automate the conversion from one API to another, to a certain extent?

When a new version of an older OS comes out (like Ubuntu 8.04 to 8.10) and it uses different programs, does that mean they changed the API?

Is it possible to have multiple API’s? Like could you have an Ubuntu 8.10 layer allowing you to use their programs? It’s entirely open source, so you would think it wouldn’t be too hard.

Thanks a ton,

Yes there are probably advantages but also disadvantages so it’s better to choose an OS you like and want to use.

No automate what I know of but there are some tricks one can use and specially the one writing the code, do it as Firefox, and/or use libraries that are written in C. an example are SDL lib that a lot of games uses.

Having multi API’s are not a good solution (not one I would support) it would take a lot of work to make and then maintain.

Usually a Port doesn’t take advantages of an OS special futures and that removes some of the nice things that OS have over other.

Hi Lexen,

As NoHaikuForMe so nicely explained, many APIs are standards that are common to many operating systems, including Linux and Haiku. Most of the code in an application like Audacity will use functions that are available on Haiku.

There is one big exception to this nice standardisation - any graphical user interface code is usually OS-specific. I’m not sure why it is, but there aren’t really any nice standard APIs for GUI stuff - probably because graphical interfaces are a relatively recent innovation in the world of computers. Old APIs like the one in win32 are also quite clumsy to use for graphical things, the BeOS one is designed much better.

So why do some graphical applications claim to be cross-platform? Usually because they use a 3rd party library to do the graphics. This 3rd party library has a common API, but the library itself needs porting to various OSes, so when an application tells the library to draw a toolbar, the library can tell the OS to do that using the OS-specific API. The advantage of this approach is that once the third party library has been ported any applications that use it should be fairly simple to get working.

Audacity, for example, uses the wxWidgets library (www.wxwidgets.org).

Porting stuff is probably easier than writing applications from scratch, but I do have a bit of a moral objection to the idea of “cross-platform” graphical applications. I think a platform should have a strong individual identity and making an application work like a Haiku application is more involved than just ensuring the controls look like controls from Haiku apps. Really I think applications should be designed from the ground up with Haiku principles in mind - simplicity, responsiveness, usability.

Okay, I hear what you are all saying and it has informed me a ton.

I love the fact that you guys are making it from scratch. It really helps everything in the long run. But is it really necessary to throw out everything? The code is different, but why not try to utilize the visual or audio done by the open source movement? I am a musician and I would love to do the audio work for you, but there are people out there who already did a better job then I could do and using their audio won’t lead to some legacy problem, you would just use new audio. The same is true for the visual aspects, but in a different way.

I guess that what I am saying is that I know that an OS specific program would run better, but a port would be a lot more refined. It would also make life easier for all the programmers involved.

Thanks again,

Can you nail one method down that is better than the rest?

The problem with FOSS is that people tend to reinvent the wheel because they believe there’s a better way (at least, that’s what I hope they’re thinking).

There isn’t one solution out there at this point, there are many.

One of the biggest problem with “reusing” stuff that’s out there is that Haiku developers avoid including GPL licensed code in their source tree, and if you look around, you’ll find that a lot of the FOSS software out there is using it. So, as you might imagine, it’s not always a technical decision making process.

The real BeOS way (that i have yet to see) for the porting problem would be to use BeOS/Haiku “translator”. After all, it’s a static data problem. We would end up with C++,Java,BASIC etc… translators.

They have already been used extensivly for text, image etc… but not for source code. Even if many different coding guide line exist on one API/Language, it’s not impossible to code a tranlator (expect it to be bigger than average ones).

To give an idea of how complex this might be, imagine the number of file in a project might be different in the original and the final port. Not to mention that depending on the complexity of the translator, resulting code might look as cryptic as a assembler decompile if language are too far appart (should be lot more natural between 2 c++ api).