OSNews

I've read BeOS source code and have analyzed the structure, and I assure you, it's not that big of a deal to come up with something more robust! Why is that? Error checking! BeOS does a poor job in handling when it hits limits, and is fond of saying, "I give up! You should never have gotten here anyway, so I'm going to merely pop up a debug message instead of actually handling the error!" and "Message? I no longer have room for messages! I think I'll just drop this one, and who will care?" while other parts of the system will wait for the message that never comes.

BeOS has hard-coded limits, which isn't a problem by itself. However, it doesn't fail in a graceful way when you hit them (most people in their normal usage, but I don't use things the way most people do) and it has problems where some API calls that can fail have no manner of returning an error code *at all* which is a real problem, and some cases where it does return something, it dumps you into the debugger instead of returning the error code to the program. In other cases, the system simply doesn't validate the parameters passed into the kernel API, which leads to some interesting things a user level program can do readily. For example, there's nothing whatsoever that stops any process from stopping any thread, or getting access to and releasing another program's shared memory at will.

If Haiku merely validated that one process was accessing something it wasn't supposed to, that would go far towards making it better than BeOS/Zeta for stability. BeOS/Zeta would be incredibly *easy* for malware to target, but there simply aren't enough to make it worthwhile.