Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!well!tenney
From: tenney@well.UUCP (Glenn S. Tenney)
Newsgroups: comp.sys.amiga
Subject: Re: Amiga Wish List (really pr_Window)
Message-ID: <3301@well.UUCP>
Date: Sat, 13-Jun-87 04:06:04 EDT
Article-I.D.: well.3301
Posted: Sat Jun 13 04:06:04 1987
Date-Received: Sat, 20-Jun-87 19:46:08 EDT
References: <8706120543.AA16187@cory.Berkeley.EDU>
Reply-To: tenney@well.UUCP (Glenn S. Tenney)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 22
Summary: well not always...

In article <8706120543.AA16187@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>	Setting the pr_Window field in a process's process structure causes
>DOS to return an error immediately without asking for user assistance.

Well, from painfull experience, not always!  Since this is a true multitasking
system, your process' pr_Window field only applies when the dos KNOWS that
the request is yours.  By the time that dos actually writes a track, it has no
idea whose request(s) that write actually covers, hence an error at that time
uses the pr_Window of the file handler's process.  Ah, you might then think
that you can alter the pr_Window of the handler.  No way Jose, then the dos
starts acting very weird.  Then, we have the situation when our friend the
validator needs to run (unbeknown to us).  Again, it is it's own process,
so our pr_Window has no affect.

In other words, you really can't easily make a system be a padded cell
and handle ALL errors yourself.  What a shame...

-- Glenn Tenney 
UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney
ARPA: well!tenney@LLL-CRG.ARPA        Delphi and MCI Mail: TENNEY
As Alphonso Bodoya would say... (tnx boulton)
Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!