Executor 2.0/executorv2.0.iso/pc/linux/extra/docs/maillist/text/archive.96/text0390.txt

Text File | 1996-07-25 | 5.4 KB | 127 lines

>>>>> "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]