Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You know, your PDF reader probably has a search function, and the book itself has an index, which has numerous references to NeXT and NeXTSTEP.

NeXT: 11, 14, 230, 296

NEXTSTEP: 11, 14, 54, 141

OpenStep: 14, 141

Page xxxi of The Unix-Haters Handbook mentions: "In fact, it was typeset using FrameMaker on a Macintosh, a Windows box, and a NeXTstation." (Affectionately called "PainMaker" by its victims.)

I wrote three long paragraphs about NeXTSTEP (however you choose to spell and capitalize it), comparing it to NeWS and Display PostScript, in the X-Windows chapter. I even gave Steve Jobs a NeWS demo and a "NeRD" button at EduCOM, the month NeXTSTEP was finally released in November of 1988 (until then it was considered vaporware, and derisively called "NeVRSTEP" -- the critics even made t-shirts):

>I gave a NeWS/Pie Menus/HyperTies/Emacs demo to Steve Jobs once, on the trade show floor at the Educom conference, right after he finally released the NeXT Machine, in November of 1988.

>Sun was letting me demo NeWS and the stuff we were developing at the UMD Human Computer Interaction Lab on a workstation at their booth, and NeXT's booth was right across the aisle, so Ben Shneiderman rope-a-doped him and dragged him over for a demo. He jumped up and down and yelled "That sucks! That sucks! Wow, that's neat. That sucks!"

>I figure a 3:1 sucks:neat ratio was pretty good for him comparing something different than his newborn baby NeXT Step, which critics had taken to calling NeVR Step, since it had been vaporware for so long until then.

>When I tried to explain to him how flexible NeWS was, he told me "I don't need flexibility -- I got my window system right the first time!"

And one of the editors, Simson Garfinkel <simsong@nextworld.com>, wrote a popular book about NeXTSTEP and was a senior editor at NeXTWORLD magazine.

p. 11:

    Date: Wed, 20 Nov 91 09:37:23 PST
    From: simsong@nextworld.com
    To: UNIX-HATERS
    Subject: Unix names

    Perhaps keeping track of the different names for various versions
    of Unix is not a problem for most people, but today the copy
    editor here Standardizing Unconformity 11 at NeXTWORLD asked me
    what the difference was between AIX and A/UX.

    “AIX is Unix from IBM. A/UX is Unix from Apple.”

    “What’s the difference?” he asked.

    “I’m not sure. They’re both AT&T System V with gratuitous
    changes. Then there’s HP-UX which is HP’s version of System V
    with gratuitous changes. DEC calls its system ULTRIX. DGUX is
    Data General’s. And don’t forget Xenix—that’s from SCO.”

    NeXT, meanwhile, calls their version of Unix (which is really Mach
    with brain-dead Unix wrapped around it) NEXTSTEP. But it’s
    impossible to get a definition of NEXTSTEP: is it the window
    system? Objective-C? The environment? Mach? What?
p. 13 (although the index says 14: blame PainMaker, which is riddled with features!):

Sun Microsystems recently announced that it was joining with NeXT to promulgate OpenStep, a new standard for object-oriented user interfaces. To achieve this openness, Sun would will wrap C++ and DOE around Objective-C and NEXTSTEP. Can’t decide which standard you want to follow? No problem: now you can follow them all.

p. 53 (although the index says 54, thanks PainMaker):

Hmm… Excuse us for one second:

    % ls /lib
    cpp* gcrt0.o libsys_s.a
    cpp-precomp* i386/ m68k/
    crt0.o libsys_p.a posixcrt0.o
    next% strings /lib/cpp-precomp | grep /
    /*%s*/
    //%s
    /usr/local/include
    /NextDeveloper/Headers
    /NextDeveloper/Headers/ansi
    /NextDeveloper/Headers/bsd
    /LocalDeveloper/Headers
    /LocalDeveloper/Headers/ansi
    /LocalDeveloper/Headers/bsd
    /NextDeveloper/2.0CompatibleHeaders
    %s/%s
    /lib/%s/specs
    next%
Silly us. NEXTSTEP’s /lib/cpp calls /lib/cpp-precomp. You won’t find that documented on the man page either:

    next% man cpp-precomp
    No manual entry for cpp-precomp.
