Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-070

Internet Message Format | 1995-06-07 | 102.9 KB | [TEXT/R*ch]

From: [e-mail] (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
([e-mail]).

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 [e-mail] 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 [e-mail]
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
[e-mail]. 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 [e-mail] (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

[e-mail]

later
--
* Joseph A. Bell (NOT Ritchie Brock)               *
* Northern Telecom / Bell-Northern Research           *
* Email:  [e-mail]                   *

+++++++++++++++++++++++++++

>From [e-mail] (Bob Bradley)
Date: Mon, 07 Nov 1994 17:30:18 -0800
Organization: SS Software Inc.

In article <39lndo$[e-mail]>, [e-mail] (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 [e-mail] (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
 [e-mail]                             Concordia University
 http://www.ece.concordia.ca/~ikb_macd/addr.html       Montreal, QC, Canada

+++++++++++++++++++++++++++

>From [e-mail] (Jeff Beeghly)
Date: 2 Nov 1994 02:55:34 GMT
Organization: University of Washington

[e-mail] (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 [e-mail] (mark)
Date: 2 Nov 94 10:50:28 EST
Organization: HRB Systems, Inc.

In article <396i5c$[e-mail]>,
    [e-mail] (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 [e-mail] (Christopher Larson)
Date: 2 Nov 1994 17:56:37 GMT
Organization: UCLA, Computer Science Department

In article <1994Nov2.105028.22266@hrbicf> [e-mail] (mark) writes:
>In article <396i5c$[e-mail]>,
>    [e-mail] (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: [e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 2 Nov 1994 22:11:01 GMT
Organization: Apple Computer

mark, [e-mail] 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                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Bretton Wade)
Date: Wed, 02 Nov 1994 19:39:28 -0500
Organization: Cornell Program of Computer Graphics

In article <[e-mail]>, Jens Alfke
<[e-mail]> 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 ([e-mail])
   http://www.graphics.cornell.edu/~bwade/

   This is funny. Laugh now.
______________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 3 Nov 1994 18:13:08 GMT
Organization: UCLA, Computer Science Department

In article <bw16-0211941939280001@132.236.236.79> [e-mail] (Bretton Wade) writes:
>In article <[e-mail]>, Jens Alfke
><[e-mail]> 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: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 4 Nov 1994 14:25:33 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <bw16-0411940015080001@132.236.236.53>, [e-mail]
(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 ([e-mail])
<    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
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 7 Nov 1994 20:23:39 GMT
Organization: UCLA, Computer Science Department

In article <bw16-0411940015080001@132.236.236.53> [e-mail] (Bretton Wade) writes:
> [e-mail] (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: [e-mail]

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Tue, 8 Nov 1994 00:25:13 GMT
Organization: Apple Computer

Bretton Wade, [e-mail] 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                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Bretton Wade)
Date: Mon, 07 Nov 1994 22:53:52 -0500
Organization: Cornell Program of Computer Graphics

In article <[e-mail]>, Jens Alfke
<[e-mail]> wrote:

> Bretton Wade, [e-mail] 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                           [e-mail]
>                    "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 ([e-mail])
   http://www.graphics.cornell.edu/~bwade/
______________________________________________________________

---------------------------

>From [e-mail] (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: [e-mail]
- --------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail]
Date: 28 Oct 94 01:51:50 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (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 [e-mail] (Juri Munkki)
Date: 3 Nov 1994 18:54:51 GMT
Organization: Helsinki University of Technology

In article <396050$[e-mail]> Alex Lelievre <[e-mail]> writes:
>In article <[e-mail]> Vince Tourangeau,
>[e-mail] 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.
 [e-mail]                Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From Dmitry Boldyrev <[e-mail]>
Date: 6 Nov 1994 21:07:30 GMT
Organization: University of Utah

In article <39bblr$[e-mail]> Juri Munkki, [e-mail]
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 [e-mail] (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
[e-mail]  |  a person' before...."
eWorld:  cTate             |        -- Mark Linton ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 3 Nov 94 18:11:13 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (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: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

+++++++++++++++++++++++++++

>From [e-mail] (Chris Driving in the Rain Tate)
Date: Thu, 3 Nov 1994 14:51:13 GMT
Organization: DCRT, NIH, Bethesda, MD

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>[e-mail] (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 <text library.c> 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
[e-mail]  |  a person' before...."
eWorld:  cTate             |        -- Mark Linton ([e-mail])

+++++++++++++++++++++++++++

>From [e-mail] (David Opstad)
Date: 6 Nov 1994 22:10:23 -0800
Organization: Apple Computer Inc, Cupertino, CA

In article <[e-mail]>, [e-mail] (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 [e-mail] (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
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (David Den Boer)
Date: 1 Nov 1994 23:29:58 GMT
Organization: The University of Manitoba

In <[e-mail]> [e-mail] (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.
[e-mail]                Borealis Project Lead

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 7 Nov 1994 00:03:29 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <396j1m$[e-mail]>, [e-mail]
(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 <AppleEvents.h>
#include <Files.h>
#include <Folders.h>

/*
** 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 <[e-mail]>
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 <Timer.h>, 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
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Coie)
Date: Mon, 31 Oct 1994 17:30:28 -0800
Organization: Intrigue Corporation

In article <393q4s$[e-mail]>, Tim Dorcey
<[e-mail]> wrote:

> Does anyone know where the Microseconds system call is documented?  I
> stumbled upon it in <Timer.h>, 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                              [e-mail]
Implementor, Intrigue Corporation     AppleLink: INTRIGUE
if intrigue.com bounces, try [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Tue, 01 Nov 1994 16:05:05 -0600
Organization: University of Illinois at Urbana-Champaign

In article <393q4s$[e-mail]>, Tim Dorcey
<[e-mail]> 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: [e-mail]

+++++++++++++++++++++++++++

>From jim [e-mail] (Jim Reekes)
Date: Tue, 1 Nov 1994 19:48:29 GMT
Organization: Apple Computer, Inc.

In article <rac-3110941730280001@198.68.126.30>, [e-mail] (Robert
Coie) wrote:

> In article <393q4s$[e-mail]>, Tim Dorcey
> <[e-mail]> wrote:
>
> > Does anyone know where the Microseconds system call is documented?  I
> > stumbled upon it in <Timer.h>, 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 [e-mail] (Charlie Reiman)
Date: Mon, 7 Nov 1994 05:46:39 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Pete Resnick) writes:

>In article <393q4s$[e-mail]>, Tim Dorcey
><[e-mail]> 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
[e-mail]

---------------------------

>From [e-mail] (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
[e-mail]           Medical School
[e-mail]            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 [e-mail] (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 [e-mail] ( nick.c )
Date: Sat, 29 Oct 1994 23:40:13 -0400
Organization: The Pitt, Chemistry

In article <38v173$[e-mail]>, [e-mail] (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: [e-mail]            _/   _/  _/  _/_/_/   _/   _/
   eWorld: nick                     _/_/ _/  _/  _/   _/  _/_/_/
      CIS: 71232,766               _/ _/_/  _/  _/       _/ _/
     http://www.pitt.edu/~nick/   _/   _/  _/   _/_/_/  _/   _/


+++++++++++++++++++++++++++

>From Darrin Cardani <[e-mail]>
Date: Wed, 2 Nov 1994 19:28:13 GMT
Organization: AT&T Global Information Solutions, Atlanta

>In article <[e-mail]>  nick.c
writes:
>In article <38v173$[e-mail]>, [e-mail] (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 [e-mail] (Avi Rappoport)
Date: 3 Nov 1994 19:06:21 GMT
Organization: Metrowerks, Inc.

Darrin Cardani <[e-mail]> writes:

>>In article <[e-mail]>  nick.c
>writes:
>>In article <38v173$[e-mail]>, [e-mail] (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                             [e-mail]
User Advocate                             [e-mail]
Online Documentation Lead                 [e-mail]
Metrowerks, Inc.                          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (MW Ron)
Date: 3 Nov 1994 17:24:07 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>, Darrin Cardani
<[e-mail]> 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
[e-mail]
Metrowerks Inc.

+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: Thu, 03 Nov 1994 19:18:51 -0500
Organization: The Pitt, Chemistry

In article <39bnu7$[e-mail]>, [e-mail] (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: [e-mail]            _/   _/  _/  _/_/_/   _/   _/
   eWorld: nick                     _/_/ _/  _/  _/   _/  _/_/_/
      CIS: 71232,766               _/ _/_/  _/  _/       _/ _/
     http://www.pitt.edu/~nick/   _/   _/  _/   _/_/_/  _/   _/


+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Fri, 04 Nov 1994 13:37:36 +0100
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] ( 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 ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  CFM 68k - solutions to yesterdays problems, tomorrow!


+++++++++++++++++++++++++++

>From [e-mail] (Spencer Low)
Date: Fri, 04 Nov 1994 17:02:42 -0800
Organization: LowTek Creations

In article <[e-mail]>,
[e-mail] ( 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 ----- [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (GHD)
Date: 6 Nov 1994 22:35:00 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] ( 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 [e-mail] ()
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 [e-mail] (AndrewWelc)
Date: 27 Oct 1994 07:57:06 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <38mvha$[e-mail]>, [e-mail] ()
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 [e-mail] (Peter N Lewis)
Date: Fri, 28 Oct 1994 10:51:14 +0800
Organization: NCRPDA, Curtin University

In article <38mvha$[e-mail]>, [e-mail] 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 <[e-mail]> - 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 [e-mail] (Kevin R. Boyce)
Date: Fri, 28 Oct 1994 13:09:49 -0400
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

>In article <38mvha$[e-mail]>, [e-mail] 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      [e-mail]
  Hope that the music turns you
  On like it's turning on me.
     --Hatfield and the North

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Mon, 31 Oct 1994 11:02:39 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>,
[e-mail] (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 [e-mail] (CW LAM)
Date: Mon, 31 Oct 1994 12:13:48 GMT
Organization: Aston University

'[e-mail]' 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 [e-mail] (Jeff Beeghly)
Date: 31 Oct 1994 18:19:16 GMT
Organization: University of Washington

[e-mail] (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 [e-mail] (Jon W{tte)
Date: Mon, 31 Oct 1994 21:15:25 +0100
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (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. [e-mail]. 'nuff said :-)

Cheers,

                    / h+


--
  Jon Wätte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

    Technology is not the problem;
    therefore, abondoning technology is not the answer.


+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: Mon, 31 Oct 1994 17:02:05 -0500
Organization: The Pitt, Chemistry

In article <[e-mail]>, [e-mail] (Jon
W{tte) wrote:

>
> NetCash. [e-mail]. '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: [e-mail]            _/   _/  _/  _/_/_/   _/   _/
   eWorld: nick                     _/_/ _/  _/  _/   _/  _/_/_/
      CIS: 71232,766               _/ _/_/  _/  _/       _/ _/
     http://www.pitt.edu/~nick/   _/   _/  _/   _/_/_/  _/   _/


+++++++++++++++++++++++++++

>From [e-mail] (Ed Watkeys)
Date: Mon, 31 Oct 1994 19:08:19 -0500
Organization: 35th and Baring

In article <[e-mail]>,
[e-mail] ( nick.c ) wrote:

> In article <[e-mail]>, [e-mail] (Jon
> W{tte) wrote:
>
> >
> > NetCash. [e-mail]. '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                     [e-mail]  Infonautics Corp.
Nihilist-Software Engineer          [e-mail]  eWorld/NewtonMail
Infonautics Corporation            [e-mail]  35th and Baring

+++++++++++++++++++++++++++

>From [e-mail] (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$[e-mail]>, [e-mail]
(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 [e-mail] (J. S. Greenfield)
Date: 1 Nov 1994 03:20:21 GMT
Organization: Los Alamos National Laboratory

In article <[e-mail]> [e-mail] (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. [e-mail]. 'nuff said :-)

Horrendously insecure.  NetThief steals your NetCash.  'nuff said. :(


--
J. S. Greenfield                                      [e-mail]
(So what were you expecting?
A Gorilla?!)                        "What's the difference between an orange?"

+++++++++++++++++++++++++++

>From [e-mail] (J. S. Greenfield)
Date: 1 Nov 1994 03:25:36 GMT
Organization: Los Alamos National Laboratory

In article <[e-mail]> [e-mail] (Ed Watkeys) writes:

>> > NetCash. [e-mail]. '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                                      [e-mail]
(So what were you expecting?
A Gorilla?!)                        "What's the difference between an orange?"

+++++++++++++++++++++++++++

>From [e-mail] (AndrewWelc)
Date: 1 Nov 1994 01:18:08 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <393cf4$[e-mail]>, [e-mail]
(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 [e-mail] (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 <[e-mail]>, [e-mail] (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 ([e-mail])
Computers do not solve problems, they execute solutions.

I know very few ideas worth dying for, none is worth killing.

+++++++++++++++++++++++++++

>From [e-mail] (Mark A Thalman)
Date: Tue, 1 Nov 1994 13:49:04 GMT
Organization: Information Data Management

AndrewWelc ([e-mail]) 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;[e-mail];[e-mail]/*clever quote provided by "fortune"*/
Beware of low-flying butterflies.

+++++++++++++++++++++++++++

>From [e-mail] (Brian Hall)
Date: Tue, 1 Nov 1994 21:10:20 GMT
Organization: Mark/Space Softworks

[e-mail] (AndrewWelc) writes:

>In article <393cf4$[e-mail]>, [e-mail]
>(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: [e-mail]
Communicate, PageNOW!, CTB Tools                 AppleLink, AOL: MARKSPACE
Macintosh connectivity software.   Goodies at ftp.netcom.com in pub/mspace

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Wed, 02 Nov 1994 00:05:48 +0100
Organization: Royal Institute of Something or other

In article <394c5l$[e-mail]>,
[e-mail] (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 ([e-mail]), 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 <[e-mail]>
Date: 2 Nov 1994 03:47:17 GMT
Organization: GUI Dude Software

In article <394mj0$[e-mail]> AndrewWelc,
[e-mail] 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
[e-mail]

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
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Wed, 02 Nov 1994 11:40:17 +0800
Organization: NCRPDA, Curtin University

In article <393cf4$[e-mail]>, [e-mail]
(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 [e-mail] is now my standard address) so
your Email address wont change, and accepts registrations via Email, FAX
or snail-mail.  Anyway, contact Kee <[e-mail]> 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 <[e-mail]> - 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 <[e-mail]>
Date: Wed, 2 Nov 1994 09:02:57 GMT
Organization: Grishnakh

In article <[e-mail]> CW LAM, [e-mail] 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 [e-mail] (Kee Nethery ([phone]))
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
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon Gotow)
Date: Thu, 3 Nov 1994 03:25:23 GMT
Organization: Ansoft Corporation

In article <394mj0$[e-mail]>
[e-mail] (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.
 [e-mail]    |  One is not getting what one wants, and the
                     |  other is getting it.         - Oscar Wilde

+++++++++++++++++++++++++++

>From [e-mail] (Jason Bobier)
Date: Mon, 31 Oct 1994 20:17:22 -0500
Organization: Prismatix Software

In article <393cf4$[e-mail]>, [e-mail]
(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: [e-mail]

"Living is easy with eyes closed..."  - The Beatles

+++++++++++++++++++++++++++

>From [e-mail] (AndrewWelc)
Date: 3 Nov 1994 22:07:39 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <397245$[e-mail]>, Grant Hulbert
<[e-mail]> 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 [e-mail] (Sak Wathanasin)
Date: Fri, 4 Nov 94 09:09:09 GMT
Organization: Network Analysis Ltd


In article <395hsj$[e-mail]> (comp.sys.mac.programmer),
[e-mail] (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: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Sat, 05 Nov 1994 16:28:35 +0800
Organization: NCRPDA, Curtin University

In article <39c8hr$[e-mail]>, [e-mail]
(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 <[e-mail]>.  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 <[e-mail]> - 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 [e-mail] (Michael Peirce)
Date: Sat, 5 Nov 94 18:21:43 PT
Organization: Peirce Software, Inc.


In article <39c8hr$[e-mail]> (comp.sys.mac.programmer), [e-mail] (AndrewWelc) writes:
> In article <397245$[e-mail]>, Grant Hulbert
> <[e-mail]> 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        __ [e-mail]    <- 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: [phone]
__    PEIRCE PRINT TOOLS __ AppleLink & AOL: peirce

+++++++++++++++++++++++++++

>From [e-mail] (J. S. Greenfield)
Date: 7 Nov 1994 19:41:00 GMT
Organization: Los Alamos National Laboratory

In article <[e-mail]> [e-mail] (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                                      [e-mail]
(So what were you expecting?
A Gorilla?!)                        "What's the difference between an orange?"

---------------------------

End of C.S.M.P. Digest
**********************