🚀 go-pugleaf

>In article <7463@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
>In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes:
>> Does anyone know how to FORCE a guru through C?
>
>	char *p;
>
>	for(p = 0; p != (char *)-1; p++)
>		*p = 0;
>
>This will certainly clobber the machine. Play with variations until you get
>the results you want. (sigh)
>-- 
>Peter da Silva.   `-_-'
><peter@sugar.hackercorp.com>.

Gee, Peter, that's a lot cleaner than using the exec Alert() function...

--
| ben@epmooch.UUCP   (Ben Mesander)       | "Cash is more important than |
| ben%servalan.UUCP@uokmax.ecn.uoknor.edu |  your mother." - Al Shugart, |
| !chinet!uokmax!servalan!epmooch!ben     |  CEO, Seagate Technologies   |

>>>>> In article <611@caslon.cs.arizona.edu>, 
>>>>> dave@cs.arizona.edu (Dave P. Schaumann) writes:

Dave> [...]
Dave> There is a solution to this.  It's called virtual memory.  It takes an MMU,
Dave> which is not available to the 68000.  However, the 68030 has one.  I think this
Dave> is something CBM should be seriously considering putting into their next major
Dave> release of Workbench.

Virtual memory does not provide protection between processes.  Virtual
memory provides a transparent way to address more memory than a
machine really has.  Memory mapping and memory protection mechanisms
(which are also provided by an MMU) provide the protection you are
referring to.

In addition, putting memory protection into AmigaDos is not as easy as
you imply.   It  will   break the  vast  majority  of   existing Amiga
programs.  All interprocess communication  in the Amiga  is done using
shared memory techniques.  Guidelines for writing programs in a manner
upwardly compatible with future memory protection  mechanisms have not
existed for a long time, and have not been religiously followed in any
case.

Almost  every "hot" game  written for   the Amiga would  fail to work,
since they  almost  all  go right to   the hardware, which    would be
disallowed in a protected AmigaDos.

In   summary, I agree that    it is true   that  memory protection  is
something  which the Amiga  needs, but it is not  that easy to achieve
(due to the  initial  design  decisions made in creating AmigaDos  (or
Exec, if you  prefer)) and in most  cases,  judicious selection of the
programs you run in your system should keep you out of trouble most of
the time.  If a program GURUs your machine, throw it away!

Hamish.
--
--------------------------------------------------------------------
himacdon@maytag.uwaterloo.ca                 watmath!maytag!himacdon

  Larry Phillips says about preventing GURU visits:
>> A new OS will not protect you from errors in your code, or ill-behaved
>> programs, or hardware failures. Investigate; do some digging.

 Dave Schaumann replies:
> Those are some rather flip answers to what, IMHO, is the Amiga's greatest
> shortcoming: any program can crash the whole system quite easily.

Umm. But they were correct answers for the _real world_ case: the current
Amiga OS/hardware configuration.  Blue-skying begs the question.

> To my mind, this is unacceptable in a multitasking machine.
> I believe that CBM has got away with it up til now because no-one
> else even had multitasking.  [...]  Who wants a computer when
> one unstable program makes the whole platform unstable?

There are three main scenarios for multitasking machines:
  1. Used by developer only
  2. Used by end user only
  3. Used by both developer and enduser

In (1), crashing is a pain, but not "unacceptable".  In (3), crashing
would be unacceptable...on a multiuser system... but since almost all Amigas
are **single-user** systems, the offending programmer is also the enduser
and should surely recognize when he's about to try something dangerous ;-).

That leaves (2), and the culling out of unstable programs renders a totally
stable enduser system... it's as simple as that.

So in return, here's _my_ own beefs <g>:  First, the unspeakable horror
of today's CS majors who rely on hardware to catch their mistakes.  Second,
the unrealistic expectation that inexpensive personal computers should have
all the bells and whistles of the expensive "machines I use at school".

Now I'll backtrack -- Yes, hardware protection is A Good Thing (so go buy
a $99 Tandy CoCo-3... it's got an MMU :).  And I'd be terribly surprised if
Amiga Unix doesn't use it.  Further, I think you're right that _eventually_
all personals will have and use an MMU.  But I also think it's gonna take
some radical changes to most current personal OS's to add that capability.
Or rather, it would break most current programs.
  best - Kevin  <kdarling@catt.ncsu.edu>  <76703.4227@compuserve.com>

Does anyone know how to FORCE a guru through C? What includes, etc, and
maybe a ForceGuru() call? I have a program where if you enter an incorrect
response, it is supposed to guru. Does anyone have a sure-fire routine?


-- 
        Joseph Hillenburg, Secretary, Bloomington Amiga Users Group
iuvax!news!valnet!joseph        jph@ais.org          anlhille@iubacs.BITNET
       "Only Apple could slow down a 68030 chip" --Computer Shopper

In article <1991Jan4.224833.24914@ncsuvx.ncsu.edu> kdarling@hobbes.ncsu.edu (Kevin Darling) writes:
>  Larry Phillips says about preventing GURU visits:
>>> A new OS will not protect you from errors in your code, or ill-behaved
>>> programs, or hardware failures. Investigate; do some digging.
>
> Dave Schaumann replies:
>> Those are some rather flip answers to what, IMHO, is the Amiga's greatest
>> shortcoming: any program can crash the whole system quite easily.
>
>Umm. But they were correct answers for the _real world_ case: the current
>Amiga OS/hardware configuration.  Blue-skying begs the question.

	Correct.  First of all, 80-90% of all Amigas do not have an MMU, and
aren't likely too (though maybe eventually - nowhere near soon - low-end
machines may have MMUs).  Also, using protected-process-techniques for 
inter-process communication would slow down the OS a lot (unacceptably so
on a 68000 machine).  They add a lot of overhead, and add it even when there's
no MMU in the system.  Witness the Bill Gates comments that multitasking will
require 4Meg, a 386, and your first-born son.

>There are three main scenarios for multitasking machines:
>  1. Used by developer only
>  2. Used by end user only
>  3. Used by both developer and enduser
>
>In (1), crashing is a pain, but not "unacceptable".  In (3), crashing
>would be unacceptable...on a multiuser system... but since almost all Amigas
>are **single-user** systems, the offending programmer is also the enduser
>and should surely recognize when he's about to try something dangerous ;-).

	Amigas also boot about 10-100 times faster than most Unix boxes.
If you care and are a developer, test programs on a second machine - they're
cheap, and it helps to have a base configuration around to test on.  (Since
most developers are running '030's with lots of mem and HD nowadays).

	Personally, I usually test stuff on my development machine.  We have
enough debugging utilities (such as enforcer) that I rarely have to reboot
(though installing a dead Dos will force it... ;-)

>That leaves (2), and the culling out of unstable programs renders a totally
>stable enduser system... it's as simple as that.

	And Commodore has been working HARD to provide developers with 
utilities to make code bug-free when shipped.  Enforcer, Mungwall (aka
MemMung and MemWall), io_torture, suck, snoop, drip, scratchr, memoration
(those last two from Bill Hawes), angel (traps free mem references with the
MMU), etc, etc.

	If something passes all of these, it's damn safe.  How many Unix
programmers do you know who ever tested their memory allocation failure
paths (or other uncommon failure paths)?  With memoration, it's easy (and
we're using it to check all the failure paths in the ROMs for 2.0x).  The
combination of Mungwall and Angel (or enforcer) should cover almost all
problems related to the fact that it's shared-memory OS.

>So in return, here's _my_ own beefs <g>:  First, the unspeakable horror
>of today's CS majors who rely on hardware to catch their mistakes.  Second,
>the unrealistic expectation that inexpensive personal computers should have
>all the bells and whistles of the expensive "machines I use at school".

	In an A500, true.  An A3000 does have them, which is why it also makes
a good Unix platform, or a _really_ fast AmigaDos platform.

>a $99 Tandy CoCo-3... it's got an MMU :).  And I'd be terribly surprised if
>Amiga Unix doesn't use it.  Further, I think you're right that _eventually_
>all personals will have and use an MMU.  But I also think it's gonna take
>some radical changes to most current personal OS's to add that capability.
>Or rather, it would break most current programs.

	MMU's (at least for modern processors) aren't cheap, and '030's aren't
cheap enough to put in A500's.  They will be, one day, but not soon.  Oh, and
of course Amiga Unix uses the MMU (Unix effectively requires it, along with
massive amounts of memory and HD and CPU power - at least compared to AmigaDos).

	AmigaDos isn't likely to support protection any time soon - it's not
designed for it, and attempting to add it would break almost any program that
uses anything more complex than Dos functions (tty-style).  This may be a
(very slight) exaggeration, but it's mostly true.  VM is far easier.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)

In article <611@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes:
> Those are some rather flip answers to what, IMHO, is the Amiga's greatest
> shortcoming: any program can crash the whole system quite easily.  To my mind,
> this is unacceptable in a multitasking machine.

But the same is true for the multitasking offerings from Apple, IBM, and other
PC manufacturers. Rather than CBM having "got away with it up til now", it's
gotten an undeserved bad reputation. Now that other PC manufacturers are
starting to offer multitasking without protected memory perhaps that will
change.
-- 
Peter da Silva.   `-_-'
<peter@sugar.hackercorp.com>.

In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes:
> Does anyone know how to FORCE a guru through C?

	char *p;

	for(p = 0; p != (char *)-1; p++)
		*p = 0;

This will certainly clobber the machine. Play with variations until you get
the results you want. (sigh)
-- 
Peter da Silva.   `-_-'
<peter@sugar.hackercorp.com>.

In article <17130@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
> 	And Commodore has been working HARD to provide developers with 
> utilities to make code bug-free when shipped.  Enforcer, Mungwall (aka
> MemMung and MemWall), io_torture, suck, snoop, drip, scratchr, memoration
> (those last two from Bill Hawes), angel (traps free mem references with the
> MMU), etc, etc.

Um, where do you *get* these. I'm a developer, I have the Autodocs, and I have
Enforcer (it came unannounced on an update disk), but I've never heard of the
majority of these programs. What should I be ordering?

Please answer in the newsfroup... I suspect I'm not the only one.
-- 
Peter da Silva.   `-_-'
<peter@sugar.hackercorp.com>.

In article <V2H++Q_@irie.ais.org>, jph@ais.org (Joseph Hillenburg) writes:
> Does anyone know how to FORCE a guru through C? What includes, etc, and
> maybe a ForceGuru() call? I have a program where if you enter an incorrect
> response, it is supposed to guru. Does anyone have a sure-fire routine?
> 

BLOODY HELL!!!!!!!

What's wrong with a nice little requester saying:

	"Oh, you naughty boy! You entered the incorrect response!"

	-----------------                ----------------
	| Oh I am silly |                |  I'm so dumb |
	-----------------                ----------------

Why the hell do you have to crash the machine??

Regards Alan

jph@ais.org (Joseph Hillenburg) writes:

>Does anyone know how to FORCE a guru through C? What includes, etc, and
>maybe a ForceGuru() call? I have a program where if you enter an incorrect
>response, it is supposed to guru. Does anyone have a sure-fire routine?

  Depends *which* guru you want.  Divide a number by zero and you'll generate
a #5 guru.  Reference an odd address with a 68000 Amiga and you'll also do
it.

  -jack-

In article <1991Jan4.203339.8800@maytag.waterloo.edu> himacdon@maytag.uwaterloo.ca (Hamish Macdonald) writes:
>>>>>> In article <611@caslon.cs.arizona.edu>, 
>>>>>> dave@cs.arizona.edu (Dave P. Schaumann) writes:
>
>Dave> [...]
>Dave> There is a solution to this.  It's called virtual memory.  It takes an MMU,
>Dave> which is not available to the 68000.  However, the 68030 has one.  I think this
>Dave> is something CBM should be seriously considering putting into their next major
>Dave> release of Workbench.

I think there is a bright young PhD student trying to get his degree by
putting VM into the AmigaOS.  This does not, however, imply memory
protection.  See below.

>Virtual memory does not provide protection between processes.  Virtual
>memory provides a transparent way to address more memory than a
>machine really has.  Memory mapping and memory protection mechanisms
>(which are also provided by an MMU) provide the protection you are
>referring to.
>
>In addition, putting memory protection into AmigaDos is not as easy as
>you imply.   It  will   break the  vast  majority  of   existing Amiga
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>programs.  All interprocess communication  in the Amiga  is done using
 ^^^^^^^^
>shared memory techniques.  [...]

>Almost  every "hot" game  written for   the Amiga would  fail to work,
>since they  almost  all  go right to   the hardware, which    would be
>disallowed in a protected AmigaDos.

I don't care much about existing programs.  If the Amiga could provide
a more stable development environment, so we know that, when the
equivalent of Unix's reference through NULL pointer or the many other
things that cause a reboot on the Amiga as is, does not mean that the
machine needs to be rebooted.  This would speed up development and allow
programmers to write more correct programs that will make everybody's
lives easier.  I know if the SunOS machines that our schools had to be
rebooted every time one of these problems happened (instead of the usual
core dump or whatever) noone would finish programs in time!

>In   summary, I agree that    it is true   that  memory protection  is
>something  which the Amiga  needs, but it is not  that easy to achieve

Even fake memory protection would due for many of us.  How about a
command like "run such and such a program so it doesn't touch anything
other than the OS".  It gets its own space, tucked away from the rest of
the system?

>(due to the  initial  design  decisions made in creating AmigaDos  (or
>Exec, if you  prefer)) and in most  cases,  judicious selection of the
>programs you run in your system should keep you out of trouble most of
>the time.  If a program GURUs your machine, throw it away!

It's not just running programs, it's developing!  Native development is
where it's at right now, and if that is made more difficult on the Amiga
then people will be more likely to develop for some other machine, and
maybe port it over to the Amiga some other time.

I don't mean to sound like a downer.  I'm sure Commodore would love to
see this sort of thing implemented, too.  It's a definite minus, but it
won't keep me from buying an A3000 later this year.  (A war in the
Persian Gulf might, but this wouldn't.)

>Hamish.
>--
>--------------------------------------------------------------------
>himacdon@maytag.uwaterloo.ca                 watmath!maytag!himacdon

--
Chris Dailey   dailey@(frith.egr|cpsin.cps).msu.edu
BRD += DDR;           __  __  ___
DDR = NULL;      \\__/  \/  \/ __:>-
num_countries --;  \__/\__/\__/ Snake in the Grass

In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes:

> Does anyone know how to FORCE a guru through C? What includes, etc, and
> maybe a ForceGuru() call? I have a program where if you enter an incorrect
> response, it is supposed to guru. Does anyone have a sure-fire routine?

 Yes! Make a short assembler program:

Crash:	illegal
end

 And call Crash when you want to crash your Amiga. Only use for this I can
imagine is if you are making a guru-killer program (like GOMF or GURU).

 MIT

--
Bubble Bobble

In article <17130@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
>	Correct.  First of all, 80-90% of all Amigas do not have an MMU, and
>aren't likely too (though maybe eventually - nowhere near soon - low-end
>machines may have MMUs).  Also, using protected-process-techniques for 
>inter-process communication would slow down the OS a lot (unacceptably so
>on a 68000 machine).  They add a lot of overhead, and add it even when there's
>no MMU in the system.  Witness the Bill Gates comments that multitasking will
>require 4Meg, a 386, and your first-born son.

  Couldn't you just make all inter-process communication be done using
MEMF_PUBLIC memory? As it was supposed to be? Since most people didn't do
this, Maybe make all the Message functions automagically force the
exchanged memory to be MEMF_PUBLIC temporarily. It'd be a pain, and a
megakludge, but it might work.

  As for Bill Gates: Did anyone else notice the InfoWorld Christmas-list
column, wherein they suggested that he wants a Video Toaster for Christmas,
to produce his next "IBM/Microsoft invented/is-leading-the-market-in
multimedia" video?

>	AmigaDos isn't likely to support protection any time soon - it's not
>designed for it, and attempting to add it would break almost any program that
>uses anything more complex than Dos functions (tty-style).  This may be a
>(very slight) exaggeration, but it's mostly true.  VM is far easier.

  Agreed, adding protection might break large quantities of stuff. How
about some kind of retrofit? Create a new object file hunk, say HUNK_FLAGS,
which tells you intimate info about the program that LoadSeg is bringing in.
You could have a flag to signify "I'm a nice program and I work well under
memory protection, so protect me if you can". This would also be an
excellent place to finally settle the PURE code problem. Make a hunk flag
that signifies, regardless of what the FS bit says, "This code is pure,
damnit." ;)

>Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
>{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  

   Chris - Xenon

-- 
#define chanson Christopher_Eric_Hanson || Lord_Xenon || Kelson_Haldane 
I work, but you don't know who I work for. And they don't know I'm here.
"We apologize for the inconveniences." -GOD. (According to D. Adams)

In article <7465@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
>In article <17130@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
>> 	And Commodore has been working HARD to provide developers with 
>> utilities to make code bug-free when shipped.  Enforcer, Mungwall (aka
>> MemMung and MemWall), io_torture, suck, snoop, drip, scratchr, memoration
>> (those last two from Bill Hawes), angel (traps free mem references with the
>> MMU), etc, etc.
>
>Um, where do you *get* these. I'm a developer, I have the Autodocs, and I have
>Enforcer (it came unannounced on an update disk), but I've never heard of the
>majority of these programs. What should I be ordering?

	Enforcer is available both on the kickfile disks, and on BIX and
perhaps other networks for downloading.  Scratchr and memoration are
definitely on BIX, and io_torture almost certainly is (and/or some devcon
disk), as is MungWall (a combination of MemMung and a "wall" test around
allocations to catch things like strcpy(AllocMem(strlen(str)),str)).  Most of
the rest are things from the software toolkit, either old or revised (though I
don't know when the revised Toolkit will be available - check with CATS).  I
don't know what the story with angel is - it did have a few problems, and
_really_ eats the CPU alive.

Remember, we do official developer support on BIX, not anywhere else - our
messages here are unofficial and on a personal basis.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)

In article <1991Jan5.200226.19718@msuinfo.cl.msu.edu> dailey@frith.uucp (Chris Dailey) writes:
>I think there is a bright young PhD student trying to get his degree by
>putting VM into the AmigaOS.  This does not, however, imply memory
>protection.  See below.

	Hmmm.  BTW, it's been done once already by a student in Canada (not
that something having been done before is a disqualification, especially if
exactly what is done or attempted is different).

>I don't care much about existing programs.  If the Amiga could provide
>a more stable development environment, so we know that, when the
>equivalent of Unix's reference through NULL pointer or the many other
>things that cause a reboot on the Amiga as is, does not mean that the
>machine needs to be rebooted.  This would speed up development and allow
>programmers to write more correct programs that will make everybody's
>lives easier.  I know if the SunOS machines that our schools had to be
>rebooted every time one of these problems happened (instead of the usual
>core dump or whatever) noone would finish programs in time!

	A one word answer: enforcer.  It traps out all reads to the lowest
1K of memory (except location 4, of course) and all writes to that
area.  Things that use NULL (or funny) pointers don't trash the system
(at least in that way - if they're confused enough, they may trash something
like the free memory list).

	BTW, since my amiga boots in about 15 seconds, it bothers me much less
than rebooting a sun would (5-10 minutes, a few more to get set up).

>Even fake memory protection would due for many of us.  How about a
>command like "run such and such a program so it doesn't touch anything
>other than the OS".  It gets its own space, tucked away from the rest of
>the system?

	The problem is defining "it's own space".  What is part of the OS,
and what is part of an App?  What if an "application" (let's say Mount)
allocates a data structure and adds it to a system list?

>It's not just running programs, it's developing!  Native development is
>where it's at right now, and if that is made more difficult on the Amiga
>then people will be more likely to develop for some other machine, and
>maybe port it over to the Amiga some other time.

	Ever notice what happens on a Mac or pcclone when you run a program
you're developing?  If it's bad, you almost always have to reboot.  Actually,
AmigaDos does a better job of trapping errors (the infamous "software error"
requester) - PC's usually just lock up, and Macs either lock up or put up the
"bombs" - almost as bad.  With the amiga, if the program didn't trash the
system, your other processes continue to work, and you can muck around in
a debugger to figure out what went wrong.  If I know why something died
(i.e. that it wouldn't have trashed anything it didn't own), or am fairly
certain, I may continue to use the system for a short while before rebooting
(part of the purpose for the "suspend" option under 2.0).  For example, if
something I wrote dies with divide by zero because of a missing check, I'll
add the check and recompile without rebooting.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)

In article <1991Jan5.213642.16547@isis.cs.du.edu> chanson@isis.UUCP (Chris Hanson) writes:
>  Couldn't you just make all inter-process communication be done using
>MEMF_PUBLIC memory? As it was supposed to be? Since most people didn't do
>this, Maybe make all the Message functions automagically force the
>exchanged memory to be MEMF_PUBLIC temporarily. It'd be a pain, and a
>megakludge, but it might work.

	Won't work.  A message usually has pointers to other areas of
arbitrary memory, or has an extended structure (ala StandardPacket), etc, etc.
As has been discussed before, MEMF_PUBLIC can't be used since each person
has had a different idea as to what should be public and what shouldn't.

>  As for Bill Gates: Did anyone else notice the InfoWorld Christmas-list
>column, wherein they suggested that he wants a Video Toaster for Christmas,
>to produce his next "IBM/Microsoft invented/is-leading-the-market-in
>multimedia" video?

	:-)

>  Agreed, adding protection might break large quantities of stuff. How
>about some kind of retrofit? Create a new object file hunk, say HUNK_FLAGS,
>which tells you intimate info about the program that LoadSeg is bringing in.
>You could have a flag to signify "I'm a nice program and I work well under
>memory protection, so protect me if you can". This would also be an
>excellent place to finally settle the PURE code problem. Make a hunk flag
>that signifies, regardless of what the FS bit says, "This code is pure,
>damnit." ;)

	A better idea.  You _could_ allow segments of code from a loadfile
to be protected (at least without many problems), and you could allow 
applications to request protected memory.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
The compiler runs
Like a swift-flowing river
I wait in silence.  (From "The Zen of Programming")  ;-)

The best thing to do to guard yourself from GURU's during software development
is to use a debugger to run your code.  There is one available on a relatively
recent fred fish disk which will suffice to debug software that doesn't take
over the display in some fashion.  Even then you could patch it to open aux:
instead of a con: window, and hook it up to a terminal.  In either case,
you can have the debugger run the code in 68000 trace mode so that any guru
inspiring phenomena will just return to the debugger rather than bring the
system down.  This won't catch all possible errors, though.. you can still feed
a system function bad information, as well as overwrite system structures.

Has anyone written a debugger that will try to watch out for your code a bit?
That is, that will monitor the PC during a trace and let you specify various
behaviors if your task goes outside of a certain set of memory regions?

-------------------------------------------------------------------------------
Jonathan Abbey				      The University of Texas at Austin
x194@cs.utexas.edu			     Computer Science-Math?-Psychology?

-- 

In article <133@atacama.cs.utexas.edu> x194@cs.utexas.edu (Jonathan Abbey) writes:
>[...]
>Even then you could patch it to open aux:
>instead of a con: window, and hook it up to a terminal.

How would you do this?  I have heard about being able to hook up a terminal
to help debug gurus, but I've never seen any documentation on How To Do It.

What kind of a terminal do you need?  Any & all pointers would be appreciated!

>Jonathan Abbey				      The University of Texas at Austin
>x194@cs.utexas.edu			     Computer Science-Math?-Psychology?

Dave Schaumann		| My folks went to uunet.uu.net, but all
dave@cs.arizona.edu	| they got me was this lousy .sig...

G'day,

RJ> Randell Jesup (jesup@cbmvax.commodore.com ) writes:

First of all, thanks Randell for your private time and efforts you put into
helping out in things Amiga in this group.

CH> Chris Hanson (chanson@isis.UUCP) writes:
[...]
CH>   Agreed, adding protection might break large quantities of stuff. How
CH> about some kind of retrofit? Create a new object file hunk, say HUNK_FLAGS,
CH> which tells you intimate info about the program that LoadSeg is bringing in.
CH> [...]

RJ>   A better idea.  You _could_ allow segments of code from a loadfile
RJ> to be protected (at least without many problems), and you could allow 
RJ> applications to request protected memory.

Randell, can the parts of the Amiga OS themselves request protected memory?
{That is in some scenario where it is available.}

This is a simple question really and I presume the answer is simple also. I
am asking because I have forgotten the details regarding the attributes RAM
required by the OS must have.  {I wish I had the RTMs.}

Btw would someone run by me again the problems with making an Amiga virtual
machine for _development_ purposes.

RJ> Randell Jesup, Keeper of AmigaDos, Commodore Engineering.

RJ> {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup  
RJ> The compiler runs
RJ> Like a swift-flowing river
RJ> I wait in silence.  (From "The Zen of Programming")  ;-)

An appropriate quote for this discussion of the GURU. :-)

yours truly,
Lou Cavallo.

In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes:
> Does anyone know how to FORCE a guru through C?

Try that for a 00000003:       or that for a 00000005:
    int *ptr = 1;                  int x = whatyouwant;
    *ptr = whatyouwant;            int y = x / 0;

(I didn't test them since I don't like when my Amiga crashs :-)
--
                                     \___/
Jean-Michel Forgeas                   \-/
cbmvax!cbmehq!cbmfra!swinjm!forgeas    |    The Software Winery
                                      -^-
                           And, where is the universe ?

In article <ben.4184@epmooch.UUCP> ben@epmooch.UUCP (Rev. Ben A. Mesander) writes:
> Gee, Peter, that's a lot cleaner than using the exec Alert() function...

Hey man, anyone who thinks they need to force a GURU would certainly have
trouble setting up the AlertMessage string.
-- 
Peter da Silva.   `-_-'
<peter@sugar.hackercorp.com>.

In article <615@caslon.cs.arizona.edu> Dave P. Schaumann writes:
>
>How would you do this?  I have heard about being able to hook up a terminal
>to help debug gurus, but I've never seen any documentation on How To Do It.
>
>What kind of a terminal do you need?  Any & all pointers would be appreciated!

Any kind of a terminal will work, although a vt100 or compatible terminal
might do more than a simple dumb tty.

I was speaking of using a debugger over the serial port, but I think what
you've heard of is ROM-WACK, which is a simple rom-based monitor which
operates over the serial port at 9600 baud to anything that will listen.  You
can invoke rom-wack by issuing the debug() command, or by pressing the delete
key on your terminal when your amiga starts to blink its power light before
rebooting.

Try to find the debugger I mentioned if you can.. it's quite a good one.
It's somewhere between ff350 and ff400, I _think_.  You can use newzap to
replace the reference to con: with one to aux: if you want a serial
based debugger, or if you leave it as is it will open its own window (which
should be sufficient for programs which don't take over the machine).

Be forewarned, it does keep your system from guruing (I used it for
Modula-2 development for a class I had, helped save me a lot of time),
but you might get a little lost if you haven't been exposed to
assembly.

A source level debugger would be optimal, of course.

If you can't find the debugger on ux1.cso.uiuc.edu by anonymous ftp, send
me mail and I'll try to send you the debugger.

>Dave Schaumann		| My folks went to uunet.uu.net, but all
>dave@cs.arizona.edu	| they got me was this lousy .sig...

-------------------------------------------------------------------------------
Jonathan Abbey				      The University of Texas at Austin
x194@cs.utexas.edu			    Major:Unknown.  Life's goals:Ditto
-- 

Every couple of months these same questions appear.  Could some take
all these posts and summarize them and build a new entry for the
monthly posting?  Randell?

It could cover which Amigas have MMUs, define memory protection vs.
virtual memory vs. resource tracking, why memory protection and
resource tracking can't reasonable be added to AmigaDOS, what
utilities (from SetCPU to Angle) do use the MMU, etc.  I think those
are all the related questions.  Any time one is asked, all the others
issues are eventually brought up too.

Other things to include advice on how to not have your Amiga guru and
notes about the fact that Mac and MS-DOS doesn't have any of this
protection and people have to reboot then all the time but they don't
complain. :-)

Hmmm... maybe I'll write this if Randell, Dave, Dave, Peter, Peter,
et. al. will let me re-use their posts.

Tom
-- 
tlimonce@drew.edu     Tom Limoncelli      "Flash!  Flash!  I love you!
tlimonce@drew.bitnet  +1 201 408 5389        ...but we only have fourteen
tlimonce@drew.uucp    limonce@pilot.njin.net       hours to save the earth!"

In article <7463@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
>In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes:
>> Does anyone know how to FORCE a guru through C?
>
>	char *p;
>
>	for(p = 0; p != (char *)-1; p++)
>		*p = 0;
>
>This will certainly clobber the machine. Play with variations until you get
>the results you want. (sigh)
>-- 
>Peter da Silva.   `-_-'
><peter@sugar.hackercorp.com>.

OR, how 'bout a nice little divide by zero exception?

    int result,
        divisor = 0 ;

    result = 10/divisor ;

That should really throw it for a loop.

PC

    

In article <17135@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
>	Won't work.  A message usually has pointers to other areas of
>arbitrary memory, or has an extended structure (ala StandardPacket), etc, etc.
>As has been discussed before, MEMF_PUBLIC can't be used since each person
>has had a different idea as to what should be public and what shouldn't.

  Ahhh, true. I spoke before thinking there.

>	A better idea.  You _could_ allow segments of code from a loadfile
>to be protected (at least without many problems), and you could allow 
>applications to request protected memory.

  Could you then please consider myself begging for such a feature? Such
programs as Enforcer are great for develop-time, but if we can add some
cover-the-user's-butt type of capability to all NEW programs it is a big
plus in my mind. I mean, Why should my perfectly innocent program get
spammed by DeluxePaint3? If I can protect the OS from my mistakes, and
have my program be protected from the mistakes of others, I can sleep
a little better, eh?

>Randell Jesup, Keeper of AmigaDos, Commodore Engineering.

  What exactly does 'Keeping' AmigaDos entail anyway? ;)

    Chris - Xenon


-- 
#define chanson Christopher_Eric_Hanson || Lord_Xenon || Kelson_Haldane 
I work, but you don't know who I work for. And they don't know I'm here.
"Someone thinks of us, therefore we are."

In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes:
>Does anyone know how to FORCE a guru through C? What includes, etc, and
>maybe a ForceGuru() call? I have a program where if you enter an incorrect
>response, it is supposed to guru. Does anyone have a sure-fire routine?

void Crash()
{
	void *zero = 0;
	while(1)
		*zero++ = 0;
}

I used this, or something similar once to crash the Amiga when a
password protection failed.  Takes ages though.  Suggestions
for a better crash would be appreciated.  Maybe copying the   
screen bitmap into the Exec structure....

:-) :-) :-)


>-- 
>        Joseph Hillenburg, Secretary, Bloomington Amiga Users Group
>iuvax!news!valnet!joseph        jph@ais.org          anlhille@iubacs.BITNET
>       "Only Apple could slow down a 68030 chip" --Computer Shopper

Colin.

In article <17135@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
>>  Agreed, adding protection might break large quantities of stuff. How
>>about some kind of retrofit? Create a new object file hunk, say HUNK_FLAGS,
>>which tells you intimate info about the program that LoadSeg is bringing in.
>>You could have a flag to signify "I'm a nice program and I work well under
>>memory protection, so protect me if you can". This would also be an
>>excellent place to finally settle the PURE code problem. Make a hunk flag
>>that signifies, regardless of what the FS bit says, "This code is pure,
>>damnit." ;)
>
>	A better idea.  You _could_ allow segments of code from a loadfile
>to be protected (at least without many problems), and you could allow 
>applications to request protected memory.

I think that would make people very happy.  Would it be possible to
keep that program from writing to unprotected areas of memory except
when dealing with the system structures?  Perhaps give system calls
universal access to all memory but not the user's code?

I consider myself a good programmer (maybe foolishly so  :), and I'm
not hit by the SEG_FAULT that often when I program for school; when I
do get them, I'm thankful my errors are handled as they are.  When I
start programming seriously for the Amiga (ie when I get a 3000) I
might not think this a major problem.  (ie a 15 second boot time might
not be so bad after a GURU-- now I have about 1.5 minutes, plus getting
things back to the state I had them in...)

>Randell Jesup, Keeper of AmigaDos, Commodore Engineering.  
>{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com  BIX: rjesup 
>The compiler runs 
>Like a swift-flowing river 
>I wait in silence.  (From "The Zen of Programming")  ;-)

--
Chris Dailey   dailey@(frith.egr|cpsin.cps).msu.edu
BRD += DDR;           __  __  ___
DDR = NULL;      \\__/  \/  \/ __:>-
num_countries --;  \__/\__/\__/ Snake in the Grass

In article <Jan.6.17.58.23.1991.29680@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes:
>Every couple of months these same questions appear.  Could some take
>all these posts and summarize them and build a new entry for the
>monthly posting?  Randell?

But every time it appears there are a couple of new points brought up,
even though a lot of the old stuff is re-hashed.  But it still is a
good idea, me thinks.

>Hmmm... maybe I'll write this if Randell, Dave, Dave, Peter, Peter,
>et. al. will let me re-use their posts.

>Tom
>-- 
>tlimonce@drew.edu     Tom Limoncelli      "Flash!  Flash!  I love you!
>tlimonce@drew.bitnet  +1 201 408 5389        ...but we only have fourteen
>tlimonce@drew.uucp    limonce@pilot.njin.net       hours to save the earth!"

P.S.  Tom, I'm sure Laura would want me to say, "Hi" to you.

--
Chris Dailey   dailey@(frith.egr|cpsin.cps).msu.edu
BRD += DDR;           __  __  ___
DDR = NULL;      \\__/  \/  \/ __:>-
num_countries --;  \__/\__/\__/ Snake in the Grass

>>>>> In article <1991Jan7.110218.9448@marlin.jcu.edu.au>,
>>>>> glmwc@marlin.jcu.edu.au (Matt Crowd) writes:

Matt> I used this, or something similar once to crash the Amiga when a
Matt> password protection failed.  Takes ages though.  Suggestions for
Matt> a better crash would be appreciated.  Maybe copying the screen
Matt> bitmap into the Exec structure....

I hope that this is a stand-alone program.  If any program I ran ever
crashed the machine just because I typed the wrong password, that
program would be sent back for a refund _fast_.

Lord save us from idiot programmers.

Hamish.
--
--------------------------------------------------------------------
himacdon@maytag.uwaterloo.ca                 watmath!maytag!himacdon

In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes:
>Does anyone know how to FORCE a guru through C? What includes, etc, and
>maybe a ForceGuru() call? I have a program where if you enter an incorrect
>response, it is supposed to guru. Does anyone have a sure-fire routine?
>
>
>-- 
>        Joseph Hillenburg, Secretary, Bloomington Amiga Users Group
>iuvax!news!valnet!joseph        jph@ais.org          anlhille@iubacs.BITNET
>       "Only Apple could slow down a 68030 chip" --Computer Shopper

Newsgroups: comp.sys.amiga.tech
Subject: Re: Help --> How to prevent the visit from the dreaded guru
Summary: 
Expires: 
References: <611@caslon.cs.arizona.edu> <1991Jan4.203339.8800@maytag.waterloo.edu> <V2H++Q_@irie.ais.org>
Sender: 
Reply-To: jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson)
Followup-To: 
Distribution: 
Organization: Jet Propulsion Laboratory, Pasadena, CA
Keywords: 

In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes:
>Does anyone know how to FORCE a guru through C? What includes, etc, and
>maybe a ForceGuru() call? I have a program where if you enter an incorrect
>response, it is supposed to guru. Does anyone have a sure-fire routine?
>
>
	Yeah! Devide by zero.
>-- 
>        Joseph Hillenburg, Secretary, Bloomington Amiga Users Group
>iuvax!news!valnet!joseph        jph@ais.org          anlhille@iubacs.BITNET
>       "Only Apple could slow down a 68030 chip" --Computer Shopper

				Jeff

In article <Jan.6.17.58.23.1991.29680@pilot.njin.net> limonce@pilot.njin.net (Tom Limoncelli) writes:
|Every couple of months these same questions appear.  Could some take
|all these posts and summarize them and build a new entry for the
|monthly posting?  Randell?
|
|[...]
|
|Hmmm... maybe I'll write this if Randell, Dave, Dave, Peter, Peter,
|et. al. will let me re-use their posts.

You have my permission.  Maybe I should ask that certain names be changed to
protect the quick-to-post.  :-/

I gotta practice sitting on my hands.

|Tom
|-- 
|tlimonce@drew.edu     Tom Limoncelli      "Flash!  Flash!  I love you!
|tlimonce@drew.bitnet  +1 201 408 5389        ...but we only have fourteen
|tlimonce@drew.uucp    limonce@pilot.njin.net       hours to save the earth!"


Dave Schaumann		| You are in a twisty maze of little
dave@cs.arizona.edu	| C statements, all different.

In article <1991Jan5.200226.19718@msuinfo.cl.msu.edu> dailey@frith.uucp (Chris Dailey) writes:
>
>I don't care much about existing programs.

I hope you wear fireproof clothes. The Amiga is *not* a machine
for only exercising in programming, it is used in the real world
with existing programs. You actually can buy some!

>Even fake memory protection would due for many of us.  How about a
>command like "run such and such a program so it doesn't touch anything
>other than the OS".  It gets its own space, tucked away from the rest of
>the system?

I fear I can't explain this too well (perhaps someone other could
cut in): In AmigaOS (and in most other current OS's) you can't draw
a sharp line between program-owned and system-owned memory, because
of all that message passing to and fro. The Amiga implementation of
the message system is very fast, because it works with shared memory
so that the contents needs not to be copied. And these messages are
bidirectional, containing perhaps different data on reply. And all
this may happen asynchroneously. - In addition there are many data
structures that are created and owned by the system on demand of a
program, but this program also must be able to access these data.

You see, it's simply not possible to define the "own space" of a
normal Amiga program, so it also can't be easily protected by a MMU.

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk

In article <1991Jan7.110218.9448@marlin.jcu.edu.au> glmwc@marlin.jcu.edu.au (Matt Crowd) writes:
>In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes:
>>Does anyone know how to FORCE a guru through C? What includes, etc, and
>>maybe a ForceGuru() call? I have a program where if you enter an incorrect
>>response, it is supposed to guru. Does anyone have a sure-fire routine?
[CODE DELETED]
>I used this, or something similar once to crash the Amiga when a
>password protection failed.  Takes ages though.  Suggestions
>for a better crash would be appreciated.  Maybe copying the   
>screen bitmap into the Exec structure....
>:-) :-) :-)
>>        Joseph Hillenburg, Secretary, Bloomington Amiga Users Group
>>iuvax!news!valnet!joseph        jph@ais.org          anlhille@iubacs.BITNET
>>       "Only Apple could slow down a 68030 chip" --Computer Shopper
>Colin.

Hmmm... As long as no GURU catchers are watching, then x=5/0; works fine.
Try it.  (If your compiler is SO SMART that it catches that mistake, then use
variables instead...)  This fires off the DIVIDE THRU NULL interuppt.  It works,
most of the time.  Now WHY would anyone want to GURU the AMIGA?  You testing a
new GURU TRAP or somethin'?


-- 

   Regards,
   UUCP: [{(uunet|pyramid|rutgers)!cbmvax}!cbmehq!cbmcel!stoller

In article <1991Jan7.181114.19016@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes:
>In article <V2H++Q_@irie.ais.org> jph@ais.org (Joseph Hillenburg) writes:
>>Does anyone know how to FORCE a guru through C? What includes, etc, and
>>maybe a ForceGuru() call? I have a program where if you enter an incorrect
>	Yeah! Devide by zero.

  Another, perhaps more random way would be to set the blitter into it's
'NASTY' mode, and instruct it to fill all of CHIP memory with zeros. This
may be quick, or it may take a few seconds. I have (ostensibly) never
done this to my poor machine. I do however, guarentee that this WILL crash
the machine. It may not even get to GURUing, it may just Crash & Burn.
 
  Or, perhaps you could merely simulate the GURU with an appropriately
set up Alert(). I believe, if it is a DEADEND_ALERT, the machine will
happily reset for you after it is done displaying the ALert.

  Do I want to know what kind of program this is for, Joseph?

>>        Joseph Hillenburg, Secretary, Bloomington Amiga Users Group
>				Jeff

    Chris - Xenon

-- 
#define chanson Christopher_Eric_Hanson || Lord_Xenon || Kelson_Haldane 
I work, but you don't know who I work for. And they don't know I'm here.
"My stack runneth over." -Brian Walder

In article <624@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes:
   >VM is NOT a solution.

   This is the second post that says VM doesn't do task protection.  I was
   taught that VM gives every task its own unique address space, and when a
   memory fetch was made, a combination of hardware/firmware mapped this into
   an actual address in memory (after a possible disk fetch).  I realize that
   any machine that needs a RAM: disk has no business running VM.  When I
   said VM, I was only thinking of the 'unique address space' aspect of it.
   I also realize that, as explained elsewhere, because of message passing,
   memory protection would break the current OS.  *sigh*.

There are two accepted meanings for the term "virtual memory". The
most common one (at least, the one I see most often) is "demand paged
virtual memory", which is a solution to the budget-constrained memory
problem. This does _not_ imply that every task has it's own private
address space. You can do demand paging on a large virtual address
space, and have all tasks live in that same address space.

The other meaning is the one you allude to, "mapped virtual memory",
where each task has it's own memory map in the MMU. No paging - or
even swapping - needed. OS/9 used to do this on the 6809, and Unix
does it on the PDP-11. Unix practically requires support for this
feature.

The two concepts are orthogonal, though most people who do demand
paging also provide mapping.

BTW, if you look around in the Unix groups, you'll find people arguing
that RAM: disks are wonderful things (even on ther demand paged
virtual memory systems), and trying to find drivers for them. And no,
I can't explain that either.

	<mike
--

In article <624@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes:
>
>  But to suggest that anyone
>just "write programs that don't guru" (under *any circumstances*) is silly.  I
>doubt there is a single programmer who would be willing to attempt to live up
>to such a standard.

Perhaps I miss your point a little, but YES: Anyone should ALWAYS
at least *attempt* to write non-guruing code!

-- 
Best regards, Dr. Peter Kittel  // E-Mail to  \\  Only my personal opinions... 
Commodore Frankfurt, Germany  \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk

In article <624@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes:
>In article <1991Jan8.213049.7683@motaus.sps.mot.com> skipper@motaus.sps.mot.com (Skipper Smith) writes:

>certainly agree, especially on the Amiga, that it is the programmer's
>responsibility to thoroughly test all code.  But to suggest that anyone
>just "write programs that don't guru" (under *any circumstances*) is silly.  I
>doubt there is a single programmer who would be willing to attempt to live up
>to such a standard.


Ummm, it is ALWAYS my GOAL to have a bug free program.  As such, as soon as
someone reports a GURU or bug to me, I fix it and give the fix to everyone
with a copy of the program.  I do NOT blame the OS for my bug, nor believe that
the OS should be modified in order to "put up" with errors in _my_ code.

						-- Kevin --
Kevin Klop		{uunet|rutgers|amiga}!cbmvax!kevin
Commodore-Amiga, Inc.

	``Be excellent to each other.''
		- Bill and Ted's most excellent adventure

Disclaimer: _I_ don't know what I said, much less my employer.

In article <17287@cbmvax.commodore.com> kevin@cbmvax.commodore.com (Kevin Klop) writes:
>Ummm, it is ALWAYS my GOAL to have a bug free program.  As such, as soon as
>someone reports a GURU or bug to me, I fix it and give the fix to everyone
>with a copy of the program.  I do NOT blame the OS for my bug, nor believe that
>the OS should be modified in order to "put up" with errors in _my_ code.
>
>						-- Kevin --

My point is an issue of robustness.  Give someone a computer, and the next
thing you know, they want to write a program on it ;).  Every time you go
through the program development process, you have to deal with bugs in your
code.  Often, these bugs are of a catastrophic nature.  I think that expecting
the OS to deal with programs that experience such bugs in a graceful manner
is not unreasonable.  I have been taught that program robustness (in dealing
with user input and environment conditions) is nearly as important as program
correctness.  Should an OS be held up to any less of a standard?

I don't blame any OS for bugs introduced by *my* code.  But I do believe that
an OS should be as robust as possible in dealing with what a user program
might do.


>Kevin Klop		{uunet|rutgers|amiga}!cbmvax!kevin
>Commodore-Amiga, Inc.
>
>	``Be excellent to each other.''
>		- Bill and Ted's most excellent adventure
>
>Disclaimer: _I_ don't know what I said, much less my employer.


Dave Schaumann		| You are in a twisty maze of little
dave@cs.arizona.edu	| C statements, all different.

In article <630@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes:
>In article <17287@cbmvax.commodore.com> kevin@cbmvax.commodore.com (Kevin Klop) writes:
>>Ummm, it is ALWAYS my GOAL to have a bug free program.  As such, as soon as
>>someone reports a GURU or bug to me, I fix it and give the fix to everyone
>>with a copy of the program.  I do NOT blame the OS for my bug, nor believe that
>>the OS should be modified in order to "put up" with errors in _my_ code.
>>
>>						-- Kevin --
>
>My point is an issue of robustness.  Give someone a computer, and the next
>thing you know, they want to write a program on it ;).  Every time you go
>through the program development process, you have to deal with bugs in your
>code.  Often, these bugs are of a catastrophic nature.  I think that expecting
>the OS to deal with programs that experience such bugs in a graceful manner
>is not unreasonable.  I have been taught that program robustness (in dealing
>with user input and environment conditions) is nearly as important as program
>correctness.  Should an OS be held up to any less of a standard?
>
>I don't blame any OS for bugs introduced by *my* code.  But I do believe that
>an OS should be as robust as possible in dealing with what a user program
>might do.
>
>
>>Kevin Klop		{uunet|rutgers|amiga}!cbmvax!kevin
>>Commodore-Amiga, Inc.
>>
>>	``Be excellent to each other.''
>>		- Bill and Ted's most excellent adventure
>>
>>Disclaimer: _I_ don't know what I said, much less my employer.
>
>
>Dave Schaumann		| You are in a twisty maze of little
>dave@cs.arizona.edu	| C statements, all different.



The problem with this is the difficulty in a non memory protected model.
There is nothing to stop the user program from trashing system structures,
passing pointers that ostensibly point to buffers and actually point to
program code, etc. to the operating system, nor is there any way to stop
a program from trashing some OTHER program's code and data.

"So put memory protection in" sounds like a possible answer, but has been
hashed over and over again, this is no easy task.  The ramifications are
pretty far reaching and too detailed for me to get into now.

Ditto for resource tracking so that memory, devices, etc. are freed when a
program exits.  I have more than one program that opens something and then
passes the IO request to some OTHER task.  The original task then exits.
I certainly do NOT want the OS closing that device or deallocating the IO
request memory on me.

The question you raise, while a valid concern, is a tough one.  How much
are we willing to trade off?  Do we need to put an MMU in the A500s and
thereby raise the price of them significantly?  If not, then we need
two (or more) operating systems.  One to deal with MMU systems and one that
doesn't.  The two OSs would be VERY dissimilar, and would thereby at least
double the R&D load here at Commodore.

				-- Kevin --	

In article <17368@cbmvax.commodore.com> kevin@cbmvax.commodore.com (Kevin Klop) writes:
![ lots of stuff about memory protection & robustness deleted ]
!
!The problem with this is the difficulty in a non memory protected model.
!There is nothing to stop the user program from trashing system structures,
!passing pointers that ostensibly point to buffers and actually point to
!program code, etc. to the operating system, nor is there any way to stop
!a program from trashing some OTHER program's code and data.
!
!"So put memory protection in" sounds like a possible answer, but has been
!hashed over and over again, this is no easy task.  The ramifications are
!pretty far reaching and too detailed for me to get into now.
!
!Ditto for resource tracking so that memory, devices, etc. are freed when a
!program exits.  I have more than one program that opens something and then
!passes the IO request to some OTHER task.  The original task then exits.
!I certainly do NOT want the OS closing that device or deallocating the IO
!request memory on me.
!
!The question you raise, while a valid concern, is a tough one.  How much
!are we willing to trade off?  Do we need to put an MMU in the A500s and
!thereby raise the price of them significantly?  If not, then we need
!two (or more) operating systems.  One to deal with MMU systems and one that
!doesn't.  The two OSs would be VERY dissimilar, and would thereby at least
!double the R&D load here at Commodore.
!
!				-- Kevin --	

I realize that there are some tough problems to be solved to increase the
robustness of the AmigaOS.  It distresses me though when I see people post
that the guru is something we should just live with.

Obviously, no one wants to OS's, or a radically more expensive A500.
At this point, I'd settle for knowing that increasing the AmigaOS's robustness
was an important goal in future Workbench releases.

Dave Schaumann		| You are in a twisty maze of little
dave@cs.arizona.edu	| C statements, all different.