Path: utzoo!mnetor!uunet!nuchat!sugar!peter
From: peter@sugar.UUCP (Peter da Silva)
Newsgroups: comp.sys.amiga
Subject: Re: Big Enhancements for 1.3
Message-ID: <1309@sugar.UUCP>
Date: 25 Dec 87 15:43:34 GMT
References: <8712070010.AA21837@cory.Berkeley.EDU>
Organization: Sugar Land UNIX - Houston, TX
Lines: 54

In article ..., dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
> 	How About (Big enhancements):
> 
> 	-Blitter:  Allow one level of asyncronous control over graphics
> 	 calls.  It is too late to make a device out of it.

Why? New programs could talk to the blitter through message ports, even if
old ones couldn't...

> 	-Gfx Calls: Better bounds checking.  Should never crash when rendering
>  	 into clipped rastports no matter what coordinate arguments are given.
> 	 ALSO, if the structures required for Area routines are not present,
> 	 do not crash, simply return an error.

Yeh, and in Intuition... do *not* crash if a sloppy programmer attempts to
open a window with insufficient data:

	- Null for the screen with CUSTOMSCREEN set.

	- Null for a gadget's Image structure for PropGadgets.

> 	-Provide a new DOS call which creates a process for a SegList giving
> 	 it a specified input stream and output stream, and a CLI, and 
> 	 creating (or using) a message port from which the return value can be
> 	 retrieved after execution completes.

While on the subject of DOS calls, how about one that works like Examine/ExNext
but only returns the name. Combine this with a file structure that's got names
in the directories. Programs that use this call would be radically speeded up.
Most of the time this is all you need...

Back to this business of creating a process from a SegList, it's pretty easy
(well, pretty hard if you want to do it generally!) to kick off a task as a
workbench process like this.

> 	 Allow said DOS process to execute another DOS call which simulates an
> 	 exit (writing a return value to the message port) but allows the DOS
> 	 process to continue to run.  The final exit code would be lost.  Have
> 	 the restriction that once a process simulates an exit it may no longer
> 	 use it's original input and output stream.

You mean "terminate and stay resident" or "emit status"? I can see where you're
going. RunBack is a bit of a kludge, isn't it? Perhaps you should just ask them
(them? C=) to provide a well behaved "runback" type program (one that doesn't
eat little chunks of memory) and leave the implementation up to them.

> 	-Provide a new DOS call which DUPlicates a FileHandle!!!!.  Provide
> 	 a new message for DOS device drivers supporting this call.

Yeh. Ironic that MS-DOS (which has no earthly use for this call) supports
it, but the Amy doesn't.
-- 
-- Peter da Silva  `-_-'  ...!hoptoad!academ!uhnix1!sugar!peter
-- Disclaimer: These U aren't mere opinions... these are *values*.