Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!ut-emx!ccwf.cc.utexas.edu
From: awessels@ccwf.cc.utexas.edu (Allen Wessels)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...)
Message-ID: <42858@ut-emx.uucp>
Date: 21 Jan 91 16:59:07 GMT
References: <42609@ut-emx.uucp> <1991Jan18.050529.13101@zorch.SF-Bay.ORG> <42731@ut-emx.uucp> <1991Jan19.035418.15192@zorch.SF-Bay.ORG> <42792@ut-emx.uucp> <22780@well.sf.ca.us>
Sender: news@ut-emx.uucp
Reply-To: awessels@ccwf.cc.utexas.edu (Allen Wessels)
Organization: The University of Texas at Austin
Lines: 50

In article <22780@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes:
>awessels@ccwf.cc.utexas.edu (Allen Wessels) writes:
>>As I understand them, desk accessaries reside primarily on disk with a pointer
>>to the code on disk.    The desk accessory is invoked via a menu.
>
>You do not understand them.  Desk accessories become part of the system
>file, unless you are running a utility like "Suitcase".  They absolutely
>take up RAM.

I don't think you understand them either.  Just because a resource (in this 
case a DA) is loaded into the System file does NOT mean that it is loaded into
RAM.  That is the whole idea behind using resources.  They are loaded as 
necessary, and the memory is released when the resource is not needed.  (This
is an oversimplification of course.)

One of the annoying things about these discussions is that advantages and
disadvantages of the various systems are exaggerated.  Just because the Mac 
doesn't have Amiga memory management doesn't mean that it has none at all.

>>With 16 Mhz 286s with 256 color VGA and Windows machines running around $1500,
>>some of those advantages are starting to blur.
>
>Nope.  They're getting clearer, as you find that you STILL can't get the
>capability of a $500 Amiga 500 on anything short of a $1500 '386 machine,
>and you can't get some of them even then.

Who ever said that computer manufacturers had to compete on a model for model
basis?  Everybody and their dog has already agreed that the 500 is one of the
best bang/$ computer available.

>>Porting is just a matter of what your development enviroment supports.
>
>Get a life.  You don't understand porting at ALL.  A common library of
>calls does NOTHING for you if you don't have the OS underneath those
>calls.  How, for example, would you propose to simulate CreateProc() on
>a Mac?  Or, for that matter, GetResource() on an Amiga?  You can't.

As I understand porting, there are very few cases in which SOME of the code does
not have to be rewritten.  As usual in these discussions, some people can't
control themselves enough to omit certain kinds of comments.  I never said 
porting was a simple matter of recompiling the source on the new machine.

>Sure, you can move BASIC programs back and forth, mostly.  But BASIC
>is very far from being generally useful, and NEVER the language of
>choice for professional work.

I guess I wasn't clear in pointing out that I knew BASIC wasn't a great 
example.  I suppose if you are careful with your definition of professional,
BASIC is NEVER the language of choice.  Maybe you should advise Microsoft to
stop selling their high-end BASIC development systems.