NeXTSTEP To Mac OS X

*no comment* writes "the folks over at OSviews have a nicely done article that explains the evolution of NeXTSTEP into Mac OS X. 'With the beginning of 1996, Apple realized that with the next generation PC's running Windows NT to be released within the decade, they would need a new, modern operating system to run on their machines. ... Amongst Apple's other options were to license Solaris from Sun, NT from Microsoft, or to purchase a small net services company called NeXT. Apple chose the latter.'" OSNews had another nice Mac-oriented look at NeXTSTEP last year; the Wikipedia entry is also worth looking through.

Comments

Screenshots

[LiNKz]

For awhile I was in search of the x86 version of Apple's Rhapsody DR2. Finally after speaking to a guy who created a page of screenshots, I found a beta software trading forum and grabbed an ISO of it. This guy also has screenshots of OpenStep too.. He's been running this site for years and its given me quite a nice look into the past. Its interesting never the less :)

Yeah, right...

[El]

And of course, the choice of NeXTStep had nothing to do with Next also being owned by Steve Jobs!

NeXT background

[close_wait]

purchase a small net services company called NeXT

They fail to mention that NeXT was the company set up by Steve Jobs after he left apple, with the mission to produce a next-generation Mac-like workstation with an OS called NeXTstep, based on mach, BSD and display Postscript

Re:BeOS

[mrchaotica]

It means that I, for one, would not be using a Mac right now. The UNIX-ness is important to me.

I think they should have bought both, though -- maybe they would have come out with Spotlight sooner.

The choice.

[juuri]

BeOS was a nonstarter.

The printing was horrid.

The development environment was awful, contrasted to the robust tools available on NeXTSTEP at the time.

NeXT had real mult-user capability. BeOS was only brought in as a bargaining chip and to entice Jobs to come onboard. BeOS at the time was really impressive on a Mac, especially if you couldn't stomach MacOS... but I ran BeOS @work and NeXTSTEP @home, the choice was readily apparent to people who actually used both systems.

Re:BeOS

[Kenja]

"I think the Mac platform would eb even further ahead if they went with Be."

As a licensed BeOS devloper who still has a Rev2 BeBox sitting around I must say you're wrong. BeOS was NEVER as far along as Nextstep was even when taking into acount the hardware transition. BeOS had poor to no network or print servies. We where promissed that they would be released "real soon now" for years. Granted what Be had was better then the same stuff on Next. But Be lacked a lot of very important stuff.

The NeXT big thing

[RealProgrammer]

I first used NeXTStep in about 1989, when NeXT was still a hardware company.

NeXT made a big splash in the trade magazines by using standard UNIX industry hardware like the 680x0 processor, standard RAM, SCSI drives, etc. They did some neat stuff like having a 600M rewritable optical disk, unheard of capacity at the time. Unfortunately, no one else followed suit.

The big thing was the apps, though. Everything was done in Postscript, and there were several desktop publishing applications. As a math student at the time, Mathematica made my jaw drop. I figured out how to use it under ASCII mode via dialup, and checked all my homework that way.

The programming environment was interesting, though I never really delved into it. Underneath (or beside) the pretty GUI there was a 4.3BSD system with a Mach kernel. I was mostly interested in this compiler they had for it, gcc. They wanted you to copy it! And hunting around the ftp sites I found this new scripting language, perl, that was really great.

Too bad stuff like that will never catch on.

This Article is riddled with inaccuracies.

[tyrione]

• Steve Jobs didn't ask the board to oust Gil Amelio (I know I know, working there had me not seeing the forrest for the trees). Steve's frustrations resided in the fact that Gil didn't listen to his advice on what to do with the direction of the company: What's the point of being a Special Consultant if your years of experience in this industry gets ignored? He was fed up and was ready to spend more time at PIXAR, which really doesn't like Steve's nitpicking but just his skill at negotiation. Fred Anderson came to Steve and asked him to return--his trump to Steve was they already wanted to get rid of Gil. Steve insisted on being able to revamp the board and begin by settling the Microsoft bad public relations.
• We at NeXT were in the middle of filing for an IPO as a WebObjects Enterprise Company. We lost one hell of a CFO during the merger.
• NeXT Engineers began working with the Linux team at Apple to piggy back a non-commercially released version of Openstep onto PowerPC architecture. The idiot wars to parallel what the OS should be and not be have continued since 1997. In two more releases we'll finally get an OS that all the Mac Zealots will accept actually was the original intent of OS X. Glad to see it took forever to drown out the whining.
• "Unlike OPENSTEP, users were able to save files directly to the desktop." --This was a design choice Keith Ohlfs, Steve Jobs and several others specifically didn't want in NeXTSTEP that obviously carried over to Openstep:: A non-cluttered Desktop to keep the clean, minimalistic look; hence THE SHELF: Reuse via the Shelf which is a collection of symlinks to files.
• "Ultimately, Quartz performed better than Display PostScript, while maintaining very high output quality." --Ultimately PDF cost Apple nothing to license and Peter Grafanino(sorry if I spelled your last name wrong Pete--you are a genius and always will be) and his team who developed Quartz chose PDF firstly for cost saving measures and then to extend it in their own rights.
• "Microsoft, Adobe, Macromedia and Quark, the keystone of Macintosh development, had all yet to release their flagship products for OS X, and in the case of Quark, would not until two years later." --They didn't release their products because they insisted upon CARBON.

