Hacker News new | ask | show | jobs
by jimjag 905 days ago
Yep... the move from m68k to PowerPC was pretty much the deathknell. To really be a successor to A/UX, the core code would have had to be ported to that chip, and the amount of work required was simply too expensive to be justified. I also had heard, unofficially at the time, that Apple's license for the UNIX parts of A/UX were specific to the m68k architecture, and that they would have had to renegotiate the license to even be allowed to port it to the PowerPC.

What is interesting is that after A/UX died, some alternatives did spring up, such as Yellowdog Linux (which was NOT a macOS/UNIX hybrid, but rather vanilla Linux).

It is a shame, because if Apple had continued in investing it it, we would have had MacOSX much, much earlier.

1 comments

Apple wouldn't have had "MacOS X" (as we got it) earlier. Had they kept up some Unix system they still would have been saddled with Toolbox, just running on a Unix kernel. They likely still would have produced Carbon but they'd still have a very backwards facing application API. It might be more stable thanks to privileges and process isolation but there's not necessarily a future there.

With NeXT, Apple got OpenStep which (IMHO) offered a superior programming model than Toolbox/Carbon. They also got a superior display subsystem, networking, and better first party tooling. Those are the things that made what got called "MacOS X". Just a Unix dragging Toolbox around wouldn't have gotten Apple where they are today.

A modernized version of Toolbox in the form of Carbon running as native unix applications in a preemptive multitasking system on A/UX would have been pretty good - maybe not as good as Cocoa, but good enough probably.

Is win32 fundamentally worse than Carbon or Cocoa? if so it seems to have not meaningfully effected the success of Windows.

That might have been good enough for 1998 but I don't think it would have been as workable in 2008 and later in 2018. Remember without acquiring NeXT they wouldn't have also gotten NeXT's engineers and management. Apple obviously had management issues in the early 90s. The management that led to the failures of Pink/Taligent and Copland wouldn't have suddenly built a great OS just because there was a Unix kernel underneath. Hell, the best Mac development APIs came from third parties (Symantec then MetroWerks) rather than Apple themselves.

Win32 is a bit different than Toolbox/Carbon. For one Microsoft had superior first party development offerings. The best development tools on the Mac were from third parties that were increasingly disinterested in the platform. Windows was also an order of magnitude larger of a market. An ISV suffering through the pain of Win32 had a huge TAM in front of them. They could be profitable by only reaching a small fraction. An ISV targeting the Mac platform had a much harder time breaking even to say nothing of profitability just due to the size and nature of the Mac market.

Interestingly, a group reverse-engineered the Mac Toolbox and used it for "native" ports to Unix of, among other things, PhotoShop and Illustrator.

http://preserve.mactech.com/articles/mactech/Vol.13/13.06/Ju...

The thing with raw Win32 is that only hard-core C folks use it as is.

It is similar to using Carbon.

Already in the Win16 days, anyone that cared about productivity was using C++ frameworks like OWL, Turbo Pascal, later MFC/VCL, Delphi, VB.

To your point the “Hello World” Win32 C example in Charles Petzold’s earlier editions of Programming Windows is infamous.

http://www.charlespetzold.com/blog/2014/12/The-Infamous-Wind...

Yeah, one of the things Windows 3.1 brought was message crackers and a strict mode via windowsx.h.

https://learn.microsoft.com/en-us/windows/win32/api/windowsx...

However still painful versus the C++, Delphi, VB alternatives.

Well, that's assuming a very specific, and stale, development direction; I think we would have seen a more native and natural migration to something very macOSX like. Sure, not exactly macOSX as we know it today, but something that we would have used and appreciated as much as what we now have.

What made OpenStep so useful was that it was immediately _available_, but imagine if it was used as a source for tech to be added to the continuing A/UX development, instead of basically being Step One.