Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!WPI.BITNET!GREYELF From: GREYELF@WPI.BITNET Newsgroups: comp.sys.apple Subject: windows Message-ID: <8904031825.AA09607@wpi> Date: 3 Apr 89 18:25:26 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 142 People who have expressed an interest: ggray@wpi.wpi.com greyelf@wpi.wpi.com nakada@HUSC4.HARVARD.EDU Geva_Apple-Maniac_Patz@cup.portal.com Key: >> Geva > Paul Nakada The rest are my humble opinions. >> * Mousetext: Should the system use Mousetext, in which event it would not >> work on ][+'s or older //es, or should it use the Graphics screen, which >> would obviously make the package bigger and slower. >mouse text is a must, though, for //e's ... Anybody know of a way to tell from software if the mouse text set is available? I think that trying to implement mousetext through graphics is a losing proposition, it even slows macs down too much. And to tell the truth I'm not overwhelmed by mousetext to begin with. I think we should start simple, little things like managing memory for where to store the hidden screen will pose enough problems without worrying about bells and whistles at this point. >> * Calling procedure: How are the routines actually called? Do we want >> something akin to the GS toolbox procedure, something like the ProDOS MLI >> or something completely different? >I see the MLI approach as the best.. no clock cycles used to set up the >paramater lists, no stack space used... a fairly good approach... The MLI approach is very good, it does allow for a much greater flexibility of calls, with much less for the programmer to memorize. It is only mildly harder to code. This brings up a new question, how (where) should we set the entry point so routines will know where to find it? >> * Mouse support: Will a mouse be unsupported, essential, or will the >> toolbox use 'pseudo-mouse' functions (i.e. allow the keyboard and >> joystick to emulate a mouse) >As i see it, we need something akin to the X window event loop... >This would be something that the programmer could choose to use or not.. >Here's what we need... some type of mask to determine what events need >to be watched for.. events: > mouse movement > mouse down > mouse up > keypress (including both apple combos) Making the mouse essential is a bad move, it is possible to tell from software whether or not a mouse is currently connected, not just whether a mouse card is present. As for mouse movement, the card will handle that itseelf, once interrupts are activated. Keypresses should be handled by the normal call to the Applesoft GET routine to avoid problems with buffer programs (Did I mention SOFTKB yet?). I could write a specific interrupt driver for the mouse to handle screen positioning if it would help. >I don't really see a need for the point and click aspect of mouse use >(as with the macintosh) With the text display, i find pointing a pain, >and would much rather use the keyboard much like shrinkit, and proterm >do. A better soultion would allow for mouse movement as done in the >ProSel utilities where mousemovement basically translates to >keypresses. It is possible (and fairly easy) to allow both mouse and keyboard drivers, like in BLU 2.28, and have them designed to work together. >> * Level: Should the toolbox allow high-level calls [create dialog box, >> create menus, etc.], low-level calls [clear screen section, save screen >> section, etc.] or both? >Here, for flexibility, i would say both.. two key routines that io feel >are a must to standardize are the selection of prefixes and filenames.. I would say high-level calls. Like MLI, it is not convenient to try to pass variables from basic, rather it is easier to poke the appropriate values into memory and call a driver. This driver would be very easy to write (Okay, I voulenteer). >> * Are uppercase-only systems, 40-column systems, etc. going to be supported? Is it possible to test for these systems from software? If not, I wouldn't worry about it, it should be easy enough to add an option for upper case only. We could even create an installer program to set the options for you (as seen in Kermit-65). >> * Form: What form is the ultimate library going to take? Will it be a >> run-time library? Will it support BASIC? Assembler? C? Pascal? >It has to be in a binary library (possibly relocatable).. it should use >aux memory as much as possible to allow for additional application >space.. Aux memory is not available on 64K apples, and they do run Prodos just fine. Relocatable is a good idea, but there must exist a way to find the entry point. We could install our own vector in page 3, in one of the open spaces, or we could claim two bytes from page 0, the one least likely to cause a problem is claiming a vector in page 3. I agree it should be binary. We could lay claim to two bytes in memory in Prodos or Basic.system, if we choose. >> I'm sure there are lots of others, but these are all that I can come up >> with off the top of my head. I look forward to hearing your response... >> >> %%%% >> Geva >> %%%% >What we have is that making of a pretty large and flexible library... >The only problems i can see are those relateed to speed.. My ersonal >feeling here is that if speed becomes a problem, become more specific to >the enhanced //e standard... and maybe develop differnt libs for each >platform.... >enough rambling... let's here some more comments.!!!! >-paul Pauls signiature deleted (the message is already long enough) I've got a question, are we deciding on Prodos compatibility only? I think that a 128K standard is a BAD idea, but there is some free memory in one of the banks of the language card that Prodos doesn't use (if memory serves). I'll have to look that up. Now we should decide on some standard calls. If you have any more long messages, like this one, why not send them to me dirctly, and I'll send them out to people that appear interested. If you want to get on the mailing list, send mail as well. -- Michael J Pender Jr Box 1942 c/o W.P.I. I wrote SHELL and Daemon, greyelf@wpi.bitnet 100 Institute Rd. send bug reports, suggestions, greyelf@wpi.wpi.com Worcester, Ma 01609 checks to me. People keep asking me if Shell or Daemon are compatible with the IIc, IIe. YES, I wrote them on my Laser 128. I mean, what would be the challenge to multitasking on a IIgs? I'll start writing dedicated gs programs when somebody sends me one in the mail.