Now that Cocoa is finally getting its just dues how long before we see replacements to these Gorillas? They didn't want to invest in Cocoa programming then, but now six years later will they have taken the time to find the talent to do it now? Hard to tell but these are my predictions.

If they don't they'll be left behind. Adobe sees it by Apple entering into the market with better products.

Macromedia sees it but lets see if they really see it.

Quark seems to be the most cautious and I'm guessing they'll hedge their bets and have invested in such talent already.

Microsoft? Never. They'll figure that Office will always guarantee them supremacy in the platform. Then again I'm sure they'll be quite pissed if Apple releases a compatible Office suite worthy of knocking off Office. Afterall, XML is the measure of compatibility on all future Office suites.

The last section is obviously just conjecture but conjecture with history.

Re:This Article is riddled with inaccuracies.

[MrLint]

Id like to add a few things based on my experiences in the user chat rooms (IRC) at the time, specifically on the "Idiot wars" (which im not sure i would have chosen as a term but hey:)

Of the many things we groused about as we saw os x develop were many of those UI things. We wanted our volumes on the desktop along with our trash (which we didnt officially get).

Many people wanted labels (of which I couldnt care less).

There was also a lot of back and forth by people who mostly didnt know anything regarding open transport, that is streams from OT (macos 7 - 9) and of course BSD sockets from NeXT. Of course in the end no one noticed any change at all and that part has long since been forgotten.

There was, and still remains some bitterness over the appearance manager getting "Steved". This one is a mixed bag. Id like to change some colors, however when you look at some the visual disasters created by ppl who would be better off doing soap carving, I dont know if i can fault Steve totally.

In the end the users didnt want to have to learn too much new stuff. The finder had to behave like everyone expected. And more importantly X-Windows style cursor focusing is just a no go. (Ive used it on Solaris, and it takes a certain mindset to deal with that meta-abstraction in a visual mode) and frankly it would be too bard for some people. As a note there was and may still be a hidden pref in the terminal.plist to turn this on for terminal, however it causes behavior inconsistencies when terminal autofocuses when you are in a "normal" app.

And thus it was from the peanut gallery.

Rhapsody DR2 x86 Developers

[not_hylas( )]

For the x86 freaks, your only hope for an Apple menu on a bare metal x86
They're making headway - mine runs.

http://www.rhapsody-project.tk/

A VERY cool resource.

http://www.shawcomputing.net/

Stone

http://www.stone.com/dev/StonesThrow21/Whats_New _I n_DR2.html

Of course, never forget about GNUstep!!

[borgheron]

I can't let this topic go without a mention...

http://www.gnustep.org

Please take a look!

Thanks, GJC

Re:Well, there was another choice.

[KurtP]

Well, Hank, I was the guy who wrote the report at Apple that recommended we buy NeXT. It was a simple choice, really, between Be and NeXTStep. NeXT had a much more complete offering, with actual commercial developers who had written really good stuff for it. Even better, it had had a number of releases, and had a mature system for handling version upgrades. Be, as many people will recall, tended to need an application recompile for every new version, and there way no obvious simple way to solve the problem. NeXT had a mature and battle tested kernel, and a real BSD layer, neither of which could really be said of Be at the time.

We considered a lot of other OSes. We looked at NT, but it looked like it would never be practical to port to a big-endian processor. We looked at Solaris, and it was a serious contender. There was no decent UI layer, though, by the standards we used to judge such things. Remember that things like KDE and GNOME were quite young and immature at the time.

Getting back Steve was a plus for the company, but wasn't a part of our deliberations as technical folks. NeXT Looked like the best technical choice, really. Linux was simply too young in 1996 to be a serious cnsideration, even though Apple had an internal mkLinux project.

Who knows what it might have been today, given a new shot at choosing. But back then, there was nothing that stood up to NeXT given the constraints of Apple's business.

