tedj@hpcilzb.HP.COM (Ted Johnson) (02/03/88)
Did Apple invent the concept of "handles"? (A handle is a pointer to a pointer; it is used for memory management purposes) Do other small computers (IBM PC, Atari, Amiga, etc.) use handles? Do people ever use handles in a Unix environment? Most Unix programmers I talk to have never heard of a "handle"... -Ted
chuq@plaid.Sun.COM (Chuq Von Rospach) (02/05/88)
>Did Apple invent the concept of "handles"? Nope. they've been around for a long time. >Do other small computers (IBM PC, Atari, Amiga, >etc.) use handles? They can. The Mac was the first major machine that required. >Do people ever use handles in a Unix environment? >Most Unix programmers I talk to have never heard >of a "handle"... How about: main(argc,argv) int argc; char **argv; This is a pointer to an array of pointers to arrays of char. To do a setenv, you basically re-arrange the array or pointers to the new strings, but the handle (the char**) doesn't change. chuq Chuq Von Rospach chuq@sun.COM Delphi: CHUQ What do you mean 'You don't really want to hurt her?' I'm a Super-Villain! That's my Schtick!
rs4u+@andrew.cmu.edu (Richard Siegel) (02/05/88)
"(A handle is a pointer to a pointer; it is used for memory management purposes)" It's more than just a pointer to a pointer. A handle's a pointer to a "master pointer", that points to a relocatable block in the Mac's heap. The memory manager can move this relocatable block at its leisure (unless the application explicitly requests that it stay in one place), and whenever it moves this relocatable block, it simply updates the master pointer. Since the pointer in your program always points to this master pointer, doing a double indirection will always get you to your data. It's also worth noting that these master pointers aren't randomly scattered through memory, either; they're grouped into "master pointer blocks"; in the system heap, a master pointer block contains 32 master pointers; in the application heap, a master ptr block contains 64 master pointers. In a Unix environment, I suspect, the memory management is not based on relocatable chunks of memory; rather, chunks are swapped in and out, and the memory manager keeps track of where they get swapped to and never moves them. (This is known as demand paging, I think.) I don't know how small non-Unix 68000 systems behave. On the Intel machines such as the IBM PC, the memory is "segmented" into 64K pages. I'm not sure how dynamic memory management is handled, though... --Rich
mz@well.UUCP (Michael Zentner) (02/08/88)
In terms of straight "C" programming, a Handle is just a pointer to a pointer. Unix programmers use them all the time but don't call them handles. On the Mac a handle carries the extra connotation that it may refer to a block of relocatable memory. The stuff in memory moves around but the handle is constant.
lawrence@bbn.COM (Gabriel Lawrence) (02/10/88)
(Michael Zentner) writes: >In terms of straight "C" programming, a Handle is just a pointer to a >pointer... Not to point any fingers but I've yet to see anyone answer this question directly. The above statement is incomplete, substituting "Pascal" or "Assembly Language" or "Forth" for "C" would have precisely the same connotation. Although the simplest way to represent the Handle as a data structure in 'C' is to use 'typedef char **handle', that does not take the complete definition of a handle into consideration. A handle is defined as a pointer to a master pointer which points to a relocatable block of memory. Because the memory manager may relocate these blocks of memory at it's own convenience, a programmer must always be aware that his/her dereferenced pointer to his/her data may or may not still be valid. A data structure which was truly representative of a handle would have to include references to master pointers, lock/unlock bits and all that nonsense. Of course to preserve a transparent memory management interface (ie. to allow software to retain compatibility whether or not a MMU is utilized) you are better off 'hiding' portions of your data structure (such as the lock/unlock mechanisms) and providing data structure specific subroutines or macros which manipulate certain portions of your elementary data structure (Right Apple??!! :-) ). I'm beginning to ramble but I hope my point is clear - the method (or language) by which access to a data structure is used does _not_ necessarily define the actual structure of the data. Now then, who can cite actual instances where a handle-based data structure has been used within a contemporary operating system? Extra points awarded if you can also cite the data structure (in any language) used to represent it. =Gabe Lawrence= USENET: ...!harvard!lawrence@bbn.com =BBN Communications= INTERNET: lawrence@BBN.COM
gpollice@eagle_snax.UUCP ( Sun ECD Software) (02/11/88)
Actually, the concept of handles came from Xerox PARC many years ago.
A handle is exactly what it's name implies, something which is used to
grab onto something else. If you make the assumption that a handle
is always a pointer to a pointer, you may get burned when someone else
uses a handle to hide information. For example, I have worked with a
scanner for a compiler which encodes all information about the token
in a TokenHandle, which is just 32 bits of information. If I tried to
use this as a pointer, my program would crash very quickly.
--
Gary F. Pollice | Remember the Wang Institute!!
Sun Microsystems | ARPAnet: gpollice@sun.com
Two Federal Street | UUCP: {decwrl,ihnp4,hplabs,ucbvax}!sun!gpollice
Billerica, MA 01821 | (617)671-0374oster@dewey.soe.berkeley.edu (David Phillip Oster) (02/13/88)
In article <245@eagle_snax.UUCP> gpollice@eagle_snax.UUCP ( Sun ECD Software) writes: >Actually, the concept of handles came from Xerox PARC many years ago. Long, long before PARC ever existed, back in the '50s, Burroughs (now Unisys) used this technique, like the Mac does, to manage all of memory. Only, instead of a "master pointer" they called the same thing a "mother descriptor". Their multi-tasking system allocated everybody's segments out of the same heap. I've been wondering why multi-finder gives each application its own heap instead of letting them all compete for pieces of a single heap. Probably because more bad old applications would not have run. --- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II. Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu