Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!pacbell!ames!hc!lll-winken!lll-lcc!pyramid!voder!apple!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.amiga
Subject: Re: Feeping Creaturism
Message-ID: <7599@apple.Apple.Com>
Date: 8 Mar 88 19:47:08 GMT
References: <8802181921.AA19069@cory.Berkeley.EDU> <682@sandino.quintus.UUCP> <5295@utah-cs.UUCP> <732@nuchat.UUCP>
Reply-To: lsr@apple.UUCP (Larry Rosenstein)
Organization: Advanced Technology Group, Apple Computer
Lines: 65

Allow me to correct some errors.

>two main reasons are that a program on the Mac has to be written essentially
>as a device driver, and that it's not even entirely examinable unless you
>have another Mac... because the resource fork contains information that is
>integral to dealing with the file but which is unintelligable even when
>it's available to people on other machines.

This is wrong.  A program on the Mac is written much like a program on the
Amiga.  It is not a device driver.  Also, as people have mentioned, it is
possible to get a textual representation of the resources, which would look
much like the equivalent data definitions in an Amiga program.  (The
difference is that the defns are not compiled in and can easily be changed.)

>It has to call the operating system at least once every 100 milliseconds to
>maintain desk accessories.

It is not essential to do this.  It is courteous to keep DAs running, but
most applications do not do this while doing compute-intensive things.

>It has to be built around an "event loop" that handles all events in the
>system, and passes down to other programs the ones it's not interested in.

This is not much different than what you have to do on the Amiga in response
to certain messages.  On the Mac, you can take advantage of frameworks such
as MacApp, which handle these things automatically.  (A programmer using
MacApp has to do a lot less work than an Amiga programmer.)

>It has to allow for arbitrary relocation of large parts of its data as the
>system collects garbage.

The system does not collect garbage and it is not arbitrary.  It coalesces
the memory blocks to prevent heap fragmentation.  This allows the program to
make better use of the available memory.  The programmer can lock these
blocks as needed and can allocate non-relocatable blocks.

>It has to use the resource fork for text messages and displays... so unless
>you have the resource fork in a human-readable form you can't even tell what
>the program's supposed to say.

This is nonsense.  Using resource makes it easy to customize the messages
using a simple program, without recompiling the application.  If you don't
care about this, you just use strings.

>The idea of porting a Mac program to anything else, or porting anyone
>else's programs to the Mac, is pretty much a fantasy. Unless you write a
>badly-behaved Mac program or use A/UX.

People at Microsoft, Aldus, ... would disagree with you.  They ported their
programs between the Mac and Windows.  I have read where this was not a
major effort (provided you allow for this in the first place).

It seems to me that porting an Amiga program would be even more difficult,
unless that program was designed to be ported and didn't take advantage of
the unique Amiga features.

If you start out with a goal of writing a portable application, then you
will isolate the unique features of each machine so that they can be handled
separately.  Much of what goes on in a program deal with data structures and
algorithms, which are universal.  

-- 
		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 32E  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr