Application Level API Incompatibilities with BeOS

Author:: Ingo Weinhold

Haiku R1 (x86) was designed and is being implemented to be binary and source compatible with applications written for BeOS R5 (x86) to a large extent, but not the other way around. In some cases we deliberately broke source compatibility while at the same time maintaining binary compatibility. Here are some specific examples:

The "be" header path is gone - it's called "os" in Haiku; since it is always part of the default header search path anyway, you can always just remove it to let your software compile on both platforms, ie. replace:
```
#include <be/interface/View.h>
```
with:
```
#include <interface/View.h>
```
or rather use the preferred method of omitting the first part and use:
```
#include <View.h>
```

BeOS contains a deprecated add-ons/TrackerAddons.h header, and a header called add-ons/TrackerAddOns.h - Haiku only contains the latter.
Likewise, you'll find support/byteorder.h and support/ByteOrder.h in BeOS; Haiku only has ByteOrder.h.
If you have subclassed BString and if you are using its _privateData member, you might notice that it has been renamed to fPrivateData . However, it's use is deprecated, and it might even be made private in the future.
The undocumented functions defined in Alias.h from the storage kit are not implemented.
The private Device Map API (used by OpenTracker) has been replaced by a different API (Disk Device API).
The application debugging interface is conceptually similar, but nevertheless source and binary incompatible.
The file system API has changed; file systems that worked on BeOS will no longer work on Haiku.
In several places we also dropped compatibility support for older BeOS versions (PR2, R3, R4), which BeOS R5 still featured.

The Haiku Book pre-R1 - Application Level API Incompatibilities with BeOS
Generated on 14 Feb 2008