p. 140 (FrameMaker's index says 141):

X Graphics: Square Peg in a Round Hole

"Programming X Windows is like trying to find the square root of pi using roman numerals." —Unknown

The PostScript imaging model, used by NeWS and Display PostScript, solves all these horrible problems in a high-level, standard, device independent manner. NeWS has integrated extensions for input, lightweight processes, networking, and windows. It can draw and respond to input in the same arbitrary coordinate system and define window shapes with PostScript paths. The Display PostScript extension for X is intended for output only and doesn’t address any window system issues, which must be dealt with through X. NEXTSTEP is a toolkit written in Objective-C, on top of NeXT’s own window server. NEXTSTEP uses Display PostScript for imaging, but not for input. It has an excellent imaging model and well designed toolkit, but the Display PostScript server is not designed to be programmed with interactive code: instead all events are sent to the client for processing, and the toolkit runs in the client, so it does not have the low bandwidth, context-switching, and code-sharing advantages of NeWS. Nevertheless, it is still superior to X, which lacks the device-independent imaging model.

On the other hand, X’s spelling has remained constant over the years, while NeXT has at various times spelled their flagship product “NextStep,” “NeXTstep,” “NeXTStep,” “NeXTSTEP,” “NEXTSTEP,” and finally “OpenStep.” A standardized, consistent spelling is certainly easier on the marketing ’droids.

Unfortunately, NeWS and NEXTSTEP were political failures because they suffer from the same two problems: oBNoXiOuS capitalization, and Amiga Persecution Attitude[TM].

p. 230 (hey FrameMaker got one right!!!):

Footnote 2: Indeed, there are so many problems with partitioning in Unix that at least one vendor (NeXT, Inc.) recommends that disks be equipped with only a single partition. This is probably because NeXT’s Mach kernel can swap to the Unix file system, rather than requiring a special preallocated space on the system’s hard disk.

p. 295 (FrameMaker guessed 296, two out of six ain't bad):

    Date: Wed, 18 Sep 1991 02:16:03 GMT
    From: meuer@roch.geom.umn.edu (Mark V. Meuer)
    Organization: Minnesota Supercomputer Institute
    Subject: Re: File find delay within Emacs on a NeXT
    To: help-gnu-emacs@prep.ai.mit.edu

    In article <1991Sep16.231808.9812@s1.msi.umn.edu>
    meuer@roch.geom.umn.edu (Mark V. Meuer) writes:

        I have a NeXT with version 2.1 of the system. We have Emacs
        18.55 running. (Please don’t tell me to upgrade to version
        18.57 unless you can also supply a pointer to diffs or at least s-
        and m- files for the NeXT.) There are several machines in our
        network and we are using yellow pages. The problem is that
        whenever I try to find a file (either through “C-x C-f”, “emacs
        file” or through a client talking to the server) Emacs freezes
        completely for between 15 and 30 seconds. The file then loads
        and everything works fine. In about 1 in 10 times the file loads
        immediately with no delay at all.

    Several people sent me suggestions (thank you!), but the obnoxious
    delay was finally explained and corrected by Scott Bertilson, one of
    the really smart people who works here at the Center.

    For people who have had this problem, one quick hack to correct it is
    to make /usr/lib/emacs/lock be a symbolic link to /tmp. The full
    explanation follows.

    I was able to track down that there was a file called !!!SuperLock!!!
    in /usr/lib/emacs/lock, and when that file existed the delay would
    occur. When that file wasn’t there, neither was the delay (usually).

    We found the segment of code that was causing the problem. When
    Emacs tries to open a file to edit, it tries to do an exclusive create on
    the superlock file. If the exclusive create fails, it tries 19 more times
    with a one second delay between each try. After 20 tries it just
    ignores the lock file being there and opens the file the user wanted. If
    it succeeds in creating the lock file, it opens the user’s file and then
    immediately removes the lock file.

    The problem we had was that /usr/lib/emacs/lock was mounted over
    NFS, and apparently NFS doesn’t handle exclusive create as well as
    one would hope. The command would create the file, but return an
    error saying it didn’t. Since Emacs thinks it wasn't able to create the
    lock file, it never removes it. But since it did create the file, all future
    attempts to open files encounter this lock file and force Emacs to go
    through a 20-second loop before proceeding. That was what was
    causing the delay.

    The hack we used to cure this problem was to make
    /usr/lib/emacs/lock be a symbolic link to /tmp, so that it would
    always point to a local directory and avoid the NFS exclusive create
    bug. I know this is far from perfect, but so far it is working correctly.

    Thanks to everyone who responded to my plea for help. It’s nice to
    know that there are so many friendly people on the net.


> The PostScript imaging model, used by NeWS and Display PostScript, solves all these horrible problems in a high-level, standard, device independent manner.

We have evolved. Now we draw "surfaces" (to draw a cursor). /s




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: