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

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

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-079
To: [e-mail]
Date: Wed, 18 Jan 1995 10:12:11 +0100 (MET)
Mime-Version: 1.0
Reply-To: [e-mail]
X-Sequence: 85

C.S.M.P. Digest             Wed, 18 Jan 95       Volume 3 : Issue 79

Today's Topics:

        Allocating Memory in a Constructor?
        Drag and Drop Promised Flavors
        PB call for copying files?
        Some Inside Macintosh available via WWW and anon FTP
        Speech Manager docs?
        What global is at memory location $03A4 or $03B4?
        Writing Fat plug-ins (on 68k platform)
        [Q] Color Notification icon?



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] (Bob Bradley)
Subject: Allocating Memory in a Constructor?
Date: Thu, 15 Dec 1994 21:36:56 -0800
Organization: SS Software Inc.

I've read that you're not supposed to allocate memory in a constructor for
a class cause it can't return a value (like the error) but, is it ok to
pass in the address of an OSErr and have a constructor that allocates
memory just write the that address so you can test it when the constructor
returns? Like this:

TClass::TClass( OSErr *constructorError )
{
    Handle             myHandle;

    myHandle          = NewHandle( 1 );
    *constructorError = MemError();
}

Is that ok?

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

>From [e-mail] (Robert Mah)
Date: Fri, 16 Dec 1994 13:48:11 -0500
Organization: One Step Beyond

[e-mail] (Bob Bradley) wrote:

) I've read that you're not supposed to allocate memory in a constructor for
) a class cause it can't return a value (like the error) but, is it ok to
) pass in the address of an OSErr and have a constructor that allocates
) memory just write the that address so you can test it when the constructor
) returns? Like this:
)
) TClass::TClass( OSErr *constructorError )
) {
)     Handle             myHandle;
)
)     myHandle          = NewHandle( 1 );
)     *constructorError = MemError();
) }
)
) Is that ok?

Well, yes, but then that means, your code will go something like this...

    OSErr  err;
    TClass cobj(&err);

    if( err == noErr )
        ....

So, why not just do...

    TClass cobj;
    if( cobj.Init() == noErr )
        ....

Contstructors are NOT initializers.  They should only be used to put
the object into a consistant and usable state.  IOW, just assign NULL
to myHandle.

Cheers,
Rob
_______________________________________________________________________
Robert S. Mah        Macintosh Software Development     +1.212.947.6507
One Step Beyond         and Network Consulting           [e-mail]

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

>From [e-mail] (Ed Anson)
Date: Fri, 16 Dec 1994 13:28:54 -0500
Organization: Tulip Software

In article <[e-mail]>, [e-mail]
(Bob Bradley) wrote:

> I've read that you're not supposed to allocate memory in a constructor for
> a class cause it can't return a value (like the error) but, is it ok to
> pass in the address of an OSErr and have a constructor that allocates
> memory just write the that address so you can test it when the constructor
> returns? Like this:
>
> TClass::TClass( OSErr *constructorError )
> {
>     Handle             myHandle;
>
>     myHandle          = NewHandle( 1 );
>     *constructorError = MemError();
> }
>
> Is that ok?

It might work -- most of the time.

The real problem with allocating memory in a constructor has nothing to do
with the ability to return a result. After all, you could just as easily
place the result in a field of the object.

It is very important that you do nothing inside a constructor that can
fail to leave the new object fully constructed. In other words, when an
object is created, the constructor must return with the object in a state
that makes sense. Otherwise, attempts to use or destroy that object might
not make sense.

Typically, anything that can fail (such as memory allocation) is handled
by a second phase of initialization that follows the constructor. If the
second phase fails, you can still destroy the object if necessary.

IHTH

--
Ed Anson
President
Tulip Software
PO Box 3046
Andover, MA 01810
U.S.A.
[e-mail]
508-475-8711

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

>From [e-mail] (Christian E. Hopps)
Date: 21 Dec 1994 06:45:42 GMT
Organization: University of Michigan EECS Dept.

Robert Mah ([e-mail]) wrote:
: Well, yes, but then that means, your code will go something like this...

:     OSErr  err;
:     TClass cobj(&err);

:     if( err == noErr )
:         ....

: So, why not just do...

:     TClass cobj;
:     if( cobj.Init() == noErr )
:         ....

or
        try {
                TClass cobj;
                ...
        } catch (memerr& err) {
                ...
        } catch (...) {
                ...
        }

Hmm but we don't have exception handling yet now do we :)

: Contstructors are NOT initializers.  They should only be used to put
: the object into a consistant and usable state.  IOW, just assign NULL
: to myHandle.

I disagree with this.  Constructors in C++ are intended to be initializers
otherwise they would not take arguements (just one reason.)  Besides
if the object depends upon that handle pointing to something then
the object is less than usable if the handle is NULL.  I will admit
that C++ is also intended to include exception handling.

Exceptions are named properly.  They are intended to handle "exceptional"
conditions.  I wish we had exception handling in Mac C++ compilers becuase
it trully moves the exceptional conditional code away from the code
that executes >99% of the time.  In most implementations exceptions
are handled with some form of setjmp()/longjmp() type scheme which
is decidedly faster than a million if (err's) and multiple initialization
calls not to mention cleaner.

Chris.

BTW I derive all my classes from a root class that looks something like:
        class root_t {
        protected:
                int ok;
                ...
        public:
                root_t()        { ok = 1; }
                int isok()      { return (ok); }
                ...
        };
Each derived class's constructor then looks like:
        der_t:der_t()
        {
                d_handle = NULL;
                ...
                if (ok == 0)
                        return;
                if ((d_handle = NewSomething()) == NULL)
                        ok = 0;
        }
It seems to work ok and allows a general checking scheme for all
objects.
        der_t object;

        if (object.isok() == 0)
                ...

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

>From [e-mail] (Ed Anson)
Date: Wed, 21 Dec 1994 16:54:04 -0500
Organization: Tulip Software

In article <3d8ium$[e-mail]>, [e-mail]
(Christian E. Hopps) wrote:

> : Contstructors are NOT initializers.  They should only be used to put
> : the object into a consistant and usable state.  IOW, just assign NULL
> : to myHandle.
>
> I disagree with this.  Constructors in C++ are intended to be initializers

Then you are wrong. General good practice dictates that nothing capable of
generating an exception should be included in a constructor.

> BTW I derive all my classes from a root class that looks something like:
>         class root_t {
>         protected:
>                 int ok;
>                 ...
>         public:
>                 root_t()        { ok = 1; }
>                 int isok()      { return (ok); }
>                 ...
>         };
> Each derived class's constructor then looks like:
>         der_t:der_t()
>         {
>                 d_handle = NULL;
>                 ...
>                 if (ok == 0)
>                         return;
>                 if ((d_handle = NewSomething()) == NULL)
>                         ok = 0;
>         }
> It seems to work ok and allows a general checking scheme for all
> objects.
>         der_t object;
>
>         if (object.isok() == 0)
>                 ...

The main problem with this is that, should allocation fail, you have no
clean way to destroy the object because it is not fully constructed.
That's why good practice dictates as I mentioned above.

I ususally use my constructor to set all pointers (handles, etc.) to NIL.
My class design takes NIL pointers into account and treats them as a valid
state. If any real use of the object requires something other than NIL,
then that is set up after the constructor has finished.

This is a bit inconvenient, but not nearly so inconvenient as trying to
unravel a partially constructed object in case of an exception.

- -----------------------------------------------------------------
Ed Anson                InterNet: [e-mail]
Tulip Software          voice: 508-475-8711
PO Box 3046
Andover, MA 01810       <http://www.tiac.net/users/tulip/home.html>
U.S.A.
Ed Anson
President
Tulip Software
PO Box 3046
Andover, MA 01810
U.S.A.
[e-mail]
508-475-8711

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

>From [e-mail] (Brian Stern)
Date: 22 Dec 1994 01:45:39 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, [e-mail] (Ed
Anson) wrote:
<
< I ususally use my constructor to set all pointers (handles, etc.) to NIL.
< My class design takes NIL pointers into account and treats them as a valid
< state. If any real use of the object requires something other than NIL,
< then that is set up after the constructor has finished.
<
< This is a bit inconvenient, but not nearly so inconvenient as trying to
< unravel a partially constructed object in case of an exception.
<
< -------------------------------------------------------------------
< Ed Anson                InterNet: [e-mail]

What's wrong with first setting all your handles to nil and then trying to
allocate them in the constructor?  In this case the object will always be
in a consistent state.

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

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

>From [e-mail] (Robert Mah)
Date: Thu, 22 Dec 1994 00:00:30 -0500
Organization: One Step Beyond

[e-mail] (Brian Stern) wrote:

) [e-mail] (Ed Anson) wrote:
) <
) < I ususally use my constructor to set all pointers (handles, etc.) to
) < NIL.  My class design takes NIL pointers into account and treats them
) < as a valid state. If any real use of the object requires something
) < other than NIL, then that is set up after the constructor has finished.
)
) What's wrong with first setting all your handles to nil and then trying
) to allocate them in the constructor?  In this case the object will always
) be in a consistent state.

To quote from the great Bjarne, font (fount?) of all that is true, wise
and good about that mystical and arcane tongue we call "C++",

 "An object is not considered constructed until its constructor has
  completed. Then and only then will stack unwinding call the destructor
  for the object.
  [...]
  A well written constructor should ensure that its object is completely
  and correctly constructed.  Failing that, the constructor should -- as
  far as possible -- restore the state of the system to what it was
  before creation.  It would be ideal for naively written constructors
  always to achieve on of these alternatives and not leave their objects
  in some 'half constructed' state."

  -- Bjarne Stroustrup, "The C++ Programming Language, Second Edition",
     pp. 309-310

This is in the chapter about exception handling, in the section regarding
resource aquisition.  Precisely the topic at hand.

As an example of the dangers involved, take a look at the following,
innocuous looking, code...

  class TC {
    char *p;
  public:
    TC()          { p = NULL; p = AllocSomething(); }
    virtual ~TC() { if( p != NULL ) FreeSomething( p ); }
  };

This class could result in memory leaks if an exception is thrown inside
AllocSomething().  Since the object is not fully constructed, the
exception handling mechanism might not call the destructor for the object.
It gets more complicated if you throw in multiple inheritance.

Besides, if you allocate memory (i.e. do the "initialzation") in the
ctor, then you preclude the ability of sub-classes from overriding the
behaviour of the initialization.

I know it is tempting to use ctor's as "initializers".  Don't sucumb to
temptation.  Ctors should only be used to put the object into a safe and
consistant state.  Nothing else.  Until you know all the ins and outs of
how C++ works, it is not safe to violate this rule.

It takes a long time and a lot of reading to learn C++ well.  After
three years of fairly heavy use, I still learn new things every day (or
at least every week anyway) and only now am I starting to consider myself
barely proficient.  With luck, I'll be "proficient" in a few more years.

Cheers,
Rob
_______________________________________________________________________
Robert S. Mah        Macintosh Software Development     +1.212.947.6507
One Step Beyond         and Network Consulting           [e-mail]

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

>From [e-mail] (Christian E. Hopps)
Date: 22 Dec 1994 06:48:43 GMT
Organization: University of Michigan EECS Dept.

Ed Anson ([e-mail]) wrote:
: In article <3d8ium$[e-mail]>, [e-mail]
: (Christian E. Hopps) wrote:
: > BTW I derive all my classes from a root class that looks something like:
: >         class root_t {
: >         protected:
: >                 int ok;
: >                 ...
: >         public:
: >                 root_t()        { ok = 1; }
: >                 int isok()      { return (ok); }
: >                 ...
: >         };
: > Each derived class's constructor then looks like:
: >         der_t:der_t()
: >         {
: >                 d_handle = NULL;
: >                 ...
: >                 if (ok == 0)
: >                         return;
: >                 if ((d_handle = NewSomething()) == NULL)
: >                         ok = 0;
: >         }
: > It seems to work ok and allows a general checking scheme for all
: > objects.
: >         der_t object;
: >
: >         if (object.isok() == 0)
: >                 ...

: The main problem with this is that, should allocation fail, you have no
: clean way to destroy the object because it is not fully constructed.
: That's why good practice dictates as I mentioned above.

I think its pretty clear in the code fragment I gave that I *do* leave
the object in a consistent state (setting d_handle to NULL)  If d_handle
is not null then it should be disposed of.  If at the point of init the
object is not ok no further init happens.

: I ususally use my constructor to set all pointers (handles, etc.) to NIL.
: My class design takes NIL pointers into account and treats them as a valid
: state. If any real use of the object requires something other than NIL,
: then that is set up after the constructor has finished.

My desgin above treats NULL (nil? :) pointers as an invalid exceptional state.
It does deal with them in cleanup, however any object that depends on
a non-NULL pointer has no reason to work with them.  If an object is in
this exceptional state then it has failed to construct and cannot be used
- -simple.

I do have classes of objects that *can* work with NULL pointers but thats
different.  In that case the state of the object is not considered
exceptional or invalid and the object just operates within that different
state.

Chris.

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

>From [e-mail] (Ed Anson)
Date: Thu, 22 Dec 1994 13:13:08 -0500
Organization: Tulip Software

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:

> In article <[e-mail]>, [e-mail] (Ed
> Anson) wrote:
> <
> < I ususally use my constructor to set all pointers (handles, etc.) to NIL.
> < My class design takes NIL pointers into account and treats them as a valid
> < state. If any real use of the object requires something other than NIL,
> < then that is set up after the constructor has finished.
> <
> < This is a bit inconvenient, but not nearly so inconvenient as trying to
> < unravel a partially constructed object in case of an exception.
> <
> < -------------------------------------------------------------------
> < Ed Anson                InterNet: [e-mail]
>
> What's wrong with first setting all your handles to nil and then trying to
> allocate them in the constructor?  In this case the object will always be
> in a consistent state.

Maybe. Maybe not. If some handles get set, and others remain NIL, you
could have a mess on your hands. For example, it could be really difficult
to maintain a consistent model of the object when random handles might be
NIL even though others have been assigned values. It's not impossible --
just too difficult to be worth the trouble.

Of course, there are many ways to solve any particular problem. I am
referring to an approach that has worked well for me over the years, and
happens to be the most generally accepted good practice.

- -----------------------------------------------------------------
Ed Anson                InterNet: [e-mail]
Tulip Software          voice: 508-475-8711
PO Box 3046                Check out my WWW page!
Andover, MA 01810       <http://www.tiac.net/users/tulip/home.html>
U.S.A.
Ed Anson
President
Tulip Software
PO Box 3046
Andover, MA 01810
U.S.A.
[e-mail]
508-475-8711

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

>From [e-mail] (Rick Wong)
Date: Thu, 22 Dec 1994 12:28:23 -0700
Organization: Stanford University

I read in "Taligent's Guide to Designing Programs," p. 77, that
the ISO/ANSI draft specification is currently silent on what
happens if an exception occurs while constructing an object
allocated with new.  Taligent states that the prevailing opinion
is that operator delete should be called in such situations,
because there would otherwise be no way to completely recover.
(Of course, since no Mac C++ compilers support exceptions,
this is a moot point for us anyway.)

<flamebait>
Does it strike anyone as odd that there's a debate at all about
something as fundamental as object initialization?  The intent
of the construction protocol is obviously to provide a well-
defined, safe, and convenient way to initialize objects.  I
don't think it meets any of those criteria.

The construction protocol, like so much else in C++, is half-
baked, and has led to a number of "C++ idioms" concerning
construction.  In the spirit of freedom, you ought to be able
to initialize objects in a way that is natural, including
allocating any memory needed by the object.  That C++ does
not currently allow you to do so safely indicates to me a
bad design.
</flamebait>

Rick "fast and bulbous" Wong

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

>From [e-mail] (Kent Sandvik)
Date: Wed, 28 Dec 1994 20:44:24 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>, [e-mail]
(Robert Mah) wrote:
> Contstructors are NOT initializers.  They should only be used to put
> the object into a consistant and usable state.  IOW, just assign NULL
> to myHandle.

True, most C++ frameworks have a method call Initialize or something
similar that returns false if something failed. The forthcoming exception
model in C++ should to some degree eliminate this situation. Constructor
(and destructors) are funny, you could never know what happened inside one
of those, unless you wrote explicit error checking for states.

Cheers, Kent

--
Kent Sandvik   [e-mail]   New Media Analyst/Programmer
Private activities on Internet.

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

>From [e-mail] (MadHack)
Subject: Drag and Drop Promised Flavors
Date: 29 Dec 1994 23:53:41 -0500
Organization: America Online, Inc. (1-800-827-6364)

I've been working with the Drag & Drop manager for a bit and was wondering
if anyone has figured out how to promise a flavor other than phfs. For
example, say I want to promise a pict and the application that recieves
the drop can call me to get it rather than creating the PICT instantly and
passing that off to the Drag Manager.

- Gus ([e-mail])

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

>From [e-mail] (Brian L. Matthews)
Date: 30 Dec 1994 18:00:25 GMT
Organization: NW NEXUS, Inc. -- Internet Made Easy [phone]

In article <3e03ol$[e-mail]>, MadHack <[e-mail]> wrote:
|I've been working with the Drag & Drop manager for a bit and was wondering
|if anyone has figured out how to promise a flavor other than phfs. For
|example, say I want to promise a pict and the application that recieves
|the drop can call me to get it rather than creating the PICT instantly and
|passing that off to the Drag Manager.

Just passing 0 for the data pointer and size will do it.  For example,
to promise a PICT when you're setting dragRef up for TrackDrag, do:

    AddDragItemFlavor (dragRef, itemRef, 'PICT', 0, 0, 0);

When (if) someone accepts the drag, the drag send proc you set with
SetDragSendProc is called by the drag manager thusly:

    dragSendProc ('PICT', refCon, itemRef, dragRef);

In dragSendProc, you do something like:

    SetDragItemFlavorData (dragRef, itemRef, flavorType, Ptr (*picHandle),
        GetHandleSize (Handle (picHandle)), 0);

(after checking that flavorType and itemRef are correct, etc.)

Brian
--
Brian L. Matthews                                       [e-mail]
  You can't have a syntax error with a hammer.

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

>From [e-mail] (Phil Smy)
Subject: PB call for copying files?
Date: Thu, 29 Dec 1994 21:20:18 -0500
Organization: InfiNet

Is there a PB (or FS) call to copy as file from one disk to another? I
would think that I wouldn't have to read in all the contents and then
write it all out again.

I have tried using PBHCopyFile (see example), but I keep getting a -50
error (which Think Ref says is no default volume(!))

   pb.ioCompletion = nil;
   pb.ioNamePtr = origName;
   pb.ioVRefNum = sourceFile->GetVolRefNum();
   pb.ioDstVRefNum = tmpVRefNum;
   pb.ioNewName =origName; // keep the same name
   pb.ioCopyName = nil;
   pb.ioNewDirID = tmpDirID;
   pb.ioDirID = sourceFile->GetDirID();

   FailOSErr(PBHCopyFile((HParmBlkPtr)&pb,async));

All the other PB call I've looked at (PBHRename, PBCatMove, etc.) seem to
all say that you can't move from one disk to another.

Am I just dreaming here?

Thanks in advance.

Humbly yours,

Phil Smy

--
*******************
* Not a signature *
*******************

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

>From mclow@san_marcos.csusm.edu (Marshall Clow)
Date: Thu, 29 Dec 1994 20:51:26 -0800
Organization: Aladdin Systems

In article <[e-mail]>,
[e-mail] (Phil Smy) wrote:

> Is there a PB (or FS) call to copy as file from one disk to another? I
> would think that I wouldn't have to read in all the contents and then
> write it all out again.
>
> I have tried using PBHCopyFile (see example), but I keep getting a -50
> error (which Think Ref says is no default volume(!))
>

If you read the docs for PBHCopyFile, it says that it only works when the
source and the dest are on the same AppleShare server.

If you need a routine to copy a file, look at Jim Luther's "MoreFiles"
package. A set of libraries for file manipulations. Source is availiable
at and ftp site near you.

-- Marshall

--
Marshall Clow
Aladdin Systems
mclow@san_marcos.csusm.edu

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

>From [e-mail] (Douglas Edward Becker)
Subject: Some Inside Macintosh available via WWW and anon FTP
Date: 2 Jan 1995 05:41:33 GMT
Organization: Rensselaer Polytechnic Institute, Troy NY

It appears that Apple has decided to let certain volumes of Inside Mac be
available via anonymous FTP at ftp.info.apple.com. A nice WWW interface
is at:
http://www.info.apple.com/dev/insidemac.html
It looks like they're releasing the basic programming manuals, but not the
more "optional" volumes. Sounds smart to me. Even better, the WWW page
claims that HTML versions will be available in Spring '95! (They may want
to get some mirror sites if they do this...)
I just found this while searching around on their site. I haven't seen
anything from Apple about this. I hope I'm not jumping the gun or anything,
but it's there...

 - Doug Becker


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

>From [e-mail] (David Sinclair)
Subject: Speech Manager docs?
Date: 2 Jan 1995 01:49:52 GMT
Organization: iconz, Auckland, New Zealand

I'm looking for the Speech Manager documentation: can someone please
point me to an ftp site & directory, or post the documentation on the
Speech Manager calls here?  (If you want to e-mail, please do so to my
AMUG address, [e-mail] -- thanks.)

David Sinclair

--

|\  ._   .  _  .     Dejal Userware  |  [e-mail]  (preferred)
| | |_   | |_| |     PO Box 33-1011  |  [e-mail]
|/  |_ \_| | | |_    Takapuna        |  ftp ftp.amug.org ... cd /pub/dejal
- ---------------    Auckland 1309   |  http://amug.org:80/~dejal/
 U S E R W A R E     New Zealand     |  [e-mail]
- ---------------

Author of SndConverter Pro, SndPlayer, QuickEncrypt, TextMerge, TextSplitter
and other Shareware and Freeware products for the Macintosh.

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

>From [e-mail] (Brian Stern)
Date: 2 Jan 1995 15:46:59 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <3e7m40$qq7@status>, [e-mail] (David Sinclair) wrote:

< I'm looking for the Speech Manager documentation: can someone please
< point me to an ftp site & directory, or post the documentation on the
< Speech Manager calls here?  (If you want to e-mail, please do so to my
< AMUG address, [e-mail] -- thanks.)
<
< David Sinclair
<
< --
<
< |\  ._   .  _  .     Dejal Userware  |  [e-mail]  (preferred)
< | | |_   | |_| |     PO Box 33-1011  |  [e-mail]
< |/  |_ \_| | | |_    Takapuna        |  ftp ftp.amug.org ... cd /pub/dejal
< -----------------    Auckland 1309   |  http://amug.org:80/~dejal/
<  U S E R W A R E     New Zealand     |  [e-mail]
< -----------------
<
< Author of SndConverter Pro, SndPlayer, QuickEncrypt, TextMerge, TextSplitter
< and other Shareware and Freeware products for the Macintosh.

ftp://ftp.apple.com/dts/mac/sys.soft/speech/speech-manager-docs.hqx

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

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

>From [e-mail] (Robert Mah)
Subject: What global is at memory location $03A4 or $03B4?
Date: Thu, 29 Dec 1994 18:18:54 -0500
Organization: One Step Beyond

Lately I've noticed that MacTCP 2.0.6 (or something related to it) is
getting stuck in a tight loop waiting for the word at $03B4 to be set
to zero.

The code is something like...

    TST.W  $0010(a0)
    BGT.S  *-$0004

...where a0 contains $03A4.

What is $03A4 or $03B4?

Cheers,
Rob
_______________________________________________________________________
Robert S. Mah        Macintosh Software Development     +1.212.947.6507
One Step Beyond         and Network Consulting           [e-mail]

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

>From [e-mail] (Richard Wesley)
Date: 30 Dec 1994 03:18:12 GMT
Organization: Punch Deck Consulting

In article <[e-mail]>
[e-mail] (Robert Mah) writes:

> Lately I've noticed that MacTCP 2.0.6 (or something related to it) is
> getting stuck in a tight loop waiting for the word at $03B4 to be set
> to zero.
>
> The code is something like...
>
>     TST.W  $0010(a0)
>     BGT.S  *-$0004
>
> ...where a0 contains $03A4.
>
> What is $03A4 or $03B4?
>
> Cheers,
> Rob
> _______________________________________________________________________
> Robert S. Mah        Macintosh Software Development     +1.212.947.6507
> One Step Beyond         and Network Consulting           [e-mail]

TMON calls these "Parms" and "Parms+10".  I seem to recall that the file
manager(?) uses them internally for making parameter blocks for internal calls
(or at least it used to). They may just be general TB scratch space.  God only
knows what the rules for using them (if any) were.

Sorry to be so vague, it was long, long ago, in a brain far, far away...

- rmgw

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

Richard Wesley     [e-mail] | "If we're not careful, we could have
Punch Deck Consulting  [e-mail] |  a farce on our hands!"
     Macintosh Software Development     |    - Tom Stoppard, "On the Razzle"
- ------------------------------------------------------------------------------


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

>From [e-mail] (Richard Wesley)
Date: 30 Dec 1994 03:24:36 GMT
Organization: Punch Deck Consulting

In article <[e-mail]>
[e-mail] (Robert Mah) writes:
> Lately I've noticed that MacTCP 2.0.6 (or something related to it) is
> getting stuck in a tight loop waiting for the word at $03B4 to be set
> to zero.
>
> The code is something like...
>
>     TST.W  $0010(a0)
>     BGT.S  *-$0004
>
> ...where a0 contains $03A4.
>
> What is $03A4 or $03B4?

After poking around in TMON some more, I was able to confirm that this is used
as scratch space by the File Manager.  There is a snippet of code in MountVol
(in my PB165 ROM) that loads Params into A0 and calls _Status.

- rmgw

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

Richard Wesley     [e-mail] | "If we're not careful, we could have
Punch Deck Consulting  [e-mail] |  a farce on our hands!"
     Macintosh Software Development     |    - Tom Stoppard, "On the Razzle"
- ------------------------------------------------------------------------------


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

>From [e-mail] (Richard Wesley)
Date: 30 Dec 1994 03:35:11 GMT
Organization: Punch Deck Consulting

In article <[e-mail]>
[e-mail] (Robert Mah) writes:

> Lately I've noticed that MacTCP 2.0.6 (or something related to it) is
> getting stuck in a tight loop waiting for the word at $03B4 to be set
> to zero.
>
> The code is something like...
>
>     TST.W  $0010(a0)
>     BGT.S  *-$0004
>
> ...where a0 contains $03A4.
>
> What is $03A4 or $03B4?

After poking around in TMON some more, I was able to confirm that this is used
as scratch space by the File Manager.  There is a snippet of code in MountVol
(in my PB165 ROM) that loads Params into A0 and calls _Status.

- rmgw

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

Richard Wesley     [e-mail] | "If we're not careful, we could have
Punch Deck Consulting  [e-mail] |  a farce on our hands!"
     Macintosh Software Development     |    - Tom Stoppard, "On the Razzle"
- ------------------------------------------------------------------------------


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

>From [e-mail] (Steve Kiene)
Date: Thu, 29 Dec 1994 21:50:32 -0700
Organization: MindVision Software

In article <[e-mail]>, [e-mail]
(Robert Mah) wrote:

> Lately I've noticed that MacTCP 2.0.6 (or something related to it) is
> getting stuck in a tight loop waiting for the word at $03B4 to be set
> to zero.
>
> The code is something like...
>
>     TST.W  $0010(a0)
>     BGT.S  *-$0004
>
> ...where a0 contains $03A4.
>
> What is $03A4 or $03B4?

$3a4 is the start of the global OS parameter block for Device/File Manager
calls. $3b4 is the ioResult field of that parameter block. It's waiting
for the call to be completed by the OS when it's sitting in that loop.

Steve Kiene
MindVision Software

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

>From [e-mail] ([e-mail])
Date: 30 Dec 1994 05:00:31 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Robert Mah) writes:
> Lately I've noticed that MacTCP 2.0.6 (or something related to it) is
> getting stuck in a tight loop waiting for the word at $03B4 to be set
> to zero.
>
> The code is something like...
>
>     TST.W  $0010(a0)
>     BGT.S  *-$0004
>
> ...where a0 contains $03A4.
>
> What is $03A4 or $03B4?
>
> Cheers,
> Rob
> _______________________________________________________________________
> Robert S. Mah        Macintosh Software Development     +1.212.947.6507
> One Step Beyond         and Network Consulting           [e-mail]

The global at $03A4 is called Params, and is used by the File Manager
for scratch space.  Specifically, it is used as a parameter block.  The
code you have above is a sync-wait loop:  someone is waiting for a file
or device call to complete by polling ioResult (which is $10 bytes from
the start of the parameter block stored in A0).  The system will do
this any time a file or device call is made syncronously, and other
programs do it as well after making async calls.  The loop is actually
waiting for ioResult to go zero or negative (GT means greater than
zero, signed test).

MacTCP has (had?  I wonder if they have fixed this...) a design bug
that causes a lock-up when an async echo-request is made in a VBL task.
 This is a pretty rare occurance, but you mentioned MacTCP, and the
lock-up is due to a never-ending sync-wait loop.

I have seen three main reasons for getting locked in a loop like this:

1)  some parameter block being used was deallocated before the call
competed ("deallocation" applies to stack pbs as well as heap pbs).
This will usually only happen to pb's that are issued asyncronously,
but can happen with sync pb's as well.  Especially likely when a
program crashes or exits abnormally during a file system or device
call.

2)  a program or driver turned off interrupts or set some system
semaphore and is waiting for the call to complete, but completion
depends on interrupts being enabled or the semaphore being cleared
(this is the case with the MacTCP bug).

3)  a parameter block was re-used before the first call completed.
This can happen for various reasons, but most times I've seen are
because the file system was improperly called during interrupt time.

Because the pb in question is a Params, I would strongly suspect (3).
If you are es'ing out of a program in MacsBug, or get an "unexpected
quit" message before you get the lock-up, then look no further.  If
your Mac locks without prodding, then you need to look at the
programs/extensions that are running.  One of them has a bug (duh, no
kidding).  Do you care to tell us what you are running?

Mark.

- --------------------------------------------------------------------
"On the Internet, nobody knows you're a dog."   Ice Peak Form Mice Elf
                    -- cartoon in New Yorker

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

>From [e-mail] (Robert Mah)
Date: Fri, 30 Dec 1994 18:43:52 -0500
Organization: One Step Beyond

[e-mail] ([e-mail]) wrote:

) [e-mail] (Robert Mah) writes:
) > Lately I've noticed that MacTCP 2.0.6 (or something related to it) is
) > getting stuck in a tight loop waiting for the word at $03B4 to be set
) > to zero.
) >
) > The code is something like...
) >
) >     TST.W  $0010(a0)
) >     BGT.S  *-$0004
) >
) > ...where a0 contains $03A4.
) >
) > What is $03A4 or $03B4?
)
) The global at $03A4 is called Params, and is used by the File Manager
) for scratch space.  Specifically, it is used as a parameter block.  The
) code you have above is a sync-wait loop:  someone is waiting for a file
) or device call to complete by polling ioResult (which is $10 bytes from
) ...
) MacTCP has (had?  I wonder if they have fixed this...) a design bug
) that causes a lock-up when an async echo-request is made in a VBL task.
) This is a pretty rare occurance, but you mentioned MacTCP, and the
) lock-up is due to a never-ending sync-wait loop.

Ah ha!  This makes sense because I have MacPPP generating echo packets
every 20 seconds.  In addition, when the machine locks up, MacPPP will
usually disconnect after a short time and I once noticed a PPP Echo
failure message.

Now, why this never happened before I don't know...but it currently seems
to afflict my Mac near the end of large file transfers.

Hopefully turning off the ping feature will fix things for me.

Thanks to everyone who replied -- have a happy New Years.

Cheers,
Rob
_______________________________________________________________________
Robert S. Mah        Macintosh Software Development     +1.212.947.6507
One Step Beyond         and Network Consulting           [e-mail]

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

>From [e-mail] (Keith MacDonald)
Subject: Writing Fat plug-ins (on 68k platform)
Date: 16 Dec 1994 16:22:01 GMT
Organization: ECE - Concordia University

I've written a 68k application which is extensible via plug-ins (code
resources).  I know that I'd like to write some fat or PPCnative-only
plug-ins in the near future.  Is it completely unreasonable to expect
to be able to develop fat/PPC native code without a PowerMac? (would
be using MetroWerks)

Also, I understand that PPC code is in the data fork - does it sound
possible to put the PPC calling code into the 68k part of a plug-in
rather than change my application's plug-in calling code?

I don't have CodeWarrior yet, but am about to release this program
and am wondering if a significant amount of work will have to be
done to allow the program to have fat/native plug-ins.  Didn't
Photoshop release a native plug-in for a 68k version?

All comments appreciated,
Keith
___________________________________________________________________________
 Keith MacDonald                                       Computer Engineering
 [e-mail]                             Concordia University
 http://www.ece.concordia.ca/~ikb_macd/addr.html       Montreal, QC, Canada

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

>From [e-mail] (Bruce Hoult)
Date: Sat, 17 Dec 1994 16:34:52 +1300 (NZDT)
Organization: (none)

[e-mail] (Keith MacDonald) writes:
> I've written a 68k application which is extensible via plug-ins (code
> resources).  I know that I'd like to write some fat or PPCnative-only
> plug-ins in the near future.  Is it completely unreasonable to expect
> to be able to develop fat/PPC native code without a PowerMac? (would
> be using MetroWerks)
>
> Also, I understand that PPC code is in the data fork - does it sound
> possible to put the PPC calling code into the 68k part of a plug-in
> rather than change my application's plug-in calling code?
>
> I don't have CodeWarrior yet, but am about to release this program
> and am wondering if a significant amount of work will have to be
> done to allow the program to have fat/native plug-ins.  Didn't
> Photoshop release a native plug-in for a 68k version?

It is possible to write PPC plug-ins which are compatable with your
*existing* program.  Look up "accelerated resources" in _Inside Mac:
PowerPC System Software_.

Basically, what happens is that the resource starts off as 68K code
and executes a special 68K trap that switches to PPC native mode,
and the remainder of the code is PPC.

You can compile and build PPC programs on a 68K Mac, with either MPW
or CodeWarrior (or Symantec I suppose -- I gave up on them more than
six months ago).  Of course you won't be able to *test* it... :-)

-- Bruce

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

>From [e-mail] (Kent Sandvik)
Date: Wed, 28 Dec 1994 20:42:54 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <3cser9$[e-mail]>, [e-mail]
(Keith MacDonald) wrote:

> I've written a 68k application which is extensible via plug-ins (code
> resources).  I know that I'd like to write some fat or PPCnative-only
> plug-ins in the near future.  Is it completely unreasonable to expect
> to be able to develop fat/PPC native code without a PowerMac? (would
> be using MetroWerks)
>
> Also, I understand that PPC code is in the data fork - does it sound
> possible to put the PPC calling code into the 68k part of a plug-in
> rather than change my application's plug-in calling code?

I think all this is doable, but I would recommend to wait for the CFM68k
environment, as CFM is the most natural way to write extensions for both
platforms, long term.

Cheers, Kent

--
Kent Sandvik   [e-mail]   New Media Analyst/Programmer
Private activities on Internet.

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

>From [e-mail] (Malcolm Slaney)
Date: Thu, 29 Dec 1994 11:24:48 -0800
Organization: Interval Research

> In article <3cser9$[e-mail]>, [e-mail]
> (Keith MacDonald) wrote:
>
> > Also, I understand that PPC code is in the data fork - does it sound
> > possible to put the PPC calling code into the 68k part of a plug-in
> > rather than change my application's plug-in calling code?

Works just fine!

MathWorks uses code resources for their 68k extensions, and code-fragments
on the PPC.  It works just great to put both in the same file!  I expect
the same trick would work for HyperCard and PhotoShop, if they choose to
do things this way.

-- Malcolm

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

>From [e-mail] (David Phillip Oster)
Date: Sat, 31 Dec 1994 07:12:03 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <3cser9$[e-mail]>, [e-mail]
(Keith MacDonald) wrote:

> I've written a 68k application which is extensible via plug-ins (code
> resources).  I know that I'd like to write some fat or PPCnative-only
> plug-ins in the near future.  Is it completely unreasonable to expect
> to be able to develop fat/PPC native code without a PowerMac? (would
> be using MetroWerks)

> Also, I understand that PPC code is in the data fork - does it sound
> possible to put the PPC calling code into the 68k part of a plug-in
> rather than change my application's plug-in calling code?

If you check out the Metrowerks CD, you'll find a file called MixedMode.r
in the Apple Development tools section of the disk. You copy
and edit the file. It defines an executable code resource, compiled
by Rez, which inforporates, in the resource, 68000 and PowerPC code.
You call it just like any 68000 plug-in, and it determines whether the
actual processor is a 68000 or a PowerPC, and jumps into the appropriate
code. It also modifies itself, so if you call that in-memory copy again,
the second time just jumps directly to the correct code.  It handles the
caches on the 68040 correctly.
--
- ------- [e-mail] ----------
"A man hears what he wants to hear and misremembers the rest."
     -- Paul Simon, ("The Boxer")


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

>From [e-mail] (Tommy Brown)
Subject: [Q] Color Notification icon?
Date: Mon, 2 Jan 1995 21:02:11 GMT
Organization: The Dorsai Embassy - New York

NMInstall takes a notification record whose nmIcon is supposed to be a
handl eot a SICN resource, which is black and white only. Yet, obviously,
I have seen applications rotate their color icons in the application
menu. How is this done? I've looked through the sample code and the NIM
on the latest bookmark CD to no avail. Thanks!

--
Tommy Brown                 | When one thing is predicated of another, all
[e-mail]           | that which is predicable of the predicate will
[e-mail] | be predicable also of the subject. -- Aristotle
[e-mail]          | --> finger [e-mail] for ZipIt info <--

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

>From [e-mail] (Brian Clark)
Date: Mon, 02 Jan 1995 16:39:14 -0600
Organization: Value-Added Ltd.

In article <[e-mail]>, [e-mail] (Tommy Brown) wrote:

> NMInstall takes a notification record whose nmIcon is supposed to be a
> handl eot a SICN resource, which is black and white only. Yet, obviously,
> I have seen applications rotate their color icons in the application
> menu. How is this done? I've looked through the sample code and the NIM
> on the latest bookmark CD to no avail. Thanks!

Use GetIconSuite (using svAllSmallData), and set the NMRec's mnIcon field
to the handle you get.

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

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