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.