[Prev][Next][Index][Thread]
Re: nextstep
>>>>> "Mark" == Mark Adler <Mark.Adler@quest.jpl.nasa.gov> writes:
>>> NEXTSTEP port
Mark> Oh thank you, thank you.
Mark> (To the person who wondered if NEXTSTEP was some sort of i/o
Mark> support, no. NEXTSTEP is the only decent operating system,
Mark> window application environment, and development environment
Mark> in the universe. It is the birthplace of Executor and the
Mark> port of NEXTSTEP to non-680x0 architectures was the
Mark> inspiration for the synthetic cpu in Executor. Cliff can
Mark> correct me if I'm wrong here.)
In my opinion NEXTSTEP is in fact the best operating system/windowing
system currently available.
The first 10,000 lines of ROMlib, the precursor to Executor, were
written on a 1 MB Macintosh Plus with no hard drive, only one floppy
drive and no printer. I used "Lightspeed C" version 1 (the precursor
to Think C) and had to use five different floppies for the source
since there wasn't too much room left on an 800k floppy with
Lightspeed C on it.
The filesystem was actually written on a PDP-11 (no, I'm not making
this up) running UNIX. Executor itself, was actually born on a
Sun3/60 taking over the frame buffer directly. A port to X-Windows on
the Sun3/60 followed, but yes, NEXTSTEP was where Executor was first
commercially released.
NeXT's port of NEXTSTEP to non-680x0 architecture was not the
inspiration for the synthetic CPU in Executor. I've been familiar
with portable code and assembly language since before NeXT existed. I
knew from the start that if we were to port Executor to a non-68k
environment we'd need a synthetic CPU. Originally I designed the
synthetic CPU when I was in bed with pneumonia. I hired Mat Hostetter
to implement my design -- I thought I would do the design work and
hold his hand as he implemented it. HAH! Mat came up with a much
better design and needed none of my help to implement it (although I
had to do some revamping of Executor's internals so that it would mate
nicely with Mat's synthetic CPU and also not be freaked out by the
different byte ordering involved).
Although we like NEXTSTEP quite a lot, we shifted all our development
to Linux because NEXTSTEP licenses are expensive, NeXT doesn't fix
their kernel bugs and it's a pain to compile Free Software Foundation
tools under NEXTSTEP right out of the box -- we get a lot of leverage
out of the FSF tools. Since we made the shift we also found that we
could use hardware watchpoints under gdb under Linux (a big win) and
lately we've also been using a Linux only debugging tool called
"checker". It was sad to move our development to Linux, but NeXT
didn't seem to care and in the long run it's helped us.
For people doing high level development the NEXTSTEP development
environment probably can't be beat right now (but that's changing).
However, writing a Mac emulator isn't a high level undertaking.
Furthermore, as an Independent Software Vendor, we need a market for
our products and being only able to sell to NEXTSTEP users greatly
narrows the potential customer base.
--Cliff
ctm@ardi.com
References:
- nextstep
- From: Mark Adler <Mark.Adler@quest.jpl.nasa.gov>