dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/07/87)
How About (Big enhancements): -Allow windows to be partially off the screen. Quite simple, really. First limit a window's maximum size to be that of the blitter's maximum handling capabilities (1024x1024?). Then allow the window to be moved off the screen top, bottom, left, and right. This requires changes only to Layers and workbench + minor checking of related code making sure nothing blows up with negative screen coordinates. -Allow user gadgets in the top screen border. -Allow programs to access other program's custom screens if those other programs allow it. Access is by name. Cause CloseScreen() NOT to close a screen if windows still exist on it, and if so to flag the screen as "CLOSE_AFTER_LAST_WINDOW" rather than block. -Blitter: Allow one level of asyncronous control over graphics calls. It is too late to make a device out of it. Gasync(Rp,1); Move(Rp, a, b); Draw(Rp, c, d); Draw(Rp, c, d); Gasync(Rp, 0); I.e. if the first draw must do several blitter runs due to overlapping windows, it returns after starting the LAST run in the series. This would work extremely well for area fills and other routines allowing fast 3D packages to use the graphics library rather than write their own custom blitter routines. -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. -Protect critical library calls from software interrupts. For instance, I want to be able to set the exception mask for intuition messages and handle them (via GetMsg()) from the SOFTWARE interrupt routine for that task... even to ReplyMsg() them... Also to be able to call exit() from the routine (assuming Aztec and Lattice were to suitably update their libraries). Have a quick system call to enable/disable critical in-task areas available to programmers. (Note: This is NOT Forbid()/Permit()) -Provide system calls to control software interrupt routines (abort and beyond current support) and provide better documentation of the calling sequence to software interrupts. -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. 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. -Provide a new DOS call which DUPlicates a FileHandle!!!!. Provide a new message for DOS device drivers supporting this call. -Matt
peter@sugar.UUCP (Peter da Silva) (12/25/87)
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*.
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (12/28/87)
In article <1309@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: >In article ..., dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> 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? [ ... ] Sigh. Go find a copy of Fish Disk #59, go into the Robotroff directory, and check out the _main.c module. This goodie causes the program to make a logical copy of itself, starts up the copy, and the original exits. This is how Robotroff forks itself into the background. It works under both CLI and Workbench, and does NOT hang on to the original CLI window (it does hold locks on directories, though, so disk icons will hang around). Check it out; this technology already exists. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape ihnp4!ptsfa -\ \_ -_ Recumbent Bikes: dual ---> !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor