[Dalgo]

I am trying to learn the Quicktime API's because I am creating a video, frame by frame, programmatically. My code to generate frames is finished and works fine but I don't want to have a folder full of frame images, I want to put them together into one movie; that's why I need to use Quicktime.

Anyway, in the Quicktime functions There is a data type called Handle. There are also lots of other things that have handle in their name. So... what is a handle? Is it a pointer? It doesn't seem to be used like a pointer. I can't find this anywhere. Also, what is up with all of the pascal crap that is all over the place?

[aleph_null]

Yay, something I can actually post about ... (I'm a Carbon developer, and most discussions 'round here are about Cocoa...)

A handle is a pointer to a pointer to some data. The idea is that the system maintains the data in a heap somewhere, and may sometimes need to move data within the heap to manage things efficiently (heap compaction and so forth). When this is going to happen can't be guaranteed, and doing so while clients have direct pointers to the data would of course be bad, so there's a level of indirection. Your pointer is the address of a pointer, which the system owns and so can update when needed.

By the way, all of this is documented, but it's mostly in the old Inside Macintosh books, which are available on Apple's site. They're rather out of date, but some of it's still applicable, and necessary to understand Carbon.

(Also note that in Carbon, with the advent of API opacity, a Handle isn't necessarily a handle anymore. The MenuHandle type, for example, is actually (currently) an index. This doesn't change the way the APIs are documented to work, but you shouldn't assume the handle-ness of a Handle when opaque types are involved. (A MenuHandle may be odd, for example.))

The pascal stuff is legacy, from when the Mac toolbox and apps were written in pascal. The pascal keyword means that the compiler should use pascal calling conventions, rather than C calling conventions, for the function typed as pascal. I wouldn't think that Carbon.framework actually has any pascal code, but CarbonLib might, in places. And anyway, the Universal Headers need to be compatible with non-Carbon builds, too.

HTH

[Dalgo]

Okay, this is strange. Does this mean that I can't use malloc? I mean, if memory is managed in a heap in Carbon, and the heap can be defragented and whatnot, then it seems like I wouldn't be able to use malloc since whatever I malloced could move. I might guess that I could malloc stuff and that it'd be allocated in a different zone than the heap where the rest of the stuff goes but I'd think that would break classic compatibility, not that I care about that too much. I saw some functions to lock the place of stuff in the heap. Could you give me some general guidelines on Carbon memory management?

[Wixar]

When you use malloc (or NewPtr) you get some memory that the OS will not move. That can make memory management easier for you, but it means that you risk fragmenting your memory. NewHandle allocates some memory that the OS can move. This can make memory management more difficult for the programmer, since he or she has to worry about locking the handle at the appropriate times, but it means that apps often can run in less memory since it uses memory more efficiently.

Here's some guidelines for memory management for carbon and classic apps:

Use NewHandle instead of NewPtr or malloc whenever possible.
Allocate your memory early to reduce fragmentation.
Lock your handles when you dereference a Handle and cache its pointer (called the master pointer). It's not necessary to lock the handle when you simply dereference it. From what I've seen, most programmers lock handles too often.
Allocating memory in the system heap (e.g. NewSysPtr, I think it's called) is fine when you need a large chunk as long as you're sure it's only temporary. Don't be like IE and fragment the system heap.

All of that is only true under Mac OS 9 and below. Under Mac OS X, you don't have to worry about it.

[ryochiji]

Also, because Handles may not be handles in MacOS X, passing them to functions like DisposeHandle may crash your app, even if it works okay in Classic.

With regards to QuickTime however, you shouldn't have to worry whether it's a handle or an index. A MediaHandler is a MediaHandler, and you shouldn't try and use it as anything else. In fact, QuickTime API's are very easy to use because in most cases, all the variable types used are defined and there are conversion routines as well (for an example, GetMediaHandler() gets you a MediaHandler from a Media).