But NEXTSTEP3.3J on VMWare Fusion 3.0 is has a problem. It won’t find root device in reboot after the installation. But you can run a kernel from floppy disk with root device directive.
Boot: fd()mach_kernel rootdev=hd0a
but still PS2 driver is not so good.

Or, you can quit software installer, at the final stage of the installation, it you give Terminal access.

To resolve change a single line in the VMWare image (which is actually a hidden directory, use Terminal.app on MacOSX and cd into it). In IMAGENAME.vmx (where IMAGENAME is the name of your VMWare image) there is the line

ethernet0.virtualDev = “e1000″

just delete it and vmxnet loads happily. This should only be needed if you import an old VMWare image (pre 4.5) into a newer VM and you have used the AMD Network driver previously.

I just tried to get NS 3.3 up and running on VMWare Fusion 2.01 – everything seems to work great, except the network. On booting it gives me a config space error in the boot log for the VMXNet driver (1.3 used) and aborts loading the driver. Had anyone the same problem and solved it?

It’s worth noting that you’ll probably want to install the Y2K patch from Apple (which takes you to 3.3p3), so that your VM doesn’t think it’s 1994…

My only snag now is that I’ve lost my copy of the Developer CD!

All of the problem areas: display, mouse, network, and sound are working. There are clearly some challenges in completing the installation. For example getting the VMMouse driver installed while the defective default driver is still running is one example. There are also several “non-obvious” bits of information that are needed, such as the need to change the “virtual network host adapter” to match the driver specifically written for NS. In the process I have bundled all of the needed drivers and packages (including the final NS updates) into a single CD iso for convenience of installation. I am guessing that with a bit of work it might even be possible to modify the initial installation data (on floppy images) to circumvent the need to post-install the needed drivers — or at least make it easier.

One of the best aspects of running NS on modern hardware is that it performs (at least on VMWare) *much* better (meaning faster) than it ever did back in 1995… on either black or white hardware. The use of networking and NFS makes the 2 GB limit on the installation disk space much less important for real world applications. NS of doesn’t care about the size of the disk space on NFS mounts, and the network setup is very clean with the NFSManager application . NFS is also the most practical way to get data in and out of the virtual NS machine. It has been fun re-learning the amazing (still) advanced features of NS. I also have an entirely practical need in reviving an old but still useful NS application that I helped develop.

I have documented my path to installation, and I would be glad to share this with interested folks (along with any assembled open-source/access drivers, etc.). With Jonathan’s help this can probably be arranged.

A comment to David on the display darkness — the video adapter and driver on NS needs to be matched with the color depth actually running on your host machine. I noticed this color distortion affect with one installation that I made. The color depth cannot (afaik) be changed on the NS system, so it must be changed to match on the host system. When I corrected the color depth of the Linux host system (to:8/8/8-32) the problem went away. I would guess that your Windows system is by default using the correct color depth to match the virtual machine.