Executor 2.0/executorv2.0.iso/pc/dos/extra/docs/maillist/text/archive.92/text0037.txt

Text File | 1996-03-31 | 12.4 KB | 251 lines

Dear Folks,

Due to the way we originally wrote our keyboard mapping routines,
Executor 1.2.1 doesn't work with the new ADB-Keyboard based NeXTs.
Obviously we need to rewrite our keyboard mapping routines and will
do so for Executor 1.3 due out in late December.  However, in the
meantime, we need to have a fix for people who buy the new hardware
and want to use Executor 1.2.1.

I've written a program, "ExecutorPatcher", which will modify
Executor, HFS_XFer, and even Executor-DEMO to work with the new
ADB-Keyboard machines.  I think it will work.  The problem is, there
don't appear to be any ADB-Keyboard based machines nearby.  Normally
stuff like this makes a great excuse to pry oneself away from the
keyboard and drive out to Stone Design, but even Andrew appears to
not yet have a new machine.

So, if any of you have access to an ADB based machine, please let me
know, ASAP (best bet is to mail to both
"iclone![e-mail]" *and* "[e-mail]").  If you already
have Executor, that will be a win.  If you don't, let me know and
we'll work something out.  Ability to spend a half hour of Sunday's
time on this is the best.  I want to get ExecutorPatcher on the
archives ASAP.  I'll also add a copy of it to our Executor building
system so new purchasers will automatically have access to it, but I
have to test it first.

When stripped and compressed, ExecutorPatcher is only 9531 bytes, so
I should be able to painlessly NeXTmail it to anyone who is
interested.  It will both patch and unpatch programs, so if you don't
have an ADB-based system and you want to fiddle with it and give me
pointers on the user interface, you can do that, but please let me
know whether or not you'll be able to test it on an ADB based system.

Thanks.

    --Cliff

From iclone![e-mail]  Mon Oct 26 21:44:19 1992
Received: from unmvax.cs.unm.edu by ictv.com (5.65+/1.34v1.3)
    id AA10239; Mon, 26 Oct 92 21:44:19 -0800
Received: from iclone.UUCP by unmvax.cs.unm.edu (5.61/3.3) with UUCP
    id <[e-mail]>; Mon, 26 Oct 92 22:44:05 -0700
Received: by  iclone  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA00206; Mon, 26 Oct 92 20:36:40 MST
Date: Mon, 26 Oct 92 20:36:40 MST
From: iclone![e-mail] (Clifford T. Matthews)
Message-Id: <9210270336.AA00206@ iclone >
Received: by NeXT Mailer (1.63)
To: ictv.com![e-mail]
Subject: potential problems with floppy drives and Executor 1.2.1 / HFS_XFer 2.1

Dear Folks,

A subtle error crept into the development of Executor 1.2.1 and the
nature of the error combined with our testing process let it slip
into the official release.

The nature of the problem is that you may find that Executor or
HFS_XFer refuses to believe that a freshly inserted floppy is
actually a removable medium.  Hence, it doesn't let you eject the
floppy, nor does it eject the floppy when it's done.

The solution is really simple.  While you're not running Executor or
HFS_XFer, remove the directory /usr/filesystems/HFS_XFer.fs.  You'll
probably need to do this using the "su" command or logged in as root.

For the curious, the problem is that we modified the utility that
communicates information about newly inserted disks.  However, the
way the utility is installed is Executor or HFS_XFer notice when the
utility is not there, and write a new copy if it's not.  The problem
is that new versions of Executor and HFS_XFer carry the new utility,
and are incompatible with the old utility, BUT the new versions of
Executor and HFS_XFer don't replace the old utility with the new
utility unless the old utility has been removed.

Why didn't our testing catch this?  Well, we delete all traces of
Executor from the machines that we're going to test new versions on
so that we don't accidently rely on something that was left behind
from the old version.  It never dawned on us that there could be the
opposite problem.

    --Cliff

From [e-mail]  Sat Oct 31 12:56:34 1992
Received: from unmvax.cs.unm.edu by ictv.com (5.65+/1.34v1.3)
    id AA06652; Sat, 31 Oct 92 12:56:34 -0800
