Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Handles and Virtual Memory
Message-ID: <33464@ucbvax.BERKELEY.EDU>
Date: 4 Jan 90 15:56:08 GMT
References: <9415@hoptoad.uucp> <18300010@ux1.cso.uiuc.edu> <18054@dartvax.Dartmouth.EDU> <9438@hoptoad.uucp> <1669@intercon.com> <33448@ucbvax.BERKELEY.EDU> <1675@intercon.com>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 34

In article <1675@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes:
>OK, now that David has done the Memory Manager, who wants to do the Resource
>Manager :-)?

1.) If you are using X, it has a component called "resource manager",
which, particularly with Motif, will strongly remind you of the Mac and
Rez.

2.) Actually, I already have re-implemented the Resource Manager: Address
Book Plus uses it for its data files. While I was at it, I removed some of
the resource Manager's limits:
	a.) The Resource Manager supports 2 levels of indicies, a 32-bit
	type, and a 16-bit id. My object manager supports an arbitrary
	number of 32-bit indices. (Isn't recursion wonderful.)

	b.) The resource manager uses 16-bit ints, so it can only support
	about 2K objects per file. Mine supports > 2^30 objects per file.

	c.) The R.M. uses linear search to find things, which gets slow
	as the file gets large. Mine uses binary search.

	d.) The R.M. tends to garble files that were not closed properly
	before a crash. Mine uses a back-up list scheme so that you may
	loose the session, but you won't loose the file.

But, this piece of code is one I'm being mercenary about. After all, I
write this stuff for a living. Thanks for giving me this chance to brag.

Probably, on Unix, the right thing to do is to extend the binary program
file with resources. There should be some fairly standard way to do this,
since the linker usually puts symbol table info in the file that is not
normally read into memory when the file is run.  This would keep the whole
shebang in one file, Mac style. Finding your binary cheaply at run-time
seems like a problem, though.