Virtual Machines & Binary Compatibilty

[Richard L. Hamilton]

All other things being kind of equal, I think I'd favor a host for the VM whose CPU generation was at least as new as what the guest OS would have originally run on, but as close as possible, of the available hosts.  Mostly I'd suppose an older OS could ignore features of a newer CPU that it didn't use...mostly.  But at the OS kernel level, compatibility issues that can usually be ignored at the application level (unless one attempts CPU-specific optimization) may exist. So the closer host and guest native CPU generations, IMO the better.

Curious what you mean by "hard-code the screen size" for macOS/OSX on VirtualBox (not looking for Hackintosh, would be running on a macOS Mojave or later host).  Easy macOS guest (usually the latest in the first few weeks after full release) is my main reason for Parallels, although If I get my hands on a working Snow Leopard Server DVD (or maybe polish the one I've got so it's fully readable?), I'd like to virtualize Snow Leopard too (being the last with Rosetta, and on which some rather old software can run) too - my 2007 Mac Mini is getting very old and cranky.  If I could have both Snow Leopard and Catalina (when past beta) guests on VirtualBox, I wouldn't need to spend for Parallels (although Parallels Access is nice, not that I don't have free alternatives there too); VirtualBox does best for Solaris (since there are guest extensions for it) and ok for CentOS or Ubuntu (the other guests I mainly run), and decent even for OS's like Haiku (open source BeOS successor), ReactOS (open source OS aiming for Windows compatibility), and even Syllable and I think Kolibri (doesn't do Plan 9 nicely though, that one's disk driver is more ancient than anything VirtualBox handles well).  So there's not much that runs on x86/x86-64 that I've tried that VirtualBox can't handle, give or take pain getting macOS working on it.  I still think Parallels does Windows a bit nicer than VirtualBox, though.

But for really weird (IBM and Burroughs mainframes, PDP-11, Apollo workstation), it still takes emulators, since their CPUs are so different. I think I collect OS's.  That, or OD-ing on geeky nostalgia. :-)

> On Sep 1, 2019, at 01:27, Bjarne D Mathiesen <macintosh at mathiesen.info> wrote:
> 
> Richard L. Hamilton wrote:
>> I don't know how it is now, but macOS/OS X clients on VirtualBox used to be a real pain to set up, starting with an ancient version of OS X and then updating to the desired level, with fingers crossed. Parallels (yearly subscription fee) is much better, but I know it does enforce the Server requirement (see next paragraph).
> 
> I've done a clean install from scratch of 10.13.x in VirtualBox.
> The only limitation is, that you'll have to hard-code the screen-size.
> It's also possible to port this to a WinTel 10 machine.
> 
> The reason I'm interested in using a VM for 10.3.6 is, that I'm
> currently making my toolchain universal on a 32 bit Core Duo in order to
> be able to rsync this to my 64 bit Core 2 Duo because
> LibcxxOnOlderSystems currently is sevely broken ... and it's taking
> 🤬ages🤬. Also, the MacPro has 12 CPU cores / 24 threads, and it's
> blisteringly fast when compiling clang & llvm et al.
> 
> Alternatively, I could use my Core i7 MacBook Pro if that's a better
> choice CPU vise ?!?
> 
> -- 
> Bjarne D Mathiesen
> Korsør ; Danmark ; Europa
> ----------------------------------------------------------------------
> denne besked er skrevet i et (næsten) M$-frit miljø
> MacOS X 10.13.6 High Sierra :
>   17" 2011 MacBook Pro ; 2.8GHz Intel Core i7 ; 16GB 1067MHz DDR3
>   2012 Mac Pro ; 2 x 3.46GHz 6-Core Xeon ; 48GB
> MacOS X 10.6.8 Snow Leopard :
>   Mac Mini ; 2GHz Core 2 Duo (64 bit) ; 4GB (3GB actual) 667MHz
>   Mac Mini ; 1.83GHz Core Duo (32 bit) ; 2GB 667Mhz
>