Received: from MVS.OAC.UCLA.EDU by unmvax.cs.unm.edu (5.61/3.3) with SMTP
    id <[e-mail]>; Sat, 31 Oct 92 13:56:20 -0700
Message-Id: <[e-mail]>
Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1)
   with BSMTP id 9373; Sat, 31 Oct 92 12:56:15 PST
Date:    Sat, 31 Oct 92 12:55 PST
To: ICTV.COM![e-mail]
From: [e-mail]
Subject: Executor port to NeXTSTEP 486??!!

Dear Mr. Matthews,

    I have been following the progress of your Executor project with
much interest for some months, being  on  the  NeXTmusic  Mailing  List.
Congratulations on the progress you've made so far.  I think that a high
priority  should  be  getting  the SCSI and serial ports to work (unless
you've already done that).  However, another new development is  on  its
way:

    I received email Oct. 14  from NeXT about the upcoming release of
NeXTSTEP 486 v.3.0, and called them in  Redwood  City;  they  said  that
information  about  it  would  not  be  available until after the COMDEX
conference, November 16-20 in Las Vegas.

    I am very much interested in both NeXTSTEP 486  and in finding out
if you folks at the Executor project are intending to make Executor  run
under  NeXTSTEP  486; since NeXT describes it as "a complete port of the
NeXTSTEP 3.0 software environment to Intel-based computers,  {with}  the
same  User  Interface, Development Environment, Applications, Networking
(NFS, NOvell, Appleshare), state-of-the-art color,  Mach  UNIX,  Display
Postscript,  3D  Renderman, etc.", it would seem that you should be able
to make it work without too much trouble.  Especially, the new operating
system has  object-oriented  driver  architecture  that  should  greatly
facilitate writing device drivers for the myriad peripheral cards in the
IBM-compatible world.

     As the October 14 email from NeXT states, in order to set up a
machine that has comparable performance to  NeXT  machines,  one  should
assume  that the Intel-based hardware is equipped with a complete set of
high-performance peripherals, including 80486DX or  DX/2  50  Mhz  board
with  processor-direct  graphics  system, EISA backplane, 32 bit LAN, 32
bit SCSI (-II), 16 bit sound,  high-performance  SCSI  disk,  etc.   You
folks  at  the Executor project should try to plan on your Executor port
so that it includes capability to work with all of the above  and  more,
if  (as  I  hope)  you do plan to port it.  NeXT claims that "a specific
NeXTSTEP  486  Hardware  Compatibility  Guide  will  be   available   in
November"; I hope that doesn't mean Nov.  1993!

     NeXT claims that there will be a DOS 5.0/Windows 3.1 (including DOS
"protected" mode/Win-16 mode) Compatibility  Package  that  will  enable
several  simultaneous DOS and/or Windows programs to run within NeXTSTEP
windows, taking "full advantage of the 486 microprocessor"; Win-32  mode
should  be  supported by mid-1993.  When one combines that with possible
Executor  capability,  one  can  begin  to  see  the  potentially   vast
versatility of such a machine.

     I'll look forward to your reply on these questions whenever you can
get around to it.  Thanks for all your good work so far!

    Robert Gaylord    <[e-mail]>

From [e-mail]  Sun Nov  1 09:30:31 1992
Received: from unmvax.cs.unm.edu by ictv.com (5.65+/1.34v1.3)
    id AA04425; Sun, 1 Nov 92 09:30:31 -0800
Received: from NeXT.COM ([129.18.1.2]) by unmvax.cs.unm.edu (5.61/3.3) with SMTP
    id <[e-mail]>; Sun, 1 Nov 92 06:31:56 -0700
Received: from  west.next.com  (west) by toto.NeXT.COM (NeXT-1.0 (From Sendmail 5.52)/NeXT0.1-Aleph-bf)
    id AA14379; Sun, 1 Nov 92 05:31:49 PST
Received: by  west.next.com  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA12888; Sun, 1 Nov 92 05:31:47 PST
From: [e-mail]
Return-Path: <jfreeman>
Received: by cary (NX5.67c/NeXT-1.0/Oei-0.9e)
    id AA02057; Sun, 1 Nov 92 08:11:31 -0500
Date: Sun, 1 Nov 92 08:11:31 -0500
Message-Id: <9211011311.AA02057@cary>
Received: by NeXT.Mailer (1.87.1)
Received: by NeXT Mailer (1.87.1)
To: [e-mail]
Subject: Re: Executor port to NeXTSTEP 486??!!
Cc: ICTV.COM![e-mail]

The work involved in doing an Executor for intel based hardware would have to be at least
double the work of doing a motorola based implementaton.  At least on  the motorola box,
you don't have to translate the machine code from one instruction set to the other.  You
only have to make sure the instructions are "safe".  An intel port would require the creation
of a virtual 68K machine on the intel world.  Consider, for example, the fact that the 68K
boxes have a larger more orthogonal register set that would have to be mapped into the
intel register space.  Also consider that all the bytes in an intel machine are stored in
reverse order of that of a motorola box.


In summary, the task of emulating a different OS is much simpler if the underlying
processor maps to the emulated processor.

Then again, I don't wor for ictv.com so they may have a totally different answer.

<joe>

Begin forwarded message:

Errors-To: [e-mail]
Errors-To: [e-mail]
Errors-To: [e-mail]
Sender: [e-mail]
Precedence: bulk
Date:    Sat, 31 Oct 92 12:55 PST
To: ICTV.COM![e-mail]
From: [e-mail]
Subject: Executor port to NeXTSTEP 486??!!

Dear Mr. Matthews,

    I have been following the progress of your Executor project with
much interest for some months, being  on  the  NeXTmusic  Mailing  List.
Congratulations on the progress you've made so far.  I think that a high
priority  should  be  getting  the SCSI and serial ports to work (unless
you've already done that).  However, another new development is  on  its
way:

    I received email Oct. 14  from NeXT about the upcoming release of
NeXTSTEP 486 v.3.0, and called them in  Redwood  City;  they  said  that
information  about  it  would  not  be  available until after the COMDEX
conference, November 16-20 in Las Vegas.

    I am very much interested in both NeXTSTEP 486  and in finding out
if you folks at the Executor project are intending to make Executor  run
under  NeXTSTEP  486; since NeXT describes it as "a complete port of the
NeXTSTEP 3.0 software environment to Intel-based computers,  {with}  the
same  User  Interface, Development Environment, Applications, Networking
(NFS, NOvell, Appleshare), state-of-the-art color,  Mach  UNIX,  Display
Postscript,  3D  Renderman, etc.", it would seem that you should be able
to make it work without too much trouble.  Especially, the new operating
system has  object-oriented  driver  architecture  that  should  greatly
facilitate writing device drivers for the myriad peripheral cards in the
IBM-compatible world.

     As the October 14 email from NeXT states, in order to set up a
machine that has comparable performance to  NeXT  machines,  one  should
assume  that the Intel-based hardware is equipped with a complete set of
high-performance peripherals, including 80486DX or  DX/2  50  Mhz  board
with  processor-direct  graphics  system, EISA backplane, 32 bit LAN, 32
bit SCSI (-II), 16 bit sound,  high-performance  SCSI  disk,  etc.   You
folks  at  the Executor project should try to plan on your Executor port
so that it includes capability to work with all of the above  and  more,
if  (as  I  hope)  you do plan to port it.  NeXT claims that "a specific
NeXTSTEP  486  Hardware  Compatibility  Guide  will  be   available   in
November"; I hope that doesn't mean Nov.  1993!

     NeXT claims that there will be a DOS 5.0/Windows 3.1 (including DOS
"protected" mode/Win-16 mode) Compatibility  Package  that  will  enable
several  simultaneous DOS and/or Windows programs to run within NeXTSTEP
windows, taking "full advantage of the 486 microprocessor"; Win-32  mode
should  be  supported by mid-1993.  When one combines that with possible
Executor  capability,  one  can  begin  to  see  the  potentially   vast
versatility of such a machine.

     I'll look forward to your reply on these questions whenever you can
get around to it.  Thanks for all your good work so far!

    Robert Gaylord    <[e-mail]>