Executor 2.0/executorv2.0.iso/pc/dos/extra/docs/maillist/text/archive.95/text2666.txt

Internet Message Format | 1996-03-31 | 5.8 KB

Received: from sloth.swcp.com (sloth.swcp.com [198.59.115.25]) by nacm.com (8.6.10/8.6.9) with ESMTP id JAA19705 for <[e-mail]>; Wed, 5 Jul 1995 09:08:22 -0700
Received: from iclone.UUCP (uucp@localhost) by sloth.swcp.com (8.6.9/8.6.9) with UUCP id KAA03126; Wed, 5 Jul 1995 10:08:19 -0600
Received: from beaut.ardi.com by mailhost  with smtp
    (nextstep Smail3.1.29.0 #11) id m0sTWyq-000YbmC; Wed, 5 Jul 95 10:07 MDT
Received: by beaut.ardi.com (linux Smail3.1.28.1 #5)
    id m0sTWyp-00000BC; Wed, 5 Jul 95 10:07 MDT
Message-Id: <[e-mail]>
Date: Wed, 5 Jul 95 10:07 MDT
From: [e-mail] (Clifford Thomas Matthews)
To: Jeff Tupper <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: Future Questions
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>>>>> "Jeff" == Jeff Tupper <[e-mail]> writes:

    Jeff> [e-mail] (Mat Hostetter):
    >> Long ago Executor was a source-compatible library, but it would
    >> be difficult to resurrect it in that form.  There are also some
    >> very difficult issues for developers involving byte ordering;
    >> have you noticed that all platforms supported by Apple (680x0,
    >> PowerPC, and those supported by MAE) are all "big endian"?

    >> -Mat

    Jeff> Well, I must be missing something, but the platforms
    Jeff> supported by Apple all do so through emulation (in addition
    Jeff> to native code).

This isn't meant to be a flame, just a simple explanation of some of
the reasons Mat said what he said.  Both Mat and I are *extremely*
aware of the issues being discussed.

Yes, one thing you appear to be missing is that Apple does not support
any Mac emulators on little-endian machines.  They support the
original 68k, the PPC, the SPARC and the HP.  Notably absent is the
x86 and Alpha.

    Jeff> If one is emulating 68K code, preserving
    Jeff> endianness is nice, but a fairly easy things for developers
    Jeff> to avoid.

No, the semantics of the Mac system calls are such that endianness has
to be considered everywhere.  If you're not familiar with programming
the Mac, the following may not make sense, but what do you do with
system routines that expect to pick up data in resources?  Should the
resources be stored in native order or canonical (big endian) order?
If you pick the former, then you can't pass files containing resources
around between machines of different endianness.  If you chose the
latter, then you have to do byte swapping yourself if you are going to
use the resource internally.

    Jeff> After all, my program runs on both 68K and x86
    Jeff> [but not VAX].

Your programs are not Mac programs, right?  Big difference (see above).

    Jeff> Just don't write out longs and read them back
    Jeff> as shorts or bytes. Read data in the same way you wrote it
    Jeff> out.

See?  You overlooked the system service issue.  Remember, the system
services that MacOS provides are already cast in stone.  We're talking
about tools to enable *existing* applications to be ported, not the
possibility of writing tools that work well with new code.

    Jeff> You have to have architecture independant file code but
    Jeff> that can be done easily as well.

Nope.  Same problem.  There are a variety of file formats that are
*already* defined.  Hence the programmer has to be aware of the byte
swapping issues.  That makes for significant amounts of extra code to
write.  Guess what happens when you provide tools that aid in this
process, but still require the end-user (i.e. the programmer doing the
port) to pay careful attention to these things?  You get tons of calls
by irate programmers saying "the tools don't work", and you know what?
They'll be right -- one out of ten times.  That one out of ten will
teach them not to trust the tools (the tools we're talking about are
prone to the same clean-room development incompatibility issues that
Executor is), so everytime something goes wrong, the tools will be blamed.

    Jeff> What would be difficult to
    Jeff> do is handle WMF/BMP files as PICT files - probably not
    Jeff> worth the hassle, just let developers write a bit of code
    Jeff> for that. (Well, it could be done - just warn developers
    Jeff> about the holes) Accessing bitmaps/video would have to be
    Jeff> patched up too, but none of this is as much work as porting
    Jeff> to a different API (all this would be done, plus a whole
    Jeff> bunch more :)

In some cases you're right, in some cases not.  Some programs would
port more easily using such tools than others.  However, we discovered
years ago that it is impossible to offer such tools when you're a
small company.  After 2.0 is shipping, if we have boatloads of cash,
it may make sense for us to reimplement what we had before.  However,
the tools would either be expensive or would have very high technical
support fees tied to them.

Remember, this is what ARDI originally did.  We ran into all the
problems mentioned above, and more.  Back then people would also ask
us whether or not our tools would be good enough to port, say,
Microsoft Word.  We'd answer "Yes.  <pause>  We think."  We'd then
have to explain that we would never see the source to Microsoft Word,
so all such answers would be speculation.  Eventually, to silence our
critics, we wrote some glue and made a small program that would run
Macintosh binaries -- you guessed it -- that program was Executor.

Once Executor got a little better, it was clear that we'd do much
better working on and selling Executor -- in fact, we even had a
couple of profitable months back in NEXTSTEP's heyday, back before
NeXT stopped making hardware, but that's another story.

    --Cliff
    [e-mail]