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

Text File | 1995-06-07 | 44.9 KB | 1,290 lines | [TEXT/R*ch]

Received-Date: Mon, 28 Nov 1994 18:41:32 +0100
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-071
To: [e-mail]
Date: Mon, 28 Nov 1994 18:41:24 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 77

C.S.M.P. Digest             Mon, 28 Nov 94       Volume 3 : Issue 71

Today's Topics:

        (PPC) MDEF's in application code
        Getting The PSN or Sig of AE Client
        Is THINK Pascal dead?
        Newbie Q:Why no DisposeHandle-ReleaseResource call?
        Prograph 2.5
        [Q] Programming with the QuickTime toolkit



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] (Tom Carstensen)
Subject: (PPC) MDEF's in application code
Date: 25 Oct 1994 16:25:54 GMT
Organization: J.P. Morgan & Co


Before PPC, I would load a stub 'MDEF' and set the proc ptr:

typedef struct GenericMDEF {
    short        JMPInstruction;
    void        *defProc;
} GenericMDEF;

   mdefHdl = GetResource('MDEF', 200);        /* sub def */

    (**((GenericMDEF **) mdefHdl)).defProc = myMdefProc;


NOW, with PPC, I'm doing:

    (**((GenericMDEF **) mdefHdl)).defProc = NewMenuDefProc(myMdefProc);

which, with code warrior, creates a new routine descriptor, and sets it up
appropriately.

This does not work.  I've read IM PowerPC System Software - but it's
somewhat confusing.  If I'm defining an accelerated resource, than I need
a routine descriptor that tells what kind of code is ahead.  I thought
the above should work, assuming the menu manager uses CallUniversalProc
to call the menu definition procedure.

BTW - I'm using Code warrior in the above example.

Thanks for any hints.

Tom Carstensen
--
--                    ___
Thomas Carstensen          //__/  60 Wall Street  17th Floor
  [e-mail]      /__//      New York, NY  10260
  [e-mail]      Morgan     212.648.4584

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

>From [e-mail] (Bo Lindbergh)
Date: 31 Oct 1994 16:31:38 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <[e-mail]> [e-mail] (Tom Carstensen) writes:

[mostly correct example of stub MDEF hacking deleted]

Try bracketing the struct definition with alignment pragmas:

    #if defined(powerc) || defined (__powerc)
    #pragma options align=mac68k
    #endif

    typedef struct GenericMDEF {
        short       JMPInstruction;
        void        *defProc;
    } GenericMDEF;

    #if defined(powerc) || defined(__powerc)
    #pragma options align=reset
    #endif

Without them, you'll get two bytes of padding between the short and the
void *.


/Bo Lindbergh

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

>From [e-mail] (Graham)
Date: Wed, 9 Nov 1994 17:02:12 GMT
Organization: N/A

I use the following routines to do this- on 68K macs it defaults to the
old way of creating a stub for the jump, on PowerMacs it creates a
routine dscriptor, so the same code works in all cases. try it.

#include    "MixedMode.h"

typedef struct
{
   short   Jmp;            // jmp instruction
   void*   Routine;        // address to jump to
}
JmpInstructionTemplate;


Handle    GetUniversalFunctionHandle(ProcPtr functionAddress,ProcInfoType
pInfo);
void     PatchJmpInstruction(void* patchAddress, void* jumpAddress);



Handle    GetUniversalFunctionHandle(ProcPtr functionAddress,ProcInfoType
pInfo)
{
    Handle                pHNullProc = NULL;
    ISAType                isa;
    UniversalProcPtr     axDEFUPP;

    isa = GetCurrentISA();

    if (isa == kPowerPCISA)
    {
       pHNullProc = NewHandle(sizeof(RoutineDescriptor));
       axDEFUPP = NewRoutineDescriptor(functionAddress,pInfo,isa);
       BlockMove(axDEFUPP, *pHNullProc, sizeof(RoutineDescriptor));
       DisposeRoutineDescriptor(axDEFUPP);
    }
    else
    {
       pHNullProc = NewHandle(sizeof(JmpInstructionTemplate));
       PatchJmpInstruction(*pHNullProc, (void*)functionAddress);
    }
    return(pHNullProc);
}


void PatchJmpInstruction(void* patchAddress, void* jumpAddress)
{
   JmpInstructionTemplate* aJmpInstructionPtr;

   aJmpInstructionPtr = (JmpInstructionTemplate *) patchAddress;
   aJmpInstructionPtr->Jmp = 0x4EF9;
   aJmpInstructionPtr->Routine = jumpAddress;
}


You have to pass the proc info type for the routine, which youll have
to look up in the universal headers, and the proc ptr to your MDEF
function, it returns a handle which you simply stuff into the relevant
defProc field.
Apple DTS gave me the bones for this, so it even has the "official"
stamp of approval!

************************************************************************
*
MHROTD, Graham.  (Sorry, I haven't got time to think of
                                       a witty signature)

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

>From [e-mail] (Anton Rang)
Date: 10 Nov 1994 14:33:59 GMT
Organization: Trillium Research, Inc.

In article <[e-mail]> [e-mail] (Graham) writes:
>I use the following routines to do this- on 68K macs it defaults to the
>old way of creating a stub for the jump, [...]

  Don't forget the posting last month from someone who had created a
six-byte handle to hold their 'JMP $xxx' instruction and found that
when the handle was moved by the memory manager, the i-cache wasn't
flushed 'cause the handle was too small.  :)
--
Anton Rang ([e-mail])

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

>From [e-mail] (Bruce Hoult)
Date: Fri, 11 Nov 1994 05:15:43 +1200 (NZST)
Organization: (none)

[e-mail] (Anton Rang) writes:
> In article <[e-mail]> [e-mail] (Graham) writes:
> >I use the following routines to do this- on 68K macs it defaults to the
> >old way of creating a stub for the jump, [...]
>
>   Don't forget the posting last month from someone who had created a
> six-byte handle to hold their 'JMP $xxx' instruction and found that
> when the handle was moved by the memory manager, the i-cache wasn't
> flushed 'cause the handle was too small.  :)

I missed that one.

But I've never understood why people use the "six-byte resource" trick
when it's so easy to use a "ten-byte resource" trick that is I-cache
safe.

-- Bruce

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

>From Jonathan Gary <[e-mail]>
Subject: Getting The PSN or Sig of AE Client
Date: Tue, 8 Nov 1994 19:59:50 GMT
Organization: Eastman Kodak

I'm trying to get the the PSN of the process that sends me an AE. I can
get the
address from the event, but how do I get at the PSN?

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

>From [e-mail] (Chris Wysocki)
Date: Fri, 11 Nov 1994 06:52:40 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]>,
Jonathan Gary  <[e-mail]> wrote:

>I'm trying to get the the PSN of the process that sends me an AE. I can
>get the address from the event, but how do I get at the PSN?

The following routine should work:

// ----------------------------------------------------------------------
// CAppleEvent::GetProcessSerialNumber
// ----------------------------------------------------------------------

void CAppleEvent::GetProcessSerialNumber(ProcessSerialNumber& thePSN) const
{
    DescType actualType;
    Size actualSize;
    TargetID theTargetID;

    FailOSErr(AEGetAttributePtr(&fMessage, keyAddressAttr, typeTargetID,
              &actualType, &theTargetID, sizeof(theTargetID), &actualSize));
    FailOSErr(GetProcessSerialNumberFromPortName(&theTargetID.name, &thePSN));
}

I believe that the sending process needs to be running on the same
machine as the target process for this to work, since PSNs are only
unique to a particular machine.

Chris.



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

>From [e-mail] (Jean-Yves Bernier)
Subject: Is THINK Pascal dead?
Date: Fri, 04 Nov 1994 11:14:55 +0100
Organization: SPECTRA Soft


Excuse-me if the topic has already been discussed here (I am a newcomer)
but I have see no such thing in the 100 last articles, and I could not
figure a more suitable group.

I am one of the many THINK Pascal users left in the dark by Symantec, after
the PowerPC. I have thousand of lines of Pascal to port to the PowerPC and
I don't want to loose the advantages of THINK Pascal (the wonderful
source-level debugger, among others).

What is the official status of THINK Pascal? Will ever exist a PowerPC
version? Is it dead? I am a registered user, but I receive absolutely no
information from Symantec. Have they e-mail support?

Thanks.



- -------------------------
Jean-Yves Bernier - SPECTRA
[e-mail]
- -------------------------


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

>From [e-mail] ( nick.c )
Date: Fri, 04 Nov 1994 10:49:30 -0500
Organization: The Pitt, Chemistry


   Yes, very dead.  I would not expect any udates or new versions.
     That said a lot of folks still use it.  It should be possible to
     port your code to CodeWarrrior Pascal (one of the compilers
     included with the CodeWarrior Gold or Bronze CD).  The Gold
     version runs native (fat - I think) and compiles for PPC.


 Internet: [e-mail]            _/   _/  _/  _/_/_/   _/   _/
   eWorld: nick                     _/_/ _/  _/  _/   _/  _/_/_/
      CIS: 71232,766               _/ _/_/  _/  _/       _/ _/
     http://www.pitt.edu/~nick/   _/   _/  _/   _/_/_/  _/   _/


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

>From [e-mail] (Lynda Botez)
Date: 6 Nov 1994 17:36:45 GMT
Organization: U of Wisconsin CS Dept

Er, Think Pascal isn't really dead, it's just comatose.

If you need to convert stuff over to the powerpc, though, I would suggest
you look into CodeWarrior. They actually have a pascal powerpc compiler
(its in beta, but I would imagine it works pretty good)... and I doubt
Symantec will bother with Think Pascal.

Also, I think most of the programmers that developed Think Pascal are now
working for Metrowerks (the company that owns CodeWarrior); so you can
imagine that Think Pascal is not long for this world..


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

>From [e-mail] (John McEnerney)
Date: Sun, 6 Nov 1994 19:11:16 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Lynda Botez) writes:

>Also, I think most of the programmers that developed Think Pascal are now
>working for Metrowerks (the company that owns CodeWarrior); so you can
>imagine that Think Pascal is not long for this world..

For anyone who's interested, the programmers who developed THINK Pascal are:

Me (at Metrowerks these days)
David Neal (director of Symantec's Mac language group)
Rich Siegel (of Bare Bones software fame)
Pete Maruhnic (author of CA's Realizer for Windows)

So only one of us ended up at Metrowerks. Still, the product is pretty
much dead wrt PowerPC, as much my fault as anyone else's: a lot of the
code was written in assembly language, the context-switch mechanism would
probably not survive a port to the PPC, etc. It is rumored that Symantec
still has plans in the Pascal arena (but as you might imagine they don't
tell me that sort of thing anymore)

-- John McEnerney, Metrowerks PowerPC Product Architect


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

>From [e-mail] (Rob Terrell)
Date: 6 Nov 1994 21:26:52 GMT
Organization: Jecta Development Corp.

John McEnerney said:
> So only one of us ended up at Metrowerks. Still, the product is pretty
> much dead wrt PowerPC, as much my fault as anyone else's: a lot of the
> code was written in assembly language, the context-switch mechanism
> would probably not survive a port to the PPC, etc. It is rumored that
> Symantec still has plans in the Pascal arena (but as you might imagine
> they don't tell me that sort of thing anymore)

Yeah, there was a rumor in MacWeek regarding this. I doubt it. The
Symantec folks were real arrogant on the topic of the death of Pascal
at the WWDC.

So, John, what's happening with Metrowerks' Pascal? I would totally
abandon Think Pascal if CW supported an Object Pascal.


Rob

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

>From [e-mail] (Rich Siegel)
Date: Mon, 7 Nov 1994 17:57:38 GMT
Organization: Bare Bones Software

In article <39j47d$[e-mail]> [e-mail] (Lynda Botez) writes:
>
>Also, I think most of the programmers that developed Think Pascal are now
>working for Metrowerks (the company that owns CodeWarrior); so you can
>imagine that Think Pascal is not long for this world..
>

That is not true.

Of the four people most directly involved in the development of THINK Pascal:

- one is at Metrowerks
- one is director of the development tools group at Symantec
- one is off doing something else (I don't recall where)
- one is president and CEO of his own software company

When this question was recently posted to Symantec personnel at a
recent BCS MacTechGroup meeting, the response was (basically) that
they plan to work with certain third-party compiler makers to produce
a Pascal solution for Rainbow (their new development environment that
is currently under development).

R.
--
Rich Siegel % [e-mail]    % President & CEO, Bare Bones Software Inc.
--> For information about BBEdit, finger [e-mail] <--

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

>From [e-mail] (Peter N Lewis)
Date: Tue, 08 Nov 1994 11:23:59 +0800
Organization: NCRPDA, Curtin University

In article <39jhms$[e-mail]>, [e-mail] (Rob
Terrell) wrote:

>Yeah, there was a rumor in MacWeek regarding this. I doubt it. The
>Symantec folks were real arrogant on the topic of the death of Pascal
>at the WWDC.

A Symantec fellow told me that the rumour is crap.  There is no Symantec
plans for a PPC pascal compiler.

>So, John, what's happening with Metrowerks' Pascal? I would totally
>abandon Think Pascal if CW supported an Object Pascal.

You and me both.  I'm strugling on with THINK Pascal waiting for objects
to show up in MW Pascal.  MW Pascal is scheduled to go 1.0 without objects
in January (CW5), and MW Object Pascal is scheduled for CW6 in May (it
better be there, otherwise Greg will have to face down some heckling at
the WWDC :-).

The best you can do to help is to a) make sure MW knows that Object Pascal
is what you need; b) buy MW CW; c) feed any bugs back to the MW bug report
line as precisely as you can.  That's what i've been doing, an Marcel has
been very good at fixing bugs (such that basically every bug I have
reported has been fixed by the next version).

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] (Ingemar Ragnemalm)
Date: 8 Nov 1994 08:17:05 GMT
Organization: (none)

[e-mail] (John McEnerney) writes:

>[e-mail] (Lynda Botez) writes:

>>Also, I think most of the programmers that developed Think Pascal are now
>>working for Metrowerks (the company that owns CodeWarrior); so you can
>>imagine that Think Pascal is not long for this world..

>For anyone who's interested, the programmers who developed THINK Pascal are:

>Me (at Metrowerks these days)
>David Neal (director of Symantec's Mac language group)
>Rich Siegel (of Bare Bones software fame)
>Pete Maruhnic (author of CA's Realizer for Windows)

>So only one of us ended up at Metrowerks. Still, the product is pretty
>much dead wrt PowerPC, as much my fault as anyone else's: a lot of the
>code was written in assembly language, the context-switch mechanism would
>probably not survive a port to the PPC, etc.

MetroWerks Pascal is sort of ok as replacement. It doesn't have Instant,
it's debugger is far from the elegance of Lightsbug, but it works.

But I wonder, why wasn't the debugger integrated with the compiler?
No flames, but I really didn't think a Think Pascal decveloper would
let so many Think C flaw through.

Why mimick the clumsy Think C when Think Pascal is so much better (language
issues aside). Imagine a system where you step and set breakpoints in the
editor, while the editor and the debugger communicated with Apple Events.
I can't see the problem, as long as we don't demand Instant.

>It is rumored that Symantec
>still has plans in the Pascal arena (but as you might imagine they don't
>tell me that sort of thing anymore)

Long ago, I bought Think C. It took several years before I got any feedback
- probably that was after buying Think Pascal. When Symantec now tries to
convince me that I should get SC++, I bought CodeWarrior instead. Much better
C environment, and a future for my Pascal code.

Fortunately, my Think Pascal isn't dead yet. I guess it will stop working
somewhere between 7.5 and 8.0 or so, but not yet.

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

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

>From [e-mail]
Date: 12 Nov 1994 19:55:02 GMT
Organization: Brandeis University

One should also mention that Language Systems is making a very
credible effort at developing an industrial strength Pascal
compiler. Unlike CodeWarrior, the LS version runs under
MPW, which you may or may not find an advantage. But for those
of us who got hooked on Object Pascal before Apple pulled the
rug out from under us, it is the only way to go, since it does
compile Object Pascal while CodeWarrior does not.

   R. Palais

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

>From [e-mail] (Roxanne Friesen)
Subject: Newbie Q:Why no DisposeHandle-ReleaseResource call?
Date: Mon, 07 Nov 1994 11:53:32 -0400
Organization: Bell-Northern Research Ltd.

I'm trying to get a better *handle* on when handles should be disposed of
and resources released.

In the first sample function below, I would have thought that the alias
handle should be disposed of once the resource has been written to the
resource file but this function doesn't do that.  Am I wrong, is this
function wrong, or is it simply not necessary, in this case, to dispose of
the handle? (For the sake of simplifying the samples, assume I'm writing
to my apps own resource fork and not a prefs file of some kind ... or does
that make a difference?)

FUNCTION doCreateAlias(fileSpec:FSSpec):OSErr;
VAR
  alisHandle : AliasHandle;
  result : OSErr;

BEGIN
  result := NewAlias(NIL, fileSpec, alisHandle);
  IF (alisHandle <> NIL) THEN BEGIN
    AddResource(Handle(alisHandle), rAliasType, 128, 'File Alias');
    result := ResError;

    IF (result = NoErr) THEN BEGIN
      WriteResource(Handle(alisHandle));
      result := ResError;
    END;
  END;

  doCreateAlias := result;
END; {doCreateAlias}


In the second sample function below, again, I would have thought that the
resource should be released once I'm finished with it but, again, this
function doesn't do that.  Am I wrong, is this function wrong, or is it
simply not necessary, in this case, to release the resource?

FUNCTION setResStr(rsrcType:ResType; rsrcID:INTEGER; content:STR255):OSErr;
VAR
  rsrcHdl : Handle;
  result  : OSErr;

BEGIN
  rsrcHdl := GetResource(rsrcType, rsrcID);
  result := ResError;

  IF (rsrcHdl <> NIL) THEN BEGIN
    SetHandleSize(rsrcHdl, LENGTH(content) + 1);
    BlockMove(@content, rsrcHdl^, LENGTH(content) + 1);
    ChangedResource(rsrcHdl);
    result := ResError;

    IF (result = NoErr) THEN BEGIN
      WriteResource(rsrcHdl);
      result := ResError;
    END;
  END;

  setResStr :=
result;

END; {setResStr}


Any help, hints, tips, suggestions would be appreciated.
Roxanne.

--
Roxanne Friesen
Bell-Northern Research Ltd.
[e-mail]

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

>From [e-mail] (Matt Jones)
Date: Mon, 07 Nov 1994 19:15:24 +0500
Organization: The Ohio State University

In article <roxanne-0711941153320001@47.221.33.54>, [e-mail] (Roxanne
Friesen) wrote:

> I'm trying to get a better *handle* on when handles should be disposed of
> and resources released.
>
> In the first sample function below, I would have thought that the alias
> handle should be disposed of once the resource has been written to the
> resource file but this function doesn't do that.  Am I wrong, is this
> function wrong, or is it simply not necessary, in this case, to dispose of
> the handle? (For the sake of simplifying the samples, assume I'm writing
> to my apps own resource fork and not a prefs file of some kind ... or does
> that make a difference?)
>
> FUNCTION doCreateAlias(fileSpec:FSSpec):OSErr;
> VAR
>   alisHandle : AliasHandle;
>   result : OSErr;
>
> BEGIN
>   result := NewAlias(NIL, fileSpec, alisHandle);
>   IF (alisHandle <> NIL) THEN BEGIN
>     AddResource(Handle(alisHandle), rAliasType, 128, 'File Alias');
>     result := ResError;
>
>     IF (result = NoErr) THEN BEGIN
>       WriteResource(Handle(alisHandle));
>       result := ResError;
>     END;
>   END;
>
>   doCreateAlias := result;
> END; {doCreateAlias}
>
>
> In the second sample function below, again, I would have thought that the
> resource should be released once I'm finished with it but, again, this
> function doesn't do that.  Am I wrong, is this function wrong, or is it
> simply not necessary, in this case, to release the resource?
>
> FUNCTION setResStr(rsrcType:ResType; rsrcID:INTEGER; content:STR255):OSErr;
> VAR
>   rsrcHdl : Handle;
>   result  : OSErr;
>
> BEGIN
>   rsrcHdl := GetResource(rsrcType, rsrcID);
>   result := ResError;
>
>   IF (rsrcHdl <> NIL) THEN BEGIN
>     SetHandleSize(rsrcHdl, LENGTH(content) + 1);
>     BlockMove(@content, rsrcHdl^, LENGTH(content) + 1);
>     ChangedResource(rsrcHdl);
>     result := ResError;
>
>     IF (result = NoErr) THEN BEGIN
>       WriteResource(rsrcHdl);
>       result := ResError;
>     END;
>   END;
>
>   setResStr :=
> result;
>
> END; {setResStr}
>
>
> Any help, hints, tips, suggestions would be appreciated.
> Roxanne.
>
> --
> Roxanne Friesen
> Bell-Northern Research Ltd.
> [e-mail]

If your compiler is any good, it checks if any of the handles in local
storage are still attached. ( I think ) Otherwise, you would be unable to
find the handles to dispose of them later. However, this is tricky internal
compiler stuff, much like pre-initialized variables. I always explicitly
dispose of handles since the moment you assume your compiler does it for
you, it stops.
- ------------------------------------------------------------------------
| it won't give up it wants me dead | |\  | | |  /| | jones.794          |
| goddamn this noise inside my head | | \ | | | / | |    @ohio-state.edu |
|                   Trent Reznor    | |  \| | |/  | | Stop the Clipper!  |
- ------------------------------------------------------------------------

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

>From [e-mail] (Sigurdur Asgeirsson)
Date: Tue, 08 Nov 1994 09:49:56 -0100
Organization: University of Iceland

In article <roxanne-0711941153320001@47.221.33.54>, [e-mail]
(Roxanne Friesen) wrote:

[snip]

> In the first sample function below, I would have thought that the alias
> handle should be disposed of once the resource has been written to the
> resource file but this function doesn't do that.  Am I wrong, is this
> function wrong, or is it simply not necessary, in this case, to dispose of
> the handle?

[snip]

> FUNCTION doCreateAlias(fileSpec:FSSpec):OSErr;
> VAR
>   alisHandle : AliasHandle;
>   result : OSErr;
>
> BEGIN
>   result := NewAlias(NIL, fileSpec, alisHandle);
>   IF (alisHandle <> NIL) THEN BEGIN
>     AddResource(Handle(alisHandle), rAliasType, 128, 'File Alias');
>     result := ResError;
>
>     IF (result = NoErr) THEN BEGIN
>       WriteResource(Handle(alisHandle));
>       result := ResError;
>     END;
>   END;
>
>   doCreateAlias := result;
> END; {doCreateAlias}
>
>
[second code example snipped for brevity]

  There is no need in this case to dispose the handle, unless the
AddResource call fails, in which case the handle should be disposed of
with DisposeHandle (since the handle is not a resource if the call fails -
see below).
  In general there is no need to dispose of resource handles, because they
are the responsibility of the Resource Manager. Resource handles must
NEVER be disposed of via DisposeHandle, since that confuses the Resource
Manager and you end up with heap corruption. (The Resource Manager does a
DisposeHandle for all loaded resources in a resource file when the
resource file is closed).
  If you feel the need to dispose of a resource handle when you're done
with it (maybe because you'd like to free the memory that the resource is
using) do it with the ReleaseResource call. It's generally better though
to mark your resources as purgeable and leave it up to the Memory and
Resource Managers to free the memory when needed. Be sure however, to use
LoadResource in this case and mark the resource unpurgeable (or lock it)
if you need to be sure that it doesn't "go away" while you're using it.

--
Sigurdur Asgeirsson    | "Well you know, C isn't that hard, void (*(*f[])())()
Kambasel 26            | for instance declares f as an array of unspecified
109 Reykjavik, Iceland | size, of pointers to functions that return pointers to
[e-mail]     | functions that return void... I think"

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

>From [e-mail] (John Selhorst)
Date: Tue, 8 Nov 1994 14:43:55 GMT
Organization: hisself

In article <[e-mail]>,
[e-mail] (Matt Jones) wrote:

[ stuff from Roxanne deleted ]

> If your compiler is any good, it checks if any of the handles in local
> storage are still attached. ( I think ) Otherwise, you would be unable to
> find the handles to dispose of them later. However, this is tricky internal
> compiler stuff, much like pre-initialized variables. I always explicitly
> dispose of handles since the moment you assume your compiler does it for
> you, it stops.

Wrong.  This is not fancy compiler stuff.  The handles Roxanne was
referring to belong to the resource manager and the resource manager will
dispose of them when it needs to.

Johnny

[e-mail]

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

>From [e-mail] (eScott Francisternet alt.bbs.lists alt.bbs.lists.d alt.bbs.majorbbs alt.bbs.metal alt.bbs.pcboard alt.bbs.pcbuucp alt.bbs.renegade alt.bbs.searchlight alt.bbs.unixbbs alt.bbs.unixbbs.uniboard alt.bbs.uupcb alt.bbs.waffle alt.bbs.wildcat alt.beadworld alt.)
Date: Tue, 08 Nov 1994 10:49:31 -0800
Organization: Radius

In article <roxanne-0711941153320001@47.221.33.54>, [e-mail]
(Roxanne Friesen) wrote:

> I'm trying to get a better *handle* on when handles should be disposed of
> and resources released.
>

In both cases the resource handle should be released with
ReleaseResource().  Many programmers have not always done so, particularly
when building apps since the res file will be closed (and all resources
from that file released) when the app quits.  While calling
ReleaseResource() is then not strictly necessary, it is good form, and can
help some types of memory problems.

Another dimension to the problem:  If you will be refetching resources
again and again, you might want to make the preloadable, and *not* release
them.  This will keep them in memory and speed up the calls to
GetResource().

--Scott

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

>From [e-mail] (Matt Mora)
Date: 8 Nov 1994 15:39:07 -0800
Organization: SRI International, Menlo Park, CA

In article <roxanne-0711941153320001@47.221.33.54> [e-mail] (Roxanne Friesen) writes:
>I'm trying to get a better *handle* on when handles should be disposed of
>and resources released.

Simple.  Handle are disposed and Resources are released.

>BEGIN
>  result := NewAlias(NIL, fileSpec, alisHandle);
>  IF (alisHandle <> NIL) THEN BEGIN
>    AddResource(Handle(alisHandle), rAliasType, 128, 'File Alias');

At this point aliasHandle is no longer a plain ol handle. After you
call Addresource the handle you supply becomes a ResourceHandle.

If its a resource handle what are you supposed to do with it? Yep
ReleaseResource.

DON'T CALL DISPOSEHANDLE AFTER YOU CALLED ADDRESOURCE ON THAT HANDLE.

>
>In the second sample function below, again, I would have thought that the
>resource should be released once I'm finished with it but, again, this
>function doesn't do that.  Am I wrong, is this function wrong, or is it
>simply not necessary, in this case, to release the resource?


In the example that was shown, you don't have to call release resource
if you might use that resource again. If you don't want it around
go ahead and call release resource.

If the resource file is closed, the Resource handles will be released.

Xavier











--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

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

>From [e-mail] (Matt Mora)
Date: 8 Nov 1994 15:40:13 -0800
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Matt Jones) writes:

>If your compiler is any good, it checks if any of the handles in local
>storage are still attached. ( I think ) Otherwise, you would be unable to
>find the handles to dispose of them later. However, this is tricky internal
>compiler stuff, much like pre-initialized variables. I always explicitly
>dispose of handles since the moment you assume your compiler does it for
>you, it stops.


Huh?







Xavier

--
___________________________________________________________
Matthew Xavier Mora                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

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

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

In article <roxanne-0711941153320001@47.221.33.54>, [e-mail]
(Roxanne Friesen) wrote:

>In the first sample function below, I would have thought that the alias
>handle should be disposed of once the resource has been written to the
>resource file but this function doesn't do that.  Am I wrong, is this
>function wrong, or is it simply not necessary, in this case, to dispose of
>the handle? (For the sake of simplifying the samples, assume I'm writing
>to my apps own resource fork and not a prefs file of some kind ... or does
>that make a difference?)

First off, you must never call DisposeHandle on a resource handle, nor
ReleaseResource on a non-resource handle.  Bad THings(tm) will happen.
There are a pair fo inits (DoubleTrouble and DisposeResource or some such)
that catch bugs like this, available from ftp.apple.com:/mac/dts/ I
believe.

Second, when you write a resource to a file, it's not necessayr to release
it afterwards, since it will be automatically released when the resource
file is closed (which tends to be quite soon afterwards anyway).  Also,
you can set the handle to be purged (HPurge) and then it'll be released
when memory is needed, but not until.  Make sure to call GetResource again
to reload the (possibly) purged handle before reusing it.

Enjoy,
   Peter.
--
Peter N Lewis <[e-mail]> - Macintosh TCP fingerpainter

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

>From [e-mail] (David C. Fallside)
Subject: Prograph 2.5
Date: 10 Nov 1994 06:39:19 GMT
Organization: a2i network

I recently accepted a $59.95 offer for Prograph 2.5. The promo blurb "Very
High Level Pictorial Object-Oriented Programming Environment" seems to be
accurate, and having worked my way through half of the tutorials, it seems
that it should be possible to develop complex applications. But I'm not a
professional programmer, and haven't found anyone else who has ever heard
of Prograph. Any comments from Netland? Thank you.
David

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'd rather be on the river ....
K1/4, SQRT/3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

>From [e-mail] ( nick.c )
Date: Thu, 10 Nov 1994 11:42:38 -0500
Organization: The Pitt, Chemistry

In article <[e-mail]>, [e-mail]
(David C. Fallside) wrote:

> I recently accepted a $59.95 offer for Prograph 2.5. The promo blurb "Very
> High Level Pictorial Object-Oriented Programming Environment" seems to be
> accurate, and having worked my way through half of the tutorials, it seems
> that it should be possible to develop complex applications. But I'm not a
> professional programmer, and haven't found anyone else who has ever heard
> of Prograph. Any comments from Netland? Thank you.


   Prograph was my first environment (not counting hypercard), and
      I consider that a mistake.  Don't get me wrong - prograph is
      both a great concept and a great engineering feet.  I still
      argue that inconic input will be the way we'll all code 10 years
      from now (or sooner).  However, prograph is a dual mode environment,
      it allows you to program at a low level, but defaults to a high
      level environment by use of it's integrated class library.
      As a result, and with the added factor there is very little
      sample code or literature, it's hard to tell where the library
      ends and the toolbox begins.  You can generate nice (albeit
      large and slow) apps with 2.5.2 - nicer ones with CPX - but
      you won't learn anything about Mac programming with it.

   To learn how to program the Mac you'll need to learn a classical
      low level language (Pascal or C would be best), and when you do
      you'll find you can generate much smaller, faster binaries and
      have access to a wealth of established library code and example
      code from all over the world.  My guess is most "professional"
      programmers, don't want to give up those advantages.

   Prograph was marketed as a non-programmers programming language, and
      I think that's still true.  However, as I said above, it does
      allow low level coding, is very powerfull, and has the best
      interface and debugger I've ever seen.  It's a glimpse of the
      future of programming, and worth knowing, just remeber you
      get paid in the present.


 Internet: [e-mail]            _/   _/  _/  _/_/_/   _/   _/
   eWorld: nick                     _/_/ _/  _/  _/   _/  _/_/_/
      CIS: 71232,766               _/ _/_/  _/  _/       _/ _/
     http://www.pitt.edu/~nick/   _/   _/  _/   _/_/_/  _/   _/


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

>From [e-mail] (Peter Jensen)
Date: Thu, 10 Nov 1994 16:53:40 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (David C. Fallside) writes:

>I recently accepted a $59.95 offer for Prograph 2.5. The promo blurb "Very
>High Level Pictorial Object-Oriented Programming Environment" seems to be
>accurate, and having worked my way through half of the tutorials, it seems
>that it should be possible to develop complex applications. But I'm not a
>professional programmer, and haven't found anyone else who has ever heard
>of Prograph. Any comments from Netland? Thank you.
>David

Prograph 2.5 is the predecessor of Prograph CPX 1.x, which is the
Prograph development environment with all the bells and whistles.  $60 is
a great price for 2.5 which has the full language implementation found in
CPX.  CPX has a rich class library a'la TCL/MacApp and a user-modifiable
GUI Builder.

I use Prograph full-time to develop complex commercial applications.
There are some very intriguing apps with high-volume potential being
developed in Prograph right now.  Prograph has arguably one of the best
debuggers ever implemented (in the interpretive mode).  There is an
optimizing compiler that generates stand-alone apps.  The code isn't as
fast or tight as C/C++ but you get RTTI, garbage collection, automatic
deref of handles/pointers, cool list management stuff, and of course, a
gorgreous visual syntax that prevents syntax errors via constrained input.

Visual Programming is for real; and Prograph is the most "real" of the new
generation.  It's one of the things that makes the Mac a special
development platform.  Sometime next year there will be a Windows Prograph
and the framework will become cross-platform.  Plus they're developing
DAL/SQL database tools that will allow you to do everything you can do in
Omnis/4D but drop into Prograph if you want real programming power.  For
compute-bound operations it's fairly straightforward to import external
primitives written in C if you feel the need for speed.  In normal usage,
you can't tell whether well-crafted apps were written in Prograph or C++
(well, maybe you can, since they're delivered earlier!).

I'm very happy with Prograph.  net.persons interested in Prograph can join
the commotion over on comp.lang.prograph.  Also, Kurt Schmucker of Apple's
ATG has written an extensive review of CPX in November's MacTech.  Look
for more Prograph articles in coming issues.

Peter Jensen                                  [e-mail]
Pepper Tree Design, Inc.                      Santa Clara, CA
   "Software crafted from the choicest of electrons" (tm)

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

>From [e-mail] (Howard Berkey)
Date: 10 Nov 1994 17:03:19 GMT
Organization: Premenos Corp

In article <[e-mail]>,
David C. Fallside <[e-mail]> wrote:
>I recently accepted a $59.95 offer for Prograph 2.5. The promo blurb "Very
>High Level Pictorial Object-Oriented Programming Environment" seems to be
>accurate, and having worked my way through half of the tutorials, it seems
>that it should be possible to develop complex applications. But I'm not a
>professional programmer, and haven't found anyone else who has ever heard
>of Prograph. Any comments from Netland? Thank you.
>David
>




I've never used it myself but it gets a lot of praise from those who
have.

You might want to check out comp.lang.prograph... I'm sure you'll get
a lot of info there.

-H-










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

>From [e-mail] (Ladan Gharai)
Subject: [Q] Programming with the QuickTime toolkit
Date: 2 Nov 1994 18:52:59 -0500
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742


Hi everyone

I am new to the QuickTime and am trying to understand how it works. I have
a bunch of questions and would appreciate any answers. I need to write a player
with very specific functionality. Going through the Inside the Mac: Quicktime
I have the following questions:

1. A sample is defined as "A single element of a sequence of time-ordered
   data" does this mean that for a vedio a sample would be a frame?

2. What function calls should I use to be able to access a single frame? In the
   Inside the Mac it says that a programmer can access every frame. How?

3. Where does QuickTime store information about the frame rates (fps) of a movie?
   For example the frame rate that a movie was created with?

4. Is there a realtionship between frame rate (fps) and playback rate?

5. When QuickTime does not have enough time to display all the frames of a
   movie, it starts dropping frames. Is there a pattern to this frame dropping?
   For example does it drop everyother frame, or the third in every 3 frames?
   How does it decide which frames to drop?



thanx
Ladan

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

>From [e-mail] (Richard Gerber)
Date: 2 Nov 1994 19:44:03 -0500
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742

I am interested too.  But specifically: from within a quicktime player is there
any way to dynamically determine -- as the movie is playing -- which particular
frames are being dropped.

If not, what's the lowest level of granularity I can get to?

rich

- ----------

Richard Gerber
Assistant Professor

Department of Computer Science
University of Maryland
College Park, MD  20742 USA

Email:   [e-mail]
Tel:     [phone]
FAX:     [phone]



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

>From [e-mail] (Ivan Cavero Belaunde)
Date: 8 Nov 1994 00:00:42 GMT
Organization: Avid Technology, Inc.

In article <3998qv$[e-mail]>, [e-mail] (Ladan Gharai)
wrote:
> Hi everyone
>
> I am new to the QuickTime and am trying to understand how it works. I have
> a bunch of questions and would appreciate any answers. I need to write a
player
> with very specific functionality. Going through the Inside the Mac: Quicktime
> I have the following questions:
>
> 1. A sample is defined as "A single element of a sequence of time-ordered
>    data" does this mean that for a vedio a sample would be a frame?

Yup.

> 2. What function calls should I use to be able to access a single frame?
In the
>    Inside the Mac it says that a programmer can access every frame. How?

If I want the sample at time 10 on the first track:
   theTrack = GetMovieIndTrack(theMovie, 1);
   theMedia = GetTrackMedia(theTrack);
   mediaTime = TrackTimeToMediaTime(theTrack, 10);
   if (mediaTime != -1) {
      err = GetMediaSample(theMedia, sampleDataHandle, 0, &sampleDataSize,
            mediaTime, nil, nil, sampleDescriptionHandle, nil, 1, nil,
            &sampleFlags);

>
> 3. Where does QuickTime store information about the frame rates (fps) of
a movie?
>    For example the frame rate that a movie was created with?

It doesn't since the frame rate can vary over time throughout the movie.
You can estimate it by walking each track by track edits via
GetTrackNextInterestingTime and then figuring out the frame rate for each
edit by looking at the edit rate for each edit as well as the durations of
the samples spanned by the edit.

> 4. Is there a realtionship between frame rate (fps) and playback rate?

I'm not sure what you mean here. The QuickTime movie will never play at a
better rate than its original stored rate - additionally, it is eminently
possible to create a movie with too high a stored frame rate that will not
play properly and will drop frames.

> 5. When QuickTime does not have enough time to display all the frames of a
>    movie, it starts dropping frames. Is there a pattern to this frame
dropping?
>    For example does it drop everyother frame, or the third in every 3 frames?
>    How does it decide which frames to drop?

A movie has a "running clock" that tells it what "time" it is within the
movie. When falling behind, QT will drop as many frames as necessary to
catch up the frame being displayed with its running clock. The results are
dependent on boatloads of factors, such as the horsepower of your machine,
the bandwidth of your storage device, the seek speed of your storage
device, the compression scheme used, the frame-differencing
characteristics of the movie, and where within the movie the "playback
head" is. There's no simple answer, sorry.

Hope this helps. Followups redirected to comp.sys.mac.programmer.

-Ivan
- --
Ivan Cavero Belaunde ([e-mail])
Avid VideoShop Lead
Avid Technology, Inc.
Disclaimer:  All views expressed are entirely my own and do not
reflect  the opinions of Avid Technology, Inc.

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

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