4 ms·

In the 90’s I worked for a company whose C/C++ code needed to run on at least 7 different Unix versions: SunOS, Solaris, two different AIX versions, HP-UX, DGUX

In the 90’s I worked for a company whose C/C++ code needed to run on at least 7 different Unix versions: SunOS, Solaris, two different AIX versions, HP-UX, DGUX, and whatever Motorola’s Unix was. The slogan around the office was, “There is no such thing as portable code, just ported code.”

toolslive 5y ago
A bit more than a decade ago, I was on the receiving end of a C level (CEO/CTO that is) decision to target Linux, BSD, Solaris and ... Windows, for a C++ application. I think I can imagine your pain.
drewg123 5y ago
In the 2000s, I worked for a company that shipped an HPC NIC (think precursor to infiniband). We had userspace software AND DEVICE DRVIVERS that supported Linux, FreeBSD, Solaris, DEC OSF/1 (Tru64), AIX, Windows and Mac OSX. The device driver code had a shared component that supported the hardware, via an OS abstraction layer over top of the various OS specific ways to do things. The driver did fun things, like pin userspace memory for RDMA, which was often outside of supported driver interfaces. The Windows, and the closed source commercial UNIXes were a PITA to bring up initially (AIX was the WORST). But once supported, they were easy to maintain because the interfaces never changed. Linux was fairly easy to write, but a PITA to maintain because the kernel interfaces changed so much. We had a configure style shell script to probe the kernel headers and detect how many args certain functions took on this particular linux version, etc. That script by itself was larger than the entire FreeBSD driver. (and FreeBSD was as easy as linux to write, and as easy as a commercial UNIX to maintain, since the interfaces we used didn't change). One interesting thing that fell out of it is that we used ioctl interfaces everywhere (even Windows and MacOS). Since this was an HPC device, latency was critical and the Mac ioctl routines were painfully slow (like 4x slower than Linux/FreeBSD on the same hardware). So I tried switching to the Mach based IOKit IPC that Apple wants you to use, and that was twice as slow as ioctls!

toolslive 5y ago

A bit more than a decade ago, I was on the receiving end of a C level (CEO/CTO that is) decision to target Linux, BSD, Solaris and ... Windows, for a C++ application. I think I can imagine your pain.

drewg123 5y ago

In the 2000s, I worked for a company that shipped an HPC NIC (think precursor to infiniband). We had userspace software AND DEVICE DRVIVERS that supported Linux, FreeBSD, Solaris, DEC OSF/1 (Tru64), AIX, Windows and Mac OSX. The device driver code had a shared component that supported the hardware, via an OS abstraction layer over top of the various OS specific ways to do things. The driver did fun things, like pin userspace memory for RDMA, which was often outside of supported driver interfaces. The Windows, and the closed source commercial UNIXes were a PITA to bring up initially (AIX was the WORST). But once supported, they were easy to maintain because the interfaces never changed. Linux was fairly easy to write, but a PITA to maintain because the kernel interfaces changed so much. We had a configure style shell script to probe the kernel headers and detect how many args certain functions took on this particular linux version, etc. That script by itself was larger than the entire FreeBSD driver. (and FreeBSD was as easy as linux to write, and as easy as a commercial UNIX to maintain, since the interfaces we used didn't change). One interesting thing that fell out of it is that we used ioctl interfaces everywhere (even Windows and MacOS). Since this was an HPC device, latency was critical and the Mac ioctl routines were painfully slow (like 4x slower than Linux/FreeBSD on the same hardware). So I tried switching to the Mach based IOKit IPC that Apple wants you to use, and that was twice as slow as ioctls!