Executor 2.0/executorv2.0.iso/pc/dos/extra/docs/maillist/text/archive.96/text0251.txt

Text File | 1996-07-25 | 12.1 KB | 292 lines

I just came across this newsgroup when I was surfing the net
yesterday...can anybody what exactly is executor and where can I get the
software?  Is it a shareware or something really special?

--
Patrick Shu
[e-mail]

From owner-paper Fri Jan 26 11:05:28 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tfsWd-0007qHa; Fri, 26 Jan 96 11:05 MST
Sender: owner-paper
Received: from nacm.com by ftp.ardi.com with smtp
    (Smail3.1.29.1 #3) id m0tfsW4-0007qGC; Fri, 26 Jan 96 11:04 MST
Received: from kitsune.swcp.com (swcp.com [198.59.115.2]) by nacm.com (8.6.10/8.6.9) with ESMTP id KAA21040 for <[e-mail]>; Fri, 26 Jan 1996 10:04:22 -0800
Received: from ftp.ardi.com ([e-mail] [204.134.8.1]) by kitsune.swcp.com (8.6.9/8.6.9) with SMTP id LAA02209; Fri, 26 Jan 1996 11:04:15 -0700
Received: from gwar.ardi.com by ftp.ardi.com with bsmtp
    (Smail3.1.29.1 #3) id m0tfsVn-0007qGC; Fri, 26 Jan 96 11:04 MST
Received: by gwar.ardi.com (Smail3.1.29.1 #3)
    id m0tfsSf-000GXNC; Fri, 26 Jan 96 11:01 MST
Message-Id: <[e-mail]>
Date: Fri, 26 Jan 96 11:01 MST
From: [e-mail] (Mat Hostetter)
To: [e-mail] (Scott Wurcer)
Cc: [e-mail]
Subject: Re: 24 bit colors under E/D
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>>>>> "Scott" == Scott Wurcer <[e-mail]> writes:

    Scott> The original poster said that he had a Linux machine w/1Meg
    Scott> of vram and a 24bit card available. Does XFree86 + E/L
    Scott> support truecolor, hence 256 grays?

Yes.  Executor internally can still only do 8-bit graphics, but if you
run it on a system with a 16-bit or 24-bit X server, Executor maps its
internal pixels to the X server's RGB pixels as they are displayed.
This means that the accuracy of the pixel colors is limited only by
the accuracy of your card's RGB colors.

You can also run Executor in "-privatecmap" mode even on 8-bit X
servers, which should give you 8-bit colors as accurate as the X
server provides.  I'd guess that XFree86 does a good job of using
8/8/8 DACs where available.

-Mat

From owner-paper Fri Jan 26 19:13:44 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tg098-0007qHa; Fri, 26 Jan 96 19:13 MST
Sender: owner-paper
Received: from ardi.com by ftp.ardi.com
    (Smail3.1.29.1 #3) id m0tg08b-0007qGn; Fri, 26 Jan 96 19:13 MST
Path: sloth.swcp.com!usenet
From: Clifford T. Matthews <[e-mail]>
Newsgroups: comp.emulators.mac.executor
Subject: Re: Arachnid 1.9
Date: 26 Jan 1996 18:31:09 -0700
Organization: ARDI
Lines: 23
Distribution: na
Message-ID: <[e-mail]>
References: <[e-mail]>
NNTP-Posting-Host: ftp.ardi.com
In-reply-to: [e-mail]'s message of Mon, 22 Jan 1996 01:51:01 GMT
X-Newsreader: Gnus v5.0
To: [e-mail]
X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
Sender: [e-mail]
Precedence: bulk

>>>>> "Justin" == Justin Seiferth <[e-mail]> writes:
In article <[e-mail]> [e-mail] (Justin Seiferth) writes:


    Justin> I'm very interested in getting the WYSIWYG HTML editor
    Justin> Arachnid running under executor.  So far I've specified 6M
    Justin> memory and system 7 in an attempt to get it running but it
    Justin> just hangs executor 1.99q before even the main menu is
    Justin> displayed.  Anyone found a combination of command line
    Justin> options which allows Arachnid to run?  It's very slick on
    Justin> my powerbook and would be a great reason to use Executor.

We're willing to take a quick look at the problem if there is a demo
of Arachnid that we can pick up and look at.

Pagemill won't run because it *requires* the Drag and Drop extension.
Foo.  One more reason for us to support extensions -- after E2 is out,
though.

    Justin> Hopefully...  Justin

--Cliff
[e-mail]

From owner-paper Fri Jan 26 21:14:03 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tg21V-0007qHa; Fri, 26 Jan 96 21:13 MST
Sender: owner-paper
Received: from ardi.com by ftp.ardi.com
    (Smail3.1.29.1 #3) id m0tg20u-0007qGn; Fri, 26 Jan 96 21:13 MST
Path: sloth.swcp.com!usenet
From: Clifford T. Matthews <[e-mail]>
Newsgroups: comp.sys.mac.advocacy,comp.emulators.mac.executor
Subject: Re: Can Quix save Apple?
Date: 26 Jan 1996 21:02:07 -0700
Organization: ARDI
Lines: 125
Message-ID: <[e-mail]>
References: <1996Jan14.170950.1@ugsc2a> <[e-mail]>
    <[e-mail]>
NNTP-Posting-Host: ftp.ardi.com
In-reply-to: [e-mail]'s message of Wed, 24 Jan 1996 22:35:11 -0700
X-Newsreader: Gnus v5.0
Xref: sloth.swcp.com comp.sys.mac.advocacy:83331 comp.emulators.mac.executor:919
To: [e-mail]
X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
Sender: [e-mail]
Precedence: bulk

>>>>> "bayleyp" == bayleyp  <[e-mail]> writes:
In article <[e-mail]> [e-mail] (bayleyp) writes:


    >> > >Personally, I think there are irreversible aspects of such a
    >> decision, >because once the System 7 brought to Intel machines,
    >> the customer will >no more rely on Apple's hardware, but on the
    >> other side, is not too >much risky a move, becaus of the
    >> possibility to have the Copland running >only on true Macs, or
    >> other similar arrangements.  >
    >>
    >> MacOS is a stupid idea on Wintel machines - it'd be slower and
    >> there would be mountains of work involved to getting it to run
    >> on all Wintel systems - you're forgetting in the Wintel world
    >> there's no such thing as standards.
    >>
    >> Another thing, why is everybody predicting gloom just because
    >> they had a lousy quarter?? Their whole year was profitable,
    >> their marketshare increased, their sales increased. Why is this
    >> a bad thing?

In my reply below, I mention Executor, our Macintosh emulator for the
PC.  I am not trying to claim that Executor is the MacOS running on PC
hardware, because it isn't.  Specifically it's a "synthetic CPU" that
allows 68k based programs to run on the PC combined with our *rewrite*
of the MacOS which we did with no help from Apple (none at all -- we
didn't disassemble any of Apple's ROMs or their System file).  Because
we use our own OS/Toolbox rewrite, we don't have as much functionality
or compatibility as a real Mac, but that's irrelevant for the purposes
of this discussion, since Executor does do a very good job of mapping
things at a low-level.

    bayleyp>    It's not the standards..mac have their own standards
    bayleyp> and drivers. What makes it such a crappy platfrom is 8086
    bayleyp> shit. 64k code limits...640k RAM along with 1000 other
    bayleyp> types of RAM used to bypass Intel...

Starting with the 80386 the x86 line can be programmed using a flat
memory model.  Windows '95, OS/2 and Linux all are programmed using a
flat memory model.  DOS can be programmed that way with a DOS
extender.

    bayleyp> BIOS...

The BIOS could be used solely to boot one of the above operating
systems.  If the work were done on top of Linux, the end product would
not require anything from Microsoft.

    bayleyp> IRQ along with

IRQs can still be tricky, but it's still possible to come up with
generic configurations that will work on a very large subset of recent
PCs, which is a substantial bit more than MacOS works on what's out
there now.

    bayleyp> ISA extenders...Little endianness, this one is a biggie
    bayleyp> because everything is effected by this like Disk IO (all
    bayleyp> PC buses are Little endian)...

Little endianness is indeed a very big concern.  None of Apple's MAE
products have yet been ported to work on little endian machines, and
MAE would be the likely in-house starting point were Apple to consider
such a task.  Still, Executor gets around the little endian problems
by using a sophisticated synthetic CPU
(ftp://ftp.ardi.com/pub/SynPaper describes it in detail).

Disk I/O itself is not affected by endianness, though.

    bayleyp> Irregular 8086 code along
    bayleyp> with it's limitations (I won't fill a page of them for
    bayleyp> your sake)...

I am well versed in x86 vs. m68k differences, but I don't know what
you mean above.  I doubt it's anything that we haven't already
addressed in Executor, though.  In fact, although as a product,
Executor has a fairly narrow audience (due to its limitations), I
think it is a very good proof of concept.  The things that are
preventing Executor from running full System 7.5 aren't nebulous
problems like "irregular 8086 code", but just that we have done all
our work without looking at *any* of Apple's ROM or System files.

    bayleyp> a bunch of IO including soundBlaster,

The vast majority of the Sound Manager that is actually used by
software can be done using SoundBlaster calls.

    bayleyp> parallel,

Printer support would require more work, which is why we've
sidestepped it for now.  However, the work involved wouldn't be that
hard, especially if Apple made a parallel printer that could be used
with this hypothetical port of MacOS to the PC.  Apple's pretty good
at making printers, too.

    bayleyp> keyboard and serial mouse,

Not that big of a problem for most apps, although special adb hardware
would be needed if Apple were to want to get all adb devices to work,
too.

    bayleyp> graphics are direct
    bayleyp> video unless you use one of the four graaphics card
    bayleyp> standards fighting it out...etc etc etc...

VESA 2 is available for most new video cards and drivers such as
UniVBE allow many older video cards to appear VESA 2 compliant.  Two
years ago this wasn't true and it was a big impediment to us (which is
one reason Executor was black and white two years ago).

    bayleyp> The truth is
    bayleyp> that Intel has standards, but it's the Mac standards that
    bayleyp> make the MacOS shine overall

The vast majority of the MacOS standards are at a sufficiently high
level that once you do the low-level mapping, all the high level stuff
will "just work".  Doing the low-level mapping is indeed very
difficult, but as Executor demonstrates, not impossible.

More information, including a demo version, can be found on
http://www.ardi.com/.  There's also an Executor newsgroup,
comp.emulators.mac.executor to which I've added to the Newsgroups
line.

--Cliff
[e-mail]

From owner-paper Sat Jan 27 01:14:06 1996
Return-Path: <owner-paper>
Received: by ftp.ardi.com (Smail3.1.29.1 #3)
    id m0tg5ll-0007qHa; Sat, 27 Jan 96 01:13 MST
Sender: owner-paper
Received: from ardi.com by ftp.ardi.com
    (Smail3.1.29.1 #3) id m0tg5l7-0007qGn; Sat, 27 Jan 96 01:13 MST
Path: sloth.swcp.com!ns2.mainstreet.net!aimnet.com!netserv.com!pagesat.net!news.ossi.com!agate!nickkral
From: [e-mail] (Nick Kralevich)
Newsgroups: comp.emulators.mac.executor
Subject: Re: ARDI mentioned in MacWEEK !
Date: 26 Jan 1996 20:04:56 GMT
Organization: Electrical Engineering Computer Science Department, University of California at Berkeley
Lines: 16
Message-ID: <4ebc58$[e-mail]>
References: <4dr37t$[e-mail]>
NNTP-Posting-Host: parker.eecs.berkeley.edu
To: [e-mail]
X-MailNews-Gateway: From newsgroup comp.emulators.mac.executor
Sender: [e-mail]
Precedence: bulk

In article <4dr37t$[e-mail]>,
Ernst J. Oud <[e-mail]> wrote:
>emulator. Version 2.0 will run on Intel-standard PCs, in addition to the
>Unix and NeXT platforms currently supported.

Throughout the article, all they did was mention "UNIX",
instead of "Linux".  I wonder why...  After all, as far as I know,
the "UNIX" version of executor consists only of the "Linux" version.

It would be nice to see more mention of Linux in the mainstream
presses.

Take care,
-- Nick Kralevich
   [e-mail]