AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (06/27/88)
>Date: Wed, 22 Jun 88 21:54:42 GMT >From: Joel Sumner <ndmath!thelink!oliver@iuvax.cs.indiana.edu> >Subject: another tasker idea >Here is another idea that I ran across for all enterprising >individuals (which may be me in a few years)... I notice that the >GET_NEXT_EVENT can only produce 16 different results (this is from >the "Programmer's Introductions to the Apple IIgs") Well, it actually returns a "word" (a 16-bit value), so there are 65536 *possible* values it could return. The way it's designed now, it will return one of up to 16 values (0 through 15) corresponding to a kind of event. There are only 16 event types (including "no event"), corresponding to most of the BITS in a 1-word "event mask". When a program asks the event manager for an event, it specifiec an event mask with a "1" in every bit corresponding to a kind of event that it wants to check for. >with number 9 being the 'switchEvt' (supposedly not supported yet). >I imagine that this is intended as something in the "SWITCHER" realm >but could this be used to tell the program to make a 'Switch' back to >whatever program is controlling the Multitasking.. (Is there any way >to even use it since it is unsupported?)... No, there's no way to use it until Apple defines what it is. No way to do it and be compatible with future developments, unless you have perfect ESP! I think this kind of event is intended for telling Applications to do any sort of CLEANING UP they need to do before the SYSTEM hands control to another program. For example, when receiving a switch event, the application might want to convert some clipboard information from the applications private format into a public format (on the "real" clipboard: the Scrap Manager) for the benefit of the application gaining control. But it would still have to be the system software, not the actual application, that handed control to the new application. (The system can do this easily by simply NOT RETURNING from a tool call...for example, GetNextEvent, for a long, long time. As far as the application could see, it just takes a LONG time for the call to return--actually, another application ran for a while in the meantime.) >Another little didy... Since NDA's are just regular programs that >don't start up any tools (except for the ones that they may need that >aren't already there)... Is there any way to make the machine think >that a program is a New Desk Accessory? An interesting idea--but I don't think this is a very workable approach (it would end up being trickier than other approaches, I think). The major problem is that NDAs do NOT have their own "event loops"; applications do. (An event loop is something that loops continuiously, waiting for some interesting event to happen--when something happens, it takes an appropriate action & then keeps waiting for another event. "No event" is also something that can happen, and there are things to do, like check whether it's time to blink any "insertion points" on or off, etc.) NDAs just get called when an event they care about (mouse click in their window, etc.) DOES happen--and the NDA returns control to the caller as soon as possible after dealing with it. >(Multi Finder already switches Applications by use of the Apple Menu >[I think, I am not a Mac II person]) [By the way, MultiFinder works on the Mac Plus Mac SE as well as the Mac II!] I assume MultiFinder intercepts the MenuSelect calls (which the application makes in response to a MouseDown event in the menu bar); it would work as described for GetNextEvent above. In this case, if the user selects another application from the Apple menu (DURING the MenuSelect call), the call does not return to the application until it takes care of making the selected application the "front" one (re-layering windows & lots more housekeeping stuff for it to do); When the MenuSelect call DOES return, it would have to tell a white lie and report that NOTHING was selected from the menu. >There is already a provision for giving an NDA 'time' to do >whatever... The only problem to this appears if you ever watch your >CLOCK.NDA while you use the Standard File box or other commands >that involves disk access, it seems to skip a few seconds in there.. >I am not sure how that can be gotten around. NDAs are called whenever the application (or some tool called BY the application) makes a SystemTask call. SystemTask checks how often each NDA has requested to be called (any number of 60ths of a second (called "ticks"), or "as often as possible," which would be during EVERY call to SystemTask), and calls all the ones that need to be called. Standard File calls SystemTask while it's waiting for the user to do something, but not while it's reading from disk. For more time-critical things like reading characters from a modem, the program would have to set up an interrupt to gain control directly when a character comes in, stuff the character in a buffer, and return to allow the system to go on with its business. This would be SEPARATE from the program getting control in the normal way, at which point it could get 0 or more characters out of that buffer and do something with them (like display them in a window). The biggest problem with modem stuff in the background is DISK ACCESS. ProDOS generally disables interrupts during all disk access, so incoming characters would be very likely to be lost. I'm NOT trying to say it can't be done, though! Apple II people NEVER admit that something can't be done...the harder the better. For example, ProDOS calls could be intercepted, and before any disk access happened, a Ctrl-S could be sent through the serial ports; after the disk access was done, a Ctrl-Q could be sent. (There may be some other problems here...I don't claim that this is a complete solution.) Even better, I would like to see Apple define a system vector called InterruptWarning that takes a 1-word value meaning that somebody was ABOUT to disable interrupts for at MOST the specified amount of time. Time-cricital things (like modem programs) could CHAIN INTO this vector (like the HeartBeat queue), CHECK the amount of time interrupts were going to be disabled for, possibly compare that value with other info (like BAUD RATE!), and decide whether to take any special action (like sending a Ctrl-S out a serial port). When the routine was called with 0, the routines would know it was safe to resume the time-critical operations (Send a Ctrl-Q). [Detail--0 would have that meaning only if interrupts were actually ENABLED when the call was made; this allows for NESTED interrupt-warning calls in cases where interrupts may ALREADY be disabled.] There ARE still problems...for example, there has to be a way to WAIT for the sender to stop sending, which could be done by NOT returning from the InterruptWarning routine until a sufficient time had passed with no characters received--but this would probably take too long if it happened before every block-level read/write call. [Maybe we will need hardware buffering for the serial ports...or maybe just a ProDOS 16 [or a GS OS] that doesn't always disable interrupts for disk operations [sounds reasonable to me...I don't think any zero-page is trashed by interrupts any more (it was NECESSARY to disable ints for disk I/O on the II+, because $45 got trashed on every interrupt, AND it was used for the parameter list of a block read/write call!)]. >[...](Just please don't turn on the flame gun.. I am quite a novice >programmer with big ideas and no way in the world to make them a >reality... [...]) Don't worry...I don't even OWN a flame gun. Why do you say you have no way in the world to make your ideas a reality? You obviously have ideas, and you can obviously type...all you need now is a couple tons of documentation and lots of TIME! >---------------------------------------------------------------------------| >| oliver@thelink.UUCP |AT&T (219) 291-8343| GEnie K.SUMNER [Joel] | >| (Joel Sumner) |----------------------------------------------------| >|USnail 1505 Sheffield Ct. | It is always darkest before the lights go out | >| South Bend, IN 46614| | >!--------------------------------------------------------------------------! --David A. Lyons a.k.a. DAL Systems PO Box 287 | North Liberty, IA 52317 BITNET: AWCTTYPA@UIAMVS CompuServe: 72177,3233 GEnie mail: D.LYONS2