Re:This is one reason apple has failed...

[g3000]

Failed? It's hard to see Apple as a "failed" company with successes like the iMac, the iPod, iTMS and recent financial figures. I confess I haven't checked stock price and financial statements, but I understand anecdotaly that Apple is doing quite well, "niche" or not.

Don't make someone bust out the old argument of market share and comparisons to companies like Lexus, etc. etc. You're just not a "success" unless you become some sort of a monopoly, is that it?

I'd better go enjoy my G5 since Apple has so miserably failed and is, true to predictions since about 1990, about to close its doors.

Re:Net services company???

[NightLamp]

WebObjects is still alive and kicking, at my company we use it for all manner of things. It has become a real workhorse and continues to evolve capability-wise and mature in terms of stability. As a J2EE certified platform (last time I checked), the thing that I find most overlooked about the package is its built-in GUI a la Dreamweaver, it is, however, much more effective at visualizing/previewing dynamic pages with active data than the Macromedia product. If you are developing database-tied web sites with Java you owe it to yourself to check out Apple WebObjects. (It is not strictly tied to the Apple platform BTW) Of all the J2EE APIs I have used it is by far the most friendly, due to a code-quality pedigree inherited from NeXT and extensively re-factored ObjectiveC MVC structures. thanks Steve, et. al. (the built-in multi-schema load-balancer is a nice finishing touch ;) /* Can you tell your JVM controller to re-start (and pass off extant sessions to other instances) your application instances to account for what could (at any time) be(come) a buggy JVM by clicking on a check-box on an HTML config page? A non-elegant but eminently practical solution for inexplicable java memory leaks is built in to this package. I call Nice. Check it out. */ TTFN.

Re:Did Copland failing actually help Apple succeed

[putaro]

I worked on Copland. The failure of Copland was not really a failure of technology but a failure of management. There were a number of management failures that brought the project down.

In the winter of 1995 we got a mandate that the first Copland beta would be made available for the May 1996 World Wide Developers' Conference.

That winter two of the major tasks that were being handled were to bring in the new file system and the new I/O system, replacing the original Copland, hastily built, prototype systems. For the purposes of that build, Copland could be split into 4 major pieces: file system, I/O subsystem, kernel and higher level functionality.

We produced set of glue code such that either file system or I/O subsystem could be used together, allowing the new I/O subsystem to be tested without alterations to the rest of the system and the new file system to be tested with the old I/O subsystem.

In January of 1996, as we were approaching the end of that build cycle, the kernel team decided that they really, really, needed to change a bunch of API's that would break just about everything. At this point, a strong management decision would have been "WAIT - those changes can go into the next build, AFTER the I/O subsystem and file system have been tested". Instead, the kernel changes were allowed to proceed. At this point everything in the system was broken. Upgrading the old I/O subsystem to work with the new kernel API's was a huge amount of work so the ability to test the new file system against the old I/O subsystem was lost. Now, the entire system had to be tested together with every component in flux. Needless to say, the integration process for this build took forever and was probably the first death blow for the project.

As WWDC approached, we expected that pressure would be brought from management to make the deadline. Instead, as the time for all-nighters with free pizza came up in about March management looked at the schedule and decided that it could not be met. Having told everyone previously if this deadline was missed the company would be in deep doo-doo, management credibility went out the window. The number of late nighters (already not enough for a project so far behind schedule) dropped precipitously. This was the second death blow to the project.

Over the summer of 1996 we were very close to having the developer release ready. A senior engineer and tech lead had been on sabbatical and doing some serious thinking and came back with a paper that cast serious doubts on the approach that Copland was taking to emulating the Mac OS System 7 environment.

Classic Mac OS is more of a library than an operating system in that all of the operating system's data structures are in the same address as applications. Copland's approach to Classic Mac OS compatibility was to emulate EVERYTHING, including internal data structures that applications might use. For example, in Classic Mac OS there is a linked list (can't remember the name of the damned thing right now) of data structures for all of the open files. Applications would walk this list to find out who else had files open. In the Copland emulation environment the Copland file system would generate events for the emulation layer so that the emulation layer could keep this list current!

This approach was causing serious problems. The mandate from marketing was that 99% of applications had to run, warts and all and this was proving to be strictly impossible. The emphasis on providing an emulation layer had bushwhacked the "new api" such that there really wasn't much available to write apps that took advantage of the multi-tasking and memory protection that the OS provided. The paper written seriously critiqued this approach.

Unfortunately as this paper made its way up the management chain to people who did not really understand what it was talking about, the entire project began to be regarded as failed.

Copland had a number of technical failings, one of its