[webwielder2]

I don't know the technical details of why it wasn't viable, and wouldn't understand them if I did, but every time I see something about A/UX, I say "Apple, you spent a decade trying to come up with a modern successor to System 6/7, and nearly died doing so, and all along you had this in the labs—and shipping?!"

[retrac]

I think it was the price more than anything. Both of the software license (not cheap!) and also the hardware requirements. It's something that doesn't come up much anymore but RAM used to be one of the main limits of a personal computer. A/UX required a high-end Mac at the time. And Macs were already high-end PCs. And UNIX wanted a lot of RAM. 16 MB was barely comfortable in the early 90s. This was a time when when typical entry-level Macs were still selling with 2 - 4 MB sometimes and a full 32 MB upgrade would cost twice as much as the base model.

In short, basically the same reasons we didn't all run SCO UNIX or whatever on our IBM PCs. Much the same dynamic for why the Windows NT kernel took so long to come down to home computers (in Windows XP finally). Even OS X's RAM requirements would inhibit its uptake for a few years. "Real" operating systems were too big for the small computers of the 1980s and even early 1990s.

[spijdar]

Tangential to AU/X and licensing costs, I think this is why OS X was something like a "from scratch" recreation of NeXTSTEP instead of being a straight port. They replaced the AT&T licensed UNIX core with a new open source one derived from the 386BSD forks (and DEC's OSF/1 mach fork), and replaced the display postscript WindowServer with Quartz, both for licensing cost and performance reasons.

At least, that's my impression from comparing NeXTSTEP and early OS X. A lot of the "base layer" was totally replaced, including those troublesome licensed bits.

[pjmlp]

You forgot there was still OpenSTEP and the collaboration with Sun, which ended up having an influence on a language being designed at the time called Oak.

Early versions of OS X were still based on OpenSTEP, thus able to run on top of Windows as well.

[spijdar]

OpenStep was still based on Mach 2 and (encumbered) 4.3BSD.

OS X Server 1.0 was very OpenStep like yes, it used the old Display Postscript server and was more compatible with next/openstep (I think the display servers were similar enough you could forward OpenSTEP software to a OS X Server 1.0 windowserver), but I believe it was based on the un-encumbered XNU, and couldn't directly run OpenSTEP programs due to this impedance. I'm fairly certain Rhapsody is the same, using the OSFMK kernel and 4.4BSD "lite".

At least, I don't think OS X Server 1.0 software would have worked on the OpenSTEP for Enterprise stuff?

[lukeh]

Rhapsody was still pre-Mk but had 4.4BSD userland. It could run OPENSTEP binaries if you copied the shared libraries over, from memory one of the ex-NeXT engineers did this for fun.

[spijdar]

Cool :) this is all before my time but I've got a few Sun boxes running various old BSDs and Nextstep 3.3.

I've always been kind of curious how hard it'd be to get NetBSD's COMPAT_DARWIN and COMPAT_MACH to run the next/openstep userland...

[pjmlp]

That much I don't recall, maybe, not sure.

[cat199]

I had thought NeXTStep was always BSD based?

Still might have paid the unix license; this was pre AT&T vs USL, but, thought nextstep was basically CMU mach (which itself was BSD+Mach) + the NextStep frameworks/ui

[spijdar]

NeXTSTEP/OpenSTEP were based on 4.3BSD/4.4BSD(not-lite) and required a license from AT&T to distribute. I assume that, to be legally safe, they would have scrapped that code entirely and replaced it with 4.4BSD lite, pulling in code from 4.4BSD lite forks like FreeBSD and NetBSD.

[pasc1878]

Yes the apis eg cocoa are the openstep apis and the terminal tools under openstep were BSD

[asveikau]

It also probably has to do with personalities, and who did what. NeXT was the Jobs thing. So Jobs came back, and they based things on NeXT.

[pjmlp]

While killing almost everything else.

The video of the audience heat he is taking for those decisions and how he goes justifying his decisions is worth watching for anyone that needs to go through something similar.

[perardi]

Though he did notably compromise on Carbon. The early plan was Cocoa/App Kit all the way, which meant a fundamental rewrite of all the important applications, namely Adobe and Microsoft stuff.

Which would not have flown.

[pjmlp]

Sean Parent was key on that whole process, given his role at Adobe and Apple, hear his interviews here,

https://adspthepodcast.com/

[vintagedave]

Do you have a link to that video?

[mrpippy]

https://archive.org/details/wwdc-1997-fireside-chat-steve-jo...

[ncmncm]

I ran A/UX comfortably in 8MB, on an SE/30.

8MB was a lot of RAM. Most people were running windos in 2MB or less, at the time.

[icedchai]

My understanding is the "Mac" side of A/UX still had no memory protection. It still had all the stability problems plaguing System 7, unlike modern macOS / OS/X

[hedgehog]

This is true and was not easily fixable with existing applications. They added a kernel supporting memory protection in the move to PowerPC but it wasn't until Carbon that apps really benefited from that. Carbon was a transitional API between classic MacOS and OS X that made it feasible to port apps to run on both, but conceivably they could have done something similar without the switch to Darwin.

[classichasclass]

This is correct, but as a practical matter, since the Finder was just another process on A/UX everything else (including X clients, if any) could keep running. Unfortunately this would kill all your Mac apps, including your X server if you were running it through MacX.

[wmf]

That's no worse than Classic aka the Blue Box. In retrospect it seems like Carbon on A/UX should have been possible.

[hedgehog]

After studying the history a bit it seems to me the reasons were organizational more than technical. Jobs brought his team back with him and they built on what they were familiar with. With better management the existing nanokernel-based MacOS could probably have been evolved similar to what MS did with NT.

[pasc1878]

Nt is not a evolution of dos.

A similar issue you need a new kernel for protected memory etc.

Apple did make attempts see Taligent

[hedgehog]

Exactly. MS rehosted win16 apps on top of a new kernel, ported the UI, and encouraged developers to migrate code to win32. Apple had pieces of a similar transition with the transition to PPC but failed to execute, maybe because they were betting on different attempts to rewrite everything from scratch.

[pjmlp]

Win16 and NT branch don't share almost anything.

Probably the only port was Win32s, which was a subset of Win32 backported to Win16.

Win16 stuff runned on a VM like environment, WOW.

https://en.m.wikipedia.org/wiki/Windows_on_Windows

[hedgehog]

I'll admit I haven't seen the NT source but from a user perspective NT's UI (widgets, progman, etc) looked and functioned near identically to Windows 3 so I've always thought those bits were ported over. I'm aware most everything under that was replaced. To my eye that was one step in a well-executed evolution up from legacy Windows towards the eventual convergence in XP.

[temac]

Yes the GUI was mostly ported from consumer Windows to NT. First the 3.1 GUI, then 95.