Other *NIX apps

[Jason Stephenson]

Kenneth E. Lussier wrote:
> Hi All,
> 
> I know that all *NIX versions (Solaris, HPUX, Linux, etc.) have their
> own little nuances, but deep down (and in some cases, really, *REALLY*
> deep down) they are supposedly all the same. This makes me wonder: Is it
> possible to run an old Solaris-based program on a Linux system? Just how
> interoperable are all of these different *NIX system? Just some fodder
> for discussion....


That depends.

Marc assumes you're talking about binary compatibility. It's possible 
among certain architectures and OS environments, but not very commonly 
used. FreeBSD'ers seem to use it the most to run those few Linux apps 
that we can't get native versions of, and of course, there's WINE, but 
that's a different question.

Supposedly, there is this IBCS standard that if you have two operating 
systems on x86-architecture that conform to the standard, you can just 
run the app on either OS. I'm not sure what configuration or library 
mangling you'd have to do, or if it even works. I've only heard about 
it. I've never seen it working in practice.

In the case of source code, most applications are easily switched from 
one modern UNIX to another. However, there are some issues that always 
come up.

I've run into issues with system calls not always working the same from 
one OS to another. poll() and sendfile() are two that come to mind 
because I've had to deal with them recently. As an example, I ran into 
an issue when working on KMail where some code that worked perfectly 
fine on a GNU/Linux machine would hang under certain circumstances when 
run on FreeBSD. I traced it down to the poll() system call. It has (or 
at least had) different return value semantics on FreeBSD and Linux.

Then, of course, there are compiler issues. HP-UX doesn't ship with a 
"working" compiler. Well, it's an old-style K&R compiler. To get an 
ANSI-compatible compiler on HP-UX, you have to pay extra. Header files 
often differ, too. POSIX had done alot to aid software portability, but 
it isn't a panacea.

Beyond that are library issues, such as they get put in different places 
by different UNIX vendors, and some libraries that you might expect to 
be there (at least a GNU/Linux user might expect them to be there), just 
aren't.

Well, I guess you really weren't asking about source code portability 
after all, but being a programmer, I can't help thinking about it.

Cheers,
Jason