From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-040 Date: Tue, 28 Jun 1994 15:44:22 +0200 (MET DST) C.S.M.P. Digest Tue, 28 Jun 94 Volume 3 : Issue 40 Today's Topics: AppleScript Programmer's Dialect BlockCompare? GX Printing callbacks are C? Handling Events during AE OpenDoc Processing How to determine which Finder windows are open? Metrowerks code generation wierdness PPC and 64-bit video (was Re: Fast full screen scrolling: impossible?) Playing QuickTime movies Quickdraw GX - Why? [Q] Programming the AT&T 3210? 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. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From hall_j@sat.mot.com (Joseph Hall) Subject: AppleScript Programmer's Dialect Date: Fri, 3 Jun 1994 22:28:40 GMT Organization: Motorola Inc., Satellite Communications Is the programmer's dialect real, or just a figment of the Language Guide's imagination? -- Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users Software Architect | a choice between the easy way and the right way. Gorca Systems Inc. | joseph@joebloe.maple-shade.nj.us (home) (on assignment) | (602) 732-2549 (work) Joseph_Hall-SC052C@email.mot.com +++++++++++++++++++++++++++ >From mwalker@netcom.com (Mel Walker) Date: Mon, 6 Jun 1994 16:02:46 GMT Organization: Committee to Elect Dan Quayle Lord of the Cosmos Joseph Hall (hall_j@sat.mot.com) wrote: : Is the programmer's dialect real, or just a figment of the Language Guide's : imagination? Also, are instructions for making dialects published anywhere? Probably not, right? -- Mel Walker mwalker@netcom.com "That is one of the unwritten rules of government bureaucracy: Doing something idiotic is not advisable; getting caught doing something idiotic is a disaster." - Mike Royko +++++++++++++++++++++++++++ >From minshull.m@applelink.apple.com (Mark Minshull) Date: Mon, 6 Jun 1994 17:55:42 GMT Organization: Apple Computer, Inc. In article <1994Jun3.222840.606@sat.mot.com>, hall_j@sat.mot.com (Joseph Hall) wrote: > Is the programmer's dialect real, or just a figment of the Language Guide's > imagination? > At this point, it's a still-born project... Mark -- Mark Minshull : minshull.m@applelink.apple.com OpenDoc Engineering Manager : Apple Computer, Inc. : Apple usually doesn't care 1 Infinite Loop, MS 303-3A : what I say... When they do Cupertino, CA 95014 : my opinions are my own. +++++++++++++++++++++++++++ >From minshull.m@applelink.apple.com (Mark Minshull) Date: Mon, 6 Jun 1994 17:58:00 GMT Organization: Apple Computer, Inc. In article , mwalker@netcom.com (Mel Walker) wrote: > > Also, are instructions for making dialects published anywhere? Probably > not, right? Right. The interface is private... -- Mark Minshull : minshull.m@applelink.apple.com OpenDoc Engineering Manager : Apple Computer, Inc. : Apple usually doesn't care 1 Infinite Loop, MS 303-3A : what I say... When they do Cupertino, CA 95014 : my opinions are my own. +++++++++++++++++++++++++++ >From Jens Alfke Date: Mon, 6 Jun 1994 20:05:00 GMT Organization: Apple Computer Joseph Hall, hall_j@sat.mot.com writes: > Is the programmer's dialect real, or just a figment of the Language Guide's > imagination? Sue Dumont of the AppleScript team wrote one, but there aren't any plans I know of to ship it. It's pretty cool, but it needs some work before it's ready for prime time. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From Jens Alfke Date: Mon, 6 Jun 1994 22:52:01 GMT Organization: Apple Computer Mel Walker, mwalker@netcom.com writes: > Also, are instructions for making dialects published anywhere? Probably > not, right? Making dialects (a) is pretty complicated and (b) requires more access to the internals of the AppleScript engine than Apple wants to give 3rd parties. A large part of it involves writing yacc syntax descriptions whose tables then get dumped into the dialect file. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From mwalker@netcom.com (Mel Walker) Date: Tue, 7 Jun 1994 17:07:02 GMT Organization: Committee to Elect Dan Quayle Lord of the Cosmos Jens Alfke (jens_alfke@powertalk.apple.com) wrote: : Mel Walker, mwalker@netcom.com writes: : > Also, are instructions for making dialects published anywhere? Probably : > not, right? : Making dialects (a) is pretty complicated and (b) requires more access to the : internals of the AppleScript engine than Apple wants to give 3rd parties. A : large part of it involves writing yacc syntax descriptions whose tables then : get dumped into the dialect file. I assume that I could write a scripting component that opened up the AppleScript component, and translate my "dialect" into AppleScript that way. Is there anything that would prevent that? -- Mel Walker mwalker@netcom.com "That is one of the unwritten rules of government bureaucracy: Doing something idiotic is not advisable; getting caught doing something idiotic is a disaster." - Mike Royko +++++++++++++++++++++++++++ >From Jens Alfke Date: Tue, 7 Jun 1994 22:04:44 GMT Organization: Apple Computer Mel Walker, mwalker@netcom.com writes: > I assume that I could write a scripting component that opened up the > AppleScript component, and translate my "dialect" into AppleScript that > way. Is there anything that would prevent that? That'd work; your component would just forward all of its calls to AppleScript. The compile and getsource calls would have to do some transformation on the source text to change it from/to your syntax to/from AppleScript. (Don't forget the getsource call or people won't be able to re-edit compiled scripts!) And also don't forget to fix up the source positions in the error descriptor when the client wants to know the source range of the error. Of course this would only work with one dialect of AppleScript. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 9 Jun 1994 08:55:24 GMT Organization: The Royal Institute of Technology In minshull.m@applelink.apple.com (Mark Minshull) writes: >In article , mwalker@netcom.com (Mel Walker) >wrote: >> Also, are instructions for making dialects published anywhere? Probably >> not, right? >Right. The interface is private... How come there's a tickle dialect of the OSA then? Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- -- I don't fear death, it's dying that scares me. +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 9 Jun 1994 18:29:45 GMT Organization: Apple Computer Jon W!tte, d88-jwa@dront.nada.kth.se writes: > How come there's a tickle dialect of the OSA then? That's not an AppleScript dialect, it's an entirely separate OSA component, like Frontier or QuicKeyScript. The difference is that a dialect is just a plug-in parser (and unparser) for the AppleScript compiler, whereas a scripting component is entirely independent of AppleScript. To write a new scripting component you just have to follow the OSA API, whereas dialects are pretty tightly coupled to AppleScript's internal parsing engine and build system. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From mwalker@netcom.com (Mel Walker) Date: Thu, 9 Jun 1994 21:57:58 GMT Organization: Committee to Elect Dan Quayle Lord of the Cosmos Jon Wätte (d88-jwa@dront.nada.kth.se) wrote: : In minshull.m@applelink.apple.com (Mark Minshull) writes: : >In article , mwalker@netcom.com (Mel Walker) : >wrote: : >> Also, are instructions for making dialects published anywhere? Probably : >> not, right? : >Right. The interface is private... : How come there's a tickle dialect of the OSA then? There's not. AppleScript is one OSA _language_ with several _dialects_. Quickeys, tickle, etc. store their internal scripts in a different form than AppleScript does, so their scripts are not compatible. If you program AppleScript in the English dialect, and select the French dialect, the script will change to reflect that without changing the underlying tokenized form. Did I get that right, O Great Gurus from Apple? -- Mel Walker mwalker@netcom.com "That is one of the unwritten rules of government bureaucracy: Doing something idiotic is not advisable; getting caught doing something idiotic is a disaster." - Mike Royko +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Fri, 10 Jun 1994 10:03:12 +0800 Organization: Department of Computer Science, The University of Western Australia In article <2t6lds$o2k@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wätte) wrote: >In minshull.m@applelink.apple.com (Mark Minshull) writes: > >>In article , mwalker@netcom.com (Mel Walker) >>wrote: > >>> Also, are instructions for making dialects published anywhere? Probably >>> not, right? > >>Right. The interface is private... > >How come there's a tickle dialect of the OSA then? You're confusing your dialects with your OSA scripting components. A dialect is a different natural language (or syntax in the case of the Programmer's Dialect) for *AppleScript*. An OSA scripting component lets you implement an entirely different programming language within the framework of the OSA. So AppleScript currently has 3 dialects (English, French, Japanese) which all compile to the same language (AppleScript). There are also buckets of other OSA scripting components (QuickKeys, TCL, etc). -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia The cute thing is that you can compile a script in one dialect and then decompile it in another. If only it translated the identifiers. Such a shame the Translation Manager doesn't live up to its name (: +++++++++++++++++++++++++++ >From msouth@BIX.com (msouth on BIX) Date: 14 Jun 94 05:31:10 GMT Organization: Delphi Internet Services Corporation mwalker@netcom.com (Mel Walker) writes: >Quickeys, tickle, etc. store their internal scripts in a different form >than AppleScript does, so their scripts are not compatible. If you >program AppleScript in the English dialect, and select the French >dialect, the script will change to reflect that without changing >the underlying tokenized form. You know, this is a _perfect_ example of how the Mac is head and shoulders above anything else. But do you think that anyone other than a already-dedicated Mac programmer knows about it? Why on earth doesn't Apple _advertise_ some of this stuff? +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 14 Jun 94 12:45:21 MST Organization: (none) In article , msouth@BIX.com (msouth on BIX) writes: > mwalker@netcom.com (Mel Walker) writes: > >>Quickeys, tickle, etc. store their internal scripts in a different form >>than AppleScript does, so their scripts are not compatible. If you >>program AppleScript in the English dialect, and select the French >>dialect, the script will change to reflect that without changing >>the underlying tokenized form. > > You know, this is a _perfect_ example of how the Mac is head > and shoulders above anything else. But do you think that anyone > other than a already-dedicated Mac programmer knows about it? > Why on earth doesn't Apple _advertise_ some of this stuff? I tell DOS-bigots all the time and their response is: "whoopee! Who would ever need to do something like that... Oh well. Lawson --------------------------- >From spencerl@crl.com (Spencer Low) Subject: BlockCompare? Date: 12 Jun 1994 14:44:31 -0700 Organization: LowTek Creations I'm looking for some sample code (preferably in C) that will compare to blocks of memory. In other words: Boolean BlockCompare(Ptr block1, Ptr block2, Size byteCount); The C libraries that come with THINK C include memcmp, but it's hand-coded in 68K assembly. I'd prefer something less platform dependent, yet still quick. Thanks, Spencer (btw, I didn't see anything like this at the alt.sources.mac archives) -- Spencer Low | MaxRAM: Compatible with RD 1.0.1 and 1.0.2, LowTek Creations | but not yet with RD 1.0.3A. spencerl@crl.com | ftp://crl.com/users/ro/spencerl/ +++++++++++++++++++++++++++ >From rang@winternet.com (Anton Rang) Date: 13 Jun 1994 01:32:50 GMT Organization: Minnesota Angsters In article <2tfvjv$8se@crl2.crl.com> spencerl@crl.com (Spencer Low) writes: >I'm looking for some sample code (preferably in C) that will compare to >blocks of memory. In other words: > > Boolean BlockCompare(Ptr block1, Ptr block2, Size byteCount); > >The C libraries that come with THINK C include memcmp, but it's >hand-coded in 68K assembly. I'd prefer something less platform dependent, >yet still quick. Just to see if they're equal? You probably can't beat a loop like this, in C, without adding various platform dependent tricks: while (byteCount--) if (*block1++ != *block2++) return (false); return (true); If you're using 68K assembly, you can do very well using 'cmpm' and a 'dbra' variant, if your loop counts will fit in a two-byte variable. Something along the lines of @0: cmpm.l (a0)+, (a1)+ ; or .b if you really need byte-by-byte dbne @0 ; branch until not-equal seq d0 ; set d0 to be non-zero if they match rts ; return Using memcmp() is your best bet for a platform-independent quick way, since it's part of the ANSI standard and probably coded in assembly. -- Anton Rang (rang@winternet.com) +++++++++++++++++++++++++++ >From bwade@graphics.cornell.edu (Bretton Wade) Date: 13 Jun 1994 04:14:26 GMT Organization: Program of Computer Graphics -- Cornell University probably your best bet if you want to do it in a high level language is to make a nice unrolled loop. you'd have to know in general that the size of the block you want to compare is divisible by some factor (say 16).. Boolean compare (long *a, long *b, long blocksize) { for (short i = 0; i < blocksize; i += 16) { if (*a++ != *b++) return FALSE; if (*a++ != *b++) return FALSE; if (*a++ != *b++) return FALSE; if (*a++ != *b++) return FALSE; } return TRUE; } the more compares you can do inside the loop, the better off you'll be (up to a point). You may also need a little code that will check any leftover that you couldn't cover with the big blocks. say you've got 64001 bytes to compare. You would check the first 64000 with a big block checker, then test the last byte separately. THINK's memcmp function checks one byte at a time. you should be able to blast that with C code quite easily... -- _______________________________________________________________________________ Bretton Wade (bw16@cornell.edu) Program of Computer Graphics 580 Engineering and Theory Center Cornell University Ithaca, NY 14853 Voice: (607) 255-6704 Fax: (607) 255-0806 _______________________________________________________________________________ +++++++++++++++++++++++++++ >From Jens Alfke Date: Mon, 13 Jun 1994 20:11:26 GMT Organization: Apple Computer Spencer Low, spencerl@crl.com writes: > The C libraries that come with THINK C include memcmp, but it's > hand-coded in 68K assembly. I'd prefer something less platform dependent, > yet still quick. If you want portability, use memcmp. You can't get much more portable than the ANSI library -- any C implementation you use, anywhere, is guaranteed to have one. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world --------------------------- >From Jens Alfke Subject: GX Printing callbacks are C? Date: Thu, 9 Jun 1994 18:02:49 GMT Organization: Apple Computer Looks like the entire GX team is on vacation this week, unless they're just refusing to return my calls, so I'll have to make like a layperson and ask the net... ;-) I'm adding GX print manager support to a QD-based app of mine (well, Sticky Memos, but this feature won't be in 1.0.) I'm following the prerelease 'develop' article. I note that the various callbacks you need to install (event filtering and shape spooling) are not declared as 'pascal' functions. This strikes me as odd since (as has been discussed recently) there are no standard C calling conventions on the Mac and the three major C compilers all do things differently. Is this going to be a problem for me? My app's written in CodeWarrior. The major thing I remember is that MPW passes all parameters of any size as longs, so I may have to make sure that any short or Boolean params are declared in my callback functions as longs. Is there anything else I need to do (besides declaring the functions as extern "C", of course)? And what do Pascal users do about this? I've heard that MPW Pascal can use C calling conventions, but what about THINK Pascal? At the risk of not sounding like a team player, I have to say that this C-callbacks thing in GX may not have been the most well thought out idea in the world. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Fri, 10 Jun 1994 10:30:53 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1994Jun9.180249.25884@gallant.apple.com>, Jens Alfke wrote: >I note that the various callbacks you need to install (event filtering and >shape spooling) are not declared as 'pascal' functions. This strikes me as >odd since (as has been discussed recently) there are no standard C calling >conventions on the Mac and the three major C compilers all do things >differently. > >Is this going to be a problem for me? My app's written in CodeWarrior. The >major thing I remember is that MPW passes all parameters of any size as >longs, so I may have to make sure that any short or Boolean params are >declared in my callback functions as longs. Is there anything else I need to >do (besides declaring the functions as extern "C", of course)? The situation is like this... MPW and CodeWarrior Pascal can both call external functions written in C. You simply declare the function header and take a "C;" after it, with an optional "EXTERNAL;" after that. Think cannot do this and it sucks big time. *None* of the Pascal compilers can compile a function written in Pascal that uses C calling conventions. So if you want to do C calling convention callbacks you are basically stuffed. My workaround to this is to write the necessary glue in C, where all the compilers support all the calling conventions. Peter Lewis (who uses Think Pascal exclusively) works around this by declaring the functions with no parameters, getting the value of the A6 register and then walking up the stack manually. It's yucky, it's non-portable, it works. btw It's not just a question of making the parameters match in size. The problem is that C requires the callee to remove the parameters and Pascal (normally) has the caller removing them. So you have to declare the function with *no* parameters to avoid big dramas with the stack. Oh yeah and returning stuff in D0 is kinda hard too. I haven't actually looked through GX yet but if it's full of C callbacks then I'm gonna be *extremely* depressed. >And what do Pascal users do about this? I've heard that MPW Pascal can use C >calling conventions, but what about THINK Pascal? At the risk of not sounding >like a team player, I have to say that this C-callbacks thing in GX may not >have been the most well thought out idea in the world. Well we get bitter and twisted and wear "C, Stop It or You'll Go Blind!" T-shirts around WWDC and harrass the guys doing the interfaces about using a decent IDL so that we can generate Pascal interfaces (and, if necessary, glue code) automatically. The depressing thing is that (I think) we've got a lot of sympathy but there's this little thing called "economic imperative" that ensures that no one does anything to help. *sigh* One nice thing is that the PPC has One True Calling Convention (tm). Hopefully this will improve matters. Share and Enjoy. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia Maintain the Rage!!! +++++++++++++++++++++++++++ >From resnick@uiuc.edu (Pete Resnick) Date: Thu, 09 Jun 1994 22:09:47 -0500 Organization: University of Illinois at Urbana-Champaign In article , quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote: >btw It's not just a question of making the parameters match in size. The >problem is that C requires the callee to remove the parameters and Pascal >(normally) has the caller removing them. You got that backwards. The caller resets the stack in *C* and the callee removes them in Pascal. pr -- Pete Resnick (...so what is a mojo, and why would one be rising?) Doctoral Student - Philosophy Department, Gregory Hall, UIUC System manager - Cognitive Science Group, Beckman Institute, UIUC Internet: resnick@uiuc.edu +++++++++++++++++++++++++++ >From Jens Alfke Date: Fri, 10 Jun 1994 21:11:41 GMT Organization: Apple Computer In article Quinn, quinn@cs.uwa.edu.au writes: > MPW and CodeWarrior Pascal can both call external functions written in C. Pascal access is certainly an issue, but not the one that immediately concerns me since I'm writing in C++. The problem is that GX presumably calls my callbacks with MPW calling conventions*, whereas my functions are implemented using CodeWarrior conventions. As has been discussed in the context of linking with .o files, the two are different and you have to be careful about what size the params are and what register the results get returned in. *Actually that's not even certain since I know that at least the graphics engine of GX was developed in THINK C. I'm guessing that for the real builds they compiled it with MPW, given the MPW-bigotry inside Apple... ;-) --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From mclow@coyote.csusm.edu (Marshall Clow) Date: 10 Jun 1994 21:48:39 -0700 Organization: California State University San Marcos Jens Alfke (jens_alfke@powertalk.apple.com) wrote: >In article Quinn, >quinn@cs.uwa.edu.au writes: >> MPW and CodeWarrior Pascal can both call external functions written in C. >Pascal access is certainly an issue, but not the one that immediately >concerns me since I'm writing in C++. The problem is that GX presumably calls >my callbacks with MPW calling conventions*, whereas my functions are >implemented using CodeWarrior conventions. As has been discussed in the >context of linking with .o files, the two are different and you have to be >careful about what size the params are and what register the results get >returned in. Starting with GM (dontcha just love it? ;-) the GX header files contain a "#ifdef applec" section that defines the calls for the MPW C compiler, and an '#else' section that works for MetroWerks and Think C. The files affected are PrintingDrivers.h and PrintingMessages.h (I think). Several of the GX libraries contain "non pascal" routines with short parameters, but since source to the libs is provided, these interfaces were not changed. Marshall Clow Amateur GX Weenie Aladdin Systems mclow@san_marcos.csusm.edu [ Apparently the first person to write a GX printer driver in Think C.] +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 13 Jun 94 18:03:18 +1200 Organization: University of Waikato, Hamilton, New Zealand In article , quinn@cs.uwa.edu.au (Quinn "The Eskimo!") writes: > In article <1994Jun9.180249.25884@gallant.apple.com>, Jens Alfke > wrote: > >>I note that the various callbacks you need to install (event filtering and >>shape spooling) are not declared as 'pascal' functions. >> >>Is this going to be a problem for me? My app's written in CodeWarrior. The >>major thing I remember is that MPW passes all parameters of any size as >>longs, so I may have to make sure that any short or Boolean params are >>declared in my callback functions as longs. Is there anything else I need to >>do (besides declaring the functions as extern "C", of course)? > > *None* of the Pascal compilers can compile a function written in Pascal > that uses C calling conventions. So if you want to do C calling > convention callbacks you are basically stuffed. > > My workaround to this is to write the necessary glue in C, where all the > compilers support all the calling conventions. Peter Lewis (who uses > Think Pascal exclusively) works around this by declaring the functions > with no parameters, getting the value of the A6 register and then walking > up the stack manually. It's yucky, it's non-portable, it works. My workaround is a generic piece of assembly-language glue which looks something like this: clr.w -(sp) ; room for Pascal function result pea 6(sp) ; pointer to C-format argument list jsr PascalRoutine ; call my Pascal-conforming routine move.w (sp)+, d0 ; return Pascal result to C rts The Pascal-conforming routine (in Modula-2, in my case) is declared like this: PROCEDURE MyHandler ( VAR Args : ArgsForThisRoutine ) : OSErr; where "ArgsForThisRoutine" is a record type that mimics the format of the C argument list. So I refer to the arguments as "Args.whatever". Not too painful at all. One common case is printing extensions and drivers. This introduces its own fiddly bits, in that the offsets in the 'over' resources must match the entry points in your 'pext' code resources. To solve all this, I wrote a custom MPW tool which takes a file of entry point definitions, and generates .o files for the segment headers (including the C-to-Pascal glue, above), and the 'over' resources, all in one fell swoop, so you never have to worry about keeping them consistent again. Nifty, huh? Lawrence "Just call me the 'Speedbump, the Roadkill Hedgehog' of the Information Superhighway" D'Oliveiro +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Tue, 14 Jun 1994 09:44:37 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1994Jun13.180319.29615@waikato.ac.nz>, ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) wrote: >My workaround is a generic piece of assembly-language glue which looks >something like this: > >[...] Neat hack! Unfortunately the problem still stands, no matter how neat a hack you use to work around it ): >Lawrence "Just call me the 'Speedbump, the Roadkill Hedgehog' of the >Information Superhighway" D'Oliveiro *laugh* -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia --------------------------- >From cvafy002@csupomona.edu Subject: Handling Events during AE OpenDoc Processing Date: 13 Jun 94 00:52:37 PST Organization: California State Polytechnic University, Pomona What's the best way to handle event processing during an AppleEvent OpenDocument event? In my application I step thru the docList retrieved from the AppleEvent and call my OpenDocument routine on each document as it is pulled out of the list. I'd like to put up a MovableModal or Modeless dialog to show progress and also allow the user to switch to other applications and even drop more documents on my application while it is running (I'm using a suspend/resume appleevent routine similar to the ones used in DragonSmith). Should I setup another event loop that I call during the Opening of the documents? All my application does is rename files based on settings the user specifies beforhand so the actual operations on each file are small but, I'd like get a good strategy for handling events when the processing time for each document increases. Any comments are appreciated. +++++++++++++++++++++++++++ >From decartwr@gamera.syr.edu (Dana Cartwright 3rd) Date: Mon, 13 Jun 1994 11:45:06 GMT Organization: Syracuse University, Syracuse, New York cvafy002@csupomona.edu wrote: : ..... I'd like get a good strategy for : handling events when the processing time for each document increases. A strategy I use (and others in this group have mentioned similar strategies) is to divide my app into two parts, call them "hot" and "cool". The "hot" part is responsible for being highly responsive to user requests (keystrokes and menu actions). The "cool" part handles things which take a longer time. In the "hot" sections, anything which would take a long time to execute is avoided...instead, a request is enqueued for the "cool" code to do the long-running work (the details of how this is done probably depend on your app, see my strategy below). When I call WNE and find I have no events queued up for me, I then dispatch the "cool" code. It looks in its work-to-be-done queue and starts grinding away. Since these are long-running tasks, there's a lot of the style of coding where tasks are interrupted with calls to WNE. When the "cool" code is running, it will happen (frequently) that the user does something which causes the "hot" code to run. So the "cool" and the "hot" code have to understand that they may run interleaved. Note: this description is basically a description of cooperative multi- tasking, but carried out within one app rather than among apps. The point is that it works beautifully.....my apps are highly responsive to mouse clicks, and you can "stack" a whole series of them with the app giving very quick visual feedback...also, you can issue a bunch of mouse clicks and then switch my app into the background.....all the "cool" code expects that it may run while the app is in the background. Now, for my enqueue strategy: it's extremely simple! I just have a global 32-bit word in which each bit corresponds to some "cool" task. When the "hot" code sees that it needs to ask the "cool" routines to take on some work, it just flips on whichever of the 32 bits corresponds to that particular task. In the "cool" code, there are up to 32 tasks which can be dispatched, keyed off the 32 bits of the dispatch word. By the way, since I dispatch starting with the left-most bit, I also achieve a strict prioritization: higher priority "cool" tasks are given bits near the high-order end of the 32-bit word. Since enqueue/dequeue of tasks is no harder than flipping a bit, I've not got much overhead. Anyway, I've used this strategy in several commercial apps, and users have commented on how responsive the software seems to be....so I claim some success! +++++++++++++++++++++++++++ >From partingt@fwi.uva.nl (Vincent Partington) Date: 14 Jun 1994 10:30:17 +0200 Organization: FWI, University of Amsterdam cvafy002@csupomona.edu writes: >What's the best way to handle event processing during an AppleEvent >OpenDocument event? The other replier mentioned partitioning his application into a "hot" and "cold" part. I do something similar but the implementation is different. I divide my programs into an interface part and a grunt-work part. The interface part handles the interface stuff and has to be quick in giving time to other apps and is centered around the event loop. When the interface part wants the grunt-work part to do something it sends an Apple Event with all necessary information to itself. The grunt-work part gets this information from the AppleEvent and starts processing but calls the "Yield" function at regular intervals. The Yield functions is the interface part: it does a WaitNextEvent and handles events until a null event comes up. Then the grunt-work part can continue. The advantage of this recursion is that I have one event-loop and that the grunt-work part can be structured like you would on a machine with preemptive multitasking and no event-loop. You only have to call Yield once in a while, you don't have to split up your work and do it in little chunks getting the necessary status info from flag words and such (was I doing X or Y?). But because of the recursion care should be taken not to get into infinite recursion. I do this by calling the "Activate" method of my Application-class when ever the grunt-work part start to do stuff that could take long: that method disables the menubar and sets the event mask to exclude High Level events. It also sets a flag so the Yield function knows to give a sleep time of 0 ticks to WaitNextEvent. At the end of the grunt-work function (the Apple Event handler) the "Deactivate" method is called and the application returns to idle state. Another advantage is that all communication goes to the grunt-work part through Apple Events: because of this my applications are recordable and scriptable. I have developed no commercial applications with this, but I'm developing a C++ DropBox class library using this approach. The idea is to make it easy to implement an algorithm for file conversion (like Unix "filters") without having to muck about with event loops. This class library should see the public domain when CodeWarrior supports exception handling and templates, so I can test my exception handling code. Vincent. -- My opinions are not my own. I copy them | Internet : partingt@fwi.uva.nl from books, television, video, the net, | vincent@tnc.nl my friends, my parents, my teachers and | FidoNet : 2:281/202.15 and numerous other contributors. | NeST : 90:500/202.15 --------------------------- >From alex@metcalf.demon.co.uk (Alex Metcalf) Subject: How to determine which Finder windows are open? Date: Fri, 10 Jun 1994 23:17:19 GMT Organization: Best Before Yesterday Up until a few weeks ago I thought it was impossible to read information such as which Finder windows are open, the positions of icons in that window (I know that's in the DB, but I don't know how to check for the open window), etc. However, Popup Folder lets you click on a finder folder and see some stuff about its hierarchy. So there MUST be a way! Also, that screen saver software that has stuff interacting with your finder windows. I've posted once already with no reply, and this information would be really useful for me. Can anyone help me by telling me how my app can find out ANY of these: o The open windows in the Finder o The names / folder paths of open windows in the Finder o The names and locations of folders in an open window in the Finder Thanks! Alex -- Alex Metcalf, Best Before Yesterday Mac programmer in C, C++, HyperTalk, assembler Juggler, 3-ball tricks Internet: alex@metcalf.demon.co.uk Fax (UK): (0570) 45636 Fax (US / Canada): 011 44 570 45636 +++++++++++++++++++++++++++ >From gurgle@netcom.com (Pete Gontier) Date: Mon, 13 Jun 1994 05:37:31 GMT Organization: cellular alex@metcalf.demon.co.uk (Alex Metcalf) writes: >Up until a few weeks ago I thought it was impossible to read >information such as which Finder windows are open, the positions of >icons in that window (I know that's in the DB, but I don't know how >to check for the open window), etc. However, Popup Folder lets you >click on a finder folder and see some stuff about its hierarchy. So >there MUST be a way! Also, that screen saver software that has stuff >interacting with your finder windows. The question is not whether it can be done or how it can be done. Those are comparatively easy questions, and I will take a swipe at answering them below. The really interesting question, however, is this: do you really want to? Finder is an application. Like many apps, it stores data in the 'refCon' field of its window records. That data, I believe, is a handle, but perhaps a pointer, to a C++ object which contains handles or pointers to other C++ objects, etc. etc. Using MacsBug, you can reverse engineer these *absitively posolutely private* data structures to determine the information you want. Of course, this assumes you somehow have access to Finder's window list. You'll probably have to write an INIT resource to do this. This is the first part of the question: do you really want to do all the work involved in this reverse engineering? It's non-trivial, especially if your MacsBug skills are not polished. The second part of the question is more of the same. Assuming you want to put in this kind of work, are you willing to put in this kind of work for System 7, System 7.1, System 7 Pro, and System 7.5? How about System 6 and for each version of the System before? And each version of the System after 7.5? Because the information is different in all of these cases. I'm not trying to be a wet blanket, but I do feel like I ought to try to discourage you for your own good. You can do it; I've done it. But you had better be sure it's worth the effort. -- Pete Gontier, CTO, Integer Poet Software; gurgle@netcom.com "...where they burn books, people are next." -- XTC +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Mon, 13 Jun 1994 00:06:49 -0700 Organization: Internet for the Olympic Peninsula In article , gurgle@netcom.com (Pete Gontier) wrote: > alex@metcalf.demon.co.uk (Alex Metcalf) writes: > > >Up until a few weeks ago I thought it was impossible to read > >information such as which Finder windows are open, the positions of > >icons in that window (I know that's in the DB, but I don't know how > >to check for the open window), etc. However, Popup Folder lets you > >click on a finder folder and see some stuff about its hierarchy. So > >there MUST be a way! Also, that screen saver software that has stuff > >interacting with your finder windows. > > The question is not whether it can be done or how it can be done. Those > are comparatively easy questions, and I will take a swipe at answering > them below. The really interesting question, however, is this: do you > really want to? > > ... [Reverse engineering 1.01 omitted] > > The second part of the question is more of the same. Assuming you want > to put in this kind of work, are you willing to put in this kind of work > for System 7, System 7.1, System 7 Pro, and System 7.5? How about System > 6 and for each version of the System before? And each version of the > System after 7.5? Because the information is different in all of these > cases. > > I'm not trying to be a wet blanket, but I do feel like I ought to try to > discourage you for your own good. You can do it; I've done it. But you > had better be sure it's worth the effort. Particulary, does he want to do this for System 7.5, whose Finder is happy to tell you: tell application "Finder" get every window end tell will return something like this (translated to text, from its list of objects form): {window of folder "HyperCard 2.2" of startup disk of application "Finder", window of startup disk of application "Finder"} And tell application "Finder" get name of every window end tell will return just the names, if that's all you want: {"HyperCard 2.2", "Vashon"} Seems a whole lot simpler to me. [Alex's own app can send the necessary event.] -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] No hablo Intel. jwbaxter@pt.olympus.net --------------------------- >From jrrk@camcon.co.uk (Jonathan Kimmitt) Subject: Metrowerks code generation wierdness Date: 6 Jun 94 21:10:45 GMT Organization: Cambridge Consultants Limited Has anybody noticed that Metrowerks DR/2 and DR/3 return values from functions in different registers depending on what the function result type is ? a function such as 'char *xmalloc(long)' returns in A0 whereas a function such as 'long temps(void)' returns in D0 No other compiler that I have ever seen for the 68K does this. ANSI C allows this, but as far as I can see it is impossible to guarantee correct code unless 'require prototypes' is checked, which makes it more difficult to port old non ANSI (K&R) code. For the above functions declared in file A (xmalloc is a function which allocates memory), if file B contains { struct junk *ptr = (struct junk *)xmalloc(sizeof(struct junk)); ..... incorrect code will be generated if your forget to use the prototype because xmalloc will be assumed to return int and the value to be put in ptr will be assumed to be in D0, whereas the actual function will put the result in A0 before returning. The result is that ptr will end up pointing to a random location in memory and will most likely cause a bus error or crash your mac. THINK C (with 4-byte ints on), MPW and gcc will handle this case correctly, so if you are porting to Metrowerks you might not notice this bug in your code until it is too late. One might speculate that this feature was implemented to improve efficiency, since theoretically a pointer returned in A0 can be used immediately. In practise it means that code resources developed with Metrowerks might not be able to be used with another compiler if they return pointers, and vice versa. Since this is a compatability issue, one would expect that this feature should be made optional. Your constructive comments are invited ... +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Tue, 7 Jun 1994 01:26:27 GMT Organization: Adobe Systems Incorporated Jonathan Kimmitt writes > One might speculate that this feature was implemented to improve > efficiency, since theoretically a pointer returned in A0 can be used > immediately. In practise it means > that code resources developed with Metrowerks might not be able to be > used with another compiler > if they return pointers, and vice versa. Since this is a compatability > issue, one would > expect that this feature should be made optional. Your constructive > comments are invited ... The 68k Macintosh has no standard C calling convention. The solution for things like code resources is to use the Pascal calling convention for every cross-interface call. In a couple years, PowerPC will have totally taken over and such concerns (along with A5 and A4 worlds) will be but dim nightmares from the past. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Never let a "final candidate" subscript get above the age of consent. +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Tue, 7 Jun 1994 15:42:08 GMT Organization: The World Public Access UNIX, Brookline, MA >a function such as 'char *xmalloc(long)' returns in A0 >whereas a function such as 'long temps(void)' returns in D0 > >No other compiler that I have ever seen for the 68K does this. ANSI C >allows this, >but as far as I can see it is impossible to guarantee correct code unless >'require prototypes' is checked, which makes it more difficult to port >old non ANSI (K&R) code. As far as the ANSI standard is concerned, it would never be correct to call a function defined as returning a pointer when there is no declaration in scope. You cannot assume that 'int' and 'pointer' have the same representation, and we are allowed to use different calling conventions for them. You can force the compiler to return pointers in D0 (this is sometimes necessary for calling C code generated by the MPW compiler) by using #pragma pointers_in_D0 -- John McEnerney, Metrowerks PowerPC Product Architect +++++++++++++++++++++++++++ >From astalker@nickel.ucs.indiana.edu (Altan J. Stalker) Date: Tue, 7 Jun 1994 15:23:57 GMT Organization: Indiana University, Bloomington IN In article <46180@io.camcon.co.uk>, Jonathan Kimmitt wrote: >Has anybody noticed that Metrowerks DR/2 and DR/3 return values from >functions >in different registers depending on what the function result type is ? > > [stuff deleted] > > ... Since this is a compatability > issue, one would > expect that this feature should be made optional. Your constructive > comments are invited ... Although I have never used it, a pragma exists to turn this feature on and off. pointers_in_A0 Make functions return pointers in the 68000 register A0 [default] pointers_in_d0 Make functions return pointers in the 68000 D0 register [what you wanted] (this is from the _Metrowerks C Language Reference DR/2_ page 13) -- Altan J. Stalker, Indiana University, Bloomington IN astalker@nickel.ucs.indiana.edu +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Wed, 8 Jun 1994 16:13:53 +1200 (NZST) Organization: (none) zstern@adobe.com (Zalman Stern) writes: > The 68k Macintosh has no standard C calling convention. The solution for > things like code resources is to use the Pascal calling convention for every > cross-interface call. In a couple years, PowerPC will have totally taken > over and such concerns (along with A5 and A4 worlds) will be but dim > nightmares from the past. ... to be replaced by new nightmares such as having to remember to put all floating point paramaters after all integer parameters, if you want them to fit into registers :-( -- Bruce "anyone who designs a calling convention around k&r should be shot" Hoult +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Wed, 08 Jun 1994 00:36:39 -0700 Organization: Internet for the Olympic Peninsula In article <2853936833@hoult.actrix.gen.nz>, Bruce@hoult.actrix.gen.nz (Bruce Hoult) wrote: > > ... to be replaced by new nightmares such as having to remember to put all > floating point paramaters after all integer parameters, if you want them > to fit into registers :-( Wouldn't have been necessary if the ANSI folks had required prototypes instead of offering them as a no-cost extra. [That would have probably exceeded the subcommittee's charter, since it would not have codified existing practice, but broken new ground. It WOULD have produced a better language, though.] -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] No hablo Intel. jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 9 Jun 1994 09:15:16 GMT Organization: The Royal Institute of Technology In <46180@io.camcon.co.uk> jrrk@camcon.co.uk (Jonathan Kimmitt) writes: >a function such as 'char *xmalloc(long)' returns in A0 >whereas a function such as 'long temps(void)' returns in D0 >No other compiler that I have ever seen for the 68K does this. ANSI C Most non-mac compilers for the 68K I've seen does this. You can turn it off with #pragma pointers_in_D0 cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- -- I don't fear death, it's dying that scares me. +++++++++++++++++++++++++++ >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Date: 09 Jun 1994 14:30:42 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article <2853936833@hoult.actrix.gen.nz> Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes: > > zstern@adobe.com (Zalman Stern) writes: > > [...] In a couple years, PowerPC will have totally taken > > over and such concerns (along with A5 and A4 worlds) will be but dim > > nightmares from the past. > > ... to be replaced by new nightmares such as having to remember to put all > floating point paramaters after all integer parameters, if you want them > to fit into registers :-( i don't know what you mean by this. the PowerPC calling conventions that i'm familiar with do not require this. for the PowerPC, standard function calling conventions state that fixed- point arguments go in r3-r10, floating-point arguments go in fr1-fr13. if you define something like: int foo(int a,float b,int c,double d) the parameters will be mapped to registers as follows: a: r3 b: fr1 c: r4 d: fr2 according to this ABI, it is explicitly stated that parameters can be declared in any order, and the fixed- and floating-point registers will be used as efficiently as possible. -gary j kacmarcik platypus@cirrus.som.cwru.edu +++++++++++++++++++++++++++ >From johnmce@world.std.com (John McEnerney) Date: Thu, 9 Jun 1994 15:09:56 GMT Organization: The World Public Access UNIX, Brookline, MA platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes: >if you define something like: > int foo(int a,float b,int c,double d) >the parameters will be mapped to registers as follows: > a: r3 > b: fr1 > c: r4 > d: fr2 WRONG! (You would think this would be the case, but it is not) a: r3 b: fr1 (r4 is reserved) c: r5 d: fr2 (r6 and r7 are reserved) additional integer arguments go in r8, etc. This is a strange nuance to the IBM PowerPC ABI. I believe that it is used for calling functions which have no prototype in scope, e.g. if I call printf() without including (which is illegal in ANSI) the compiler will pass the floating-point arguments in -both- the integer and floating-point registers, so the callee can work correctly no matter if it takes a variable number of arguments or has arguments declared as floating-point types. Note that as the original poster pointed out, you get best results by declaring your integer arguments first and then your floating-point arguments. The CodeWarrior compiler does not implement this feature, since the ANSI standard us strict on this issue (it is illegal to call a function taking a variable number of arguments without a prototype) However, for compatibility with the Apple Toolbox and such, we incur the same penalty in register usage. -- John McEnerney, Metrowerks PowerPC Product Architect +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Fri, 10 Jun 1994 16:45:43 +1200 (NZST) Organization: (none) platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes: > > ... to be replaced by new nightmares such as having to remember to put all > > floating point paramaters after all integer parameters, if you want them > > to fit into registers :-( > > i don't know what you mean by this. the PowerPC calling conventions that > i'm familiar with do not require this. > > for the PowerPC, standard function calling conventions state that fixed- > point arguments go in r3-r10, floating-point arguments go in fr1-fr13. > > if you define something like: > > int foo(int a,float b,int c,double d) > > the parameters will be mapped to registers as follows: > a: r3 > b: fr1 > c: r4 > d: fr2 > > according to this ABI, it is explicitly stated that parameters can be > declared in any order, and the fixed- and floating-point registers will > be used as efficiently as possible. Would that it were so! Unfortunately, this directly contradicts Apple's _Inside Macintosh: PowerPC System Software_, page 1-50: "Placing a floating point parameter into a floating point register also reserves one or two genrral-purpose registers, depending on whether the paramater is 32 or 64 bits long. This behavious is dictated in order to support the ability of a C function to call another function without knowing the number or types of the callee's parameters. [...] The only difference betwen cases in which the prototype is available and cases in which the prototype isn't available is that the floating point parameters are copied into the general-purpose register(s) in the latter case but not in the former." [there follows an example of register mapping] "NOTE. It would have been possible to pas all the fixed point values in registers if the floating-point parameters had been grouped at the end of the parameter list". I would *love* to learn that this is wrong. -- Bruce +++++++++++++++++++++++++++ >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Date: 10 Jun 1994 20:22:51 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article johnmce@world.std.com (John McEnerney) writes: > > platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes: > > >if you define something like: > > int foo(int a,float b,int c,double d) > >the parameters will be mapped to registers as follows: > > a: r3 > > b: fr1 > > c: r4 > > d: fr2 > > WRONG! (You would think this would be the case, but it is not) i looked this up when i got home and discovered that what i was describing was the *Embedded* ABI, which apparently has a more intelligent way of allocating registers. it also has things like not always generating the (typically unused) 'param area' to shadow the GPR's on the stack - it only generates a param area if it's needed. apparently the embedded people care more about having proper register and stack allocation and are willing to forsake screwy calling conventions to get it. ;-) it's funny that i never came across an example that exposed this - i guess i don't do as much floating-point code as i thought. -gary j kacmarcik platypus@cirrus.som.cwru.edu +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Sat, 11 Jun 1994 01:30:31 GMT Organization: Adobe Systems Incorporated Gary Kacmarcik writes > apparently the embedded people care more about having proper register and > stack allocation and are willing to forsake screwy calling conventions > to get it. ;-) The embedded people have the advantage of defining their calling convention four years later when it is obvious what you can and cannot realistically depend on in ANSI-C code. They are also willing to sacrifice a little more for performance. (I.e. portability is less of a concern in embedded code.) -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Never let a "final candidate" subscript get above the age of consent. +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Sun, 12 Jun 1994 21:03:48 +1200 (NZST) Organization: (none) platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes: > i looked this up when i got home and discovered that what i was describing > was the *Embedded* ABI, which apparently has a more intelligent way > of allocating registers. it also has things like not always generating > the (typically unused) 'param area' to shadow the GPR's on the stack - > it only generates a param area if it's needed. > > apparently the embedded people care more about having proper register and > stack allocation and are willing to forsake screwy calling conventions > to get it. ;-) > > it's funny that i never came across an example that exposed this - i guess > i don't do as much floating-point code as i thought. Agreed that it's screwy (I have to -- I'm the one that started this :-), but there are some nice things in the PPC calling conventions as well, most of them designed to make tiny functions extremely efficient. For example, it's really nice that you can quite legally push a few things on the stack without adjusting the stack pointer, because you can depend on interrupt routines always skipping over the first couple of hundred bytes of stack, in case you're using it. It's also neat that a function like... long myAdd(long a, long b){return a+b;} ...can be compiled into just... add r3,r3,r4 blr ...which results in no memory access at all (other than instruction fetch). Most 68k compilers will give even this function the full treatment... link a6,#0 move.l 8(a6),d0 add.l 12(a6),d0 unlk a6 rts ... not to mention the caller setting up the stack beforehand, and cleaning off the parameters afterwards, causing eight memory references in using this little function (ten for Pascal calling conventions) In fact, on many code examples I've looked at, the PPC code is actually *smaller* than the equivalent 68K code generated by the MPW or Symantec compilers. -- Bruce +++++++++++++++++++++++++++ >From platypus@cirrus.som.cwru.edu (Gary Kacmarcik) Date: 12 Jun 1994 18:18:31 GMT Organization: Case Western Reserve University, Cleveland, Ohio (USA) In article <2854299828@hoult.actrix.gen.nz> Bruce@hoult.actrix.gen.nz (Bruce Hoult) writes: > > Agreed that it's screwy (I have to -- I'm the one that started this :-), > but there are some nice things in the PPC calling conventions as well, most > of them designed to make tiny functions extremely efficient. > > For example, it's really nice that you can quite legally push a few things > on the stack without adjusting the stack pointer, because you can depend > on interrupt routines always skipping over the first couple of hundred > bytes of stack, in case you're using it. hmmm... i don't think that i would have chosen this particular example to try to demonstrate why the calling conventions _weren't_ screwy. ;-) when i first saw IBM's compiler generating code that placed values above the stack ptr, my first response was . i can deal with it now that i understand that the compiler's trying to insure that r1 is always pointing to a value stack frame. one thing i wonder about (but have yet to try) is how alloca() is handled. overall, the calling conventions aren't bad and there are many advantages. but there certainly are wierdnesses. gary j kacmarcik platypus@cirrus.som.cwru.edu +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Mon, 13 Jun 1994 19:41:53 +1200 (NZST) Organization: (none) platypus@cirrus.som.cwru.edu (Gary Kacmarcik) writes: > > For example, it's really nice that you can quite legally push a few things > > on the stack without adjusting the stack pointer, because you can depend > > on interrupt routines always skipping over the first couple of hundred > > bytes of stack, in case you're using it. > > hmmm... i don't think that i would have chosen this particular example to > try to demonstrate why the calling conventions _weren't_ screwy. ;-) > when i first saw IBM's compiler generating code that placed values above > the stack ptr, my first response was . > > i can deal with it now that i understand that the compiler's trying to insure > that r1 is always pointing to a value stack frame. one thing i wonder about > (but have yet to try) is how alloca() is handled. > > overall, the calling conventions aren't bad and there are many advantages. > but there certainly are wierdnesses. The way I look at it is that most of this stuff has been designed to be fast running, even if it make life hell for the asm programmer trying to keep track of things manually. That, after all, being what compilers are for. -- Bruce --------------------------- >From rang@winternet.com (Anton Rang) Subject: PPC and 64-bit video (was Re: Fast full screen scrolling: impossible?) Date: 13 Jun 1994 02:33:06 GMT Organization: Minnesota Angsters In article <1994Jun12.182803.1@west.cscwc.pima.edu> 103t_english@west.cscwc.pima.edu writes: >d e v e l o p 18 claims that the PPC blitter that they used was slower than >CopyBits because it didn't (presumably, for some unknown reason, *couldn't*) >take advantage of the 64-bit path of video. Unless you're using the floating-point registers, you can't use the full 64-bit path efficiently, because there's no 64-bit integer load. I haven't looked at NQDCopyBits to see if it uses the FP registers; I suppose that it *could*, in cases where there is no scaling, shifting, etc. but it seems unlikely that it would. >For this same reason, *BlockMove* was also slower. Well, BlockMove is going to be slower on the PPC because the video memory is noncachable and BlockMove will pre-zero it using the dcbz instruction ('zero-cache-block'). Using dcbz is a big win when doing copies between cachable blocks, because it eliminates the pre-read that the processor will otherwise do when storing data. The Power Macintosh NuBus technical note addresses this, and includes a new interface, PBBlockMove, which is supposed to take into account the cachability of source and destination memory ranges. (No word on when this will be shipping or whether it will be licensable as a system extension.) >What is going on with the memory subsystem in the PowerMacs? Is it or isn't it >64-bit? Is the DRAM video 64-bit? Is the AV video? Is the non-AV PDS video? The non-AV PDS VRAM is 64-bit, the DRAM is 64-bit (all of memory is). The AV bus internally is 32-bits (it's the same chips as on the 680x0 AVs), but might have a 64-bit interface to the processor bus; I haven't looked. > [ questions about video bandwidth deleted, i have no answers ] >For that matter, why can't BlockMove move data in 64-bit chunks when >it is most optimal to do so? It can. The problem is the dcbz, which when used with video memory will result in every word being written twice. That's why you should use CopyBits instead. :-) >And finally, what happened to the load/store multiple instructions >that are (I assume?) faster on the 601, but will probably be slower >"in future implementations?" They're actually not faster on the 601, they simply take less code space. They still take one cycle per register to process. I haven't checked to see whether they're slower on the 603/604, but would guess that they may cause synchronization on the 603, which would certainly slow things down relative to just using plain load/store. The fastest way to move memory on the 601 is to use floating-point registers (load/store double), coupled with 'dcbz' if you're going to cachable memory, but *not* when you're going to non-cachable memory. (All of this presumes aligned memory, incidentally; if you're not aligned, you're out of luck and probably need to use the string instructions instead.) -- Anton Rang (rang@winternet.com) --------------------------- >From Frank Manshande Subject: Playing QuickTime movies Date: Mon, 6 Jun 1994 11:41:21 GMT Organization: AND Software BV Hi, I have a question concerning playing QuickTime movies. What I want is to store the movie (data) into the datafork at a specific offset (for example at offset 3000), and later play that movie from that offset. This way I can put more than one QuickTime movie into one file and play a movie at a specific offset. The call "PutMovieIntoDataFork" only seems to store the movie structure, and not the movie data, into a file at the specified offset. This way the PutMovieIntoDataFork call creates a file of about 1,5 KB which only contains a reference to the original movie data file. Does anybody have suggestions? I would be very grateful! Frank Manshande frankm@and.nl +++++++++++++++++++++++++++ >From breger@netcom.com (Ron Breger) Date: Mon, 6 Jun 1994 17:49:45 GMT Organization: Netcom Frank Manshande (frankm@and.nl) wrote: : Hi, : I have a question concerning playing QuickTime movies. : What I want is to store the movie (data) into the datafork at : a specific offset (for example at offset 3000), and later play : that movie from that offset. This way I can put more than one : QuickTime movie into one file and play a movie at a specific : offset. : The call "PutMovieIntoDataFork" only seems to store the movie : structure, and not the movie data, into a file at the specified : offset. This way the PutMovieIntoDataFork call creates a file : of about 1,5 KB which only contains a reference to the original : movie data file. I am having the same problem, but I am using handles. This is something that I'm trying to do: // save the moive PutMoiveIntoHandle() AddResource(publicMoive, 'MRES', 1000, ""); ReleaseResource(publicMovie); then // play the movie publicMovie = GetResource('MRES',1000); DetachResource(publicMoive); StartMoive(publicMoive); I would like to have one (resource) file to contain many movies. I don't want to use MovieFiles. I would like the data to be in a resource and not contain any references to the original files. Is this possible? Please help. (email or post). Thanks. Ron Breger -- ===================================================================== Ron Breger breger@netcom.com AppleLink: RON.BREGER ===================================================================== +++++++++++++++++++++++++++ >From ivanski@world.std.com (Ivan M CaveroBelaunde) Date: Mon, 6 Jun 1994 20:27:32 GMT Organization: The World Public Access UNIX, Brookline, MA breger@netcom.com (Ron Breger) writes: >Frank Manshande (frankm@and.nl) wrote: >: Hi, >: I have a question concerning playing QuickTime movies. >: What I want is to store the movie (data) into the datafork at >: a specific offset (for example at offset 3000), and later play >: that movie from that offset. This way I can put more than one >: QuickTime movie into one file and play a movie at a specific >: offset. FlattenMovieData to a temp file, then copy the data over, using SetMediaDataRef to repoint all the medias in the movie to the new file. >I am having the same problem, but I am using handles. >This is something that I'm trying to do: >// save the moive >PutMoiveIntoHandle() >AddResource(publicMoive, 'MRES', 1000, ""); >ReleaseResource(publicMovie); This would work in theory; however, you should do a WriteResource before you do a ReleaseResource. Is there a reason why you're not using Add/UpdateMovieResource, however? >then >// play the movie >publicMovie = GetResource('MRES',1000); >DetachResource(publicMoive); >StartMoive(publicMoive); This will *not* work. You'd have to do: myMovie = NewMovieFromHandle(publicMovie); >I would like to have one (resource) file to contain many movies. Perfectly feasible with Add/UpdateMovieResource, since you can specify the resID, as well as scan the movie res file for 'moov' resources. >I don't want to use MovieFiles. Why? Are there limitations you see in using them? > I would like the data >to be in a resource and not contain any references to >the original files. Is this possible? Nope. The movie *data* must be in a data fork. It *is* possible for the file to be completely self-contained (ie all the movie data would be in the data fork of the file that contains the movie resources), however. -Ivan - - Ivan Cavero Belaunde (ivanski@world.std.com) Avid VideoShop Project Lead Avid Technology, Inc. +++++++++++++++++++++++++++ >From Frank Manshande Date: Tue, 7 Jun 1994 07:29:44 GMT Organization: AND Software BV In article Ivan M CaveroBelaunde, ivanski@world.std.com writes: >FlattenMovieData to a temp file, then copy the data over, using >SetMediaDataRef to repoint all the medias in the movie to the new file. > I'm reading IM-QuickTime right now, but I can't seem to find how I can play a movie from a specific offset. If I succeed in saving the movie the way you describe, using SetMediaDataRef for all the tracks, how can I then play that movie. And would that also work under QuickTime for Windows? Thanks for your time! Frank Manshande frankm@and.nl +++++++++++++++++++++++++++ >From ivanski@world.std.com (Ivan M CaveroBelaunde) Date: Tue, 7 Jun 1994 13:50:44 GMT Organization: The World Public Access UNIX, Brookline, MA Frank Manshande writes: >In article Ivan M CaveroBelaunde, >ivanski@world.std.com writes: >>FlattenMovieData to a temp file, then copy the data over, using >>SetMediaDataRef to repoint all the medias in the movie to the new file. >> >I'm reading IM-QuickTime right now, but I can't seem to find how I can >play a movie from a specific offset. If I succeed in saving the movie >the way you describe, using SetMediaDataRef for all the tracks, how can >I then play that movie. And would that also work under QuickTime for >Windows? The way you would play that movie is that you would, in that same file, store multiple movie resources for each of the movies stored at different offsets using Add/UpdateMovieResource. Then you can just do NewMovieFromFile/FromHandle and play whichever one you want. This does *not* work at all under QuickTime for Windows, since QTW uses data-fork only movies. Since df movies are defined to contain its "movie resource" at the end of the data stream, you can only have *one* movie per file, unlike the flexibility you have when you use moov resources. QTW has a number of other limitations you might want to read up on. I don't remember them off the top of my head, but, for exmaple, I don't believe multitrack or multifile (dependent file) support is in there yet - you're limited to comlletely self-contained movies with at most 1 video track and 1 audio track. -Ivan - - Ivan Cavero Belaunde (ivanski@world.std.com) Avid VideoShop Project Lead Avid Technology, Inc. +++++++++++++++++++++++++++ >From breger@netcom.com (Ron Breger) Date: Wed, 8 Jun 1994 15:39:47 GMT Organization: Netcom : >I am having the same problem, but I am using handles. : >This is something that I'm trying to do: : >// save the moive : >PutMoiveIntoHandle() : >AddResource(publicMoive, 'MRES', 1000, ""); : >ReleaseResource(publicMovie); I did the WriteResource. : This would work in theory; however, you should do a WriteResource : before you do a ReleaseResource. Is there a reason why you're not using : Add/UpdateMovieResource, however? : >then : >// play the movie : >publicMovie = GetResource('MRES',1000); : >DetachResource(publicMoive); : >StartMoive(publicMoive); : This will *not* work. You'd have to do: : myMovie = NewMovieFromHandle(publicMovie); Yes, I am doing the NewMovieFromHandle. : Perfectly feasible with Add/UpdateMovieResource, since you can specify : the resID, as well as scan the movie res file for 'moov' resources. : >I don't want to use MovieFiles. : Why? Are there limitations you see in using them? I want to use my own resources instead of MovieFiles, so that I can put all the movies in regular resource files and use ResEdit to copy and paste the movies I need. Also, I would like to have my application contain all the resources it needs and not have it depend on any other files. I am planning of using QuickTime 2.0 that supports Music (MIDI) and would like to have all of the Movies be in the resource fork of the application. I find it very convienient to be able to use ResEdit to copy/paste resources around. So, I was trying to have a movie be self-contained, storing the movie as a resource, and reading it back in using GetResource() and NewMoiveFromHandle(), but have been unsuccessful. I still am a little confused why this doesn't work: AddResource(publicMoive, 'MRES', 1000, ""); WriteResource(publicMovie); ReleaseResource(publicMovie); [I don't want to use AddMoiveResource(), as I don't want to use MoiveFiles(). I want all the data to be in one resource and not use the data fork. That way, I can use ResEdit to eaisly copy/paste movies around. This is what I do with my 'snd ' resources!] then // play the movie publicMovie = GetResource('MRES',1000); DetachResource(publicMoive); NewMovieFromHandle(&theMovie, publicMovie); StartMoive(theMoive); Thanks for all your help. -- ===================================================================== Ron Breger breger@netcom.com AppleLink: RON.BREGER ===================================================================== +++++++++++++++++++++++++++ >From jywang@apple.com (John Wang) Date: 9 Jun 1994 21:37:17 GMT Organization: Apple Computer, Inc. There are two parts to a movie. 1) the movie data atom. 2) the movie resource atom. The movie data atom is always in the data fork. However, the movie resource atom can be stored in either the resource fork or the data fork. If the movie resource atom is stored in the resource fork, it is very easy to randomly access the many atoms that you might have stored in individual resources. But, if you want your movies to be cross-platform compatible, then you'll want to stored the movie resource atoms in the data fork. To store the movie data atom into a file, you must call either FlattenMovie or FlattenMovieData. The difference between FlattenMovie and FlattenMovie is that FlattenMovie also adds the movie resource atom to the resource fork. Therefore, you'll want to call FlattenMovieData if you don't want to add a movie resource atom to the resource fork. Instead, in either call, you can use the flag, flattenAddMovieToDataFork. This will add the movie resource atom to the data fork. For a more complete discussion of this topic, please read my column on "Movie Files" in issue #16 of develop magazine (an Apple publication). John Wang In article , breger@netcom.com (Ron Breger) wrote: > Frank Manshande (frankm@and.nl) wrote: > : Hi, > > : I have a question concerning playing QuickTime movies. > > : What I want is to store the movie (data) into the datafork at > : a specific offset (for example at offset 3000), and later play > : that movie from that offset. This way I can put more than one > : QuickTime movie into one file and play a movie at a specific > : offset. > > : The call "PutMovieIntoDataFork" only seems to store the movie > : structure, and not the movie data, into a file at the specified > : offset. This way the PutMovieIntoDataFork call creates a file > : of about 1,5 KB which only contains a reference to the original > : movie data file. > > I am having the same problem, but I am using handles. > This is something that I'm trying to do: > > > // save the moive > PutMoiveIntoHandle() > AddResource(publicMoive, 'MRES', 1000, ""); > ReleaseResource(publicMovie); > > then > > // play the movie > publicMovie = GetResource('MRES',1000); > DetachResource(publicMoive); > StartMoive(publicMoive); > > > I would like to have one (resource) file to contain many movies. > I don't want to use MovieFiles. I would like the data > to be in a resource and not contain any references to > the original files. Is this possible? > > Please help. (email or post). > > Thanks. > Ron Breger > > -- > ===================================================================== > Ron Breger > breger@netcom.com AppleLink: RON.BREGER > ===================================================================== +++++++++++++++++++++++++++ >From ivanski@world.std.com (Ivan M CaveroBelaunde) Date: Mon, 13 Jun 1994 21:56:13 GMT Organization: The World Public Access UNIX, Brookline, MA breger@netcom.com (Ron Breger) writes: >I want to use my own resources instead of MovieFiles, so that I can >put all the movies in regular resource files and use ResEdit to copy >and paste the movies I need. Also, I would like to have my application >contain all the resources it needs and not have it depend on any >other files. QT usually *needs* to store movie data in the data fork of files. QT2 introduces a "handle data handler," which allows you to create movies that are held entirely in memory. (Maynard Handley will like this...) The twist is, of course, that you have to save them yourself somehow (the movie user data could be the place for it). So the movie creation process goes as follows: - Create the movie the usual way, putting the data in the data fork. - After you're done, make a copy of the movie by copying each track by hand (using InsertTrackSegment). However, on the copied movie, when you create the media, specify that you're using the handle data handler instead of the alias data handler. This will create an in-memory copy of the movie data. - Save the handles where the data is sitting in the movie's user data using AddUserData. - Do the PutMovieIntoHandle, etc, stuff and save the movie as a resource. Once you've done that once, you can load the movie by doing the following: - GetResource() - NewMovieFromHandle() - GetMovieUserData() - For every track in this movie, if the media type is 'hndl', use the SetMediaDataRef call to "repoint" the media to the handle from GetMovieUserData. Although I haven't tried this specifically, I've used all of these calls at one time or another, so it should work. The downside to this trick is that you end up with two copies of the data in memory, which for large movies would be a serious issue. That can be addressed by putting the data handle in a separate resource instead of the user data, but the drawback there is that you must copy two resources around, which might or might not be a big deal. You could still use the movie user data to specify the res type and id where the data is stored. Hope this helps, -Ivan - - Ivan Cavero Belaunde (ivanski@world.std.com) Avid VideoShop Project Lead Avid Technology, Inc. #include --------------------------- >From nagle@netcom.com (John Nagle) Subject: Quickdraw GX - Why? Date: Mon, 30 May 1994 03:46:07 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) Well, we now have Quickdraw GX, which is a 2D object-oriented graphics system. This is nice, but does it solve a real problem? It's not a full 3D system, so you can't use it for 3D graphics. It's not compatible with existing object-oriented graphics standards, like X or PHIGS. It's complicated; several volume of manuals are required. Rescalable icons are nice, but Quickdraw GX seems overkill just to achieve that. What kind of application would be simpler if written to use Quickdraw GX? John Nagle +++++++++++++++++++++++++++ >From opstad@apple.com (David Opstad) Date: 29 May 1994 22:01:29 -0700 Organization: Apple Computer Inc, Cupertino, CA In article , John Nagle wrote: > Well, we now have Quickdraw GX, which is a 2D object-oriented >graphics system. This is nice, but does it solve a real problem? >It's not a full 3D system, so you can't use it for 3D graphics. >It's not compatible with existing object-oriented graphics standards, >like X or PHIGS. It's complicated; several volume of manuals are required. >Rescalable icons are nice, but Quickdraw GX seems overkill just to >achieve that. What kind of application would be simpler if written to use >Quickdraw GX? A word processing or page layout app would be much simpler using GX, since the typographic expressiveness built into GX is very great. An application that wishes to print to multiple kinds of paper in the same job (portrait and landscape, say, or throw in an envelope too) has an easy road using GX printing. Printing transfer modes (including to PostScript (TM) printers) that you couldn't used to print is now possible with GX. Having pictures that are both parsable and able to themselves contain pictures makes for much easier handling of whole trees of image data to be rendered. And so on... GX definitely isn't just for 2D graphics. Of course, your points about 3D are well-taken, but that wasn't the problem that GX was intended to solve. For years, developers for apps on the Mac have had to put up with a lot of quirks in the way that QuickDraw forced them to deal with device-dependent graphics, and with printing that also had its share of strange hackishness. GX finally fixes many of these problems. Dave Opstad GX Line Layout Weenie +++++++++++++++++++++++++++ >From d88-jwa@dront.nada.kth.se (Jon Wätte) Date: 30 May 1994 07:43:14 GMT Organization: The Royal Institute of Technology In nagle@netcom.com (John Nagle) writes: > Well, we now have Quickdraw GX, which is a 2D object-oriented >graphics system. This is nice, but does it solve a real problem? Yes. >It's not compatible with existing object-oriented graphics standards, >like X or PHIGS. 1) X is not object oriented; it's QuickDraw where the bottlenecks go through a network driver. 2) PHIGS is a 3D library. >It's complicated; several volume of manuals are required. Would you rahter it was less capable? The documentation for QDGX is quite good to my meaning, what's missing is a lot of sample code (there is some at least) and support in our frameworks of choise. >Rescalable icons are nice, but Quickdraw GX seems overkill just to >achieve that. What kind of application would be simpler if written to use >Quickdraw GX? QuickDraw GX printing is not a, but SEVERAL steps up, and re-defines desktop printing. It shoots Apple ahead of the competition. The GX imaging model has several things going for it, both in simplicity and capability. You can write a capable draw program with much less effort than before. You can expect to see shareware programs going after the Illustrator and FreeHand crowd! It's also _much_more_capable_ with ligatures, special forms and kerning handled automatically, as well as providing very good typographic control ("Gunk" and "Funk" axes, anyone? :-) If you can't see the use of this to create more beautiful documents, you're positioned where one-font-only people were in the middle of the 80s. Cheers, / h+ -- -- Jon W{tte, h+@nada.kth.se, Mac Software Engineer Deluxe -- Engineering: "How will this work?" Science: "Why will this work?" Management: "When will this work?" Liberal Arts: "Do you want fries with that?" -- Jesse N. Schell +++++++++++++++++++++++++++ >From dank@alumni.caltech.edu (Daniel R. Kegel) Date: 30 May 1994 07:55:28 GMT Organization: California Institute of Technology, Pasadena In article , John Nagle wrote: > Well, we now have Quickdraw GX, which is a 2D object-oriented >graphics system. This is nice, but does it solve a real problem? Quickdraw GX supports Unicode, which means that software will be easier to internationalize. Although the application developer still needs to worry about different character sets when talking to the outside world, inside everything can be Unicode. This makes document exchange and maintenance easier in a multilingual environment. - Dan +++++++++++++++++++++++++++ >From peirce@outpost.SF-Bay.org (Michael Peirce) Date: Mon, 30 May 94 09:58:47 PST Organization: Peirce Software, Inc. In article (comp.sys.mac.programmer), nagle@netcom.com (John Nagle) writes: > Well, we now have Quickdraw GX, which is a 2D object-oriented > graphics system. This is nice, but does it solve a real problem? > It's not a full 3D system, so you can't use it for 3D graphics. > It's not compatible with existing object-oriented graphics standards, > like X or PHIGS. It's complicated; several volume of manuals are required. > Rescalable icons are nice, but Quickdraw GX seems overkill just to > achieve that. What kind of application would be simpler if written to use > Quickdraw GX? For me the two most important parts of QuickDraw GX aren't specific to it's graphics engine: Typography and Printing. QuickDraw GX typography brings truly great type handling to "normal" programs with the line layout manager. No longer will this be limited to page layout programs. Related is the new font technology: support for TrueType GX and Type 1 multi master fonts. These fonts allow for smarts to be put directly into the font to do things that wasn't possible before. QuickDraw GX printing finally remakes the printing user interface. Switching printers at print dialog time, desktop printers that allow users to move a print job from one printer to another, and much better support for paper types are just three examples of making the printing experience for the user much simplier, yet more powerful. Another key benefit for users is that GX pictures don't have any of the horrible 72-dpi problems that you run into with PICTs. And Portable Digital Documents extend this idea so that a user can create a PPD and not wworry about not having the right font if they try to print or view it on another system. I could go on, but you get my drift. __ Michael Peirce __ peirce@outpost.sf-bay.org __ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301 __ __ San Jose, California USA 95117-1844 __ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: +1.408.244.6882 __ Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce +++++++++++++++++++++++++++ >From usenet@lowry.eche.ualberta.ca (Brian Lowry) Date: 30 May 1994 21:05:13 GMT Organization: Dept. of Chemical Eng., University of Alberta In article , nagle@netcom.com (John Nagle) wrote: > Well, we now have Quickdraw GX, which is a 2D object-oriented > graphics system. This is nice, but does it solve a real problem? Yes, by expressing coordinates as fixed point numbers instead of integers. That alone is enough to recommend it. -- Brian Lowry +++++++++++++++++++++++++++ >From AppleGG@lamg.com (Gordon Apple) Date: 30 May 1994 21:54:19 -0000 Organization: Los Angeles Macintosh Group BBS > Yes, by expressing coordinates as fixed point numbers instead of >integers. That alone is enough to recommend it. I think it's ironic that Quickdraw GX went to such lengths (i.e., "Fixed" format) to avoid floating point operations, and is being released almost simultaneously with the switch to PowerPC processors that run blazing fast floating point that would have been faster than using "Fixed". +++++++++++++++++++++++++++ >From dowdy@apple.com (Tom Dowdy) Date: Tue, 31 May 1994 17:06:52 GMT Organization: Apple Computer, Inc. In article , peirce@outpost.SF-Bay.org (Michael Peirce) wrote: > > In article (comp.sys.mac.programmer), nagle@netcom.com (John Nagle) writes: > > Well, we now have Quickdraw GX, which is a 2D object-oriented > > graphics system. This is nice, but does it solve a real problem? > > It's not a full 3D system, so you can't use it for 3D graphics. > > It's not compatible with existing object-oriented graphics standards, > > like X or PHIGS. It's complicated; several volume of manuals are required. > > Rescalable icons are nice, but Quickdraw GX seems overkill just to > > achieve that. What kind of application would be simpler if written to use > > Quickdraw GX? > > For me the two most important parts of QuickDraw GX aren't specific > to it's graphics engine: Typography and Printing. Michael mentions several nice things about these two areas, and one nice thing about graphics (the no-72 dpi picture thingie). I'd like to mention several other "nice graphics thingies" just to give that part of GX even time. - rotation of all objects (everyone asks, so I call it out) - 3X3 transformation matricies (including perspective) - area, length, and other geometric information routines - full geometry engine, letting you hit test, subdivide, and intersect (via any boolean operator that makes sense) any two shapes and get a device-independant GEOMETRY out the other side. No other general purpose graphics system has this, and it lets you do some excellent things, such as creating shapes from other shapes in a drawing package. (I personally think this area is very exciting, as I'd love to be able to SUBTRACT from one shape to create masks and such). - VERY powerful transfer mode functionality (and it all prints to everything, including PostScript). - device and space independant color, allowing you to create objects in any color space you feel comfortable with, and have the graphics system worry about the translation - curves - shape tagging, which lets you attach information or hints that are of use to either you or the system to shapes and pictures. (and also lets us extend GX in the future without the need to rev existing applications) - pictures can be "walked" or edited without the need to replay them to do so. GX is lots of books. But the API is really well thought out, and once you start using it, you'll find that most API calls make sense and you can figure them out by "guessing" the name. ob funny: when the PrintShop first started working with the GX graphics system, we liked to "make up" fake API calls by combining the logical flow of the API into nonsense API calls that sounded useful: GXGetTransformViewPortMappingStyle() GXSetMappingInk() -- 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." +++++++++++++++++++++++++++ >From dowdy@apple.com (Tom Dowdy) Date: Tue, 31 May 1994 17:11:45 GMT Organization: Apple Computer, Inc. In article <2sbrv9$t5f@apple.com>, opstad@apple.com (David Opstad) wrote: > In article , John Nagle wrote: > > Well, we now have Quickdraw GX, which is a 2D object-oriented > >graphics system. This is nice, but does it solve a real problem? > >It's not a full 3D system, so you can't use it for 3D graphics. > >It's not compatible with existing object-oriented graphics standards, > >like X or PHIGS. It's complicated; several volume of manuals are required. > >Rescalable icons are nice, but Quickdraw GX seems overkill just to > >achieve that. What kind of application would be simpler if written to use > >Quickdraw GX? > > A word processing or page layout app would be much simpler using GX, since the > typographic expressiveness built into GX is very great. One thing Dave didn't mention is that at the WWDC during the type demo we showed a sample application using GX and its rich text to create page layouts. The application does multiple collumns, wraps text around objects (using the cool GX geometry engine), and flows across multiple pages. It prints (and we've used to it to create some cool party invites here!), saves, and can handle custom page setups (doesn't yet do multiple formats). Except for all of the "app stuff" like clipboard, typing, cut and paste, undo, etc -- it's pretty much fully functional. It's 50K of compiled code. Something I think is quite impressive -- and the savings comes from thinking in a GX world where the system handles more of the work for you. -- 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." +++++++++++++++++++++++++++ >From jwbaxter@olympus.net (John W. Baxter) Date: Tue, 31 May 1994 13:02:27 -0700 Organization: Internet for the Olympic Peninsula In article , dowdy@apple.com (Tom Dowdy) wrote: > GX is lots of [Inside Macintosh} books. But the API is really well thought > out, and > once you start using it, you'll find that most API calls make sense > and you can figure them out by "guessing" the name. Tom...I fully agree. You and friends did very well. -- John Baxter Port Ludlow, WA, USA [West shore, Puget Sound] jwbaxter@pt.olympus.net +++++++++++++++++++++++++++ >From Jens Alfke Date: Tue, 31 May 1994 22:00:32 GMT Organization: Apple Computer John Nagle, nagle@netcom.com writes: > What kind of application would be simpler if written to use > Quickdraw GX? Any kind of illustration program a la Illustrator or FreeHand or Canvas. GX makes it very easy to write such programs, since it does so much work for you: not only does it support powerful graphics primitives like quadric Beziers, fancy options like dashes and joins, and really sophisticated color models, but it also makes it very easy to manipulate these objects. Hit-testing any GX objects (including type) is mostly just a matter of one call. Whether the big guns like Aldubeus or Deneba will move over to GX is unclear; after all, they've already got code to do most of this stuff. But remember how after 32-bit QuickDraw appeared we started to get some good color paint programs from smaller developers that were cheap and reasonably powerful for mere mortals? That's because 32BQD made it so much easier to do offscreen color graphics. I think GX will have the same effect on illustration and typography software, since it makes it possible to do very powerful PostScript-style (and more!) graphics without requiring you to write your own rendering engine for display or build custom PostScript code for printing. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 31 May 94 15:53:49 MST Organization: (none) In article , dowdy@apple.com (Tom Dowdy) writes: > > One thing Dave didn't mention is that at the WWDC during the type > demo we showed a sample application using GX and its rich text to create > page layouts. The application does multiple collumns, wraps text > around objects (using the cool GX geometry engine), and flows across > multiple pages. It prints (and we've used to it to create some > cool party invites here!), saves, and can handle custom page setups > (doesn't yet do multiple formats). > > Except for all of the "app stuff" like clipboard, typing, > cut and paste, undo, etc -- it's pretty much fully functional. > > It's 50K of compiled code. Something I think is quite impressive -- > and the savings comes from thinking in a GX world where the system > handles more of the work for you. > Is it available as sample source code or will it be? Lawson +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 31 May 94 21:14:40 MST Organization: (none) In article <1994May31.220032.15476@gallant.apple.com>, Jens Alfke writes: > John Nagle, nagle@netcom.com writes: >> What kind of application would be simpler if written to use >> Quickdraw GX? > [snip] > Whether the big guns like Aldubeus or Deneba will move over to GX is unclear; > after all, they've already got code to do most of this stuff. But remember > how after 32-bit QuickDraw appeared we started to get some good color paint > programs from smaller developers that were cheap and reasonably powerful for > mere mortals? That's because 32BQD made it so much easier to do offscreen > color graphics. I think GX will have the same effect on illustration and > typography software, since it makes it possible to do very powerful > PostScript-style (and more!) graphics without requiring you to write your own > rendering engine for display or build custom PostScript code for printing. > I think that eventually even games will start making use of GX once it becomes a standard on enough machines... Will GX ship with 7.5 or later? Lawson +++++++++++++++++++++++++++ >From dank@alumni.caltech.edu (Daniel R. Kegel) Date: 1 Jun 1994 05:45:46 GMT Organization: California Institute of Technology, Pasadena 103t_english@west.cscwc.pima.edu writes: >I think that eventually even games will start making use of GX once it becomes >a standard on enough machines... Roger on that one. >Will GX ship with 7.5 or later? I hear it will ship with 7.5, but my info is a couple months old. -Dan +++++++++++++++++++++++++++ >From pd@world.std.com (Peter F Davis) Date: Wed, 1 Jun 1994 14:24:02 GMT Organization: The World @ Software Tool & Die dowdy@apple.com (Tom Dowdy) writes: . . . >I'd like to mention several other "nice graphics thingies" just >to give that part of GX even time. . . . > - curves Actually, this is one of the things that really frustrates me about GX. Everyone else is using cubics. Why did GX go with quadrics? -pd -- =============================================================================== Peter Davis "Standardization is the opposite of innovation." +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 1 Jun 1994 21:30:07 GMT Organization: Apple Computer Peter F Davis, pd@world.std.com writes: > Actually, this is one of the things that really frustrates me about > GX. Everyone else is using cubics. Why did GX go with quadrics? (1) Quadrics are a lot faster to render, and to perform other operations on (like intersection.) (2) Cubics are mathematically intractable under some geometric operations. For example, insetting or outsetting a shape made of cubics would result in curves of degree 6; whereas insetting or outsetting quadrics just results in new quadrics. This kind of ability is absolutely fundamental to GX's geometry engine, where you can apply any kind of geometric operation to a shape and end up with another shape. Note that in PostScript you cannot do this, which makes some kinds of operations insanely difficult or impossible. (I once worked at a font company and we wanted to apply operations like insetting or outsetting to character outlines. What we had to do to implement this in PostScript would curl your hair, and it didn't even work that well. With GX it would have been trivial.) (3) In practice, for drawing, quadrics are nearly as powerful as cubics. Most of the kinds of shapes people actually draw in illustration programs can be rendered with only a few more quadrics than you'd need cubics for. It turns out the kind of cubics that _are_ really difficult to approximate as quadrics are the really twisty, loopy ones that people learn very quickly not to use in drawing. Disclaimer: I don't work on GX. Most of this is based on what I've learned over the years or have been told by people on the GX team. --Jens Alfke jens_alfke@powertalk Rebel girl, rebel girl, .apple.com Rebel girl you are the queen of my world +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 2 Jun 94 17:27:53 +1200 Organization: University of Waikato, Hamilton, New Zealand In article , nagle@netcom.com (John Nagle) writes: > Well, we now have Quickdraw GX, which is a 2D object-oriented > graphics system. This is nice, but does it solve a real problem? Absobloodylutely! > It's not a full 3D system, so you can't use it for 3D graphics. > It's not compatible with existing object-oriented graphics standards, > like X or PHIGS. I notice you didn't say "not compatible with existing _widespread_ object- oriented graphics standards"... > It's complicated; several volume of manuals are required. No it isn't! Add up all the volumes of QuickDraw and Printing Manager documentation, including all the tech notes on printing hacks and the like. Compare that to the size of the QuickDraw GX documentation. Now compare the respective functionality you get. The GX API is a model of simplicity, compared to all the accretions to QuickDraw that have accumulated over the years. > Rescalable icons are nice, but Quickdraw GX seems overkill just to > achieve that. What kind of application would be simpler if written to use > Quickdraw GX? ALL OF THEM!!! Other people have mentioned the typography and printing support. Perhaps you aren't clear how much functionality GX gives you: In the typography, you get much cleaner multilingual support than old QuickDraw is capable of; contextual and alternate character forms; font variations (what Adobe calls "multiple masters"); and automatic justification and kerning. In the printing support, you get: anything you can draw, you can print! And this applies to both PostScript and non-PostScript printers. You realize how much of a breakthrough this is? All those times people have torn out their hair over things coming out different on the printer compared to how they look on the screen--all that goes away! And you get printer sharing and background printing for *all* printers. And it is easier for third parties to develop printer drivers. And it is easier still for other third parties to write extensions that hook into the printing process in all kinds of useful ways (such as Michael Peirce's "Peirce Print Tools"). And the graphics is pretty cool, too. Look at it this way: when the original Macintosh came out in 1984, a lot of people wondered why they would need the graphics and the text-graphics integration, to do things that they were happily doing on typewriter-like systems before. Nobody seriously asks that question any more. GX will similarly raise people's expectations of what basic text and graphics handling is all about. The coming of the typewriter was a giant step backwards for the printed word, and computers have only made things worse. The original Mac went a long way to countering a lot of the pervasiveness of that "typewriter mentality". But with QuickDraw GX, we can finally say that the computer is capable of enriching, rather than retarding, the development of all that is best in typography, and that the ghost of the typewriter has been well and truly laid to rest. Long live type! 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 A: OS/2 2.1, CD-i, and the Commodore Amiga. Q: Name 3 products which have outsold Windows NT. +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 3 Jun 94 11:05:01 +1200 Organization: University of Waikato, Hamilton, New Zealand In article , nagle@netcom.com (John Nagle) writes: > [GX is] complicated; several volume of manuals are required. Just to prove that GX is not only powerful for dealing with complex things, it's also easy to use for simple things, here's a couple of minimal, _complete_ demo programs for you to compare. (I compiled and ran both versions with THINK C 6, so I know they work.) First, the QuickDraw version: #include void main(void) { GrafPort MyPort; InitGraf(&qd.thePort); OpenPort(&MyPort); MoveTo(100, 100); DrawString("\pHello, World!"); ClosePort(&MyPort); } /*main*/ Next, the QuickDraw GX version: #include #include #include void main(void) { gxPoint where = {IntToFixed(100), IntToFixed(100)}; #define TheText "Hello, World!" GXDrawText(sizeof(TheText), (unsigned char *) TheText, &where); } /*main*/ Now, what do you think of their relative complexity? 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 Please do not feed the vegetables. +++++++++++++++++++++++++++ >From peirce@outpost.SF-Bay.org (Michael Peirce) Date: Fri, 3 Jun 94 16:09:15 PST Organization: Peirce Software, Inc. In article <2smvne$mkg@news.kth.se> (comp.sys.mac.programmer), d88-jwa@dront.nada.kth.se (Jon Wätte) writes: > >3. No stupid conversions and typecasting to remember all over the place. > > Okay, I buy that. Personally I blame that on C. C just doesn't have a "native" fixed type with associated operations. Also (very minor point) I use the ff() macro rather than the IntToFixed() - they are equivalent, but ff is more compact. I do wish there was a VALIDATE mode that would yell when it started seeing coordinates like 0x00000001 rather than 0x00010000. Such tiny coordinates can't be common or generally useful. I have gotten into trouble by passing integer coordinates rather than fixed coordinates, though they aren't hard bugs to figure out. ____________ My only real grip with GX is that the interface is opague. I understand the rational that they might/will change things inside at a later date. That's well and good, but it makes it MUCH harder to debug. With old QuickDraw I could root around in the debugger and see exactly what my visRegion was set to and such. With GX there is no way to see, for example, what my Ink happens to be or my clip shape or whatever. They supply GraphicsBug, but it's basically useless for the kind of work I do (non-applications). And it's a pretty aweful interface even for app use - it makes Jasik look like an UI god. [ 1/2 :-) ] And it crashes all the time for me. What I'd like to see is a way to peer inside. Make it 100% clear that things will change and all that, but allow us to debug things in a reasonable way! __ Michael Peirce __ peirce@outpost.sf-bay.org __ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301 __ __ San Jose, California USA 95117-1844 __ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: +1.408.244.6882 __ Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce +++++++++++++++++++++++++++ >From Rick Wong Date: 3 Jun 1994 23:06:32 GMT Organization: Stanford University In article <1994Jun3.093501.1@west.cscwc.pima.edu> , 103t_english@west.cscwc.pima.edu writes: >Perhaps the sample source code to draw the same text a dozen times, rotated by >30 degrees each time in a loop? > >Takes only a few lines more than simply drawing the text in the first place... > > >Lawson #include #include #include #include #define TheText "GX Rules!" void main(void) { gxPoint myPoint = {ff(100), ff(100)}; gxShape myTextShape = GXNewText(strlen(TheText), TheText, &myPoint); gxTransform myShapeTransform = GXGetShapeTransform(myTextShape); int i; for (i = 0; i < 12; ++i) { GXDrawShape(myTextShape); GXRotateTransform(myShapeTransform, ff(30), myPoint.x, myPoint.y); } GXDisposeShape(myTextShape); } Any sort of rotation operation (including bitmaps) is trivial with QuickDraw GX. This doesn't even nick the surface of its capabilities. I am just starting to read the QD GX docs, and I must say that I am quite impressed by the job Apple's done. Not only is QD GX loaded with great new features, the underlying model is indeed well thought out, and the APIs are exemplary in their cleanness and consistency. I'm going to enjoy forgetting everything I ever learned about PixMaps, GDevices, cluts, etc. Rick Wong +++++++++++++++++++++++++++ >From sho@bohr.physics.purdue.edu (Sho Kuwamoto) Date: 3 Jun 94 17:35:05 GMT Organization: Purdue University Physics Department ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > #include > #include > #include > > void main(void) > { > gxPoint where = {IntToFixed(100), IntToFixed(100)}; > #define TheText "Hello, World!" > > GXDrawText(sizeof(TheText), (unsigned char *) TheText, &where); > } /*main*/ One thing I'd like to see is a way to specify fixed point constants from within the mac C compilers. What? Did I hear you cry, "nonstandard"? Well, what about four byte chars (e.g., 'APPL')? How standard are they? I imagine being able to type 100F to represent a fixed point 100 in much the same way that one types 100L to represent a long int 100. I realize it's grossly nonstandard, but wouldn't it make GX so much easier? -Sho -- sho@physics.purdue.edu <<-- finger this account to find out what I'm having for lunch! Sho Kuwamoto. +++++++++++++++++++++++++++ >From blm@coho.halcyon.com (Brian L. Matthews) Date: 4 Jun 1994 01:06:33 GMT Organization: A World of Information at Your Fingertips In article <16887@dirac.physics.purdue.edu>, Sho Kuwamoto wrote: |> gxPoint where = {IntToFixed(100), IntToFixed(100)}; | |One thing I'd like to see is a way to specify fixed point |constants from within the mac C compilers. Well, if you're willing to switch to C++, it would be fairly easy to make some classes so you could just say: gxPoint where = { 100, 100 }; and the compiler (with the help of some classes you write) would do the right thing. One could also be clever and make it so: gxPoint where = { 10.53, 9.47 }; also does (usually) the right thing. And all without modifying the language. This would also fix problems with accidentally passing an int where Fixed was expected. With proper declarations, such a thing wouldn't be possible (well, wouldn't be easy. Anything's possible in C :-)). Brian +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Sat, 4 Jun 1994 06:02:23 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) sho@bohr.physics.purdue.edu (Sho Kuwamoto) writes: >One thing I'd like to see is a way to specify fixed point >constants from within the mac C compilers. What? Did I >hear you cry, "nonstandard"? Well, what about four byte >chars (e.g., 'APPL')? How standard are they? Actually, multicharacter constants are standard C and C++, although they are a recent addition to the language. >I imagine being able to type 100F to represent a fixed point >100 in much the same way that one types 100L to represent a >long int 100. I realize it's grossly nonstandard, but >wouldn't it make GX so much easier? Why build it into the language? Just add the new type. class QDfixed { long fval; public: QDfixed(int intval) { fval = intval * int_scale_factor; } QDfixed(QDfixed fixedval) { fval = fixedval.fval; } QDfixed(int intval, int fractpart) { fval = intval * int_scale_factor + fractpart; } .... } You get the idea. Of course, because the Mac interface is still defined in terms of C, not C++, the standard headers won't support this properly, but that could be fixed with some glue routines expressed as inlines. John Nagle +++++++++++++++++++++++++++ >From marke@infi.net (Mark Eaton) Date: 4 Jun 1994 18:06:09 GMT Organization: InfiNet Ralph Martin (Ralph.Martin@cm.cf.ac.uk) wrote: : In article <1994Jun3.110501.29244@waikato.ac.nz> Lawrence D'Oliveiro, : ldo@waikato.ac.nz writes: : >Next, the QuickDraw GX version: : > : > #include : > #include : > #include : > : > void main(void) : > { : > gxPoint where = {IntToFixed(100), IntToFixed(100)}; : > #define TheText "Hello, World!" : > : > GXDrawText(sizeof(TheText), (unsigned char *) TheText, &where); : > } /*main*/ : > : >Now, what do you think of their relative complexity? : It's not obvious: : Good points for Quickdraw: : 1. Less headers. I wonder if compiler providers like Symantec and MetroWerks will come up with a unified header for GX that includes the necessary headers... Its just a matter of time. : 2. Functionality divided into smaller chunks (what to draw, where to draw : separate). Yes, but now we arent restricted to one 'pen'. We can have any number of points without having to call move and moveto constantly. I think the new way is better. : 3. No stupid conversions and typecasting to remember all over the place. : Good points for Quickdraw GX: : 4. No rubbish concerning initialising and setting up ports. : Overall - the Quickdraw is easier to read, and looks more maintainable : and less error prone because of point 3. It is probably easier to write : given point 2, as the programmer has to concentrate on less things at : once. Had he used unsigned char* theText = "Hello World"; he wouldnt have needed a cast. He used a numdefine instead... It was a programmer choice... : Seriously, you are probably right about QuickDraw GX having a better : model underlying it. I'm not so sure that the realisation of that model : into an API is a great leap forward though. Perhaps longer examples would : be more convincing! : Ralph -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Mark Eaton | MacXPerts - Custom Mac and Newton Software marke@infi.net | 3228L W. Cary St. | Richmond, VA. 23221 | (804) 353-7122 FAX: (804) 358-3847 +++++++++++++++++++++++++++ >From marke@infi.net (Mark Eaton) Date: 4 Jun 1994 18:11:20 GMT Organization: InfiNet Rick Wong (rick@jessica.stanford.edu) wrote: : #define TheText "GX Rules!" : void main(void) : { : gxPoint myPoint = {ff(100), ff(100)}; : gxShape myTextShape = GXNewText(strlen(TheText), TheText, &myPoint); Its interesting that GX uses shapes and converts text to shapes. This is very much like the Newton form of QuickDraw. Did some of the engineers work on both, or is this just coincidence? : gxTransform myShapeTransform = GXGetShapeTransform(myTextShape); : int i; : for (i = 0; i < 12; ++i) { : GXDrawShape(myTextShape); : GXRotateTransform(myShapeTransform, ff(30), myPoint.x, myPoint.y); : } : GXDisposeShape(myTextShape); : } : Any sort of rotation operation (including bitmaps) is trivial with : QuickDraw GX. This doesn't even nick the surface of its capabilities. : I am just starting to read the QD GX docs, and I must say that I am : quite impressed by the job Apple's done. Not only is QD GX loaded : with great new features, the underlying model is indeed well thought : out, and the APIs are exemplary in their cleanness and consistency. : I'm going to enjoy forgetting everything I ever learned about PixMaps, : GDevices, cluts, etc. Much agreed! : Rick Wong -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Mark Eaton | MacXPerts - Custom Mac and Newton Software marke@infi.net | 3228L W. Cary St. | Richmond, VA. 23221 | (804) 353-7122 FAX: (804) 358-3847 +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 7 Jun 94 11:41:28 +1200 Organization: University of Waikato, Hamilton, New Zealand In article <2sqfqh$l0r@lucy.infi.net>, marke@infi.net (Mark Eaton) writes: > > Had he used unsigned char* theText = "Hello World"; he wouldnt have needed a > cast. He used a numdefine instead... It was a programmer choice... Actually, it was my ignorance of C showing. :-} Seriously, though, if unsigned char* theText = "Hello World" compiles without needing a cast, while I needed a cast to pass the exact same literal to an unsigned char* argument, isn't that an inconsisten-C? 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 ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 7 Jun 94 11:46:51 +1200 Organization: University of Waikato, Hamilton, New Zealand In article , peirce@outpost.SF-Bay.org (Michael Peirce) writes: > > Also (very minor point) I use the ff() macro rather than the > IntToFixed() - they are equivalent, but ff is more compact. I deliberately used IntToFixed to try to make it clearer what was going on. > What I'd like to see is a way to peer inside. Make it 100% > clear that things will change and all that, but allow us to > debug things in a reasonable way! There are some GX functions that provide such an escape, eg GXGetShapeStructure. If you have a look at the source of SlideMaster that came with the beta 1 distribution, you can see an example of this in use (it makes a big difference to the speed of the "Particles" animation!). All you need is some documentation on how to use this, or, failing that, some time spent poking around for yourself... 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 ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 7 Jun 94 12:02:22 +1200 Organization: University of Waikato, Hamilton, New Zealand In article <1994Jun3.094115.17117@cm.cf.ac.uk>, Ralph Martin writes: > In article <1994Jun3.110501.29244@waikato.ac.nz> Lawrence D'Oliveiro, > ldo@waikato.ac.nz writes: >> >>Now, what do you think of their relative complexity? > > Good points for Quickdraw: > 2. Functionality divided into smaller chunks (what to draw, where to draw > separate). Actually, this statement is more true of GX in general. My sample code was for drawing text: consider equivalent code for drawing, say, polygons. (Do you want me to inflict some on you?) > 3. No stupid conversions and typecasting to remember all over the place. I was using THINK C for communication purposes. Normally I use Modula-2. Much less typecasting. :-) 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 ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 7 Jun 94 12:04:03 +1200 Organization: University of Waikato, Hamilton, New Zealand In article <2smvne$mkg@news.kth.se>, d88-jwa@dront.nada.kth.se (Jon Wätte) writes: > In <1994Jun3.094115.17117@cm.cf.ac.uk> Ralph Martin writes: > >>Good points for Quickdraw GX: >>4. No rubbish concerning initialising and setting up ports. > > Actually, there is; Lawrence was cheating (or rather not using > a relevant test case) I wasn't cheating. The GX documentation says you can leave out all the client setup if the defaults are adequate, and in this case, they were! 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: Tue, 7 Jun 1994 01:21:35 GMT Organization: Adobe Systems Incorporated Lawrence D'Oliveiro, Waikato University writes > Seriously, though, if unsigned char* theText = "Hello World" compiles without > needing a cast, while I needed a cast to pass the exact same literal to an > unsigned char* argument, isn't that an inconsisten-C? Its not an inconsistency because it doesn't compile. -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Never let a "final candidate" subscript get above the age of consent. +++++++++++++++++++++++++++ >From peirce@outpost.SF-Bay.org (Michael Peirce) Date: Mon, 6 Jun 94 20:25:05 PST Organization: Peirce Software, Inc. In article <1994Jun7.114651.29344@waikato.ac.nz> (comp.sys.mac.programmer), ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > In article , peirce@outpost.SF-Bay.org (Michael Peirce) writes: > > > > Also (very minor point) I use the ff() macro rather than the > > IntToFixed() - they are equivalent, but ff is more compact. > > I deliberately used IntToFixed to try to make it clearer what was going on. > > > What I'd like to see is a way to peer inside. Make it 100% > > clear that things will change and all that, but allow us to > > debug things in a reasonable way! > > There are some GX functions that provide such an escape, eg GXGetShapeStructure. GXGetShapeStructure will return geometry information about a shape. Other calls can also return infomation about other stuff like inks and transforms. With these it is possible to build some sort of debugging library yourself, but it really doesn't help much when you are stepping through source code and need to see what the ink of a given shape is or maybe its transform. GraphicsBug tries to address some of this, but it was clearly written by someone that thinks Macsbug was a great model to follow for a debugger UI :-( It's completely unusable by folks who don't have a friendly event loop handly. People who write print drivers or extensions or even App code that uses GX for just a little work, then cleans up before idle time are left in a lurch. I had to dust off some really old code that spits out debugging information over the net to a log app so I can get some idea what's going on deep in the bowels of message overrides. This is code that I haven't had to use since symbolic debugging arrived on the Mac many moons ago. Maybe I'm carrying on at a bit too much length, but having spend the last months debugging our printing extensions and I've wasted large amounts of time because its hard to debug GX code. (You also have to jump through hoops to get source debugging to work with print drivers and extensions, but that's yet another story!). The easier it is to debug GX apps and such, the sooner they will start showing up. __ Michael Peirce __ peirce@outpost.sf-bay.org __ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301 __ __ San Jose, California USA 95117-1844 __ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: +1.408.244.6882 __ Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 7 Jun 1994 13:33:06 -0700 Organization: SRI International, Menlo Park, CA In article peirce@outpost.SF-Bay.org (Michael Peirce) writes: >GraphicsBug tries to address some of this, but it was clearly written >by someone that thinks Macsbug was a great model to follow for a debugger >UI :-( It's completely unusable by folks who don't have a friendly event >loop handly. People who write print drivers or extensions or even App I thought that the GX team answered your question about that. Didn't they mention that there is a call you can use to simulate a Event loop? Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From peirce@outpost.SF-Bay.org (Michael Peirce) Date: Tue, 7 Jun 94 15:06:31 PST Organization: Peirce Software, Inc. In article <1994May31.211440.1@west.cscwc.pima.edu> (comp.sys.mac.programmer), 103t_english@west.cscwc.pima.edu writes: > Will GX ship with 7.5 or later? QuickDraw GX swill ship with 7.5. Before then, GX can be licensed by third party companies that want to include it with their products. Since our Peirce Print Tools won't work without GX, we are in the process of licensing GX and will bundle it in with our product in a week (or two or three depending on how long it takes Apple licensing to process the paperwork!). It's four HDFD disks and will work with System 7.1 or later. __ Michael Peirce __ peirce@outpost.sf-bay.org __ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301 __ __ San Jose, California USA 95117-1844 __ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: +1.408.244.6882 __ Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 9 Jun 94 11:39:00 +1200 Organization: University of Waikato, Hamilton, New Zealand In article , peirce@outpost.SF-Bay.org (Michael Peirce) writes: > > In article <1994Jun7.114651.29344@waikato.ac.nz> (comp.sys.mac.programmer), ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >> In article , peirce@outpost.SF-Bay.org (Michael Peirce) writes: >> >> > What I'd like to see is a way to peer inside. Make it 100% >> > clear that things will change and all that, but allow us to >> > debug things in a reasonable way! >> >> There are some GX functions that provide such an escape, eg GXGetShapeStructure. > > GXGetShapeStructure will return geometry information about a shape. > Other calls can also return infomation about other stuff like inks > and transforms. > > With these it is possible to build some sort of debugging library > yourself, but it really doesn't help much when you are stepping through > source code and need to see what the ink of a given shape is or maybe > its transform. You could write a MacsBug dcmd or two to make these calls. Since GX is supposed to be interrupt-reentrant, they might even work quite safely. > GraphicsBug [is] completely unusable by folks who don't have a friendly event > loop handly. People who write print drivers or extensions or even App > code that uses GX for just a little work, then cleans up before idle > time are left in a lurch. Here's the tip that was given out at the GX in QD apps and debugging tips session at WWDC: break into MacsBug, switch to the system heap zone, then type "g InitEventLoop" (I think that's how it's spelt). This is supposed to get you into a dummy event loop so you can use GraphicsBug on your driver/extension. By the way, I think this only works with the debugging version of GX. MacsBug can't seem to find a symbol resembling this in the 1.0f2c13 (non-debugging) version I'm running. 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 peirce@outpost.SF-Bay.org (Michael Peirce) Date: Wed, 8 Jun 94 21:52:09 PST Organization: Peirce Software, Inc. In article <1994Jun9.113900.29449@waikato.ac.nz> (comp.sys.mac.programmer), ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > > Here's the tip that was given out at the GX in QD apps and debugging tips > session at WWDC: break into MacsBug, switch to the system heap zone, then type > "g InitEventLoop" (I think that's how it's spelt). This is supposed to get you > into a dummy event loop so you can use GraphicsBug on your driver/extension. > > By the way, I think this only works with the debugging version of GX. MacsBug > can't seem to find a symbol resembling this in the 1.0f2c13 (non-debugging) > version I'm running. Right, but who uses Macsbug? Seriously. I guess the GX team does. Yikes! __ Michael Peirce __ peirce@outpost.sf-bay.org __ Peirce Software, Inc. __ 719 Hibiscus Place, Suite 301 __ __ San Jose, California USA 95117-1844 __ Makers of: Smoothie & __ voice: +1.408.244.6554 fax: +1.408.244.6882 __ Peirce Print Tools __ AppleLink: peirce & AOL: AFC Peirce +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 13 Jun 1994 09:56:34 +0800 Organization: Department of Computer Science, The University of Western Australia In article <1994Jun3.094115.17117@cm.cf.ac.uk>, Ralph Martin wrote: >Seriously, you are probably right about QuickDraw GX having a better >model underlying it. I'm not so sure that the realisation of that model >into an API is a great leap forward though. Perhaps longer examples would >be more convincing! The important point is not whether GX is simpler, it's that you can do more. Colour QuickDraw is fine until you hit one of its boundaries and then you suffer much pain and misery trying to work around it. With GX the boundaries are much further out, thus you're less likely to hit them. The classic example here is rotated text. Hmm, of course when you do hit GX's boundaries... -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia Who, as a Mac user as well as a programmer, can't wait for GX drawing/DTP. And is glad he doesn't have to write it (: --------------------------- >From tboucher@teleport.com (Tyson B. Boucher) Subject: [Q] Programming the AT&T 3210? Date: Thu, 09 Jun 1994 03:15:16 -0800 Organization: Teleport - Portland's Public Access (503) 220-1016 Does anyone know of a cheap/free way to learn how to program the 3210 (the DSP in av Macs)? IÕd like to take advantage of it, but IÕm still working on getting a full set of IM, so I donÕt want to spend a lot buying a manual from AT&T if I can help it. Besides, this is (for now) just a casual interest and I donÕt want to toss a lot of $$$ after this if it turns out to be not worth it. -- | tboucher@teleport.com | | /-Student | | Tyson B. Boucher-|-Programmer | | \-lifeless.net.bum ;) | +++++++++++++++++++++++++++ >From Darrin Cardani Date: Fri, 10 Jun 1994 13:55:13 GMT Organization: AT&T Global Information Solutions, Atlanta >In article Tyson B. Boucher writes: > Does anyone know of a cheap/free way to learn how to program the 3210 >(the DSP in av Macs)? IÕd like to take advantage of it, but IÕm still >working on getting a full set of IM, so I donÕt want to spend a lot buying >a manual from AT&T if I can help it. Besides, this is (for now) just a >casual interest and I donÕt want to toss a lot of $$$ after this if it >turns out to be not worth it. First off, most readers don't recognize the funky characters you've got in your post. You might want to use standard ascii when posting. But to answer your question, The manual for the language is free from AT&T. I don't have the address with me right now. The commercially available development system is $1000. Some people on the net are trying to write one that I assume will be ftp'able from the major mac archive sites. There is a group called comp.dsp. You might want to check it out and ask for the Mac DSP mini-faq. It has more info. (like the phone number for the free manual.) Darrin +++++++++++++++++++++++++++ >From qmot@cs.mcgill.ca (Thomas PUSHPATHADAM) Date: 11 Jun 1994 21:19:10 GMT Organization: SOCS, McGill University, Montreal, Canada (*** Note: posting from borrowed account ***) > Does anyone know of a cheap/free way to learn how to program the 3210 > (the DSP in av Macs)? IUd like to take advantage of it, but IUm > still > working on getting a full set of IM, so I donUt want to spend a lot > buying > a manual from AT&T if I can help it. Besides, this is (for now) just > a casual interest and I donUt want to toss a lot of $$$ after this if > it turns out to be not worth it. Stefan Arentz (arentz@batcave.knoware.nl), Andrew Grignon (Andrew-Grignon@uiowa.edu) and myself (Paul Lalonde, paul@architecture.mcgill.ca) are currently writing an assembler for the DSP3210. Since we're doing this in our scarce spare time, it's moving rather slowly. We want to upload to the major ftp sites by the end of June. In the meantime, you might call AT&T and ask for the "DSP3210 information manual". It's free, and it introduces you to the DSP's instruction set. Their number is 1-800-372-2447. You will also need the "Centris 660AV & Quadra 840AV developer note", available on more recent Bookmark & developer CDs. This documents the interface to the DSP. Hope this helps, Paul Lalonde paul@architecture.mcgill.ca +++++++++++++++++++++++++++ >From amanda@intercon.com (Amanda Walker) Date: Mon, 13 Jun 1994 14:32:50 -0500 Organization: InterCon Systems Corporation, Herndon, VA USA Darrin Cardani writes: > The commercially available development system is $1000. Spectral Innovations is now selling the ARTA development for $495 without support ($995 includes support). I wouldn't advise doing this unless you've done DSP code before, though :)... Amanda Walker InterCon Systems Corporation --------------------------- End of C.S.M.P. Digest **********************