From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-013 Date: Wed, 13 Apr 94 14:54:30 MET DST C.S.M.P. Digest Wed, 13 Apr 94 Volume 3 : Issue 13 Today's Topics: AppleEvents to Run Excel? Finding the High Bit Generating Activate Events I got my PPC PDS card... Moving an editText area in a Modal Dialog Q PPC Development and MPW Tools PowerMac Programming PowerMacs and ARTA Quickdraw GX Beta 3 The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users as comp.sys.mac.programmer.src. ------------------------------------------------------- >From greer@utdallas.edu (Dale M. Greer) Subject: AppleEvents to Run Excel? Date: 28 Mar 1994 20:56:10 GMT Organization: The University of Texas at Dallas I need to make an application to run Excel from a C program. I've got the MS Excel SDK and the IM IAC books. The former describes objects and event which act upon them, while the latter gives examples of how to use AppleEvents. But these examples aren't much use helping me figure out how to do it with Excel, and the Excel book has no examples at all. Can someone point me in the right direction as to how to find how how to do what I need to do? My code will get data from somewhere, and then create a .XLS file from the data. To do the latter, the code will use AppleEvents to run Excel to create a spreadsheet and enter the data there. -- Dale Greer, greer@utdallas.edu "You can't just wake up and kiss the mirror and say 'I'm so purdy, I think I'll run for Governor.'" - Texas Gov. Ann Richards +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Tue, 29 Mar 1994 10:16:36 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Dale M. Greer (greer@utdallas.edu) wrote: > I need to make an application to run Excel from a C program. I've > got the MS Excel SDK and the IM IAC books. The former describes > objects and event which act upon them, while the latter gives > examples of how to use AppleEvents. But these examples aren't > much use helping me figure out how to do it with Excel, and the > Excel book has no examples at all. Can someone point me in the > right direction as to how to find how how to do what I need to do? Let me just say that I know all about this stuff and I wouldn't take on that job for all the tea in China! Of course, if I WERE stupid enough, I would simply implement the OSALoad & OSAExecute calls in my program so that I could run scripts and do all the Excel crap (and that's the part I wouldn't touch) in scripts. That would save you lots of time. Once you got it working (or should I say IF) you could save the script readonly for distribution as a program resource. Excel is one of the worst scriptable apps in existence and very poorly documented, if you can even call it documentation. Hopefully someone will take pity on you and provide example scripts. You'll need them. You'll need AppleScript for this too. It's the OSA layer. Jon +++++++++++++++++++++++++++ >From greer@utdallas.edu (Dale M. Greer) Date: 29 Mar 1994 14:45:43 GMT Organization: The University of Texas at Dallas Jon Pugh (jonpugh@netcom.com) wrote: > Dale M. Greer (greer@utdallas.edu) wrote: > > I need to make an application to run Excel from a C program. I've > > got the MS Excel SDK and the IM IAC books. The former describes > > objects and event which act upon them, while the latter gives > > examples of how to use AppleEvents. But these examples aren't > > much use helping me figure out how to do it with Excel, and the > > Excel book has no examples at all. Can someone point me in the > > right direction as to how to find how how to do what I need to do? > Let me just say that I know all about this stuff and I wouldn't take on > that job for all the tea in China! > Of course, if I WERE stupid enough, I would simply implement the OSALoad & > OSAExecute calls in my program so that I could run scripts and do all the > Excel crap (and that's the part I wouldn't touch) in scripts. That would > save you lots of time. Once you got it working (or should I say IF) you > could save the script readonly for distribution as a program resource. > Excel is one of the worst scriptable apps in existence and very poorly > documented, if you can even call it documentation. Hopefully someone > will take pity on you and provide example scripts. You'll need them. > You'll need AppleScript for this too. It's the OSA layer. Thanks for the encouraging words! ;-) I was considering the tack you suggest, and was able to load and manipulate data into a spreadsheet from an AppleScript script. But it just seems kind of ugly to have software components strewn all over the disk. On the other hand, we've only got about 4 weeks to do this, so I might just do the quick and dirty first, and tidy it up later. At least there is an example of how to load, compile and execute a script in the IM IAC book. And I actually found an example of how to use Create Element, but in the Recording Apple Events section instead of the Creating and Sending Apple Events section where one might have hoped it would be. Still no success there, but I think I'm converging on it. -- Dale Greer, greer@utdallas.edu "You can't just wake up and kiss the mirror and say 'I'm so purdy, I think I'll run for Governor.'" - Texas Gov. Ann Richards +++++++++++++++++++++++++++ >From Carl R. Osterwald Date: Tue, 29 Mar 94 17:14:07 GMT Organization: National Renewable Energy Laboratory In article Jon Pugh, jonpugh@netcom.com writes: >Excel is one of the worst scriptable apps in existence and very poorly >documented, if you can even call it documentation. Hopefully someone >will take pity on you and provide example scripts. You'll need them. Ugh -- X-barf. This reminds me of the time I had to write a external function to allow a macro to do serial I/O. The external was easy -- integrating it into and debugging the macro was, shall we say, less than pleasant. I was ready for a self-lobotomy about half way through. Excel macro language -- absolutely the worst programming environment I have ever personally been exposed to. +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Tue, 29 Mar 1994 18:40:12 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) jonpugh@netcom.com (Jon Pugh) writes: >Dale M. Greer (greer@utdallas.edu) wrote: >> I need to make an application to run Excel from a C program. I've >> got the MS Excel SDK and the IM IAC books. The former describes >> objects and event which act upon them, while the latter gives >> examples of how to use AppleEvents. But these examples aren't >> much use helping me figure out how to do it with Excel, and the >> Excel book has no examples at all. Can someone point me in the >> right direction as to how to find how how to do what I need to do? >Let me just say that I know all about this stuff and I wouldn't take on >that job for all the tea in China! I did the other side of this last year. I had to write a program that received and processed the Table Suite events that Excel understands. It's a pain, and it runs slow, but it can be done. It doesn't require AppleScript at all. But I had to write a few thousand lines of code to do it. Here, for reference, is the AppleEvent which sets cell [1,1] to a value of 0.0: AppleEvent received: AppleEvent: Class 'core' ID 'setd' List of 2 items: [ 1] Key: '----' Type: 'obj ' Record of 4 items: [ 1] Key: 'want' Type: 'type' [ 1] 4 bytes: [ 1] 0x00: 0x6363656c 'ccel' [ 2] Key: 'from' Type: 'obj ' Record of 4 items: [ 1] Key: 'want' Type: 'type' [ 1] 4 bytes: [ 1] 0x00: 0x63726f77 'crow' [ 2] Key: 'from' Type: 'obj ' Record of 4 items: [ 1] Key: 'want' Type: 'type' [ 1] 4 bytes: [ 1] 0x00: 0x646f6375 'docu' [ 2] Key: 'from' Type: 'null' [ 2] 0 bytes: [ 3] Key: 'form' Type: 'enum' [ 3] 4 bytes: [ 3] 0x00: 0x6e616d65 'name' [ 4] Key: 'seld' Type: 'TEXT' [ 4] Text (9 chars): [ 4] "Link file" [ 3] Key: 'form' Type: 'enum' [ 3] 4 bytes: [ 3] 0x00: 0x696e6478 'indx' [ 4] Key: 'seld' Type: 'long' [ 4] Text (1 chars): [ 4] "1" [ 3] Key: 'form' Type: 'enum' [ 3] 4 bytes: [ 3] 0x00: 0x696e6478 'indx' [ 4] Key: 'seld' Type: 'long' [ 4] Text (1 chars): [ 4] "1" [ 2] Key: 'data' Type: 'TEXT' [ 2] Text (5 chars): [ 2] "0.000" John Nagle +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Tue, 29 Mar 1994 11:22:30 -0800 Organization: Internet for the Olympic Peninsula In article , jonpugh@netcom.com (Jon Pugh) wrote: > Excel is one of the worst scriptable apps in existence and very poorly > documented, if you can even call it documentation. Hopefully someone > will take pity on you and provide example scripts. You'll need them. Well, Excel was also one of the earliest scriptable applications, and some things changed after it came out (like Apple appropriating the word "text"). Excel even came before the change in Frontier's construction of object specifiers between Frontier 1.0 (weird, and I never fully "got" it) and Frontier 2.0 (quite simple), so, unlike the FileMaker folks, the Excel developers didn't even have Frontier to use for testing. So while Excel has problems, it at least has a decent excuse. -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From Manuel Veloso Date: Wed, 30 Mar 1994 06:41:04 GMT Organization: Ibex Productions In article Jon Pugh, jonpugh@netcom.com writes: >Excel is one of the worst scriptable apps in existence and very poorly >documented, if you can even call it documentation. Hopefully someone >will take pity on you and provide example scripts. You'll need them. That's really true. However, on AOL there's some documentation written by one of the Excel guys about its applescript/ae support, and it works. I was always under the impression you needed the "R1C1" format, but Excel actually supports the "row 1 of column 5" specifier. I really don't quite know where to post this, but if people want it I can send them a copy. +++++++++++++++++++++++++++ >From isis@netcom.com (Mike Cohen) Date: Wed, 30 Mar 1994 18:34:42 GMT Organization: ISIS International Carl R. Osterwald writes: >In article Jon Pugh, jonpugh@netcom.com >writes: >>Excel is one of the worst scriptable apps in existence and very poorly >>documented, if you can even call it documentation. Hopefully someone >>will take pity on you and provide example scripts. You'll need them. >Ugh -- X-barf. This reminds me of the time I had to write a external >function to allow a macro to do serial I/O. The external was easy -- >integrating it into and debugging the macro was, shall we say, less than >pleasant. I was ready for a self-lobotomy about half way through. Excel >macro language -- absolutely the worst programming environment I have >ever personally been exposed to. There's one even worse - FoxPro (which I've unfortunately been doing a lot of work with lately). Is it a coincidence that both are from Microsoft? -- Mike Cohen - isis@netcom.com NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20 +++++++++++++++++++++++++++ >From Carl R. Osterwald Date: Wed, 30 Mar 94 22:58:30 GMT Organization: National Renewable Energy Laboratory In article Mike Cohen, isis@netcom.com writes: >There's one even worse - FoxPro (which I've unfortunately been doing a lot of >work with lately). Well, I hope I don't have to find out! >Is it a coincidence that both are from Microsoft? Most likely not. +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Wed, 30 Mar 1994 09:41:47 -0800 Organization: Internet for the Olympic Peninsula As an experiment, I have added a source file to a toy application in which I am experimenting with OSA issues. The addition implements two ways to cause Excel to launch (if it isn't running), open a particular toy spreadsheet (if it isn't open), and set cell 1 of row 1 of that spreadsheet to a value (ie, set the formula of the cell to a formula which produces the value). The two ways: 1--compile and execute an OSA script (I used AppleScript); 2--use toolbox (LaunchApplication), AE Manager, and other routines to launch Excel and send the appropriate events. It took around a half hour (half of which was reminding myself of toolbox details) to get the OSA script method running...in the course of which I learned a detail about Excel scripting [below]. The rest of the evening (not full time) got the other method to the point of launching Excel (if necessary), and opening the document. Now I need to go back and check whether the document is open, and set the cell formula. I expect to post the resulting source code to the server at gaea.kgs.ukans.edu as sampleware when it's ready. Go the OSA route: it's simpler and less painful, provided you know your execution environment HAS a scripting environment (AppleScript or Frontier) running. - --------Excel Note--------- If you send Excel an open event for a spreadsheet which is already open and modified, Excel demands to come to the front so it can ask the user whether to revert the document. Excel does this even if the open event is sent with the kAENeverInteract flag. So: in scripts (or the other way), check for the document being open first. -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] jwbaxter@pt.olympus.net --------------------------- >From Chris Russo Subject: Finding the High Bit Date: 24 Mar 1994 17:58:53 GMT Organization: Sonic Systems, Inc. Hi all, I need to find the high bit in a long as quickly as possible. 1. I could brute-force shift left till negative. 2. I could brute-force shift right till zero. 3. I could create a 256 byte lookup table and do 1-4 lookups. 4. Someone on the net could show me some neat new algorithm, like (number)>>(number>>1) ^ number = solution. There HAS to be something like that out there somewhere. :-) Thanks in advance, Chris Russo Note new address -> chris@sonicsys.com +++++++++++++++++++++++++++ >From resnick@cogsci.uiuc.edu (Pete Resnick) Date: Thu, 24 Mar 1994 12:28:48 -0600 Organization: University of Illinois at Urbana-Champaign In article <2mskct$50a@gaia.internex.net>, Chris Russo wrote: > I need to find the high bit in a long as quickly as possible. If you don't care about doing it in C and you can depend on a 68020 or better: #pragma parameter __D0 FindFirstOne(__D0) long FindFirstOne(long value) = {0xEDCO,0x0000}; Otherwise, I think the brute force shift right is best if you put the value into an unsigned long first: myUnsigned = myLong; bitCount = 0; while(myUnsigned != 0L) { ++bitCount; myUnsigned >>= 1; } pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Graduate assistant - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@cogsci.uiuc.edu +++++++++++++++++++++++++++ >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Date: 25 Mar 1994 16:43:12 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article <2mskct$50a@gaia.internex.net> Chris Russo writes: > I need to find the high bit in a long as quickly as possible. > 1. I could brute-force shift left till negative. > 2. I could brute-force shift right till zero. > 3. I could create a 256 byte lookup table and do 1-4 lookups. > 4. Someone on the net could show me some neat new algorithm, like > (number)>>(number>>1) ^ number = solution. There HAS to be > something like that out there somewhere. :-) well, i'm not sure if this is of value to you, but if you can assume that you're on a PowerPC-based Mac, you can use the cntlzw (Count Leading Zeros Word) instruction. the syntax is: cntlzw[.] rA,rS and it returns (in rA) the number of leading zeros (0-32) in the value stored in rS. if you append the '.', the condition codes will be updated so you can quickly tell if the value in rA is zero (meaning the high-bit of rS is set). there is also a doubleword version (cntlzd) that will work on 64-bit quantities, but it exists only on 64-bit PowerPC implementations, eg: the 620. -gary j kacmarcik platypus@curie.ces.cwru.edu +++++++++++++++++++++++++++ >From sigurasg@rhi.hi.is (Sigurdur Asgeirsson) Date: 25 Mar 1994 20:56:45 GMT Organization: University of Iceland In platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes: >In article <2mskct$50a@gaia.internex.net> Chris Russo writes: >> I need to find the high bit in a long as quickly as possible. >> 1. I could brute-force shift left till negative. >> 2. I could brute-force shift right till zero. >> 3. I could create a 256 byte lookup table and do 1-4 lookups. >> 4. Someone on the net could show me some neat new algorithm, like >> (number)>>(number>>1) ^ number = solution. There HAS to be >> something like that out there somewhere. :-) >well, i'm not sure if this is of value to you, but if you can assume >that you're on a PowerPC-based Mac, you can use the cntlzw (Count >Leading Zeros Word) instruction. [snip] On the >=68020 there is a similar BFFO (bitfield find first one) instruction that will find the first 1 bit in a bit field (register if you will). -- Sigurdur Asgeirsson | "Well you know, C isn't that hard, void (*(*f[])())() Kambasel 26 | for instance declares f as an array of unspecified 109 Reykjavik, Iceland | size, of pointers to functions that return pointers to sigurasg@rhi.hi.is | functions that return void... I think" +++++++++++++++++++++++++++ >From tzs@u.washington.edu (Tim Smith) Date: 26 Mar 1994 08:53:28 GMT Organization: University of Washington School of Law, Class of '95 Chris Russo wrote: >Hi all, > > I need to find the high bit in a long as quickly as possible. >1. I could brute-force shift left till negative. >2. I could brute-force shift right till zero. >3. I could create a 256 byte lookup table and do 1-4 lookups. >4. Someone on the net could show me some neat new algorithm, like > (number)>>(number>>1) ^ number = solution. There HAS to be > something like that out there somewhere. :-) > >Thanks in advance, This *almost* works (rounding problems--maybe they can be fixed), and is reasonably portable, and might even be fast, if your compiler can inline log: int FindFirstBit( unsigned long arg ) { return log(arg)/log(2); } This can compile to something like this: 00000000: 4E56 0000 LINK A6,#$0000 00000004: F22E 4014 0008 FLOGN.L arg(A6),FP0 0000000A: F23C 5094 0002 FLOGN.W #$0002,FP1 00000010: F200 0420 FDIV FP1,FP0 00000014: F200 0003 FINTRZ FP0 00000018: F200 7000 FMOVE.W FP0,D0 0000001C: 4E5E UNLK A6 0000001E: 4E75 RTS --Tim Smith +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Sat, 26 Mar 1994 18:23:40 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) >In article <2mskct$50a@gaia.internex.net> Chris Russo writes: >> I need to find the high bit in a long as quickly as possible. Use a BFFFO (Find First One in Bit Field) instruction. This requires a 68020 or above. Check the timing table for your CPU, though; this may turn out to be slow for large shifts on some CPUs. The right way to implement an instruction like this is by using the floating point normalizer, but this instruction isn't an FPU instruction, so it probably doesn't. Alternatively, though, you could write something like int ffb(unsigned long n) { if (n & 0xffff0000) { if (n & 0xff000000) return(tab[n>>24]+24); else return(tab[(n>>16)&0xff]+16); } if (n & 0xff00) return(tab[(n>>8)&0xff]+8); else return(tab[n]); } using a pre-built table. Shifts of multiples of 8 bits are fast on 68K CPUs, so this is reasonably efficient. But look at what comes out of the compiler, and make sure the compiler is smart enough to do this without pushing operands on the stack. Are you doing cryptanalysis, chess, or emulation of some nonstandard FPU? John Nagle +++++++++++++++++++++++++++ >From tom@dtint.dtint.com (Thomas R. Kimpton) Date: Tue, 29 Mar 94 00:16:24 GMT Organization: Digital Technology, International In article <2mskct$50a@gaia.internex.net> Chris Russo writes: >Hi all, > > I need to find the high bit in a long as quickly as possible. >1. I could brute-force shift left till negative. >2. I could brute-force shift right till zero. >3. I could create a 256 byte lookup table and do 1-4 lookups. >4. Someone on the net could show me some neat new algorithm, like > (number)>>(number>>1) ^ number = solution. There HAS to be > something like that out there somewhere. :-) > >Thanks in advance, > >Chris Russo > >Note new address -> chris@sonicsys.com long findHighBit(register unsigned long n) { register long bitnum = 0; if(n & 0xffff0000){ bitnum += 16; n >>= 16; } if(n & 0xff00){ bitnum += 8; n >>= 8; } if(n & 0xf0){ bitnum += 4; n >>= 4; } if(n & 0xc){ bitnum += 2; n >>= 2; } if(n & 0x2){ bitnum += 1; } } You'd want to check to see if 'n' is zero before calling this, though. Tom. -- - - Tom Kimpton tom@dtint.dtint.com Digital Technology Int. (801)226-2984 500 W. 1200 South, Orem UT, 84057 FAX (801) 226-8438 +++++++++++++++++++++++++++ >From saseew@router.unx.sas.com (Ed Walker) Date: Wed, 30 Mar 1994 14:21:47 GMT Organization: SAS Institute Inc. In article <1994Mar29.001624.845@dtint.dtint.com>, tom@dtint.dtint.com (Thomas R. Kimpton) writes: >In article <2mskct$50a@gaia.internex.net> Chris Russo writes: >>Hi all, >> >> I need to find the high bit in a long as quickly as possible. >>1. I could brute-force shift left till negative. >>2. I could brute-force shift right till zero. >>3. I could create a 256 byte lookup table and do 1-4 lookups. >>4. Someone on the net could show me some neat new algorithm, like >> (number)>>(number>>1) ^ number = solution. There HAS to be >> something like that out there somewhere. :-) >> >>Thanks in advance, >> >>Chris Russo >> >>Note new address -> chris@sonicsys.com > > >long >findHighBit(register unsigned long n) >{ >register long bitnum = 0; > > if(n & 0xffff0000){ > bitnum += 16; > n >>= 16; > } > if(n & 0xff00){ > bitnum += 8; > n >>= 8; > } > if(n & 0xf0){ > bitnum += 4; > n >>= 4; > } > if(n & 0xc){ > bitnum += 2; > n >>= 2; > } > if(n & 0x2){ > bitnum += 1; n >>= 1; /* Added line */ > } if ( n ) bitnum += 1; /* Added line */ return bitnum; /* Added line */ > >} > >You'd want to check to see if 'n' is zero before calling this, though. > >Tom. > Good job Tom! I suggest adding the indicated lines above. Your method numbers the bits from 0 to 31 (right to left) while the additions number them 1-32 (r-l) and returns zero if none are on. Ed >'< (o o) +---------------------------------------------o0o-U-o0o---------------+ | EdWalker@aol.com (home) | It is impossible to make anything | | saseew@sas.mvs.com (work) | foolproof; fools are so ingenious. | +---------------------------------------------oo0---0oo---------------+ --------------------------- >From blalock@opus.hpl.hp.com (Travis Blalock) Subject: Generating Activate Events Date: Tue, 29 Mar 1994 18:59:08 GMT Organization: HP Labs, High Speed Electronics Dept., Palo Alto, CA ** Warning UI violations in progress ** I am looking at ways of generating activate/deactivate events from a system extension. Activate events are not listed in IM as one of the events I can post with PostEvent or PPostEvent. Is this a 'real' limitation or a 'you shouldn't do this' limitiation? I will just try it as soon as I get a chance, but I thought I would test the waters here. I do not want to use SelectWindow because I don't want the window to come to the top. Any advice (other than don't do that :-)) appreciated. Travis blalock@hpl.hp.com +++++++++++++++++++++++++++ >From d88-jwa@hemul.nada.kth.se (Jon Wätte) Date: 29 Mar 1994 20:29:36 GMT Organization: The Royal Institute of Technology In <14290001@opus.hpl.hp.com> blalock@opus.hpl.hp.com (Travis Blalock) writes: >I am looking at ways of generating activate/deactivate events from a >system extension. Activate events are not listed in IM as one of the LMSetCurActivate() and LMSetCurDeactive() However, if there's already such an event pending, you're out of luck. -- -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe -- Santa's Reindeer: Fry 1 minced onion, add 1 lb thinly sliced frozen reindeer, fry to color, add 1/2 lb mushrooms and 1/2 lb sour cream, simmer 5 mins, add soy to taste, salt, pepper. Serve with boiled rice and tart jelly. +++++++++++++++++++++++++++ >From walkerj@math.scarolina.edu (Jim Walker) Date: 29 Mar 1994 21:20:47 GMT Organization: University of South Carolina - Columbia - Computer Science Activate/deactivate are not supposed to be in the event queue, hence you are not supposed to create them with PostEvent/PPostEvent. However, for certain purposes having to do with scrap conversion, I have found it useful to create activate events with PPostEvent, and have not seen any obvious ill effects. I don't think I ever tried it for a window that's not the front window, though. As always, "your mileage may vary." -- -- Jim Walker USC Dept. of Math. walkerj@math.scarolina.edu --------------------------- >From Willie Rauchwerger Subject: I got my PPC PDS card... Date: 30 Mar 1994 15:26:21 GMT Organization: OU Health Sciences Center Well, I got my PPC PDS card for my Quadra 700 yesterday. I know not many people (if any) have posted their experiences with the card, and I thought I might give a bit of an overview. In the box, their are three major items: - the PDS cad - a 610-PDS adaptor for the card - System 7.1.2 Installing it was pretty easy - pop open the Quadra, decide what NuBus card I was going to lose, and put the card in the PDS slot. Then, boot from the install disk, and let it upgrade your system to System 7.1.2. (Now I did this on my portable drive I bring to work, and I can verify that System 7.1.2 does boot for 68k machines as well. As I booted off it to type this post...) System 7.1.2 is basically a minor rev to support PowerPC. Very, very little is native as far as control panels, extensions, the finder, etc. As a matter of fact, the finder is completely emulated, and every control panel and extension I looked at (I may have missed a few) were 68k binaries. No code fragments to be found. Except in the "PowerPC Upgrade Card Enabler"...it is a 420k file, that some interesting things inside of it. In the "fovr" resource, I assume I found Native QuickDraw (NQD), and the new native Memory Manager...also I found maybe a native on-board video display driver? I am not sure whether or not it was replacing the one in the system or not. Oh, yeah, the QuickTime native codecs are in the QuickTime power plug...yes, it is very fast... I digress...after you perform the update, reboot. My Quadra booted into the 68k enviroment, since I hadn't a chance to set the control panel to reboot from the PDS card. Set the control panel and shutdown. Restart doesn't cut it - anytime you switch between the PDS and the 040, you have to shutdown. I assume some pram thing... Power on. A really killer startup sound. And it isn't the new Stanley Jordan one, nor is it the old Quadra one, or the AV one... I think this one is great... OK, I know, how did it work? Well, about as I expected in emulation. I ran my normal software and it was a bit slower than my 040. However, my heavily reliant on QuickDraw things, (some of my own software that pegs CopyBits, etc. and others) were very fast. ClarisWorks for 68k seemed no different than on the 040. I found one problem...Think C 6.01 won't compile...not that it is a big issue for me...I jumped to Metrowerks for most of my stuff now anyway. Metrowerks C++ for PPC was great. I had worked on getting my software ready for it, and I just love it. It is really repsonsive, and compiles very, very fast. A project that was taking approx 2:00 min to compile under Think on a Q800, 1:15 min under Metrowerks on a Q800, took 28 secs on Metrowerks for PPC on my upgrade card. Wow. I was also concerned about how fast it would be accessing memory that was on the main board, so I wrote some stuff to work with 8mb pointer, and the PPC card was still about 3 times faster than with my Q700 with the 040 running. I know this is a bit rambling, but I didn't know what everyone would be interested in...I will try to answer any questions anyone has about it. Bottom line: It seemed almost as fast as the Q700 in emulation, and was 2-3 faster in native software. Well, worth the $650 bucks... - ----------------------------------------------------------------- Willie Rauchwerger AppleLink: Willie Telemedicine Software Guy Internet: willie-rauchwerger@uokhsc.edu OU Health Sciences Center --------------------------- >From kpmiller@netcom.com (Kent Miller) Subject: Moving an editText area in a Modal Dialog Q Date: Mon, 28 Mar 1994 05:01:46 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Can anyone tell me how to move an editText area in a modal dialog? A little background: I am writing a code resource to put up a dialog for user input. Since I didn't want to go to the hassle of making sure that all the resources got moved with the code resource, I decided to use NewDialog instead of making dialog resources. To have an item list, I made one in resedit, then copied the hex and put it with the code. When I want to use it, I just make a new handle and copy the list data in it, then pass that to NewDialog. This works pretty well and I can move buttons around to my hearts content (after I figured out that you had to call SetDItem and MoveControl to do it.) But, now I need to move the editText area. Any help would be appreciated. Kent -- ____________________________________________________________ kpmiller@netcom.com | Macintosh Software Engineer ____________________________________________________________ +++++++++++++++++++++++++++ >From smoke@well.sf.ca.us (Nicholas Jackiw) Date: 29 Mar 1994 17:59:42 GMT Organization: The Whole Earth 'Lectronic Link, Sausalito, CA In article , Kent Miller wrote: > >Can anyone tell me how to move an editText area in a modal dialog? > >Kent If you need to move them only once (i. e. "to final position"), simply use SetDItem(theDlog, theItem, ... theRect), where theRect is computed to be the desired location of the editText item in dialog-local coordinates. Do this before you ShowWindow(theDlog) and things look dandy. If you need to move an edit text item while the dialog is showing, it's more complicated. If the edit text happens to be the one currently in use by the user (not necessarily the case if there are >1 edit text items), you need to treat DialogPeek(theDlog)^.textH as an active TEdit control and update its viewRect and destRect. (The user is currently using edit text item DialogPeek(theDlog)^.editField+1.) A more elegant approach, in this second case, would be to use multiple edit text boxes, one at Location 1 and one at Location 2, etc. Use HideDItem and ShowDItem to determine which one is visible at any given time. Is this the sort of info you wanted? -- --- * --- Nick Jackiw Smoke@well.sf.ca.us | Jackiw@cs.swarthmore.edu Key Curriculum Press, Inc. Applelink:KEY.EDUSOFT | (510) 548-2304 --- * --- +++++++++++++++++++++++++++ >From leblonk@netcom.com (Marcel Blonk) Date: Tue, 29 Mar 1994 22:10:06 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Kent Miller (kpmiller@netcom.com) wrote: : Can anyone tell me how to move an editText area in a modal dialog? Here's a copy of the method I use to move dialog items: void CDialog::SetDRect( short item, Rect *r) { short type; Handle h; Rect rr; GetDItem( window, item, &type, &h, &rr); SetDItem( window, item, type, h, r); type &= ~itemDisable; if ( (type & ~0x3) == ctrlItem ) { MoveControl( (ControlHandle)h, r->left, r->top); SizeControl( (ControlHandle)h, r->right - r->left, r->bottom - r->top); } else if ( type == editText ) { if ( item == (((DialogPeek)window)->editField + 1) ) { if ( ((DialogPeek)window)->textH != nil ) { OffsetRect( &(*((DialogPeek)window)->textH)->destRect, r->left - rr.left, r->top - rr.top); OffsetRect( &(*((DialogPeek)window)->textH)->viewRect, r->left - rr.left, r->top - rr.top); OffsetRect( &(*((DialogPeek)window)->textH)->selRect, r->left - rr.left, r->top - rr.top); } } } } Hope this helps, Marcel --------------------------- >From bcburke@violet.berkeley.edu (Brian C. Burke) Subject: PPC Development and MPW Tools Date: Thu, 24 Mar 1994 23:02:09 -0800 Organization: UC Berkeley Will any of the available PowerPC development environments allow development and execution of (MPW like) tools in PowerPC native code. Brian +++++++++++++++++++++++++++ >From peirce@outpost.SF-Bay.org (Michael Peirce) Date: Mon, 28 Mar 94 10:17:35 PST Organization: Peirce Software, Inc. In article (comp.sys.mac.programmer), bcburke@violet.berkeley.edu (Brian C. Burke) writes: > Will any of the available PowerPC development environments allow > development and execution of (MPW like) tools in PowerPC native code. How about MPW? Apple has said they will be shipping some native MPW tools real-soon-now. I'm not holding my breath, but it should take them too long to do this for some of the more important tools. -- Michael Peirce -- peirce@outpost.sf-bay.org -- Peirce Software, Inc. -- 719 Hibiscus Place, Suite 301 -- -- San Jose, California USA 95117 -- Makers of: Smoothie & -- voice: +1.408.244.6554 fax: +1.408.244.6882 -- Peirce Print Tools -- AppleLink: peirce & America Online: AFC Peirce +++++++++++++++++++++++++++ >From langsys@pcthree.com (Language Systems) Date: Tue, 29 Mar 1994 14:23:30 GMT Organization: PC Three, Inc. peirce@outpost.SF-Bay.org (Michael Peirce) writes: >In article (comp.sys.mac.programmer), bcburke@violet.berkeley.edu (Brian C. Burke) writes: >> Will any of the available PowerPC development environments allow >> development and execution of (MPW like) tools in PowerPC native code. >How about MPW? Apple has said they will be shipping some native >MPW tools real-soon-now. I'm not holding my breath, but it should >take them too long to do this for some of the more important tools. Language Systems will soon be shipping 2 development tools for the PowerMacs. LS Pascal/PPC LS FORTRAN/PPC Both run with MPW and will be native on the PowerMac. Lisa Jones Language Systems 800-252-6479 (for more info) +++++++++++++++++++++++++++ >From Manuel Veloso Date: Wed, 30 Mar 1994 06:35:07 GMT Organization: Ibex Productions In article Michael Peirce, peirce@outpost.SF-Bay.org writes: >How about MPW? Apple has said they will be shipping some native >MPW tools real-soon-now. I'm not holding my breath, but it should >take them too long to do this for some of the more important tools. Last I heard, MPW was going to be native near the end of the year. This is from a friend who called & asked APDA about it, since he was also asking about his Mac on RISC disc upgrade. This is kind of ridiculous at first glance, but a few weeks ago I was looking at the funky stuff MPW had to do for tool support, and well, I understand why converting that might take a while. Then again, there's probably an alpha floating around out there somewhere, since Apple's never been shy about keeping tools in the alpha/beta state for a while. --------------------------- >From Dave.Falkenburg%f1.n3641.z1@psybbs.durham.nc.us (Dave Falkenburg) Subject: PowerMac Programming Date: 16 Mar 94 02:04:58 GMT Organization: (none) Organization: Apple Computer, Inc. In article Robert S. Mah, rmah@panix.com writes: > From the Mart 94 AppleDirections newsletter... > > Macintosh With PowerPC Bundle (B1864LL/A) $849.00 > Programmer's Introduction to RISC and PowerPC (R0172LL/A) $150.00 > Macintosh with PowerPC Starter Kit (R0563LL/A) $39.95 > Gack. That!s ALOT of money. Seems like E.T.O. should come with all this stuff, wouldn't you think? -Dave Falkenburg Disclaimer: I don!t speak for Apple in this post, although someone who think!s that the SDK is worth $850 bucks probably would. +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Fri, 25 Mar 1994 16:37:12 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) Dave.Falkenburg%f1.n3641.z1@psybbs.durham.nc.us (Dave Falkenburg) writes: >Organization: Apple Computer, Inc. >In article Robert S. Mah, >rmah@panix.com writes: >> From the Mart 94 AppleDirections newsletter... >> >> Macintosh With PowerPC Bundle (B1864LL/A) $849.00 >> Programmer's Introduction to RISC and PowerPC (R0172LL/A) $150.00 >> Macintosh with PowerPC Starter Kit (R0563LL/A) $39.95 >> >Gack. That!s ALOT of money. Keeps the rabble out. Can't have just anybody developing PowerPC apps. I still haven't seen a single PowerPC app in shrink-wrap form on a store shelf, but I talked to somebody who said that they knew somebody who had seen one. John Nagle +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Sat, 26 Mar 1994 01:50:31 GMT Organization: Adobe Systems Incorporated John Nagle writes > I still haven't seen a single PowerPC app in shrink-wrap form on > a store shelf, but I talked to somebody who said that they knew somebody > who had seen one. How about every copy of Photoshop 2.5.1 on store shelves? With the Power Macintosh accelerator (avaiable free on the net, as well as elsewhere) this product delivers the performance a straight Power Macintosh port would deliver for most operations. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 "Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins) +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Sat, 26 Mar 1994 18:02:30 GMT Organization: NETCOM On-line Communication Services (408 241-9760 guest) zstern@adobe.com (Zalman Stern) writes: >John Nagle writes >> I still haven't seen a single PowerPC app in shrink-wrap form on >> a store shelf, but I talked to somebody who said that they knew somebody >> who had seen one. >How about every copy of Photoshop 2.5.1 on store shelves? With the Power >Macintosh accelerator (avaiable free on the net, as well as elsewhere) this >product delivers the performance a straight Power Macintosh port would >deliver for most operations. I'm talking about product marketing. Yes, there's stuff you can get by mail-order. But I'm not seeing retailers committing shelf space to PowerPC software. Besides, the Photoshop "accelerator" isn't a full port; it's just faster versions of a few of the slower filters. John Nagle +++++++++++++++++++++++++++ >From usenet@lowry.eche.ualberta.ca (Brian Lowry) Date: 26 Mar 1994 21:29:44 GMT Organization: Chem Eng - Univ of Alberta In article , nagle@netcom.com (John Nagle) wrote: > zstern@adobe.com (Zalman Stern) writes: > >John Nagle writes > >> I still haven't seen a single PowerPC app in shrink-wrap form on > >> a store shelf, but I talked to somebody who said that they knew somebody > >> who had seen one. > >How about every copy of Photoshop 2.5.1 on store shelves? With the Power > >Macintosh accelerator (avaiable free on the net, as well as elsewhere) this > >product delivers the performance a straight Power Macintosh port would > >deliver for most operations. > I'm talking about product marketing. Yes, there's stuff you can get > by mail-order. But I'm not seeing retailers committing shelf space to > PowerPC software. > Besides, the Photoshop "accelerator" isn't a full port; it's just > faster versions of a few of the slower filters. I guess this means that almost every single filter built into Photoshop is one of the slower ones... where are the faster filters hiding? Before you go any further showing your massive misunderstanding of PowerPC programming, perhaps you ought to consider that a port to the PowerPC does not require 100% native code. All that is required is native code which patches the most processor intensive portions of an application. This is essentially what the Photoshop plug-in does, hence Photoshop is now native. Demanding 100% PowerPC code makes about as much sense as demanding that programmers stop using Quickdraw and write something more efficient... both Quickdraw and 680x0 emulation are built in, and there's no reason to reinvent the wheel for something like a 5% speed improvement. btw - before I get jumped on, yes I do know that Photoshop doesn't use Quickdraw exclusively, but then, Quickdraw doesn't support CMYK :) -- Brian Lowry +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Sun, 27 Mar 1994 09:42:27 GMT Organization: Adobe Systems Incorporated John Nagle writes [I still haven't seen a single PowerPC app in shrink-wrap form on a store shelf.] I wrote: [How about Photoshop 2.5.1 plus the Power Macintosh accelerator?] John Nagle writes > I'm talking about product marketing. Yes, there's stuff you can get > by mail-order. But I'm not seeing retailers committing shelf space to > PowerPC software. New copies of Photoshop 2.5.1 are shipping with the Power Macintosh accelerator in the package. This product provides the winning feature of a Power Macintosh (i.e. speed). It doesn't matter that it is not completely native. (And before you complain that it would be slightly faster if it were fully native, keep in mind that Apple made the same decision about their OS.) I'm not sure if the boxes will have a sticker on them saying "Includes Power Macintosh support" or whatever. > Besides, the Photoshop "accelerator" isn't a full port; it's just > faster versions of a few of the slower filters. I generally don't tell other people what code they wrote does unless I'm *damn* sure I know what I'm talking about. I expect you to afford me the same courtesy. The accelerator provides native implementations of almost every routine that is written in 68K assembly for 2.5.1. Considering the quality of Macintosh compilers, it it was speed critical, a routine got written in assembly. (Note: the main failing of the accelerator is it provides minimal speedup for plug-in filters. These run at emulated speed.) The accelerator provides around 90% of the speed benefit of a full native application with minimal impact on the memory footprint. (I know this because we did a bunch of measurements to make the comparison.) The QA effort for the accelerator product is relatively small. (Which is incredibly important given the limited beta testing opportunities.) The distribution plan is easy: anybody who wants one can have one because to get any value from it they need a copy of 2.5.1. In short, its an excellent engineering answer to the overhead of doing a complete new release of a product that's been shipping for a year to support a new piece of hardware. (When the full native version ships, it will be faster than the accelerator, but that has more to do with my improving the code between the products shipping.) The idea of allowing speed critical functions to be replaced at runtime and its implementation in Photoshop is due to Mark Hamburg and Thomas Knoll. The underlying technology that allows this replacement on PowerPC is Mixed Mode, implemented by various people at Apple (or formerly at Apple :-)) including Sean Parent and Bruce Jones. Given these two great ideas, I didn't have to think very hard to come up with the idea of this accelerator. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 "Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins) +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 29 Mar 94 13:36:14 MST Organization: (none) In article <764568523.AA03220@psybbs.durham.nc.us>, Dave.Falkenburg%f1.n3641.z1@psybbs.durham.nc.us (Dave Falkenburg) writes: > Organization: Apple Computer, Inc. > > In article Robert S. Mah, > rmah@panix.com writes: >> From the Mart 94 AppleDirections newsletter... >> >> Macintosh With PowerPC Bundle (B1864LL/A) $849.00 >> Programmer's Introduction to RISC and PowerPC (R0172LL/A) $150.00 >> Macintosh with PowerPC Starter Kit (R0563LL/A) $39.95 >> > > Gack. That!s ALOT of money. > > Seems like E.T.O. should come with all this stuff, wouldn't you think? > > -Dave Falkenburg > > Disclaimer: I don!t speak for Apple in this post, although someone who > think!s that the SDK is worth $850 bucks probably would. Do NOT buy the Programmer's Intro to RISC!!!!! Honest. It is a waste of money. I am working on a shareware product (also done in HyperCard) which will be worth far more and cost 1/10 as much. Lawson +++++++++++++++++++++++++++ >From siegel@netcom.com (Rich Siegel) Date: Wed, 30 Mar 1994 03:33:56 GMT Organization: Bare Bones Software In article <1994Mar29.133614.1@west.cscwc.pima.edu> 103t_english@west.cscwc.pima.edu writes: >Do NOT buy the Programmer's Intro to RISC!!!!! > > >Honest. It is a waste of money. I am working on a shareware product (also done >in HyperCard) which will be worth far more and cost 1/10 as much. > >Lawson ...and which will enrich your bottom line, or so you hope. Be sure that when posting, you make your articles as biased and content-free as possible, lest someone mistake your motives. R. (warning: the above may cause cognitive dissonance for the sarcasm-impaired.) -- Rich Siegel % siegel@netcom.com % Principal, Bare Bones Software --> For information about BBEdit, finger bbedit@world.std.com <-- "...yeah, I inhaled, and then I drank the bong water. So what're you gonna do about it?" - Dennis Miller, on Bill Clinton --------------------------- >From steve@hi.com (Steve Byan) Subject: PowerMacs and ARTA Date: 21 Mar 1994 19:30:16 GMT Organization: Hitachi Computer So what's happened to ARTA in the PowerMacs? How do I write real-time DSP code for the 601? (I'm not interested in purchasing a 3210 add-in card for the PowerMacs.) Steve Byan internet: steve@hi.com Hitachi Computer Products (America), Inc. 1601 Trapelo Road phone: (617) 890-0444 Waltham, MA 02154 FAX: (617) 890-4998 +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 23 Mar 94 10:05:25 +1300 Organization: University of Waikato, Hamilton, New Zealand In article , steve@hi.com (Steve Byan) writes: > So what's happened to ARTA in the PowerMacs? How do I write real-time DSP > code for the 601? (I'm not interested in purchasing a 3210 add-in card for > the PowerMacs.) Last I heard ARTA is included with the PowerMacs, only there is no DSP for them to talk to (you have to buy add-in cards for that). As for writing real-time DSP code for a general-purpose CPU, good luck... Lawrence D'Oliveiro fone: +64-7-856-2889 Info & Tech Services Division fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Wed, 23 Mar 1994 05:00:05 GMT Organization: Adobe Systems Incorporated Lawrence D'Oliveiro, Waikato University writes > In article , steve@hi.com (Steve Byan) writes: > > So what's happened to ARTA in the PowerMacs? How do I write real-time DSP > > code for the 601? (I'm not interested in purchasing a 3210 add-in card for > > the PowerMacs.) > > Last I heard ARTA is included with the PowerMacs, only there is no DSP for > them to talk to (you have to buy add-in cards for that). The 'rtmr' gestalt selector is undefined on the Power Macintosh. I assume third-party DSP cards provide ARTA themselves as they do for non-AV 68K Macs. > As for writing real-time DSP code for a general-purpose CPU, good luck... This has a lot more to do with the OS software than the CPU. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 "Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins) +++++++++++++++++++++++++++ >From steve@hi.com (Steve Byan) Date: 23 Mar 1994 17:58:37 GMT Organization: Hitachi Computer In article <1994Mar23.100525.26753@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) wrote: > > In article , steve@hi.com (Steve Byan) writes: > > So what's happened to ARTA in the PowerMacs? How do I write real-time DSP > > code for the 601? (I'm not interested in purchasing a 3210 add-in card for > > the PowerMacs.) > > Last I heard ARTA is included with the PowerMacs, only there is no DSP for > them to talk to (you have to buy add-in cards for that). > > As for writing real-time DSP code for a general-purpose CPU, good luck... Apple claims to ship real-time speech-recognition, speech synthesis, and 9600 baud modem code with the PowerMacs - using only the 601 - not using any DSP chip. Supposedly the 601 can do multiply-accumulates faster than the 3210. The remaining question is "by what mechanism am I supposed to schedule real-time (DSP) code that executes on the 601, and processes sound samples?". For the AV Macs, the answer was "use ARTA". My hope is that the same API applies for the PowerMacs. Does anyone have any real information they can pass on? Thanks, -Steve Steve Byan internet: steve@hi.com Hitachi Computer Products (America), Inc. 1601 Trapelo Road phone: (617) 890-0444 Waltham, MA 02154 FAX: (617) 890-4998 +++++++++++++++++++++++++++ >From amanda@intercon.com (Amanda Walker) Date: Wed, 23 Mar 1994 16:08:20 -0500 Organization: InterCon Systems Corporation, Herndon, VA USA ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > Last I heard ARTA is included with the PowerMacs, only there is no DSP > for them to talk to (you have to buy add-in cards for that). ARTA is not present. There is evidently some real-time code in them (used by the Power Macintosh Geoport software, for example), but it is so far undocumented. > As for writing real-time DSP code for a general-purpose CPU, good > luck... Indeed. I get sound dropouts on my 8100/80 if the CPU gets busy. I'm sticking with my 660AV for anything involving audio for the time being. Amanda Walker Advanced Projects InterCon Systems Corporation +++++++++++++++++++++++++++ >From amanda@intercon.com (Amanda Walker) Date: Wed, 23 Mar 1994 16:09:26 -0500 Organization: InterCon Systems Corporation, Herndon, VA USA steve@hi.com (Steve Byan) writes: > For the AV Macs, the answer was "use ARTA". My hope is that the same API > applies for the PowerMacs. It does not. Any real-time API that may exist on Power Macintosh machines is currently undocumented. There's always the Time Manager, I suppose :-P. Amanda Walker Advanced Projects InterCon Systems Corporation +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 25 Mar 94 14:27:54 +1300 Organization: University of Waikato, Hamilton, New Zealand In article <9403231608.AA20803@fusion.intercon.com>, amanda@intercon.com (Amanda Walker) writes: > ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >> Last I heard ARTA is included with the PowerMacs, only there is no DSP >> for them to talk to (you have to buy add-in cards for that). > > ARTA is not present. There is evidently some real-time code in them (used > by the Power Macintosh Geoport software, for example), but it is so far > undocumented. > >> As for writing real-time DSP code for a general-purpose CPU, good >> luck... > > Indeed. I get sound dropouts on my 8100/80 if the CPU gets busy. > I'm sticking with my 660AV for anything involving audio for the time being. (Gloat, gloat.) I'd just like to repeat a couple of statements I made on comp.sys.mac.hardware: * N + 1 processors are better than N. You can usually find a way to make use of more processors to run things in parallel. * A purpose-built processor is inherently superior to a general-purpose one _for that particular purpose_. People keep talking about how "DSP-like" the PowerPC is, just because it can do a multiply-and-add in one instruction. But there's more to a DSP than that. Put these two together, and the conclusion is inescapable: Apple is going to have to return to the multiple-processor approach, and bring out Power Macs with DSPs in them. When that happens, I might be tempted to give up my 840AV... Lawrence D'Oliveiro fone: +64-7-856-2889 Info & Tech Services Division fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 +++++++++++++++++++++++++++ >From james@astro.as.utexas.edu (James McCartney) Date: 25 Mar 1994 14:27:43 GMT Organization: McDonald Observatory, University of Texas @ Austin In article <9403231609.AA26772@fusion.intercon.com>, Amanda Walker wrote: > Any real-time API that may exist on Power Macintosh machines >is currently undocumented. There's always the Time Manager, I suppose :-P. Having not used the Time Mgr, what does it really guarantee in terms of max delay, etc? How reliable would using the callback routines in the double buffering sound routines be? --- james mccartney +++++++++++++++++++++++++++ >From andrewb@iconz.co.nz (Andrew Bevin) Date: 26 Mar 1994 07:34:32 GMT Organization: data visual software In article <1994Mar25.142754.26895@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) wrote: ... > > Put these two together, and the conclusion is inescapable: Apple is going > to have to return to the multiple-processor approach, and bring out Power Macs > with DSPs in them. > > When that happens, I might be tempted to give up my 840AV... > > Lawrence D'Oliveiro fone: +64-7-856-2889 > Info & Tech Services Division fax: +64-7-838-4066 > University of Waikato electric mail: ldo@waikato.ac.nz > Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 So what happened to the centris 650 with the Video Spigot? Andrew "Just keeping tabs" Bevin -- andrewb@iconz.co.nz -- "I've a Plan so cunning you could put a tail on it and call it a weasel" - BlackAdder +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Sun, 27 Mar 1994 03:06:35 GMT Organization: Adobe Systems Incorporated Lawrence D'Oliveiro, Waikato University writes > (Gloat, gloat.) I'd just like to repeat a couple of statements I made on > comp.sys.mac.hardware: Gloating seldom improves the rigor of one's arguments. > * N + 1 processors are better than N. You can usually find a way to make use > of more processors to run things in parallel. The above statement is simply not true. First off, N + 1 processors cost more than N (for positive N :-)). In the case of going from N=1 to N=2, the expense is more than the added cost of another processor as external hardware must be added and significant software development costs must be amortized. In the performance realm, there are plenty of examples of parallelized software running slower than a uniprocessor version. There are two primary reasons for this: communication overhead and slower hardware. Communication overhead involves the obvious issue of synchronizing separate processes and transferring data from one processor to another. (Even if they share memory, cache issues must be taken into account.) The slower hardware issue is more interesting. Generally, simpler hardware has a faster design cycle and is cheaper to produce. The result of this is that for a given amount of money in a given timeframe, a uniprocessor machine will be faster than the individual processors in a multiprocessor box. Unless you're application takes good advantage of the multiprocessor, it will run faster on the uniprocessor. This is especially relevant for a heterogeneous multiprocessor like the 840AV where it is more difficult (and much less portable) to split one's application between different CPUs. > * A purpose-built processor is inherently superior to a general-purpose one > _for that particular purpose_. The DSP subsystem in Apple's AV Macs attempts to be general purpose. By the time all is said and done, it has to support telecommunications, audio processing, and image processing. A whole real-time OS and software architecture is required to implement all this. Furthermore, since it is exported to applications software, lots of flexibility in hardware implementation is lost since future platforms have to be compatible. The subsystem is most specialized for telecom applications. Which is nice, except that I can get that functionality with cost effective add-on modem hardware. In contrast, when SGI (a company noted for strong multi-media support) built hardware with an embedded DSP, they did not export interfaces to the DSP directly. Rather they provided high-level libraries to implement signal processing functionality. They now ship R4000 based machines without a DSP and old software works fine. > People keep talking about how "DSP-like" the > PowerPC is, just because it can do a multiply-and-add in one instruction. But > there's more to a DSP than that. PowerPC provides a number of other features which are useful for implementing signal processing codes such as zero overhead loops and update addressing modes. The only DSP like thing that is really missing is efficient methods of converting floating-point numbers into common signal data formats (e.g. 8 and 16 bit integers, u law and A law 8 bit formats). The architecture also makes it difficult to cheaply implement as much memory bandwidth as the DSP3210 has. However, the DSP3210 architecture basically mandates a certain pipeline and other features which make it fairly inflexible. > Put these two together, and the conclusion is inescapable: Apple is going > to have to return to the multiple-processor approach, and bring out Power Macs > with DSPs in them. The problem Apple has now is running anything remotely real-time on the same processor as their system software. One solution to this is adding another processor to the box. Another solution is to write better system software. If they do add more hardware to the box, there is nothing that says it has to be a DSP3210. (For example, a 603 or one of the new PowerPC implementations targeted at the embedded market would probably work as well and be a lot easier to develop software for.) > When that happens, I might be tempted to give up my 840AV... My two favorite quotes on the 840AV: "It sucketh mightily." and "The IIfx of the 90's." I've tried programming the DSP3210 and I have lots of experience with PowerPC. I'll take PowerPC anytime thank you. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 "Do right, and risk consequences." Motto of Sam Houston (via Molly Ivins) +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 28 Mar 1994 13:44:02 -0800 Organization: SRI International, Menlo Park, CA In article <1994Mar27.030635.19508@adobe.com> zstern@adobe.com (Zalman Stern) writes: >I've tried programming the DSP3210 and I have lots of experience with >PowerPC. I'll take PowerPC anytime thank you. Besides, I you can get a PPC compiler for about $300.00. The DSP compiler is about $1000.00. Ouch! Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 29 Mar 94 11:54:55 +1300 Organization: University of Waikato, Hamilton, New Zealand In article <1994Mar27.030635.19508@adobe.com>, zstern@adobe.com (Zalman Stern) writes: > Lawrence D'Oliveiro, Waikato University writes >> * N + 1 processors are better than N. You can usually find a way to make > use >> of more processors to run things in parallel. > > The above statement is simply not true. First off, N + 1 processors cost > more than N (for positive N :-)). Nevertheless, according to our shop price lists, a 6100/60AV is significantly more expensive than a 660AV. > In the performance realm, there are plenty of examples of parallelized > software running slower than a uniprocessor version. There are two primary > reasons for this: communication overhead and slower hardware. No, the primary reason is dumbass programmers who think that they *must* run everything in parallel, just because they can. That extra processor gives you the choice: the trick is knowing when to take it. > The slower hardware issue is more interesting. Generally, simpler hardware > has a faster design cycle and is cheaper to produce. See above re prices. >> * A purpose-built processor is inherently superior to a general-purpose > one >> _for that particular purpose_. > > The DSP subsystem in Apple's AV Macs attempts to be general purpose. By the > time all is said and done, it has to support telecommunications, audio > processing, and image processing. A whole real-time OS and software > architecture is required to implement all this. Furthermore, since it is > exported to applications software, lots of flexibility in hardware > implementation is lost since future platforms have to be compatible. I see your point about things like DSP libraries. That would have been a good thing to add, and I don't think it's too late to do so. > The > subsystem is most specialized for telecom applications. Which is nice, > except that I can get that functionality with cost effective add-on modem > hardware. The nicest thing I can say is that this is a short-sighted view. > >> Put these two together, and the conclusion is inescapable: Apple is going >> to have to return to the multiple-processor approach, and bring out Power > Macs >> with DSPs in them. > > The problem Apple has now is running anything remotely real-time on the same > processor as their system software. No way can you get the performance this way, as some PowerMac users are already discovering. Keeping the real-time and non-real-time stuff on separate processors is the way to go. >> When that happens, I might be tempted to give up my 840AV... > > My two favorite quotes on the 840AV: "It sucketh mightily." and "The IIfx of > the 90's." I've had a IIfx for several years. And I've had an 840AV for about a month now. I'll take the 840AV anytime thank you. > I've tried programming the DSP3210 and I have lots of experience with > PowerPC. I'll take PowerPC anytime thank you. We do DSP programming not because it is easy, but because it is hard... Lawrence (still gloating) --------------------------- >From marshall@kauri.vuw.ac.nz (Stephen Marshall) Subject: Quickdraw GX Beta 3 Date: 18 Mar 1994 03:21:19 GMT Organization: Victoria University of Wellington Hi, I have just tried to run this off the March Developers CD and got a finder error 41 (could not load finder?). Has anyone else encountered this problem? Happens on a 660av and an LC475 with a new install of System 7.1. Stephen Marshall -- Macintosh Consultant Marshall@kauri.vuw.ac.nz Victoria University of Wellington New Zealand +++++++++++++++++++++++++++ >From andreas@sctc.com (Glenn Andreas) Date: Sat, 19 Mar 1994 15:16:23 GMT Organization: SCTC marshall@kauri.vuw.ac.nz (Stephen Marshall) writes: >Hi, >I have just tried to run this off the March Developers CD and got a finder >error 41 (could not load finder?). Has anyone else encountered this >problem? Happens on a 660av and an LC475 with a new install of System 7.1. >Stephen Marshall I've had the exact same problem. You can just hit "g" from MacsBug and it will eventually bring up an alert saying "Couldn't load QuickDraw GX,." or something like that. What is happening is that the QuickDraw GX file is compressed on the CD and when the installer goes to expand it, something goes wrong, which results in resource fork being hosed. The finder goes to open the resource fork, and fails, thus the message. However, I don't know why the installer doesn't expand it correctly - I've yet to get it to work (I've tried on different machines (though all C610 running either 7.1 or 7.1 Pro) with different CD Roms, tried moving the installer stuff to hard drive, etc...) What is strange is that the results of the different attempts often different. Basically, something is being expanded too big (the file is larger, usually by some value that is a multiple of at least $100, often $1000) and so doesn't work as a resource file - I've even tried changing the header information to point to where the resmap ends up, but upon opening it with ResEdit, only about half the resources can be salvaged. I was guessing it was just me, since I hadn't seen anything posted here about it (though I find it difficult to believe that a CD can be "bad", that was one of the constants between all installs), and the next mailing is due in a week or so, I figured I'd just try again then. Glenn Andreas +++++++++++++++++++++++++++ >From b-clark@nwu.edu (Brian Clark) Date: Sat, 19 Mar 1994 18:15:52 -0600 Organization: Northwestern University In article <1994Mar19.151623.19993@sctc.com>, andreas@sctc.com (Glenn Andreas) wrote: > marshall@kauri.vuw.ac.nz (Stephen Marshall) writes: > I was guessing it was just me, since I hadn't seen anything posted here > about it (though I find it difficult to believe that a CD can be "bad", > that was one of the constants between all installs), and the next mailing > is due in a week or so, I figured I'd just try again then. I've had something similar happen. Everything loads fine at startup, and seems to work, but DiskFix complains about the QD GX extension file length being wrong. Making a copy of the file, then replacing the active version with the copy usually works, but I have had the error message reccur. +++++++++++++++++++++++++++ >From Jaime Prilusky Date: Sun, 20 Mar 1994 15:16:04 GMT Organization: Weizmann Institute of Science In article Stephen Marshall, marshall@kauri.vuw.ac.nz writes: >I have just tried to run this off the March Developers CD and got a finder >error 41 (could not load finder?). Has anyone else encountered this >problem? Happens on a 660av and an LC475 with a new install of System 7.1. Please check if you have installed the WunderBar Control pannel. I had the same problem, even with MPW, until we removed it. Dr Jaime Prilusky, Head Bioinformatics Unit ! LSPRILUS@WEIZMANN.WEIZMANN.AC.IL Weizmann Institute of Science ! fax: 972-8-344113 76100 Rehovot - Israel ! tel: 972-8-343456 +++++++++++++++++++++++++++ >From gwatts@whcdfo.fnal.gov Date: 21 Mar 94 12:09:51 -0600 Organization: Fermi National Accelerator Lab In article <1994Mar20.151604.10409@wisipc.weizmann.ac.il>, Jaime Prilusky writes: > In article Stephen > Marshall, marshall@kauri.vuw.ac.nz writes: >>I have just tried to run this off the March Developers CD and got a > finder >>error 41 (could not load finder?). Has anyone else encountered this >>problem? Happens on a 660av and an LC475 with a new install of System > 7.1. I too had this problem on my SE/30. A clean install of sys 7.1 didn't fix it, however, careful dusting and wiping of the cd did.... I swear! It was as if some bad data came off my cd. The bomb was reproducable (sp) and I repeated the install (of sys 7 and GX) three times before I "cleaned" my CD and off it went. I was using the GX Beta 3 off of develop, by the way. My se/30 has 5 megs (can you say "virtual memory"). I've seen this happen before -- nonsense characters in header files, for example. I'm not sure why the CD didn't do error checking on the file. Cheers, Gordon (gwatts@fnal.fnal.gov) +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 22 Mar 94 17:46:05 +1300 Organization: University of Waikato, Hamilton, New Zealand In article <1994Mar19.151623.19993@sctc.com>, andreas@sctc.com (Glenn Andreas) writes: > > What is happening is that the QuickDraw GX file is compressed on the CD and > when the installer goes to expand it, something goes wrong, which results > in resource fork being hosed. The finder goes to open the resource fork, > and fails, thus the message. > > However, I don't know why the installer doesn't expand it correctly - I've > yet to get it to work (I've tried on different machines (though all C610 > running either 7.1 or 7.1 Pro) with different CD Roms, tried moving the > installer stuff to hard drive, etc...) What is strange is that the results > of the different attempts often different. For what it's worth, I've done 3 installs of QuickDraw GX beta 3 so far, from the March developer CD. The two on 68040 machines (a Centris 650 and an 840AV) worked perfectly. I've been through the _entire_ SlideMaster demo on both machines without a single crash! And several parts were noticeably faster than with beta 2. I installed the PPC version on a PowerMac 6100/60AV. That one mostly works, but I got one crash in SlideMaster, and printers don't seem to appear reliably in the Chooser. One definite problem is that I can't print to a LaserJet 4ML with the LaserWriter GX driver. But then, it's not the first problem I've had with an HP PostScript printer... By the way, here's a small puzzle that might entertain some. After updating to the b3 interfaces and recompiling my code, none of it would work. It took me two days to figure out what the problem was. Here's an example of what I was doing wrong: can you spot the mistake? PROCEDURE GXNewShape ( aType : gxShapeType ) : gxShape; CODE 0709EH, (* moveq.l #$9E, d0 *) 0A832H, (* _Skia *) 0588FH, (* addq.l #4, sp *) 02E80H; (* move.l d0, (sp) *) Lawrence D'Oliveiro fone: +64-7-856-2889 Info & Tech Services Division fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00 +++++++++++++++++++++++++++ >From hammett@sbsu1.auckland.ac.nz (Tim Hammett) Date: 22 Mar 1994 23:52:57 GMT Organization: University of Auckland ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >By the way, here's a small puzzle that might entertain some. After updating >to the b3 interfaces and recompiling my code, none of it would work. It took >me two days to figure out what the problem was. Here's an example of what I >was doing wrong: can you spot the mistake? > > PROCEDURE GXNewShape > ( > aType : gxShapeType > ) : gxShape; > > CODE > 0709EH, (* moveq.l #$9E, d0 *) > 0A832H, (* _Skia *) > 0588FH, (* addq.l #4, sp *) > 02E80H; (* move.l d0, (sp) *) I'll take a guess (at the risk of making myself look like an idiot). I assume that $9e is the routine selector which you pass to the _Skia trap to tell it you want to do a GXNewShape(). My guess is that moveq sign extends the $9e (since it's negative when considered as a byte), so while you thought you were passing $0000009e in d0, you were actually passing $ffffff9e. KON: Nasty. BAL: Yup. -- Tim Hammett, School of Biological Sciences, Auckland University, New Zealand. t.hammett@auckland.ac.nz Phone: +64-9-373-7599 x8365 FAX: +64-9-373-7416 +++++++++++++++++++++++++++ >From ivanski@world.std.com (Ivan M CaveroBelaunde) Date: Tue, 22 Mar 1994 23:08:28 GMT Organization: The World Public Access UNIX, Brookline, MA ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > PROCEDURE GXNewShape > ( > aType : gxShapeType > ) : gxShape; > CODE > 0709EH, (* moveq.l #$9E, d0 *) > 0A832H, (* _Skia *) > 0588FH, (* addq.l #4, sp *) > 02E80H; (* move.l d0, (sp) *) How come your compiler didn't barf at having a *procedure* that returns a result? Also, wouldn't a moveq.l sign-extend 9E before stuffing it into D0? -Ivan - - Ivan Cavero Belaunde (ivanski@world.std.com) Avid VideoShop Project Lead Avid Technology, Inc. +++++++++++++++++++++++++++ >From Stephan Bublava Date: 23 Mar 1994 08:34:32 GMT Organization: Vienna University of Technology In article Ivan M CaveroBelaunde, ivanski@world.std.com writes: >How come your compiler didn't barf at having a *procedure* >that returns a result? Because it is Modula-2 and not Pascal. -- Stephan Bublava stephan@iguwnext.tuwien.ac.at +++++++++++++++++++++++++++ >From andreas@sctc.com (Glenn Andreas) Date: Wed, 23 Mar 1994 14:57:43 GMT Organization: SCTC marshall@kauri.vuw.ac.nz (Stephen Marshall) writes: >Hi, >I have just tried to run this off the March Developers CD and got a finder >error 41 (could not load finder?). Has anyone else encountered this >problem? Happens on a 660av and an LC475 with a new install of System 7.1. Well, after having the same problem, I finally found a way around it (see my previous post for more symptoms). I copied the installer folder onto my hard disk (takes 6.2 megs). I then took the Installer 4.0GM from the April dev CD (arived yesterday). Modified the installer script in ResEdit to say version 4.0 instead of 4.0b1. Launched the installer and proceeded as normal. So it appears that the problem was not the CD (though I did try cleaning it) but rather flaky behavior with the beta installer. Glenn +++++++++++++++++++++++++++ >From marshall@kauri.vuw.ac.nz (Stephen Marshall) Date: 24 Mar 1994 01:36:41 GMT Organization: Victoria University of Wellington > marshall@kauri.vuw.ac.nz (Stephen Marshall) writes: > > >Hi, > > >I have just tried to run this off the March Developers CD and got a finder > >error 41 (could not load finder?). Has anyone else encountered this > >problem? Happens on a 660av and an LC475 with a new install of System 7.1. > > >Stephen Marshall In article <1994Mar19.151623.19993@sctc.com>, andreas@sctc.com (Glenn Andreas) wrote: > What is happening is that the QuickDraw GX file is compressed on the CD and when the installer goes to expand it, something goes wrong, which results in resource fork being hosed. The finder goes to open the resource fork, and fails, thus the message. > Lawrence D'Olivero wrote: > For what it's worth, I've done 3 installs of QuickDraw GX beta 3 so far, from the March developer CD. > And someone else suggested I clean the CD. Well, despite Lawrence's (and presumably many other's) happy experiences I have not been able to install the software. When I try to open the Quickdraw GX extension with ResEdit I am informed that the file is corrupt and should be replaced with a backup. This is with a clean CD (well polished 8-), and also with trying to install from a hard disk rather than the CD. I can't help wondering if a subset of the CDs have been incorrectly produced or damaged in some fashion (???). I guess I will have to wait for the next release of the software 8-( Stephen -- Macintosh Consultant Marshall@kauri.vuw.ac.nz Victoria University of Wellington New Zealand +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 24 Mar 94 17:00:06 +1300 Organization: University of Waikato, Hamilton, New Zealand In article , ivanski@world.std.com (Ivan M CaveroBelaunde) writes: > ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >> PROCEDURE GXNewShape >> ( >> aType : gxShapeType >> ) : gxShape; > >> CODE >> 0709EH, (* moveq.l #$9E, d0 *) >> 0A832H, (* _Skia *) >> 0588FH, (* addq.l #4, sp *) >> 02E80H; (* move.l d0, (sp) *) > > How come your compiler didn't barf at having a *procedure* that returns > a result? Hint: the language doesn't have a "FUNCTION" keyword. > Also, wouldn't a moveq.l sign-extend 9E before stuffing it into > D0? Give the man a cigar! Lawrence (only using moveq's for selectors up to 7F now.) +++++++++++++++++++++++++++ >From dowdy@apple.com (Tom Dowdy) Date: Wed, 30 Mar 1994 01:53:07 GMT Organization: Apple Computer, Inc. In article , marshall@kauri.vuw.ac.nz (Stephen Marshall) wrote: > Well, despite Lawrence's (and presumably many other's) happy experiences I > have not been able to install the software. When I try to open the > Quickdraw GX extension with ResEdit I am informed that the file is corrupt > and should be replaced with a backup. This is with a clean CD (well > polished 8-), and also with trying to install from a hard disk rather than > the CD. ResEdit will normally offer to repair this, and the resulting file should be usable. > I can't help wondering if a subset of the CDs have been incorrectly > produced or damaged in some fashion (???). I guess I will have to wait for > the next release of the software 8-( Should be out soon -- but what is on the disk should install with the exception of the "repair" mentioned above. -- Tom Dowdy Internet: dowdy@apple.COM Apple Computer MS:302-3KS UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy 1 Infinite Loop AppleLink: DOWDY1 Cupertino, CA 95014 "The 'Ooh-Ah' Bird is so called because it lays square eggs." --------------------------- End of C.S.M.P. Digest **********************