[Prev][Next][Index][Thread]

Executor/NEXTSTEP 1.99o9 is out, sans READMEs



Executor/NEXTSTEP/Intel 1.99o9 is now in
ftp://ftp.ardi.com/pub/BleedingEdge/NEXTSTEP/executor-nsintel-199o9.tar.gz
That file will expand to Executor.app, which you should probably put
in /LocalApps.

NOTE: we have changed the registration procedure and will need to
issue all our current NEXTSTEP customers new keys.  In the meantime,
until the end of October, every Executor/NEXTSTEP user (current
customers and not) has permission to use this serial number and key:

Serial Number = 100
Key = "z5nk6yn28jy9n"

This will only work under Executor/NEXTSTEP and it will only work for
versions 1.x.  It even stops functioning November 1.  We'll either get
new serial numbers to all our current NEXTSTEP customers by then or
we'll release another key that everyone can use while we sort things
out.

To use this key, fire up Executor, then click on the "Info" button.
It will prsent you with a page of legalese, and the option to click on
the "Next" button to get another page of legalese.  After you've
clicked on the Next button about a dozen times, you'll be prompted for
your name, organization, serial number and authorization key.  Use the
values supplied above for the last two choices.  You will have to run
Executor once as root after you've entered the registration
information.

If you run Executor/NEXTSTEP in demo mode and it times out on you,
you'll be presented with the "Time's Up" message, but after you click
on "OK", Executor will hang.  We should have that fixed by the time we
release 1.99p, which will be the first 1.99<x> experimental (as
opposed to bleeding edge) release for NEXTSTEP.

Earlier today I answered a customers question about
Executor/NEXTSTEP/Motorola.  My reply is tacked on to the end of this
letter.

	--Cliff
	ctm@ardi.com

Q: What about Executor for NEXTSTEP/Motorola

A:

Mat is working on it.  We have three things that need to be done:

Rework the interface between Mac code and ROMlib/Executor code so that
NS/motorola can use the same code for this boundary laye rthat all the
other implementations do.  Previously there were two different sets of
code for the boundary stuff, but as we've added much more code of late
it makes sense to just rework the interface and share the code than to
maintain two different sets.

Make the blitter work.  This is a multi-step process.  First we need
an implementation that does the job but isn't necessarily efficient.
Our old code was black and white only.

Adjust how interrupts are handled.  When we're using our synthetic CPU
we just turn on a bit that says an interrupt is pending and we will
know that eventually someone will see that bit and call the interrupt
routine at an opportune time.  Under NS/Motorola there is no way to
set a "pending" bit.  We have to do things during interrupt time,
which requires more care to properly block and unblock interrupts.  We
used to have code that would do this, but it may have succumbed to
bitrot.

We're *hoping* to have E/NS/Motorola limping by October 7, when we
start hackathon II, but if we don't, then we'll probably have to put
work on it on hold until October 24.

NOTE: Between 1.99o8 and 1.99o9 we cleaned out some outdated stuff
from our NS NIB files and got printing to work again, so we have been
doing some NEXTSTEP work.