From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-070 Date: Mon, 21 Nov 1994 14:44:23 +0100 (MET) C.S.M.P. Digest Mon, 21 Nov 94 Volume 3 : Issue 70 Today's Topics: A few newbie (to Mac Programming) questions... Checking for low memory condition Fast Pixel Drawing GX text problems Macintosh Drag and Drop Microseconds() documentation? NOTE TO ALL SCREEN SAVER AUTHORS Power Plant Documentation?? Shareware successes? 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 jobell@bnr.ca (Ritchie Brock) Subject: A few newbie (to Mac Programming) questions... Date: 7 Nov 1994 11:16:40 -0600 Organization: Bell-Northern Research, Richardson, TX I'm a newbie to Macintosh programming, but not to programming in general or Macintoshes. Here are my questions: I'm writing a simple program that displays a window with some graphics in it. The window is invoked through a menu and a corresponding command key. The window can be closed through the go away box and through the menu. Here is my problem: I am not sure on how about updating my window when something is moved over it. Does my application have to redraw the entire contents of the window? Furthermore, should window generation and window drawing be two different functions? I think this should be because everytime my app received an activate event it would create a new window and create a new drawing (since the function doDrawing generated the window and the contents). For some reason I think the app receives an activate event continuously because once I invoked the doDrawing routine for the first time it would loop continuously createing multiple windows. anyway, thanx for the help. e-mail me if possible. Joe jobell@bnr.ca later -- * Joseph A. Bell (NOT Ritchie Brock) * * Northern Telecom / Bell-Northern Research * * Email: jbell@utdallas.edu * +++++++++++++++++++++++++++ >From bb@lightside.com (Bob Bradley) Date: Mon, 07 Nov 1994 17:30:18 -0800 Organization: SS Software Inc. In article <39lndo$f0u@crchh932.bnr.ca>, jobell@bnr.ca (Ritchie Brock) wrote: > I'm a newbie to Macintosh programming, but not to programming > in general or Macintoshes. > > Here are my questions: > > I'm writing a simple program that displays a window with > some graphics in it. The window is invoked through a menu > and a corresponding command key. The window can be closed > through the go away box and through the menu. Here is > my problem: > > I am not sure on how about updating my window when something > is moved over it. Does my application have to redraw the > entire contents of the window? Furthermore, should window > generation and window drawing be two different functions? I > think this should be because everytime my app received an > activate event it would create a new window and create a new > drawing (since the function doDrawing generated the window > and the contents). For some reason I think the app receives > an activate event continuously because once I invoked the > doDrawing routine for the first time it would loop continuously > createing multiple windows. Do all of your drawing in in your updateEvt handler. This way you only have 1 routine that handles all drawing, whether it's the first time or when your window is uncovered. As far as drawing the entire window when you get an updateEvt, just draw the portion of the window that was previously hiden. After you call BeginUpdate, you can use the visRgn of the window to know what part to draw (BeginUpdate changes the visRgn of the window to cover only the part of the window that needs updating). It mainly depends on how complicated what you are drawing is. If you have complex objects that take a long time to re-calculate and draw, you may want to calculate, based on the visRgn, which of those complex shapes to redraw but, if you've got just a couple simple objects in your window, it may be faster to just redraw them all then try to re-calculate which objects intersect the visRgn. Also, when your window is shown, an update event is automatically generated with the full content of the window in the visRgn so you don't have to manually draw the window when it is created, it will be handled by your updateEvt handler. I'm not sure why you are creating a window each time you get an activate event. If you mean each time your application gets an OpenApplication AppleEvent I understand but, when you get an activate event for a window, you don't want to create a new one, you just want to activate (or deactivate) anything needs to be activated (or deactivated). --------------------------- >From ikb_macd@ece.concordia.ca (Keith MacDonald) Subject: Checking for low memory condition Date: 1 Nov 1994 23:14:52 GMT Organization: ECE - Concordia University >From what I've read here recently, the Toolbox often crashes if less than approx 12K of memory is available. In trying to deal with this: 1) is checking FreeMem ok, or must I check using MaxMem? - is MaxMem much slower than freeMem? 2) how often would I want to check the available memory? - after file loading & major (>1K) allocations or everytime through event loop? Thanks in advance, Keith ___________________________________________________________________________ Keith MacDonald Computer Engineering ikb_macd@ECE.concordia.ca Concordia University http://www.ece.concordia.ca/~ikb_macd/addr.html Montreal, QC, Canada +++++++++++++++++++++++++++ >From jbeeghly@u.washington.edu (Jeff Beeghly) Date: 2 Nov 1994 02:55:34 GMT Organization: University of Washington ikb_macd@ece.concordia.ca (Keith MacDonald) writes: >From what I've read here recently, the Toolbox often crashes if less >than approx 12K of memory is available. In trying to deal with this: I was the one who started the minimum mememory running thread. The 12k was the limit for the StandardGetFile dialog... the min. amount changes from task to task. Someone suggest that the minimum amount should be 32k (due to some toolbox calls that >MIGHT< require 32k). To me, this sounds rediculous... apps should be more streamlined. In order to boob-proof your app you should test each path under critical conditions. > 1) is checking FreeMem ok, or must I check using MaxMem? remember, FreeMem just reports the amount of FREE memory. My app contains quite a bit of purgeable code that can be freed up to increase the amount of free menory. If you don't have them yet, get SWATCH (system Watcher) and ZoneRanger. > 2) how often would I want to check the available memory? > - after file loading & major (>1K) allocations > or everytime through event loop? What I'm doing is two things: 1) My even loop looks something like this: static Boolean bWarned = FALSE; while( !gIsAppDone ) { if( WaitNextEvent(....) ) { DoEvent(....); } else { DoIdle(....); } if(FreeMem() < LOW_RAM_WARNING) { if(bWarned == FALSE) { CautionAlert(....); bWarned = TRUE; } } } This warns the user when the memory drops below LOW_RAM_WARNING Second, before I perform a function, I perform a minimum memory check... something like... switch( menu ) { case mOpen: if(FreeMem() < MINIMUM_RAM) ErrorAlert(...); // tell the user "sorry, but there // is not enough free memory // please close one or more windows" else OpenFile(); break; } +++++++++++++++++++++++++++ >From mhl@icf.hrb.com (mark) Date: 2 Nov 94 10:50:28 EST Organization: HRB Systems, Inc. In article <396i5c$4ae@newsflash.concordia.ca>, ikb_macd@ece.concordia.ca (Keith MacDonald) writes: > From what I've read here recently, the Toolbox often crashes if less > than approx 12K of memory is available. In trying to deal with this: > 1) is checking FreeMem ok, or must I check using MaxMem? > - is MaxMem much slower than freeMem? > 2) how often would I want to check the available memory? > - after file loading & major (>1K) allocations > or everytime through event loop? > Keith, It is reassuring to see programmers making crash-proof applications. You are correct. In addition to rigorous error checking, verifying the presence of required features is a good safety feature. In this case - available memory. A good figure to look for, in terms of free memory, would be 33K. Much of the Toolbox limits data structures to what can be indexed by a short (i.e. 32767 bytes). Allowing for overhead we arrive at 33K. In terms of frequency, we really do not need to check at all (although the functions you listed would work). The Memory Manager provides a mechanism to inform applications when "memory is low". What is need is a Grow Zone Procedure. When something needs memory, either directly, by calling NewPtr or NewHandle, or indirectly, by calling a Toolbox routine which does, the memory manager checks to see if the request can be satisfied. If it can not, the Grow Zone Procedure will be called in search of additional memory. If we have allocated a 33K block of memory, early in execution, we can dispose of this block when our Grow Zone Procedure is called. This should (probably) satisfy any unforseen Toolbox needs. In addition, we know that memory is low, and can take defensive measures like disabling menu items which will need large amounts of memory (e.g. File>New, File>Open...). We should also program defensively elsewhere. Always check the results of NewHandle and NewPtr for nil. Provide a graceful return from such situations (not a hard crash). Be aware that Toolbox routines that return a pointer or Handle to a new data structure also need to be checked. Given the precautions set out here, we should be relatively safe from crashes due to low memory in Toolbox calls. For additional information on the topic of Grow Zone Procedures and avoiding memory allocation problems in general, please refer to the new Inside Macintosh: Files. > Thanks in advance, > Keith -- Hope this helps. Mark H. Linton ____________________________________________________________________ mark \'märk\ n [ME, fr. OE mearc boundary, march, sign; akin to OHG marha boundary, L margo] 1 a : a conspicuous object serving as a guide for travelers 2 : A standard or criterion of quality 3 : An object or point that serves as a guide --idiom. mark time. 1 : To make little or no progress +++++++++++++++++++++++++++ >From larson@base.cs.ucla.edu (Christopher Larson) Date: 2 Nov 1994 17:56:37 GMT Organization: UCLA, Computer Science Department In article <1994Nov2.105028.22266@hrbicf> mhl@icf.hrb.com (mark) writes: >In article <396i5c$4ae@newsflash.concordia.ca>, > ikb_macd@ece.concordia.ca (Keith MacDonald) writes: >> From what I've read here recently, the Toolbox often crashes if less >> than approx 12K of memory is available. In trying to deal with this: > > [ most of Mark's excellent answer deleted ] > > Given the precautions set out here, we should be relatively safe > from crashes due to low memory in Toolbox calls. For additional > information on the topic of Grow Zone Procedures and avoiding > memory allocation problems in general, please refer to the new > Inside Macintosh: Files. ^^^^^^^^^^^^^^^^^^^^^^^ I'm sure Mark meant _Inside Macintosh: Memory_. --Chris _______________________________________________________________________________ Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious Death to the Trojans! Go Bruins! (Insert disclaimer here) Internet: larson@kingston.cs.ucla.edu +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 2 Nov 1994 22:11:01 GMT Organization: Apple Computer mark, mhl@icf.hrb.com writes: > In terms of frequency, we really do not need to check at all > (although the functions you listed would work). The Memory > Manager provides a mechanism to inform applications when "memory > is low". What is need is a Grow Zone Procedure. Right on! I agree completely. This is how MacApp and TCL (and PowerPlant?) do it, and the way I do it in any serious app I write. In addition, to make this work better it helps if your own explicit memory allocations cannot trigger the GZproc (since it's their for the Toolbox's use, not yours.) I do this by having a global Boolean flag that tells the GZproc whether it's okay to dispose the "cushion" block. Then I have routines like MyNewHandle that set the flag to false, call NewHandle, then set it to true. This ensures that your code doesn't eat into the cushion. Moreover, once the cushion is eaten into, all of your explicit memory allocations should fail until the cushion can be re-inflated to its original size. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From bw16@cornell.edu (Bretton Wade) Date: Wed, 02 Nov 1994 19:39:28 -0500 Organization: Cornell Program of Computer Graphics In article <1994Nov2.221101.2400@gallant.apple.com>, Jens Alfke wrote: > Right on! I agree completely. This is how MacApp and TCL (and PowerPlant?) do > it, and the way I do it in any serious app I write. > > In addition, to make this work better it helps if your own explicit memory > allocations cannot trigger the GZproc (since it's their for the Toolbox's > use, not yours.) I do this by having a global Boolean flag that tells the > GZproc whether it's okay to dispose the "cushion" block. Then I have routines > like MyNewHandle that set the flag to false, call NewHandle, then set it to > true. This ensures that your code doesn't eat into the cushion. > > Moreover, once the cushion is eaten into, all of your explicit memory > allocations should fail until the cushion can be re-inflated to its original > size. This last part is the part that I've always wondered about. The OS doesn't seem to have a nice "more memory is available now" function to match the GZ function. Not that I'd expect one... What would be the best way to alleviate this problem? I can think of most of the obvious solutions, like having my own allocator that checked to see if the buffer had been released, and whether or not it could be reclaimed... ______________________________________________________________ Bretton Wade (bw16@cornell.edu) http://www.graphics.cornell.edu/~bwade/ This is funny. Laugh now. ______________________________________________________________ +++++++++++++++++++++++++++ >From larson@base.cs.ucla.edu (Christopher Larson) Date: 3 Nov 1994 18:13:08 GMT Organization: UCLA, Computer Science Department In article bw16@cornell.edu (Bretton Wade) writes: >In article <1994Nov2.221101.2400@gallant.apple.com>, Jens Alfke > wrote: >> >> [ Stuff about using a grow-zone procedure deleted ] >> >> Moreover, once the cushion is eaten into, all of your explicit memory >> allocations should fail until the cushion can be re-inflated to its original >> size. > >This last part is the part that I've always wondered about. The OS doesn't >seem to have a nice "more memory is available now" function to match the >GZ function. Not that I'd expect one... Maybe I'm misunderstanding your wondering, but that's exactly what a grow-zone procedure is for. A grow-zone procedure is called by the OS when it can't allocate a block of the requested size. The GZProc returns a value telling the OS how much memory it freed (if any) and the memory allocation is re-tried (purging and compacting the heap if necessary). So the return value of the GZProc does tell the OS that "more memory is available now," if it returned non-zero, or "no more memory is available," if it returned zero. >What would be the best way to alleviate this problem? I can think of most >of the obvious solutions, like having my own allocator that checked to see >if the buffer had been released, and whether or not it could be >reclaimed... The procedure outlined in Inside Macintosh: Memory recommends a procedure similar to this. It suggests that custom allocators for both handles and pointers be created which check the status of the buffer (and check to see that the amount of free memory available after the allocation is above a 'cushion' value). If both of these conditions hold, the grow-zone procedure is disabled (as Jens suggests, to make sure the buffer is not used for this allocation), the allocation is made, and the grow-zone procedure re-enabled. IM: Memory also suggests that the place to determine if the buffer can be re-allocated (once freed) is in the event loop of the program. The purpose of the buffer (and the 'cushion' suggested by IM) is to ensure that allocations made by the OS succeed (since parts, if not all, of the OS assumes they will). The custom allocation procedures are not intended to filter OS allocations, only allocations made by the application itself. All of this is explained in detail in Inside Macintosh: Memory. I _highly_ recommend that this chapter be required reading for anyone implementing a Mac application. Not because I think it's the utmost in low-memory handling (although I think it's quite good and I haven't come up with a better one) but because it brings all the relevant issues to light and provides reasonable solutions to low-memory problems. Again, I apologize if I've misunderstood your questions. Hope this helps. --Chris _______________________________________________________________________________ Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious Death to the Trojans! Go Bruins! (Insert disclaimer here) Internet: larson@kingston.cs.ucla.edu +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 4 Nov 1994 14:25:33 GMT Organization: The University of Texas at Austin, Austin, Texas In article , bw16@cornell.edu (Bretton Wade) wrote: < > IM: Memory also suggests that the place to determine if the buffer can < > be re-allocated (once freed) is in the event loop of the program. < > < < This is one of the obvious solutions that I mentioned, and seems less than < optimal. I'll be checking a zillion times a second for a condition that < should probably never happen to most properly functioning < applications?!?!? < < < Bretton < < ______________________________________________________________ < Bretton Wade (bw16@cornell.edu) < http://www.graphics.cornell.edu/~bwade/ < ______________________________________________________________ I don't think that this is a problem. Say your memory buffer is a handle, and that when it is freed you set the variable to NULL. Then do something like this in your event loop: if ( !gMemoryBuffer ) gMemoryBuffer = NewHandle( kMemBuffSize ); I don't think that checking that once through your event loop will take much time at all. If you like you could do it only on null events. -- Brian Stern :-{)} Toolbox commando and Menu bard Jaeger@fquest.com +++++++++++++++++++++++++++ >From larson@base.cs.ucla.edu (Christopher Larson) Date: 7 Nov 1994 20:23:39 GMT Organization: UCLA, Computer Science Department In article bw16@cornell.edu (Bretton Wade) writes: > larson@base.cs.ucla.edu (Chris Larson) writes: >> Maybe I'm misunderstanding your wondering, but that's exactly what a > >Yeah, you misunderstand. I want to know a *GOOD* way to determine when it >is OK to reclaim my emergency buffer. OOPS. Sorry. See below. >> IM: Memory also suggests that the place to determine if the buffer can >> be re-allocated (once freed) is in the event loop of the program. >> > >This is one of the obvious solutions that I mentioned, and seems less than >optimal. I'll be checking a zillion times a second for a condition that >should probably never happen to most properly functioning >applications?!?!? The buffer de-allocation and re-allocation is done either with DisposeHandle/NewHandle or EmptyHandle/ReallocHandle (I forget which and am away from my Mac -- I think it's with the latter, so I'll assume that). After the GZProc calls EmptyHandle, the handle's master pointer will be NULL, so the check in the event loop consists of something like the following: if ( ( gEmergencyMemory == NULL ) || ( *gEmergencyMemory == NULL ) ) { /* Yipes, buffer is free -- do something about it */ } If everything is OK, this consists of two comparisons against zero, one dereference, and a branch. We're talking 5 or 6 instructions here, utterly insignificant when compared with the call to WaitNextEvent. So, yes, this check will run many times a second, but it costs virtually nothing to run in the case that the buffer is intact (which will be the case most of the time, as you point out). It is not _absolutely_ optimal but it won't impact the operation of any real-world application at all. Now for the first part of your question (hopefully I'll answer the right question this time ;-). Once you have determined that the buffer has been de-allocated, the best way to determine if it can be re-allocated is to call ReallocHandle. If this suceedes, continue execution. If you can't get the buffer back, it's time to take drastic actions. Now, I'm sure you knew about ReallocHandle and I think your question is really "How can I tell when the OS is done with the buffer's memory and ReallocHandle() will succeed?" This question is answered by the philosophy behind this entire low-memory scheme. The purpose of the emergency buffer is to provide a last-ditch area for Toolbox calls to use as scratch space. If it is being used in a more permanent fashion, the heap is very close to full. That being the case, anytime the buffer is de-allocated, you should try to reclaim it. If you can't you know your application is seriously low on memory and something extreme needs to be done. Again, this is simply based on the philosophy behind this particular scheme. If you are interested in allowing use of the buffer for more permanent storage, some rethinking of the entire scheme will likely be necessary. Having not done this, I can't offer any experience-based ideas to help. --Chris _______________________________________________________________________________ Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious Death to the Trojans! Go Bruins! (Insert disclaimer here) Internet: larson@kingston.cs.ucla.edu +++++++++++++++++++++++++++ >From Jens Alfke Date: Tue, 8 Nov 1994 00:25:13 GMT Organization: Apple Computer Bretton Wade, bw16@cornell.edu writes: > This is one of the obvious solutions that I mentioned, and seems less than > optimal. I'll be checking a zillion times a second for a condition that > should probably never happen to most properly functioning > applications?!?!? 1. If your event loop runs "a zillion times a second" I don't want to use your app! You should be passing a valid time in the 'sleep' parameter to WNE. 2. You feel that running low on memory is something that will never happen to a properly functioning app? Hmm, I _really_ don't want to run your app now ;-) --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From bw16@cornell.edu (Bretton Wade) Date: Mon, 07 Nov 1994 22:53:52 -0500 Organization: Cornell Program of Computer Graphics In article <1994Nov8.002513.26665@gallant.apple.com>, Jens Alfke wrote: > Bretton Wade, bw16@cornell.edu writes: > > This is one of the obvious solutions that I mentioned, and seems less than > > optimal. I'll be checking a zillion times a second for a condition that > > should probably never happen to most properly functioning > > applications?!?!? > > 1. If your event loop runs "a zillion times a second" I don't want to use > your app! You should be passing a valid time in the 'sleep' parameter to WNE. > > 2. You feel that running low on memory is something that will never happen to > a properly functioning app? Hmm, I _really_ don't want to run your app now ;-) > > --Jens Alfke jens_alfke@powertalk.apple.com > "A man, a plan, a yam, a can of Spam ... Bananama!" Exageration to make a point, I admit. The point seems to have been lost on you, however. =) =) Bretton ______________________________________________________________ Bretton Wade (bw16@cornell.edu) http://www.graphics.cornell.edu/~bwade/ ______________________________________________________________ --------------------------- >From vtourang@chat.carleton.ca (Vince Tourangeau) Subject: Fast Pixel Drawing Date: Fri, 28 Oct 1994 03:21:36 GMT Organization: Carleton University What's the fastest method of writing a pixel to the current CGrafPtr? I'm currently writing my own graphic routines for the game I'm designing - QuickDraw seems way too slow for some things, so I'm trying to optimize all the commands for what I'm doing. Right now, I'm calling SetCPixel to write to the current port. Is there a more direct way of doing this? Come to think of it, how do I write directly to an arbitrary PixMap? Thanks, Vince - -------------------------------------------------------------------- Vince Tourangeau Carleton University _______________________________________________________________ (Insert witty quote above) Email address: vtourang@chat.carleton.ca - -------------------------------------------------------------------- +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 28 Oct 94 01:51:50 MST Organization: (none) In article , vtourang@chat.carleton.ca (Vince Tourangeau) writes: > What's the fastest method of writing a pixel to the current CGrafPtr? > I'm currently writing my own graphic routines for the game I'm > designing - QuickDraw seems way too slow for some things, so I'm > trying to optimize all the commands for what I'm doing. Right now, I'm > calling SetCPixel to write to the current port. Is there a more direct > way of doing this? Come to think of it, how do I write directly to an > arbitrary PixMap? > Thanks, > Vince > "Drawing in GWorlds for Speed and Versatility" in develop 10 and "Writing Directly to the Screen" in develop 11 are good places to start looking. SetCPixel, on a PowerMac, is so slow that I wonder if it is any faster than a Quadra in this case. Lawson +++++++++++++++++++++++++++ >From jmunkki@beta.hut.fi (Juri Munkki) Date: 3 Nov 1994 18:54:51 GMT Organization: Helsinki University of Technology In article <396050$10b@ccnet.ccnet.com> Alex Lelievre writes: >In article Vince Tourangeau, >vtourang@chat.carleton.ca writes: > >>This is all Mac stuff, but any help would be appreciated... >>What's the fastest method of writing a pixel to the current CGrafPtr? >>I'm currently writing my own graphic routines for the game I'm >>designing - QuickDraw seems way too slow for some things, so I'm >>trying to optimize all the commands for what I'm doing. Right now, I'm >>calling SetCPixel to write to the current port. Is there a more direct >>way of doing this? Come to think of it, how do I write directly to an >>arbitrary PixMap? > >All you have to do is insert a pixel value at the right place in memory. >A CGrafPort has a handle to the PortPixMap. This struct has a pointer to >the base address of the actual pixel map. >All you need to do is calculate the rowBytes (which is already done for >you by quickdraw) and index into the pixel map manually. Except that if you are drawing to the screen and the user is in a 24 bit addressing mode, you'll be most probably writing into random memory unless you call SwapMMUMode before and after drawing. You should also call ShieldCursor when you draw to the screen. Offscreen GWorlds can also be stored on video cards and such, so even offscreen devices are not completely safe. Followups to comp.sys.mac.programmer. -- Juri Munkki There ain't no such thing as a shareware lunch. jmunkki@hut.fi Windsurfing: Faster than the wind. +++++++++++++++++++++++++++ >From Dmitry Boldyrev Date: 6 Nov 1994 21:07:30 GMT Organization: University of Utah In article <39bblr$jh1@nntp.hut.fi> Juri Munkki, jmunkki@beta.hut.fi writes: >Except that if you are drawing to the screen and the user is in a 24 bit >addressing mode, you'll be most probably writing into random memory unless >you call SwapMMUMode before and after drawing. You should also call >ShieldCursor when you draw to the screen. Offscreen GWorlds can also >be stored on video cards and such, so even offscreen devices are not >completely safe. > >Followups to comp.sys.mac.programmer. I completely agree with Juri, here is a little (unsafe) fast pixel code I wrote for my molecule designer :-) void FastPixel(ptr baseAddr, ulong rowBytes, short x, short y, byte color) { asm { movem.l d0-d7/a0-a6,-(a7) move.w x,d0 move.w y,d1 move.l baseAddr,a0 move.l rowBytes,d6 mulu.l d6,d1 add.l d1,d0 add.l d0,a0 // a0 = address of the first point to draw move.b color,(a0) movem.l (a7)+,d0-d7/a0-a6 } } --------------------------- >From fixer@faxcsl.dcrt.nih.gov (Chris Driving in the Rain Tate) Subject: GX text problems Date: Wed, 2 Nov 1994 19:03:55 GMT Organization: DCRT, NIH, Bethesda, MD I'm *sure* this is a no-brainer, but I can't seem to figure out what I'm supposed to be doing. GX is *incredibly* cool on first glance, and most things seem perfectly straightforward, but.... I want to draw some text in Geneva Bold. That's it. However, I can't figure out how to specify that font. IM: QDGX Typography says that you should use GXFindFonts() to get a gxFont object that fits your needs. That's cool; I can get "Geneva" by name just fine. However, later on it implies that if you pass the name "Geneva Bold," GX will give you the appropriate flavor of font, and you go from there. Unfortunately, "Geneva Bold" isn't a legitimate font name, apparently. Passing "Geneva" as the name gives me back a gxFont, passing "Geneva Bold" doesn't. :-( *HOW* can I specify that I want to use Geneva Bold? Ah, yes: I've tried associating a style object with the font, after setting the style object to indicate boldness, but I wound up with heavy type fit into the "standard" metrics, which is not what I want. Help! How do you choose a particular font "flavor" programmatically? - ------------------------------------------------------------------ Christopher T{te | "I never thought of surgery as 'editing fixer@faxcsl.dcrt.nih.gov | a person' before...." eWorld: cTate | -- Mark Linton (mhl@icf.hrb.com) +++++++++++++++++++++++++++ >From ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Date: 3 Nov 94 18:11:13 +1300 Organization: University of Waikato, Hamilton, New Zealand In article <1994Nov2.190355.20865@alw.nih.gov>, fixer@faxcsl.dcrt.nih.gov (Chris Driving in the Rain Tate) writes: > > I want to draw some text in Geneva Bold. That's it. However, I can't > figure out how to specify that font. IM: QDGX Typography says that you > should use GXFindFonts() to get a gxFont object that fits your needs. > That's cool; I can get "Geneva" by name just fine. > > However, later on it implies that if you pass the name "Geneva Bold," GX > will give you the appropriate flavor of font, and you go from there. > Unfortunately, "Geneva Bold" isn't a legitimate font name, apparently. > Passing "Geneva" as the name gives me back a gxFont, passing "Geneva Bold" > doesn't. :-( That's probably because there is no such font as Geneva Bold, only Geneva Regular. > *HOW* can I specify that I want to use Geneva Bold? First, the good news: yes, QuickDraw GX is incredibly cool, and lets you do neat stuff without batting an eyelid, that you had to jump through hoops to do with QuickDraw. Now, the not-quite-so-good news: a few things which were very simple in QuickDraw, are a little less simple in GX. In QuickDraw, you only had a limited set of text styles (bold, italic, underline, outline, shadow, condensed, extended): and if you asked for a style for which there was no actual font, QuickDraw would fake it for you automatically. Under GX, the real fonts and the fakes are kept rigidly separate, and there is no automatic crossing between them. To create a bold version of Geneva, you will need to set up a text face structure. > Ah, yes: I've tried associating a style object with the font, after > setting the style object to indicate boldness, but I wound up with > heavy type fit into the "standard" metrics, which is not what I want. Sounds like you've already got part of the text face business sorted out (since I can't remember any other way to add boldness to text). It looks to me like the part you're missing is an appropriate setup for the advanceMapping field, to change the width of the glyphs. Disclaimer: this is getting into parts of GX that I remember reading about in the manuals, but for which I've yet to write any actual code that uses the stuff. Lawrence D'Oliveiro fone: +64-7-856-2889 Computer Services Dept fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00 +++++++++++++++++++++++++++ >From fixer@faxcsl.dcrt.nih.gov (Chris Driving in the Rain Tate) Date: Thu, 3 Nov 1994 14:51:13 GMT Organization: DCRT, NIH, Bethesda, MD ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: >fixer@faxcsl.dcrt.nih.gov (Chris Driving in the Rain Tate) writes: >> >> I want to draw some text in Geneva Bold. That's it. However, I can't >> figure out how to specify that font. IM: QDGX Typography says that you >> should use GXFindFonts() to get a gxFont object that fits your needs. >> That's cool; I can get "Geneva" by name just fine. >> >> However, later on it implies that if you pass the name "Geneva Bold," GX >> will give you the appropriate flavor of font, and you go from there. >> Unfortunately, "Geneva Bold" isn't a legitimate font name, apparently. >> Passing "Geneva" as the name gives me back a gxFont, passing "Geneva Bold" >> doesn't. :-( > >That's probably because there is no such font as Geneva Bold, only Geneva >Regular. The electronic (DocViewer) version of IM: QDGX Typography that's on ETO 15 is bogus in several ways that I've discovered in the last few days. One is that, for example, the code on page 6-26, which is supposed to set up a gxTextFace to indicate bolding, won't even compile as printed: it uses curly quotes instead of flat ones, and it gets confused about whether it ought to be using "face.field" or "face->field" notation in the middle of a function. Also, on page 7-24 (the chapter on fonts), it says that using the gxFullFontName selector for the GXFindFonts() function lets you search for fonts based on "The full font name, such as 'Geneva Bold'." Oops. >> *HOW* can I specify that I want to use Geneva Bold? > > [snip] > >Now, the not-quite-so-good news: a few things which were very simple in >QuickDraw, are a little less simple in GX. In QuickDraw, you only had a limited >set of text styles (bold, italic, underline, outline, shadow, condensed, >extended): and if you asked for a style for which there was no actual font, >QuickDraw would fake it for you automatically. Under GX, the real fonts and >the fakes are kept rigidly separate, and there is no automatic crossing between >them. > >To create a bold version of Geneva, you will need to set up a text face >structure. > >> Ah, yes: I've tried associating a style object with the font, after >> setting the style object to indicate boldness, but I wound up with >> heavy type fit into the "standard" metrics, which is not what I want. > >Sounds like you've already got part of the text face business sorted out >(since I can't remember any other way to add boldness to text). It looks to >me like the part you're missing is an appropriate setup for the advanceMapping >field, to change the width of the glyphs. I eventually decided that I probably *ought* to be doing this, even if it seemed like more work than should have been necessary at the time. I'm glad that I decided on the "right" solution! Originally, I was trying to use the SetCommonFace() routine that's included with the file in the GX stuff on ETO 15; it was giving me more bolding than I wanted, and not setting the advanceMapping attribute (which is indeed what was causing the scrunching that I observed). Eventually I did the following (WORKING code follows): extern gxRectangle gPageSize; // printing page size extern gxViewPort gPrintingViewPort; // port we're printing through gxTextFace boldFace; gxShape aTextShape; gxPoint aPos; // set up the bold text face boldFace.faceLayers = 1; ResetMapping(&(boldFace.advanceMapping)); boldFace.faceLayer[0].outlineFill = gxWindingFill; boldFace.faceLayer[0].flags = 0; boldFace.faceLayer[0].outlineStyle = nil; boldFace.faceLayer[0].outlineTransform = nil; boldFace.faceLayer[0].boldOutset.x = fixed1/48; // gentle boldface boldFace.faceLayer[0].boldOutset.y = 0; // draw the document title against the left margin aTextShape = GXNewText(fileName[0], &(fileName[1]), &aPos); GXSetShapeFace(aTextShape, &boldFace); GXSetShapeTextAttributes(aTextShape, GXGetShapeStyleAttributes(aTextShape) | gxAutoAdvanceText); GXSetShapeFont(aTextShape, myFont); GXSetShapeTextSize(aTextShape, ff(9)); GXMoveShapeTo(aTextShape, gPageSize.left, gPageSize.top + ff(HEADER_LINE)); GXSetShapeViewPorts(aTextShape, 1, &gPrintingViewPort); GXDrawShape(aTextShape); GXDisposeShape(aTextShape); The part that took a little getting-used-to was the concept of a "text face". Once I understood that *that* is the basic mechanism GX uses for most of its real text shape manipulations, including italicising and bolding and whatnot, it was pretty straightforward. Also, GX seems to handle fonts better than Quickdraw did (not that I'm surprised, though!) - my printed output is rather more nicely turned out than the non-GX version, although I'm trying pretty hard to make the "new" output look like the old. In particular, the tracking and kerning of printed output is now much better, even though I'm not using layout shapes! I'm thinking that there should be a section in the FAQ, or perhaps a separate FAQ, on Quickdraw GX. A collection of war stories like mine (and yours, and Michael Pierce's, and... :-) would probably be pretty handy for people who are having to dive headfirst into GX, and are daunted by the sheer volume of documentation - some of which is incorrect or misleading. :-( - ------------------------------------------------------------------ Christopher T{te | "I never thought of surgery as 'editing fixer@faxcsl.dcrt.nih.gov | a person' before...." eWorld: cTate | -- Mark Linton (mhl@icf.hrb.com) +++++++++++++++++++++++++++ >From opstad@apple.com (David Opstad) Date: 6 Nov 1994 22:10:23 -0800 Organization: Apple Computer Inc, Cupertino, CA In article <1994Nov2.190355.20865@alw.nih.gov>, fixer@faxcsl.dcrt.nih.gov (Chris Driving in the Rain Tate) writes: > > I want to draw some text in Geneva Bold. That's it. However, I can't > figure out how to specify that font. IM: QDGX Typography says that you > should use GXFindFonts() to get a gxFont object that fits your needs. > That's cool; I can get "Geneva" by name just fine. > > However, later on it implies that if you pass the name "Geneva Bold," GX > will give you the appropriate flavor of font, and you go from there. > Unfortunately, "Geneva Bold" isn't a legitimate font name, apparently. > Passing "Geneva" as the name gives me back a gxFont, passing "Geneva Bold" > doesn't. :-( All that GXFindFonts does is look for a gxFont object whose name table reports a name matching the criteria you specify. Since no font has a name table that matches "Geneva Bold", the GXFindFonts call can't help. In cases like this, the next step is to use either a variation (if the font supports them; call GXCountFontVariations to see it it does), or to use a textFace (which can be used with any font). There is sample code in the text library (on the SDK CD) that makes it a little easier to construct a text face: void SetStyleCommonFace(gxStyle source, commonFace face); Just pass in the style and a txFace-like constant and you're set. Dave Opstad GX Line Layout Weenie --------------------------- >From tlindner@netcom.com (Tim Lindner) Subject: Macintosh Drag and Drop Date: Mon, 31 Oct 1994 11:44:44 GMT Organization: Computers Suck!, Inc. I am having trouble implementing two things I see other drag-aware applications do: 1: Click-Through How do I keep my application becomming the front most when a user clicks on his selection from different application? The _Human Interface_Guidelines_ calls this supporting click-through and nothing more is said about it. 2: Trash-aware How do I determing when the user dragged his selection in-to the finders trash can? The Note Pad uses this like a "Cut" operation and I would like to do the same. -- tim lindner tlindner@netcom.com +++++++++++++++++++++++++++ >From denboer@cc.umanitoba.ca (David Den Boer) Date: 1 Nov 1994 23:29:58 GMT Organization: The University of Manitoba In tlindner@netcom.com (Tim Lindner) writes: >I am having trouble implementing two things I see other drag-aware >applications do: >2: Trash-aware > How do I determing when the user dragged his selection in-to the >finders trash can? The Note Pad uses this like a "Cut" operation and I >would like to do the same. Check out the source code for DragText, which is included with the Drag Manager's Developers Kit (which I believe is on ftp.apple.com now). In the Drag.c source file is a routine called DropLocationIsFinderTrash which you can pretty much get the whole concept from. If you do not have this code, and cannot find the archive, mail me and I will mail you my modified version of this code. -- David A. denBoer MUSI Computer Products, Inc. denboer@cc.umanitoba.ca Borealis Project Lead +++++++++++++++++++++++++++ >From jumplong@aol.com (Jump Long) Date: 7 Nov 1994 00:03:29 -0500 Organization: America Online, Inc. (1-800-827-6364) In article <396j1m$mp3@canopus.cc.umanitoba.ca>, denboer@cc.umanitoba.ca (David Den Boer) writes: >>2: Trash-aware >> How do I determing when the user dragged his selection in-to the >>finders trash can? The Note Pad uses this like a "Cut" operation and I >>would like to do the same. > >Check out the source code for DragText, which is included with the Drag >Manager's Developers Kit (which I believe is on ftp.apple.com now). In >the Drag.c source file is a routine called DropLocationIsFinderTrash >which you can pretty much get the whole concept from. The routine in DragText unlocks a handle before it is done with it. I've fixed the routine and copied it below - Jim Luther #include #include #include /* ** DropLocationIsFinderTrash returns true if the given ** dropLocation AEDesc is a descriptor of the Finder's Trash. */ Boolean DropLocationIsFinderTrash(AEDesc *dropLocation); Boolean DropLocationIsFinderTrash(AEDesc *dropLocation) { Boolean result; AEDesc dropSpec; FSSpec *theSpec; CInfoPBRec pb; short trashVRefNum; long trashDirID; result = false; /* default to false */ /* Coerce the dropLocation descriptor to an FSSpec. If there's no dropLocation or */ /* it can't be coerced into an FSSpec, then it couldn't have been the Trash. */ if ( (dropLocation->descriptorType != typeNull) && (AECoerceDesc(dropLocation, typeFSS, &dropSpec) == noErr) ) { /* Lock dropSpec.dataHandle while we use it as a pointer */ HLock(dropSpec.dataHandle); theSpec = (FSSpec *) *dropSpec.dataHandle; /* Get the directory ID of the given dropLocation object. */ pb.dirInfo.ioNamePtr = theSpec->name; pb.dirInfo.ioVRefNum = theSpec->vRefNum; pb.dirInfo.ioFDirIndex = 0; pb.dirInfo.ioDrDirID = theSpec->parID; if ( PBGetCatInfoSync(&pb) == noErr ) { /* The drop location must be a directory to be the trash */ if ( (pb.hFileInfo.ioFlAttrib & ioDirMask) != 0 ) { /* Find the trash folder on the drop location's volume. */ if ( FindFolder(theSpec->vRefNum, kTrashFolderType, kCreateFolder, &trashVRefNum, &trashDirID) == noErr ) { /* If the directory ID of the dropLocation object is the same as the */ /* directory ID returned by FindFolder, then the drop must have */ /* occurred into the Trash. */ result = ( pb.dirInfo.ioDrDirID == trashDirID ); } } } /* Unlock and dispose of the descriptor record */ HUnlock(dropSpec.dataHandle); AEDisposeDesc(&dropSpec); } return ( result ); } --------------------------- >From Tim Dorcey Subject: Microseconds() documentation? Date: 31 Oct 1994 22:12:44 GMT Organization: Cornell University Does anyone know where the Microseconds system call is documented? I stumbled upon it in , but can't find mention of it anywhere else. Can I assume it to be available on any machine with the "Revised Time Manager?" I had already written my own timer using PrimeTime/RmvTime but would just as soon use the system call if I can be sure it is as widely applicable. Thanks, Tim Dorcey T.Dorcey@cornell.edu +++++++++++++++++++++++++++ >From rac@intrigue.com (Robert Coie) Date: Mon, 31 Oct 1994 17:30:28 -0800 Organization: Intrigue Corporation In article <393q4s$gu0@newsstand.cit.cornell.edu>, Tim Dorcey wrote: > Does anyone know where the Microseconds system call is documented? I > stumbled upon it in , but can't find mention of it anywhere > else. Can I assume it to be available on any machine with the "Revised > Time Manager?" I had already written my own timer using > PrimeTime/RmvTime but would just as soon use the system call if I can be > sure it is as widely applicable. Thanks, Microseconds has its own trap ($A193), and you can check for its availability using your favorite TrapAvailable() function. I think there's an example in Think Reference. The following is based on my own experience with Microseconds (about 6 months ago, and some of the infomation may be out of date). Your mileage may vary. Why Microseconds Is Not My Favorite Toolbox Routine 1) The System 7.1 stock version of it is not a good neighbor. It stomps on a nonvolatile register (90% sure it was A2). This caused code that worked on Think C to fail when compiled under CodeWarrior (Think wasn't using A2, CodeWarrior used it for the C++ "this" pointer). 2) Under some conditions, Microseconds (stock 7.1) will warp back in time. Successive calls are not guaranteed to return equal or greater values than previous calls. 3) Because of (2), QuickTime patches out Microseconds, so you will need to test your code with and without QuickTime. I fell for this one, because the QuickTime version of Microseconds preserves A2, and all my machines have QuickTime. It was only when I started distributing to beta testers that the bombs began bursting in air. We ended up requiring QuickTime. 4) Trying to eliminate trap dispatcher overhead by jumping directly to the NGetTrapAddress hook will fail unless you are real careful. Even though it is prototyped pascal stack based, it does not follow standard Pascal stack behavior. On exit, A0 is the high word of a 64-bit value, and D0 is the low word. You will need to do your own assembly glue if you want to avoid the trap dispatcher. 5) It is emulated on the PowerPC. (at least under 7.1.2, anybody know about 7.5?) This will cause major performance degradation if you are calling it frequently. I had a program that used Microseconds in a process scheduler, and it ran *slower* on a 6100 (with the app native) than on a Quadra 700. There was a thread on AppleLink late last year sometime about high-resolution timing on the Power Mac, and I don't recall an official recommendation from Apple about what to do. A member of the QuickTime team told me that they use the Microseconds trap for their timing even in the native QT versions: they just make sure to call it very infrequently. Before that conversation occurred, however, I had already made up my mind to get real nonportable and hit up the RTC register on the 601. If anybody is interested, I can post that native Microseconds timer to here and/or alt.sources.mac. Note that I am *not* recommending this option -- the RTCR is clearly documented as "601 only, off-limits, here be dragons". What are other c.s.m.p'ers doing for PowerPC high-resolution timing? -- Robert Coie rac@intrigue.com Implementor, Intrigue Corporation AppleLink: INTRIGUE if intrigue.com bounces, try rac%intrigue.com@internex.net +++++++++++++++++++++++++++ >From resnick@uiuc.edu (Pete Resnick) Date: Tue, 01 Nov 1994 16:05:05 -0600 Organization: University of Illinois at Urbana-Champaign In article <393q4s$gu0@newsstand.cit.cornell.edu>, Tim Dorcey wrote: > Does anyone know where the Microseconds system call is documented? Inside Macintosh: Operating System Utilities. Page 4-49 in the Date, Time, and Measurement Utilities chapter. 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 jim _reekes@quickmail.apple.com (Jim Reekes) Date: Tue, 1 Nov 1994 19:48:29 GMT Organization: Apple Computer, Inc. In article , rac@intrigue.com (Robert Coie) wrote: > In article <393q4s$gu0@newsstand.cit.cornell.edu>, Tim Dorcey > wrote: > > > Does anyone know where the Microseconds system call is documented? I > > stumbled upon it in , but can't find mention of it anywhere > > else. Can I assume it to be available on any machine with the "Revised > > Time Manager?" I had already written my own timer using > > PrimeTime/RmvTime but would just as soon use the system call if I can be > > sure it is as widely applicable. Thanks, > > Microseconds has its own trap ($A193), and you can check for its > availability using your favorite TrapAvailable() function. I think > there's an example in Think Reference. > > The following is based on my own experience with Microseconds (about 6 > months ago, and some of the infomation may be out of date). Your mileage > may vary. > > Why Microseconds Is Not My Favorite Toolbox Routine > > 1) The System 7.1 stock version of it is not a good neighbor. It stomps > on a nonvolatile register (90% sure it was A2). This caused code that > worked on Think C to fail when compiled under CodeWarrior (Think wasn't > using A2, CodeWarrior used it for the C++ "this" pointer). > > 2) Under some conditions, Microseconds (stock 7.1) will warp back in > time. Successive calls are not guaranteed to return equal or greater > values than previous calls. > > 3) Because of (2), QuickTime patches out Microseconds, so you will need to > test your code with and without QuickTime. I fell for this one, because > the QuickTime version of Microseconds preserves A2, and all my machines > have QuickTime. It was only when I started distributing to beta testers > that the bombs began bursting in air. We ended up requiring QuickTime. > > 4) Trying to eliminate trap dispatcher overhead by jumping directly to the > NGetTrapAddress hook will fail unless you are real careful. Even though > it is prototyped pascal stack based, it does not follow standard Pascal > stack behavior. On exit, A0 is the high word of a 64-bit value, and D0 is > the low word. You will need to do your own assembly glue if you want to > avoid the trap dispatcher. > > 5) It is emulated on the PowerPC. (at least under 7.1.2, anybody know > about 7.5?) This will cause major performance degradation if you are > calling it frequently. I had a program that used Microseconds in a > process scheduler, and it ran *slower* on a 6100 (with the app native) > than on a Quadra 700. Add this to the list. You should NOT call this trap at interrupt level. The timer is incremented by a Time Manager task (level 1 interrupt). Therefore, the time does not change during all but a VBL interrupt. - --------------------------------------------------------------------- Jim Reekes, Polterzeitgeist | Macintosh Toolbox Engineering | Sound Manager Expert Apple Computer, Inc. | "All opinions expressed are mine, and do 2 Infinite Loop MS 302-3KS | not necessarily represent those of my Cupertino, CA 95014 | employer, Apple Computer Inc." +++++++++++++++++++++++++++ >From creiman@netcom.com (Charlie Reiman) Date: Mon, 7 Nov 1994 05:46:39 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) resnick@uiuc.edu (Pete Resnick) writes: >In article <393q4s$gu0@newsstand.cit.cornell.edu>, Tim Dorcey > wrote: >> Does anyone know where the Microseconds system call is documented? >Inside Macintosh: Operating System Utilities. Page 4-49 in the Date, Time, >and Measurement Utilities chapter. No one has mentioned the biggest pitfall of Microseconds: It's emulated on a powermac. If you plan to poll this trap, you can expect abyssmal performance from a native application. -- "You can't cancel the project! We already made the T-shirts!" Charlie Reiman creiman@netcom.com --------------------------- >From reed@medicine.wustl.edu (Thomas Reed) Subject: NOTE TO ALL SCREEN SAVER AUTHORS Date: Mon, 07 Nov 1994 11:05:56 -0600 Organization: Washington University (Sorry for shouting... ;-) I'd like to request of all screen saver authors that they start to support at least the SAVR Gestalt. Doing this would increase the possibility of having programs interact with screen savers, which I think is a very good thing. I can understand if folks didn't support the SAVR selector because they didn't know how. So, I've made my SAVR_code source, available at: ftp://thomas_mac.wustl.edu/Public/for_ftp/ ...along with a file, AfterDarkGestalt.h, which supports calling these selectors from a program and stuff like that. With a few modifications, my code could also easily support the SAVC selector, which provides a way for a program to actually control the screen saver. Hopefully, I'll be able to provide a fat version of the code therein soon, but right now, it's just 68K code. If you would like to use this code, feel free. -Thomas ===================================================== Thomas Reed Washington University reed@telesphere.wustl.edu Medical School reed@medicine.wustl.edu Saint Louis, MO - --------------------------------------------------- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain ===================================================== Opinions posted are not the opinions of Wash. U. --------------------------- >From mrogers@well.sf.ca.us (Michael Rogers) Subject: Power Plant Documentation?? Date: 30 Oct 1994 02:42:43 GMT Organization: The Whole Earth 'Lectronic Link, Sausalito, CA Hello, All: I've just got CodeWarrior Gold, and am pretty dismayed at the documentation for PowerPlant. Is "PowerPlant Cookbook" all there is? Because it isn't much... Mike -- Dilbert for President! Dogbert for First Dog! +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Sat, 29 Oct 1994 23:40:13 -0400 Organization: The Pitt, Chemistry In article <38v173$n5v@nkosi.well.com>, mrogers@well.sf.ca.us (Michael Rogers) wrote: > I've just got CodeWarrior Gold, and am pretty dismayed at the > documentation for PowerPlant. Is "PowerPlant Cookbook" all there > is? Because it isn't much... 'Fraid that's it. However, I've heard rumors to the efect that more info on PP will be included on CW 5 or perhaps with the netborne update for PP that's lagging behind the 4.5 release, but expected any day now. No details, no guarantees. Also, I'm told many of the classes are documented at: http://www.iquest.com/~fairgate/cw/pplant.html Internet: nick+@pitt.edu _/ _/ _/ _/_/_/ _/ _/ eWorld: nick _/_/ _/ _/ _/ _/ _/_/_/ CIS: 71232,766 _/ _/_/ _/ _/ _/ _/ http://www.pitt.edu/~nick/ _/ _/ _/ _/_/_/ _/ _/ +++++++++++++++++++++++++++ >From Darrin Cardani Date: Wed, 2 Nov 1994 19:28:13 GMT Organization: AT&T Global Information Solutions, Atlanta >In article nick.c writes: >In article <38v173$n5v@nkosi.well.com>, mrogers@well.sf.ca.us (Michael >Rogers) wrote: >>[...] Is "PowerPlant Cookbook" all there >> is? Because it isn't much... > > > 'Fraid that's it. However, I've heard rumors to the efect that > more info on PP will be included on CW 5 or perhaps with the > netborne update for PP that's lagging behind the 4.5 release, > but expected any day now. > Thank God! I just started trying to write my first program using PowerPlant, and I'm lost! Eagerly awaiting more docs. Darrin +++++++++++++++++++++++++++ >From avirr@well.sf.ca.us (Avi Rappoport) Date: 3 Nov 1994 19:06:21 GMT Organization: Metrowerks, Inc. Darrin Cardani writes: >>In article nick.c >writes: >>In article <38v173$n5v@nkosi.well.com>, mrogers@well.sf.ca.us (Michael >>Rogers) wrote: >>>[...] Is "PowerPlant Cookbook" all there >>> is? Because it isn't much... >> >> >> 'Fraid that's it. However, I've heard rumors to the efect that >> more info on PP will be included on CW 5 or perhaps with the >> netborne update for PP that's lagging behind the 4.5 release, >> but expected any day now. > >Thank God! I just started trying to write my first program using >PowerPlant, and I'm lost! Eagerly awaiting more docs. >Darrin True that there will be more docs on the January CW5 disc, but I doubt that we'll release them before that. Sorry. -- Avi Rappoport AviRr@metrowerks.com User Advocate AviRr@aol.com Online Documentation Lead AviRr@eworld.com Metrowerks, Inc. AviRr@well.sf.ca.us +++++++++++++++++++++++++++ >From mwron@aol.com (MW Ron) Date: 3 Nov 1994 17:24:07 -0500 Organization: America Online, Inc. (1-800-827-6364) In article , Darrin Cardani writes: >>Thank God! I just started trying to write my first program using PowerPlant, and I'm lost! Eagerly awaiting more docs. Darrin, The best method for right now is to just get into one of the samples and play with it. We will have much better documentation with CW 5 with the fast turn around and evolution of PowerPlant, it simply was not practical to write any tutorials or references until now. Ron Liechty MWRon@metrowerks.com Metrowerks Inc. +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Thu, 03 Nov 1994 19:18:51 -0500 Organization: The Pitt, Chemistry In article <39bnu7$qt1@newsbf01.news.aol.com>, mwron@aol.com (MW Ron) wrote: > The best method for right now is to just get into one of the samples > and play with it. We will have much better documentation with CW 5 with > the fast turn around and evolution of PowerPlant, it simply was not > practical to write any tutorials or references until now. Ron: Simple question (I'm trying to figure out PP too :-), what is the purpose of the URegister class? I realize it has something to do with telling PP you've got some custom classes - but I'm unsure of *why* you need to tell PP this. TIA. Internet: nick+@pitt.edu _/ _/ _/ _/_/_/ _/ _/ eWorld: nick _/_/ _/ _/ _/ _/ _/_/_/ CIS: 71232,766 _/ _/_/ _/ _/ _/ _/ http://www.pitt.edu/~nick/ _/ _/ _/ _/_/_/ _/ _/ +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Fri, 04 Nov 1994 13:37:36 +0100 Organization: Royal Institute of Something or other In article , nick+@pitt.edu ( nick.c ) wrote: > Simple question (I'm trying to figure out PP too :-), what is the > purpose of the URegister class? I realize it has something > to do with telling PP you've got some custom classes - but I'm > unsure of *why* you need to tell PP this. TIA. PowerPlant doesn't provide new_by_name() or member() as the TCL does. In order to create classes from a stream though (view resources for example) it has to have SOME way of mapping some kind of name to a newly instantiated object of that class. URegistrar::RegisterClass() simply establishes a mapping from a constant used by the view editor, or your, to a function that instantiates an object of the class associated with that constant. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden CFM 68k - solutions to yesterdays problems, tomorrow! +++++++++++++++++++++++++++ >From spencerl@crl.com (Spencer Low) Date: Fri, 04 Nov 1994 17:02:42 -0800 Organization: LowTek Creations In article , nick+@pitt.edu ( nick.c ) wrote: > Simple question (I'm trying to figure out PP too :-), what is the > purpose of the URegister class? I realize it has something > to do with telling PP you've got some custom classes - but I'm > unsure of *why* you need to tell PP this. TIA. If I remember correctly, the URegister class lets you associate a function with a class so that the class can be instantiated from resources. Like you could associate a function 'CreateMySpecialDialogFromStream' with the type 'MySp' to create a dialog from a resource. Spencer (check out the PowerPlant stuff at http://www.iquest.com/~fairgate) ________________________________________________________________________ Spencer "MaxRAM" Low ------ LowTek Creations ----- spencerl@crl.com +++++++++++++++++++++++++++ >From ghd@aol.com (GHD) Date: 6 Nov 1994 22:35:00 -0500 Organization: America Online, Inc. (1-800-827-6364) In article , nick+@pitt.edu ( nick.c ) writes: > Simple question (I'm trying to figure out PP too :-), what is the > purpose of the URegister class? I realize it has something > to do with telling PP you've got some custom classes - but I'm > unsure of *why* you need to tell PP this. TIA. The URegister class maintains a table of Class ID's and function pointers. This table is used when you create objects from a 'PPob' resource. PP Constructor creates 'PPob' resources for View hierarchies; you can also use Rez and Resorcerer to directly edit 'PPob' resources. Since CW does not have a "new by name" feature (I don't think this feature is in the ANSI C++ draft standard either), you need a way to create an object from an external text description. PowerPlant does this by mapping a Class ID (four-character code) to a pointer to a function that returns an object of that class. You must explicitly provide this association between Class ID and function pointer by calling URegistrar::RegisterClass() for every class whose objects you wish to create from 'PPob' resources. -- Greg Dow -- metrowerks --------------------------- >From d8berber@sisko.sbcc.cc.ca.us () Subject: Shareware successes? Date: 27 Oct 1994 01:24:58 GMT Organization: Santa Barbara City College I'm new to Macintosh programming and I am curious to know whether people who are releasing their software as shareware are making any money. What do you do to 'coax' people into sending in that payment? A stern message in a README file, a serial number scheme, annoying messages that show up when the program is launched or when the user selects About..., software that 'self-destructs' after a certain number of uses or time limit? Share your experiences with the rest of us! +++++++++++++++++++++++++++ >From andrewwelc@aol.com (AndrewWelc) Date: 27 Oct 1994 07:57:06 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <38mvha$2bl@coyote.rain.org>, d8berber@sisko.sbcc.cc.ca.us () writes: > I'm new to Macintosh programming and I am curious to know whether > people who are releasing their software as shareware are making any > money. What do you do to 'coax' people into sending in that payment? > A stern message in a README file, a serial number scheme, annoying > messages that show up when the program is launched or when the user > selects About..., software that 'self-destructs' after a certain > number of uses or time limit? Share your experiences with the rest > of us! While it wouldn't be proper to release sales figues, I can tell you that nothing increases your revenues like releasing a quality product. After that, making it easy for folks to register (credit card orders, 800 number) a registration and reminder system, and providing good support are all factors as well. Cheers, Andrew Welch Ambrosia Software, Inc. +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Fri, 28 Oct 1994 10:51:14 +0800 Organization: NCRPDA, Curtin University In article <38mvha$2bl@coyote.rain.org>, d8berber@sisko.sbcc.cc.ca.us wrote: >I'm new to Macintosh programming and I am curious to know whether people >who are releasing their software as shareware are making any money. What Yes. I am (reasonable amounts anyway :-), and I presume Aladdin and Ambrosia are, and there are certainly others. >do you do to 'coax' people into sending in that payment? Write good software and make it easy to pay for. I use a checkbox in the prefs window "I Paid", and change an about box strings from "Please Register" to "Thanks for Registering" and stop the non-modal about box from apearing at startup. Aladdin and Ambrosia use a serial number scheme. Aladdin unlocks extra features, I don't think Ambrosia do anything. Enjoy, Peter. -- Peter N Lewis - Macintosh TCP fingerpainter FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/ +++++++++++++++++++++++++++ >From Kevin.R.Boyce@gsfc.nasa.gov (Kevin R. Boyce) Date: Fri, 28 Oct 1994 13:09:49 -0400 Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA In article , peter.lewis@info.curtin.edu.au (Peter N Lewis) wrote: >In article <38mvha$2bl@coyote.rain.org>, d8berber@sisko.sbcc.cc.ca.us wrote: > >>I'm new to Macintosh programming and I am curious to know whether people >>who are releasing their software as shareware are making any money. What > >Yes. I am (reasonable amounts anyway :-), and I presume Aladdin and >Ambrosia are, and there are certainly others. > >>do you do to 'coax' people into sending in that payment? > >Write good software and make it easy to pay for. > >I use a checkbox in the prefs window "I Paid", and change an about box >strings from "Please Register" to "Thanks for Registering" and stop the >non-modal about box from apearing at startup. Peter, I wonder whether you forgot a very important thing: invent a price for site licenses, and put it in your documentation. You could say better than anyone else what fraction of your money comes from site licenses, but I suspect it's nontrivial. I know that we at Goddard now have licenses for Network Time, Fetch, MacHTTP, and something else I've forgotten, and there's a big P.O. heading toward Oz now. And I bet in every case the site license was substantially more money than the total of users on site who would have registered. So can I check the "I paid" box now, or do I have to wait until you get the PO and send it back, and purchasing cuts your check? :-) -- Kevin Kevin.R.Boyce@gsfc.nasa.gov Hope that the music turns you On like it's turning on me. --Hatfield and the North +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Mon, 31 Oct 1994 11:02:39 +0800 Organization: Department of Computer Science, The University of Western Australia In article , Kevin.R.Boyce@gsfc.nasa.gov (Kevin R. Boyce) wrote: >So can I check the "I paid" box now, or do I have to wait until you get >the PO and send it back, and purchasing cuts your check? :-) My policy on this is that if I've paid, I will check the "I Paid" box. If the money doesn't make it to the author, that's tough on them. They should've support VISA registration. Share and Enjoy. -- Quinn "The Eskimo!" "I wasn't the one who fired the heat seeking population annihilator out the window!" And I have the hacking skill to support my policy (: +++++++++++++++++++++++++++ >From lamcw@aston.ac.uk (CW LAM) Date: Mon, 31 Oct 1994 12:13:48 GMT Organization: Aston University 'd8berber@sisko.sbcc.cc.ca.us' wrote: ;I'm new to Macintosh programming and I am curious to know whether people ;who are releasing their software as shareware are making any money. What ;do you do to 'coax' people into sending in that payment? A stern message in ;a README file, a serial number scheme, annoying messages that show up when ;the program is launched or when the user selects About..., software that ;'self-destructs' after a certain number of uses or time limit? Share your ;experiences with the rest of us! the best way is to produce something that's useful in the first place. then if you really want to squeeze blood out a stone, chop out half the features, stating that they only get them when they register. some people may then bother to register, most won't. promises of enhanced versions and full documentation may also help. i may be wrong but my guess is that most freeware/shareware stuff is written first for personal use and then made available to the public. i've heard some people say they have around a 1000 registered users. well at $10 a time, it doesn't take a calculator to work out the net profit. chris lam, aston university, u.k. +++++++++++++++++++++++++++ >From jbeeghly@u.washington.edu (Jeff Beeghly) Date: 31 Oct 1994 18:19:16 GMT Organization: University of Washington quinn@cs.uwa.edu.au (Quinn "The Eskimo!") writes: >My policy on this is that if I've paid, I will check the "I Paid" box. If >the money doesn't make it to the author, that's tough on them. They >should've support VISA registration. >Share and Enjoy. >-- >Quinn "The Eskimo!" "I wasn't the one who fired the heat seeking Have you ever looked into getting a VISA (no, not the kind where you can PURCHASE goods from, but the kind where you get money)? I agree, VISA is very easy on the register, and ideally, I'd like to support VISA as well. The problem: $$$. Not only does it take a lot of money to get a VISA account set up, but there is a "minimum" monthly charge (which is quite a bit) and you need to guarente VISA that you will have at least X amount of business each month. If you are a small shareware author, VISA is not feasible. The worst part about it though is that without VISA, it makes internalional payments VERY difficult. +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Mon, 31 Oct 1994 21:15:25 +0100 Organization: Royal Institute of Something or other In article , quinn@cs.uwa.edu.au (Quinn "The Eskimo!") wrote: >My policy on this is that if I've paid, I will check the "I Paid" box. If >the money doesn't make it to the author, that's tough on them. They >should've support VISA registration. NetCash. info@agents.com. 'nuff said :-) Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Technology is not the problem; therefore, abondoning technology is not the answer. +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Mon, 31 Oct 1994 17:02:05 -0500 Organization: The Pitt, Chemistry In article , h+@nada.kth.se (Jon W{tte) wrote: > > NetCash. info@agents.com. 'nuff said :-) > Don't those guys charge something like 20% to buy net cash? Doesn't seem like a reasonable option to me (yet). Internet: nick+@pitt.edu _/ _/ _/ _/_/_/ _/ _/ eWorld: nick _/_/ _/ _/ _/ _/ _/_/_/ CIS: 71232,766 _/ _/_/ _/ _/ _/ _/ http://www.pitt.edu/~nick/ _/ _/ _/ _/_/_/ _/ _/ +++++++++++++++++++++++++++ >From edw@distant.com (Ed Watkeys) Date: Mon, 31 Oct 1994 19:08:19 -0500 Organization: 35th and Baring In article , nick+@pitt.edu ( nick.c ) wrote: > In article , h+@nada.kth.se (Jon > W{tte) wrote: > > > > > NetCash. info@agents.com. 'nuff said :-) > > > > Don't those guys charge something like 20% to buy net cash? > Doesn't seem like a reasonable option to me (yet). They have a new kind of currency, NetCash $US, and there's a 2% fee to get it, and a 2% fee to cash it. It's a pretty good system, IMHO. A lot better than sending junk in envelopes via snail mail. Read the info -- there's little reason to not support it. Ed -- Ed Watkeys edw@infonautics.com Infonautics Corp. Nihilist-Software Engineer edw@eworld.com eWorld/NewtonMail Infonautics Corporation edw@distant.com 35th and Baring +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Tue, 01 Nov 1994 10:05:00 +0800 Organization: Department of Computer Science, The University of Western Australia In article <393cf4$f3@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: >Have you ever looked into getting a VISA? Yeah, I know exactly how painful it is, Peter Lewis moans about it quite literally every day. It's not the point though. If you want to be a successful shareware author then credit card registration is a starting point IMHO. Otherwise you're ignoring at least 50% of your market ('cause 50% of Macs are sold outside the US) and probably a lot more ('cause more people are going to register if they can do it via Email). Share and Enjoy. -- Quinn "The Eskimo!" Pez: "What's with all the happy sounds?" Giggywig: "They're giddy with fear!" +++++++++++++++++++++++++++ >From greeny@lanl.gov (J. S. Greenfield) Date: 1 Nov 1994 03:20:21 GMT Organization: Los Alamos National Laboratory In article h+@nada.kth.se (Jon W{tte) writes: >>My policy on this is that if I've paid, I will check the "I Paid" box. If >>the money doesn't make it to the author, that's tough on them. They >>should've support VISA registration. > >NetCash. info@agents.com. 'nuff said :-) Horrendously insecure. NetThief steals your NetCash. 'nuff said. :( -- J. S. Greenfield greeny@thelair.zynet.com (So what were you expecting? A Gorilla?!) "What's the difference between an orange?" +++++++++++++++++++++++++++ >From greeny@lanl.gov (J. S. Greenfield) Date: 1 Nov 1994 03:25:36 GMT Organization: Los Alamos National Laboratory In article edw@distant.com (Ed Watkeys) writes: >> > NetCash. info@agents.com. 'nuff said :-) >> > >> >> Don't those guys charge something like 20% to buy net cash? >> Doesn't seem like a reasonable option to me (yet). > >They have a new kind of currency, NetCash $US, and there's a 2% fee to get >it, and a 2% fee to cash it. It's a pretty good system, IMHO. A lot better >than sending junk in envelopes via snail mail. Read the info -- there's >little reason to not support it. Actually, there's a very big reason not to support it--it is terribly insecure. No doubt, the time is right for NetCash. Unfortunately, Software Agents decided to give it a go before they had worked out a viable plan for insuring the integrity of the system. -- J. S. Greenfield greeny@thelair.zynet.com (So what were you expecting? A Gorilla?!) "What's the difference between an orange?" +++++++++++++++++++++++++++ >From andrewwelc@aol.com (AndrewWelc) Date: 1 Nov 1994 01:18:08 -0500 Organization: America Online, Inc. (1-800-827-6364) In article <393cf4$f3@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) writes: > I agree, VISA is very easy on the register, and ideally, I'd like > to support VISA as well. The problem: $$$. Not only does it take > a lot of money to get a VISA account set up, but there is a > "minimum" monthly charge (which is quite a bit) and you need to > guarente VISA that you will have at least X amount of business each > month. If you are a small shareware author, VISA is not feasible. > The worst part about it though is that without VISA, it makes > internalional payments VERY difficult. Actually it doesn't cost money to get a Visa/MasterCard merchant account setup -- it cost us a small application fee. Also we have no monthly minimum, and we only pay a rental charge on the unit we use, plus a small percentage of sales. The biggest problem is getting a bank to even talk to you about setting up a merchant account. The vast majority of banks won't even talk to you if you're doing a mail order business -- which is what you are doing. So then you're forced to go with a provider, who lets you use their merchant account. This is of course more costly, but it is the only alternative if you can't get a merchant number. Cheers, Andrew Welch Ambrosia Software, Inc. +++++++++++++++++++++++++++ >From gasser@masg1.epfl.ch (Laurent Gasser) Date: 1 Nov 1994 14:04:03 GMT Organization: Ecole Polytechnique Federale de Lausanne Many have reported difficulties to be accepted as VISA individual debitors. That's one touchy subject about shareware: getting the money to the author, not to the bank making the transaction. In article , quinn@cs.uwa.edu.au (Quinn "The Eskimo!") writes: |> My policy on this is that if I've paid, I will check the "I Paid" box. If |> the money doesn't make it to the author, that's tough on them. They |> should've support VISA registration. |> |> Share and Enjoy. |> -- |> Quinn "The Eskimo!" "I wasn't the one who fired the heat seeking |> population annihilator out the window!" |> And I have the hacking skill to support my policy (: -- Laurent Gasser (gasser@dma.epfl.ch) Computers do not solve problems, they execute solutions. I know very few ideas worth dying for, none is worth killing. +++++++++++++++++++++++++++ >From mat@idm.com (Mark A Thalman) Date: Tue, 1 Nov 1994 13:49:04 GMT Organization: Information Data Management AndrewWelc (andrewwelc@aol.com) wrote: [Snip] > ...nothing increases your revenues like releasing a quality product. He should know about releasing a quality product. I'm a dedicated Maelstrom addict. > After that, making it easy for folks to register (credit card orders, 800 > number) a registration and reminder system, and providing good support are ^^^^^^^^^^^^^^^ Unfortunately, Maelstrom's doesn't go away when you send in your fee, but at least I don't have to press buttons that change their meaning at random (are you listening Aladdin?). -- Mark Thalman;mat@idm.com;mat@mcs.com/*clever quote provided by "fortune"*/ Beware of low-flying butterflies. +++++++++++++++++++++++++++ >From mspace@netcom.com (Brian Hall) Date: Tue, 1 Nov 1994 21:10:20 GMT Organization: Mark/Space Softworks andrewwelc@aol.com (AndrewWelc) writes: >In article <393cf4$f3@nntp1.u.washington.edu>, jbeeghly@u.washington.edu >(Jeff Beeghly) writes: >> I agree, VISA is very easy on the register, and ideally, I'd like >> to support VISA as well. The problem: $$$. Not only does it take >> a lot of money to get a VISA account set up, but there is a >> "minimum" monthly charge (which is quite a bit) and you need to >> guarente VISA that you will have at least X amount of business each >> month. If you are a small shareware author, VISA is not feasible. >> The worst part about it though is that without VISA, it makes >> internalional payments VERY difficult. >Actually it doesn't cost money to get a Visa/MasterCard merchant account >setup -- it cost us a small application fee. Also we have no monthly >minimum, and we only pay a rental charge on the unit we use, plus a small >percentage of sales. >The biggest problem is getting a bank to even talk to you about setting up >a merchant account. The vast majority of banks won't even talk to you if >you're doing a mail order business -- which is what you are doing. >So then you're forced to go with a provider, who lets you use their >merchant account. This is of course more costly, but it is the only >alternative if you can't get a merchant number. Most prviders also handle shipping, which is handy. Shareware folks can get merchant visa accounts from several sources. Check out the various BBS magazines (CONNECT, BBS Caller Digest, Boardwatch, etc) for ads. -- __________________________________________________________________________ Brian Hall, Mark/Space Softworks Internet: mspace@netcom.com Communicate, PageNOW!, CTB Tools AppleLink, AOL: MARKSPACE Macintosh connectivity software. Goodies at ftp.netcom.com in pub/mspace +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Wed, 02 Nov 1994 00:05:48 +0100 Organization: Royal Institute of Something or other In article <394c5l$7au@newshost.lanl.gov>, greeny@lanl.gov (J. S. Greenfield) wrote: >Horrendously insecure. NetThief steals your NetCash. 'nuff said. :( Tell me more? As far as I know, the only way of stealing NetCash would be to have access to the raw network packets, AND filter through each and every one. That's of course doable, but anyone doing it on a larger scale would be found out. However, if you use encrypted mail (like with PGP) this isn't a problem at all. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden "After I first used the Mac, I had a dream in which I would walk up to people, touch them, and they'd turn black. Then I could talk to them." -- Anon +++++++++++++++++++++++++++ >From Grant Hulbert Date: 2 Nov 1994 03:47:17 GMT Organization: GUI Dude Software In article <394mj0$hq9@newsbf01.news.aol.com> AndrewWelc, andrewwelc@aol.com writes: >The biggest problem is getting a bank to even talk to you about setting up >a merchant account. The vast majority of banks won't even talk to you if >you're doing a mail order business -- which is what you are doing. Call David Jones at TeleFlora: 800-325-4849 x2076 direct: 303-750-7958 BBS: 303-750-8198 david.jones@hotelnet.com Believe it or not, TeleFlora (the people who do florist's VISA accounts) has a special shareware author's account. I called David and was set up immediately for very little cash (no minimums). I get money from people in other countries all the time. It's great! They understand shareware and mail-order. --Grant Hulbert guidude@netcom.com +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Wed, 02 Nov 1994 11:40:17 +0800 Organization: NCRPDA, Curtin University In article <393cf4$f3@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: >Have you ever looked into getting a VISA (no, not the kind where you can >PURCHASE goods from, but the kind where you get money)? I agree, VISA is >very easy on the register, and ideally, I'd like to support VISA as >well. The problem: $$$. Not only does it take a lot of money to get a >VISA account set up, but there is a "minimum" monthly charge (which is Yes, believe me I've looked. I finally found Kee Nethery who has set up a shareware registration system that is reasonably priced (4%-10% depending on the payment method (checks, cash, American Express, VISA, MasterCard or NetCash US$ (original NetCash $ cost 20%, so they are pretty hideous to process, but the new ones aren't bad)). I've been using the system with Kee for the last two months while we sorted out the kinks, and it's worked very well. Kee also has a permanent PO box so your address wont change, and can reflect Email (eg peter@kagi.com is now my standard address) so your Email address wont change, and accepts registrations via Email, FAX or snail-mail. Anyway, contact Kee for more information. Note: I may end up having a small share of this system so I am not entirely unbiased, but I would be using it and recomending it anyway - does anyone think that VISA cards registrations wont increase your payments by 10%? or that having a nice "company" fronting you wont smooth those anoying government/university/company people who don't like making checks out to individuals (or sending them to strange Australians who for some weird reason don't have a US SSN or tax number...). For myself, just having someone else deal with mailed registrations is worth 5% (although my dad is really upset that his stamp collect Note2: This is not "enough". Nothing will turn you from unsuccessful to successful except writing a decent program that people are actually going to use. So if you've got $20 worth of payments so far, it's unlikely this (or anything else) will bring you thousands of dollars... Peter. -- Peter N Lewis - Macintosh TCP fingerpainter FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/ +++++++++++++++++++++++++++ >From Andrew Barry Date: Wed, 2 Nov 1994 09:02:57 GMT Organization: Grishnakh In article CW LAM, lamcw@aston.ac.uk writes: >;I'm new to Macintosh programming and I am curious to know whether people >;who are releasing their software as shareware are making any money. What >;do you do to 'coax' people into sending in that payment? A stern message in >;a README file, a serial number scheme, annoying messages that show up when >;the program is launched or when the user selects About..., software that >;'self-destructs' after a certain number of uses or time limit? Share your >;experiences with the rest of us! In Prince of Destruction we decided to limit the game through a number of mechanisms: - Limit areas of the game that can be accessed - Limit 'power' level that player can reach - Shutdown game after an hour - Limit ability to load and save games We're currently picking up about 10 registrations a week - who knows how long this will continue.... I must admit that I have a fairly low regard for the 'honour' system. It's sad, I know. +++++++++++++++++++++++++++ >From kee@kagi.com (Kee Nethery (+1 510 843 6140)) Date: Wed, 2 Nov 1994 19:17:45 GMT Organization: Kagi Engineering Figured I should say hello since I am acting as a shareware registration service. Like Peter Lewis mentioned earlier, I accept; Visa, MC, AmExp, US$checks, cash (from just about any country in the world), and NetCash. I accept payment via; email, fax, postal. I do invoicing when required by the payee and I provide paper receipts when required by the payee. I provide email receipts for each payee (a copy to the author also) and in the process send them the author's blurb describing their other products and how to obtain them, etc. I offer permanent postal, fax and email addresses so that if you move, payments still make it to you. There is a Mac shareware registration program that I provide that is included in the fee that I charge. It preprocesses the payment information to allow me to keep costs low. There is a Newton shareware registration application being developed and I'm looking for someone to develop PC and Unix versions. I will soon be providing database type detailed summaries detailing payee information in an electronic format (working out the desired outputs right now). I'd say that half of the payments these days are electronic and half are postal. As an FYI, my merchant account for Visa and MC has a minimum monthly charge and a several hundred dollar setup fee and like someone else mentioned, getting a mail order merchant account is not easy. Fortunately, I knew my banker and was able to convince him to take the risk and to help me get a merchant account. If you have questions, feel free to drop me a line. Kee Nethery kee@kagi.com +++++++++++++++++++++++++++ >From gotow@ansoft.com (Jon Gotow) Date: Thu, 3 Nov 1994 03:25:23 GMT Organization: Ansoft Corporation In article <394mj0$hq9@newsbf01.news.aol.com> andrewwelc@aol.com (AndrewWelc) writes: > Actually it doesn't cost money to get a Visa/MasterCard merchant account > setup -- it cost us a small application fee. Also we have no monthly > minimum, and we only pay a rental charge on the unit we use, plus a small > percentage of sales. > > The biggest problem is getting a bank to even talk to you about setting up > a merchant account. The vast majority of banks won't even talk to you if > you're doing a mail order business -- which is what you are doing. > > So then you're forced to go with a provider, who lets you use their > merchant account. This is of course more costly, but it is the only > alternative if you can't get a merchant number. We just set up a merchant account, and found that the small community banks were reasonably open-minded. After the president of our local bank finished chuckling at the notion of shareware, he was very receptive. One of the big problems with mail order is the high rate of charge-backs (ie. returns). All I had to do was explain that the stuff is distributed on a try-before-you-buy honor system in the first place, and then they stopped worrying. Who's going to voluntarily pay for something they already have, then return the software for a refund? If you can get the banker to listen, it makes a whole lot of sense - there's really very little risk at all for them in handling your credit card transactions. _____________________________________________________________________ Jon Gotow | In this world there are only two tragedies. gotow@ansoft.com | One is not getting what one wants, and the | other is getting it. - Oscar Wilde +++++++++++++++++++++++++++ >From jbobier@cybernetics.net (Jason Bobier) Date: Mon, 31 Oct 1994 20:17:22 -0500 Organization: Prismatix Software In article <393cf4$f3@nntp1.u.washington.edu>, jbeeghly@u.washington.edu (Jeff Beeghly) wrote: > Have you ever looked into getting a VISA (no, not the kind where you can > PURCHASE goods from, but the kind where you get money)? I agree, VISA is > very easy on the register, and ideally, I'd like to support VISA as > well. The problem: $$$. Not only does it take a lot of money to get a > VISA account set up, but there is a "minimum" monthly charge (which is > quite a bit) and you need to guarente VISA that you will have at least > X amount of business each month. If you are a small shareware author, > VISA is not feasible. The worst part about it though is that without > VISA, it makes internalional payments VERY difficult. This is not necessarily true. It completely depends upon the bank that is issuing the VISA account to you. Just like when you get a VISA card, the bank determines many of the variables. Moral of the story: Credit Unions are cool... Jason _____________________________________________________________________ Jason A. Bobier Prismatix Software Email: jbobier@cybernetics.net "Living is easy with eyes closed..." - The Beatles +++++++++++++++++++++++++++ >From andrewwelc@aol.com (AndrewWelc) Date: 3 Nov 1994 22:07:39 -0500 Organization: America Online, Inc. (1-800-827-6364) In article <397245$flv@coyote.csusm.edu>, Grant Hulbert writes: > Believe it or not, TeleFlora (the people who do florist's VISA > accounts) has a special shareware author's account. I called David > and was set up immediately for very little cash (no minimums). I > get money from people in other countries all the time. It's great! > They understand shareware and mail-order. Yes, but you've made my point. By going through TeleFlora you are going through a middleman to a bank, which of course means that everyone wants a cut along the way, and you end up paying pretty unreasonable rates. We managed to get ours through a bank (so we actually have a merchant number) but I'd consider ourselves extremely lucky, especially after hearing the experiences of a number of other folks who have attempted this. Regards, Andrew Welch Ambrosia Software, Inc. +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Fri, 4 Nov 94 09:09:09 GMT Organization: Network Analysis Ltd In article <395hsj$959@info.epfl.ch> (comp.sys.mac.programmer), gasser@masg1.epfl.ch (Laurent Gasser) writes: > Many have reported difficulties to be accepted as VISA individual > debitors. Doesn't surprise me: the banks are wary of "businesses" who set up shop, take credit card orders, and then do a moonlight flit, leaving the bank to refund the poor punters when they realize that the goods were never going to arrive. We had to provide 2 trade refs, a bank ref, 3 years audited accounts, and they visited our premises. It's hard on individual shareware authors, but the banks would be negligent if they didn't make any effort to check that they weren't throwing their customer's money away. And if you are a merchant account holder, beware of people approaching you to process credit card transactions on their behalf. If they do a runner, you will be left with the "chargeback". There's a scam currently going the rounds... Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UK Internet: sw@network-analysis-ltd.co.uk uucp: ...!uknet!nan!sw AppleLink: NAN.LTD Phone: (+44) 203 419996 Mobile:(+44) 850 587411 Fax: (+44) 203 690690 +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Sat, 05 Nov 1994 16:28:35 +0800 Organization: NCRPDA, Curtin University In article <39c8hr$t2s@newsbf01.news.aol.com>, andrewwelc@aol.com (AndrewWelc) wrote: >> Believe it or not, TeleFlora (the people who do florist's VISA >> accounts) has a special shareware author's account. I called David >> and was set up immediately for very little cash (no minimums). I >> get money from people in other countries all the time. It's great! >> They understand shareware and mail-order. > >Yes, but you've made my point. By going through TeleFlora you are going >through a middleman to a bank, which of course means that everyone wants a >cut along the way, and you end up paying pretty unreasonable rates. Well, that's true. My solution (since there is no way I could get a VISA merchant account to opperate in US dollars here (the *only* people who can do that are the airlines, and I'm a bit short of cash to start up an airline :-)) was to go thru Kee Nethery . True, it costs 4 or 5% more than direct to the bank, but he also does all the processing (and since I have a stack of letters from older versions that I have to process once I finish reading news, his service looks even better - I'll be happy when all my customers (except Australian ones) go thru him). Plus there is no monthly fees so there isn't any real disinsentive unless you believe that credit cards wont increase your sales by 10% (I should have some hard figures in the near future, although it's confounded by new releases and the ever increasing Internet usership). Enjoy, Peter. -- Peter N Lewis - Macintosh TCP fingerpainter FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/ +++++++++++++++++++++++++++ >From mpeirce@outpost.peircesw.com (Michael Peirce) Date: Sat, 5 Nov 94 18:21:43 PT Organization: Peirce Software, Inc. In article <39c8hr$t2s@newsbf01.news.aol.com> (comp.sys.mac.programmer), andrewwelc@aol.com (AndrewWelc) writes: > In article <397245$flv@coyote.csusm.edu>, Grant Hulbert > writes: > > > Believe it or not, TeleFlora (the people who do florist's VISA > > accounts) has a special shareware author's account. I called David > > and was set up immediately for very little cash (no minimums). I > > get money from people in other countries all the time. It's great! > > They understand shareware and mail-order. > > Yes, but you've made my point. By going through TeleFlora you are going > through a middleman to a bank, which of course means that everyone wants a > cut along the way, and you end up paying pretty unreasonable rates. > > We managed to get ours through a bank (so we actually have a merchant > number) but I'd consider ourselves extremely lucky, especially after > hearing the experiences of a number of other folks who have attempted > this. Peirce Software is setup through Teleflora (Visa/MC/AmEx). I switched from a bank provided account to them because they offered better rates and lower fees than I could get almost anywhere else. Their tech support is excellent (I once had to reprogram my cc terminal from a hotel room before a MacWorld Expo and they had folks answering the phone at 10:30 PM). They also have about as clear a set of user guides and such as I have seen. I highly recommend them. __ Michael Peirce __ mpeirce@peircesw.com <- New ADDRESS! __ 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 & AOL: peirce +++++++++++++++++++++++++++ >From greeny@lanl.gov (J. S. Greenfield) Date: 7 Nov 1994 19:41:00 GMT Organization: Los Alamos National Laboratory In article h+@nada.kth.se (Jon W{tte) writes: >>Horrendously insecure. NetThief steals your NetCash. 'nuff said. :( > >Tell me more? > >As far as I know, the only way of stealing NetCash would be to >have access to the raw network packets, AND filter through each >and every one. That's of course doable, but anyone doing it on >a larger scale would be found out. Well, that's certainly *a* way, and as you say is doable. Of course, one can also use any variety of trojan horse schemes to access only email, and one can direct his efforts toward particular sites that have significant numbers of NetCash transactions going on. As for catching folks--I have very little confidence in this. If you consider how easy it is to be anonymous on the net, and if you consider that Software Agents hasn't set up a system for dealing with such matters. It's quite believable that an individual could steal a significant amount of NetCash and either cash it out or pass it on before the principals involved are even aware that mail didn't make it through. The phone companies and law enforcement have a terrible time trying to shut down fly-by-night boiler room operations that set up to con people out of their money. This is an old and well-known paradigm for fraud. What makes you think that one company that has just entered the net-cash business and which has provided no security mechanism (other than some limited protection against simple guessing attacks) is prepared to take action against fraud? And even if it were true that only small scale theft could succeed, so what? It certainly wouldn't make it acceptable to me, considering that they have made essentially no effort to protect against such fraud. >However, if you use encrypted mail (like with PGP) this isn't a >problem at all. This is not an adequate solution. First of all, the vast majority of netters do *not* encrypt their email. It makes little sense to count upon encrypted mail as a security tool when most people won't use it. Perhaps more importantly, this is the wrong way to approach things. Requiring that users be responsible for all security is not an acceptable solution for system security problems. It's akin to a bank saying "Sure, we'll give you a safety deposit box, but it will be a box accessible to the public. If you want to put a lock on the box, you're welcome to do that. However, the box isn't nailed down, and we accept no responsibility should your box be stolen." I have, however, just returned from the ACM conference on Computer and Communication Security, and I'm glad to report that there are other entities (ranging from the major credit card companies to a new company call CyberCash to academic researchers) that are working on the development of network payment mechanisms. Fortunately, these companies seem to be seriously concerned by the security issues, and are actively working on the development of systems in which security is an integral part of the design. -- J. S. Greenfield greeny@thelair.zynet.com (So what were you expecting? A Gorilla?!) "What's the difference between an orange?" --------------------------- End of C.S.M.P. Digest **********************