I've heard many answers over the years:
Mach is a microkernel, they are easier to port
NeXT never made their own hardware so they designed it that way from the start
It contained 'very little assembly'
I've heard many answers over the years:
Mach is a microkernel, they are easier to port
NeXT never made their own hardware so they designed it that way from the start
It contained 'very little assembly'
When I think NeXT, I think the NeXTcube (1990-1993) [0], which apparently also had a predecessor in the NeXT Computer (1988-1991) [1]. NeXT made their own hardware for a solid chunk (nearly half) of their lifespan, and NeXTSTEP was originally released with the NeXT Computer [2]. It didn't even support CPU architectures other than the Motorola 68k series until 1993, around the demise of the NeXTcube! I think its ultimate portability probably has more to do with being a UNIX at its core (so a battle-tested design written in somewhat portable C) plus a user environment written in a higher-level, easier to port language (Objective-C).
[0]: https://en.wikipedia.org/wiki/NeXTcube [1]: https://en.wikipedia.org/wiki/NeXT_Computer [2]: https://en.wikipedia.org/wiki/NeXTSTEP
Though fine in 1988, NeXT's own hardware was rather under-powered for the early 90's. Their main competitor, Sun, was transitioning to their own RISC architecture (SPARC) after originally being on 68K. DEC was coming out with the Alpha. HP had moved to PA RISC. Though I digress, it's too bad NeXT never ran on the Alpha! That would've been a killer 90's setup.
The Mach-as-microkernel thing couldn't have helped portability. The Mach task, port, thread and pager abstractions seem like they'd be difficult to port, but I could be wrong.
I read at the time that NeXTStep the GUI ran faster on Solaris than on Mach, because pipes and sockets were faster than Mach ports. So I'll believe the very little assembly.
I suspect that Mach-O file format had something to do with the portability, you can put arbitrary sections in it. Some NeXT games kept image and sound "files" in a single huge Mach-O executable.
The task/port/thread/pagers are primitives that let Mach run some other OS executables, not made it easy to port Mach to other hardware. There were papers about getting MSDOS and VMS executables to run in Mach tasks. Some startup was making a system to run (pre-OSX) Mac executables.
After the early days, Solaris did improve, but I think that was because ideas / pieces of BSD (from SunOS) were put back into the OS.
I don't think Solaris pipes / sockets performed better than Mach.
"Mach 3 (Figure B.1) moves the BSD code outside of the kernel, leaving a much smaller microkernel. This system implements only basic Mach features in the kernel; all UNIX-specific code has been evicted to run in user-mode servers. Excluding UNIX-specific code from the kernel allows replacement of BSD with another operating system or the simultaneous execution of multiple operating-system interfaces on top of the microkernel. In addition to BSD, user-mode implementations have been developed for DOS, the Macintosh operating system, and OSF/1. This approach has similarities to the virtual-machine concept, but the virtual machine is defined by software (the Mach kernel interface), rather than by hardware."
The BSD stuff was kind of bolted on. Very uneasy marriage there.
At one point DEC had a 2 Mach task system that could run VMS processes, but I'm pretty sure that was Mach 3.0 based.
That is to say, Mach 2.0 wasn't as advanced in portability, and the "portability" targeted was different.
« microkernels are easier to port » is not a thing.
NeXT did make their own hardware, it was 680x0-based and it was nicer to use than the x86 PC shitboxes it ran on when they stopped making hardware.
« very little assembly » is closest to the truth. NeXTstep and OpenStep were written almost entirely in C and Objective-C and compiled using the GNU toolchain. NeXT was always a hybrid of Unix userspace on top of a Mach microkernel. It’s just not that hard to port a Unixlike OS to another CPU architecture. It’s literally been done since the 1970’s.
However, it is much more difficult to port the OS and maintain binary compatibility with apps created for the previous CPU architecture, which has always been Apple’s special sauce since the original PowerPC Macs.
Obv writing in a portable language and on a portable microkernel helps.