Slashdot Mirror
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.
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 :)
Proceed with Format (Y/N)? Y
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
and found this which looked to be fairly indepth about the history of the Mac OS, including some information on what was taken from what and went into what.
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.
--- I do not moderate.
By 1996 WebObjects was pretty much all NeXT had left after sales of NeXT and NeXT systems had plummeted to vitually nil.
Did apple *choose* Next, or did Steve Jobs simply decree it? Were apple engineers involved in this 'choice'?
Remember who Jobs was working for - NeXT. A Jobsian decree didn't mean anything at all at Apple in those days - the company was in the (in)capable hands of Gil Amelio. It wasn't until after the NeXT purchase that Jobs managed to oust Amelio, and assume the role of 'iCEO'.
And tomorrow the stock exchange will be the human race
Forgot to post the link - clicky here
And tomorrow the stock exchange will be the human race
http://en.wikipedia.org/wiki/NeXT
:-)
The machines weren't ready for "real" sales until 1990, when they went on the market for $9999.
Guess my memory isn't completely shot yet.
The revolution will NOT be televised.
For the x86 freaks, your only hope for an Apple menu on a bare metal x86
w _I n_DR2.html
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_Ne
~hylas
I can't let this topic go without a mention...
http://www.gnustep.org
Please take a look!
Thanks, GJC
Gregory Casamento
## Chief Maintainer for GNUstep
It means that I, for one, would not be using a Mac right now. The UNIX-ness is important to me.
BeOS is posix compatible, has all the GNU tools you expect and the default shell is based on Bash.
BeOS was heavily influenced by XINU.
The NT kernel was mostly designed by a team a DEC engineers (including Dave Cutler) bought out by microsoft after they couldn`t design the os the wanted at DEC. (They worked on VMS). The NT kernel design is imho the only piece of software developed somewhat within microsoft but still with an actual design behind it. Compared to the patch upon patch shell, office, mail stuff, servers that arent bought from elseware and of course browser... the NT kernel is based on a vision. It has a microkernel-ish design, is designed to run on every processor architecture people can make up, it can have many API`s (win32, os/2, posix) and has a security architecture that works provided you dont give everyone and everything administrative privileges by default that is. What other modern operating system allows for ACL`s on individual configuration settings?
The idea of apple considering both mach and NT makes sense, they are more alike then mach and most "unix" kernels. Ofcourse the idea of Apple being stupid and taking both the kernel *and* the rest from windows does make one vomit...
For info about the evolution of NextStep to OS X, the Mac OS X history article is also worth reading.
http://alternatives.rzero.com/
You actually are strictly correct but Merriam Webster typically adapts its definitions to fit more modern interpretations. Further and farther are a great example. Traditionally further is additional time while farther is additional distance but MW has given them both the identical definition.
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.
They did. I have a Mac SE/30 (1989) running A/UX, Apple's first UNIX. The stumbling block for A/UX was the same as the early releases of what came to be OSX: classic Mac/OS emulation. A/UX runs Mac OS 6 under emulation, kind of like the Classic subsystem in OSX, and performance on even a 68030 (which was a pretty fast chip at the time) was lousy.
NeXT, running what became Cocoa, was zippier on a 68030 than either OS9 or OSX on the first generation Powermacs. If they could have shipped Rhapsody for the desktop it wuld have kicked OS9's behind... unfortunately, their developers more or less forced them to hold it back until they had good MacOS emulation (Classic) and a good dual-OS runtime (Carbon), and... well... I booted OSX on a 180 MHz Powermac 7600 and it was far far slower than NeXTstep on my Nexstation. The OS install took a full day to complete...
It's a real shame Apple didn't join the fight over Lorraine (what became the Amiga). The Amiga Exec was a high performance microkernel and with Apple's GUI people handling the user interface it could have been a killer combo.
It was designed and prototyped shortly before they stopped making hardware (in 1993), so it never shipped.
The head designer was Jon Rubenstein, who left NeXT at that point. He (and, I think, others from the hardware group) went on designing dual-processor PPC systems. First they had a company called FirePower. That was bought by Motorola, I think.
When Apple bought NeXT, Rubenstein came on board to run hardware. Because he'd kept working on dual-processor systems after leaving NeXT, his SMP-fu wasn't stale.
So, basically, on the hardware side, NeXT vs. Be was a wash.
Well, they stopped selling hardware in 1993, so they were down to selling Openstep/Mach, Openstep/NT, the OpenStep developer tools ($4000/seat), PDO (portable distributed objects, for GUI-less servers on things like HP/UX and Solaris), and WebObjects.
WebObjects was probably the only thing selling to new customers. They also provided contract developers and training. I think the WebObjects development package cost about $800, but deployment could be really expensive - tens of thousands of dollars.
As Much as I would love to purchase your Cube, I am no where near CO, but in IN and the shipping would be most prohibitive. However:
Black Hole, Incorporated
3007 Conestoga Ct.
Fort Collins, CO 80526
970-223-9976 Phone
970-223-9975 Fax
President: Rob Blessin
Black Hole is a company located in CO that deals with NeXT equipment and acts as a reseller of used machines and other NeXT items including printers.
Note: This post in no way is meant as an advertisement for Black Hole, Inc. I am not affiliated, nor have I ever actually had business dealing with, the mentioned company.
Just thought the info might come in handy. Though, if you don't think the shipping would be *too* bad, or if you happen to have any *dead* cubes. I'd be interested in an email.
"Genius may shine aloof and alone, like a star, but goodness is social, and it takes two men and God to make a Brother."
I saw inside one of those.. Geez, had to be 12 or 13 years ago.
What I remember was that the front of the case came off, exposing a bunch of HUGE cards mounted vertically. They were like 12x10" or something crazy like that.
I remember one of the cards had a processor on it, so they must have all plugged into a passive backplane.
I remember two cards had a SHITPILE of ram on them. 30 pin SIMMs, I think, on one; the other was VRAM IIRC, on the display postscript card. The DPS card might have had an Intel i860 or something like that one board as well.
I don't remember where the optical and hard drives were. Below the cards, I think.
If you took a Sun Enterprise E3K, flipped it around, chopped off the drive bays and put a single cover over all the boards, you'd have something resembling a NeXT Cube, only purple.
Do daemons dream of electric sleep()?
>big-endian porting?
What are you talking about. Windows NT 3.5 ran on IBM CHRP systems like the RS/6000 43P on a PowerPC 601; what about that would be big-endian unhappy?. 43P could run OS/2, AIX, or NT.
NeXT built Dell's first web store for them (for the princely sum of $100,000 I believe, though now I doubt Michael Dell would even buy a car worth less than that).
Of course, once NeXT was subsumed by Apple, the WebObjects store had to be replaced for political reasons, at a much higher cost.
"Apple has made OS X work, apparently quite well. I guess there isn't much point in playing the "what if" game, but I'd like to see what Apple could have done with the Be OS. It was snappy on a 200 Mhz 603ev processor, it would have stomped some serious ass on a G4."
Maybe so.
But nobody ever wrote derivatives trading applications, handling billions of dollars' worth of trades per day, with the Be frameworks, or ran them on BeOS.
Such systems were implemented on NeXTSTEP. Bank of America was still using one, at least as late as 2001. (And trying to port it to Java. Dunno how that's going...)
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.
I was reading with great interest 'till I got here. Just to make sure I hadn't gone mad, I grabbed my NT4 cd from the bookshelf. I hadn't. I scanned the CD for this comment.
So, either you're putting us on, had an excusable brain-fart, or we're talking Apples and Oranges. Pick a card any card.
Assuming you're just getting old like the rest of us, perhaps you can shed some light as to whether the mkLinux's Mach microkernel was considered either a proof-of-concept or an enabling technology when it came to porting OpenStep to Macintosh.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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.
The purchase of NeXT was far more a purchase of Jobs than it was of the actual technology. Amelio was pushing for the acquisition Be Inc's BeOS and turning that into the next MacOS. remember, at the time Apple had a 10 year streak of failures trying to modernize the OS, starting with Copland and ending with Rhapsody. System7 was supposed to be the last non-memory protected, cooperative multitasking MacOS, but then they released 8 and 9 while their new projects floundered. I think far more likely, the board of directors at Apple decided that they need someone who could steer the company and push out a modern OS, as well as reinvigorate the product line. I'm not a big fan of Jobs, but there is no doubt he saved Apple.
Well, to be precise: Gil Amelio chose NeXT over Be, on Ellen Hancock's recommendation. When the board decided that Gil wasn't really cutting it w/r/t marketing, they let him go, and then did a full-court press to get Steve Jobs to serve as the interim CEO.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
NetInfo was way too obtuse to catch on,
Actually, NetInfo is a marvelous technology, and I'm rather sad to see it on the way out. At one major investment bank where I worked, five full-time sysops were able to manage about 4K workstations, globally. We used NetInfo to store app parameters, so the same app launched in Zurich came up configured rather differently than if you launched it on a workstation in Chicago.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
> >big-endian porting?
> What are you talking about. Windows NT 3.5 ran on IBM CHRP systems like the RS/6000 43P on a PowerPC 601; what about that would be big-endian unhappy?. 43P could run OS/2, AIX, or NT.
PPC is bi-endian. NT can run on it, but in little endian mode, while all the Mac code is big endian. Next to impossible to write something like the blue box.
OPENSTEP is basically the implementation of the OpenStep API + extras, which is a reinvention of the NeXTSTEP APIs so they were platform independent. OPENSTEP ran on Mach, much in the same vein as NeXTSTEP, but also on other operating systems and architectures, even Windows NT, so code could be very easily ported from architecture to architecture.
PowerPC can be switched to little-endian mode, so an operating system running on PPC may decide to be little-endian instead of big-endian.
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
If you can read french, there is a site full of screenshots :
http://www.levenez.com/NeXTSTEP/.
Yes, we had all of these discussions. But as you doubtless know, it was not acutally possible to switch the processor between big endian and little endian mode quickly enough to run both kinds of apps in separate processes at anything like decent speeds The kernel was going to have to run either big endian or little endian, and one class of apps was going to suffer hugely on performance. That meant one thing, given that we already had a huge base of big-endian compiled apps we needed to run at close to full speed. We were going to have to shift the endianness of the NT kernel and all the apps to get decent speed.
Remember, I said practical. It was clearly possible, but business-wise it made next to no sense given the technological constraints we had to work with.
This turns out not to be the case. The first Apple PPC machines didn't show up until after the merger. The nearest thing we had in late 1996 at NeXT was a NeXT RISC Worktstation prototype with the 88110 processors replaced by a daughter card packed with programmable parts and a 601. (Yay! Jeff and Ali rocked!)
I spent a happy fun Christmas break diddling a GCC compiler to spiff code generation for the NeXT RISC ABI and the 601, so I could get Display PostScript to compile and run.
2) in favor of free technologies like Quartz Now. They rewrote Display PostScript as Display PDF. THEN added Quartz on top, wich is something they've developed for this specific purpose. It wasn't free. They made it. And it's hosted on top of Display PDF.
Display PDF? I don't think so, MouseR. Quartz is a marketing name for the graphics rendering technology used. A PDF interpreter can be hosted on top of this technology, and by establishing what's called a "PDF context", the calls to the Quartz API can generate PDF data.
There is no Display PDF. Really.
The rendering technology is all home-grown, though. This avoids the unpleasant experience of having one's products at the mercy of another company that may not have one's best interests in mind...
The end result was that Mac OS X was not shipped until 2001, nearly 3 years behind what was promised.
You're leaving out some rather crucial parts of the story, here. In Spring of 1999, Apple shipped Mac OS X Server 1.0. In many respects, this is what was promised: Nextstep/Rhapsody on PowerPC hardware. It's a far cry from what we have in Mac OS X today, but that's because the requirements changed.
First, the original Next acquisition strategy was to require everyone to rewrite their apps in NextStep APIs (predecessor to Cocoa). Companies like Adobe didn't like this prospect, so Apple went back and started working on Carbon, which was a significant undertaking. In addition, Quartz was created to replace Display PostScript. And that's really just scratching the surface.
Nonetheless, Apple went from having about 10% of the desktop market when I started in 1995 to less than 4% today
Windows 95 combined with Apple management issues certainly had a significant impact. But to be fair, not all of this is due to Apple losing customers. Today, market share includes $168 PCs from Walmart, but this is a much different type of experience offered to a much different type of customer than what we typically think of as computer users.
So, if Copland had succeeded would Apple have been sunk? I don't think so. The fact that OS X has a Unix underpinning has had very little effect on the number of applications available for it. OS X's windowing system is most emphatically NOT X Windows so a port of any interesting application from Unix or Windows is major work.
This is misleading in several senses. Not only does come with a X11 server but a lot of significant Unix software (Apache, MySQL, etc) is faceless. In terms of consumer desktop application, what the Unix side brings is basic infrastructure for a multi-user system.
But one of the most significant advantages that Next brought to the table was the development environment. Not only for third party developers but Apple itself. The speed at which one can write high quality applications is a huge asset.
Objective-C has become the language of choice for Mac applications which again makes your applications totally non-portable.
The language is essentially irrelevant. The difference is in the frameworks. Unless you're using cross-platform toolkits, the language issue is a moot point. And cross-platform apps generally don't serve the platform or users as much as the developer.
Your best bet is to write the core engine in something like C, and write the higher level UI stuff in whatever the platform prefers.
Had Apple had strong enough managemnt to rein in engineering and force the product to ship it would have been successful and a strong contender to Windows NT on the desktop.
We clearly have different opinions on this, but I have a rather hard time seeing your parallel universe comparing favorably to one with Jobs, Cocoa, iMac, iPod/iTunes, iMovie, iPhoto, Final Cut Pro, etc. That's just my gut feeling.
- Scott
Scott Stevenson
Tree House Ideas
No, the Apple demos were mostly done using a couple Toshiba laptops, running the OPENSTEP for x86 port. We resurrected a NeXTTIME port specifically to demonstrate multimedia support, and ran several Quicktime movies on the laptop at the same time. This was a fun demo to assemble.
All I could find for now is this: link [roughlydrafted.com].
That refers to the old NeXT RISC workstation project. That started life as a RISC workstation built around the 88110, and later moved to using an adapter card in the processor socket to try other architectures. One such adapter used an early 601 processor, and managed to boot a NeXTSTEP 3.0 kernel.
This is far from being a port, and never ran Apple's PPC ABI. It never shipped, and was not maintained, as it was a lab experiment.
I came across this excerpt from Apple Confidential that someone (above or below) linked to here. I found the following paragraph very interesting.
It's not offtopic, dumbass. It's orthogonal.
NeXT _really_ had a fully functional, more featureful (eg: multiuser) OS with a history and existing software base that would require porting, but would not be difficult to port.
Then there are the other considerations. Be was asking for a fortune. NeXT came with Steve Jobs.
Apple would have had to do at _least_ as much work on BeOS as they did on NeXT (albeit in different areas - but I'm willing to bet porting portable code is a hell of a lot easier than creating new code from scratch). More, IMHO.
Some corrections and clarification.
1. The NeXT optical disk was manufactured by Canon and had a 256MB capacity per side--NeXT sold single-sided media. 256MB for removable media was huge at that time. The trouble, though, was it was slow and produced loud clunks as its head was accessing, probably due to the use of a stepper head motor. My OD drive is dead due to non-use, but I'm sure the media is still fine. I still have some double-sided media (512MB) from Canon, but you had to flip the disk.
2. NeXT used a unified imaging model (Display Postscript for the screen and Postscript for print), but the GUI applications were written in Objective-C. Although a lot of applications have some sort of Postscript glue. Interface Builder was already a part of 1.0.
3. Most notable at that time was the inclusion of all these academia programs such as the complete Shakespeare's works, quotes, and the unabridged Webster dictionary (a lot of companies sold abridged, so you cannot search for f..k) with audio pronounciation. For me, the most enigmatic "app" was Allegro Common LISP--didn't know what to do with that. Yes, Mathematica was jaw-dropping. Not the graphing part, but that was impressive, too. First time I saw a program that solved integrals outputting intermediate steps.
Finally, the most powerful aspect of NeXT software architecture was its object-oriented model based on Objective-C. Obj-C's late binding was slower than C++'s early binding, but it allowed most applications to not break as the underlying framework was changed/modified/rev'ed. That was one of the problems with BeOS's C++-based OO framework at that time. You probably can have a C++ framework and not require recompiles of all your apps, but the framework would have to be very mature, something the Be framework could not be given the limited man-years it received.
Personally, I think Apple was correct in choosing NeXT technologies because of Obj-C's battle-tested framework.
Mac OS X has less code in common with NEXTSTEP than commonly assumed; it also lacked large swaths of current functionality, and much of what it had was rewritten. The XNU kernel, including networking, is a fresh implementation of the same architecture. Printing was redone to work with the new driver and display models, then scrapped and replaced with CUPS just two years ago. Developers balked when told that the only way to get their apps running natively on Rhapsody would be to rewrite them in Java or some crazy moon language, so Apple had to go write Carbon.
Unlike the grandparent, I'm not convinced that 'Plan Be' would have worked out better than what we have now, but reusable lines of code and time to market weren't the NeXT advantages Apple thought they would be.