Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!sizzlean!lippin
From: lippin@sizzlean.berkeley.edu (The Apathist)
Newsgroups: comp.sys.mac.programmer
Subject: Re: THINK C 4.0 Upgrade Question
Message-ID: <26762@agate.BERKELEY.EDU>
Date: 29 Jul 89 01:30:52 GMT
References: <4663@tank.uchicago.edu> <2295@husc6.harvard.edu> <3212@internal.Apple.COM>
Sender: usenet@agate.BERKELEY.EDU
Reply-To: lippin@math.berkeley.edu
Organization: Authorized Service, Incorporated
Lines: 27

Recently MAC.ROMOS@applelink.apple.com (Ian Hendry) wrote:
>Does 4.0 do anything about the 32K segment limit?  If the smart linker 
>would not barf on 32K segments before it removed the unused code that 
>would be cool too.  It is really annoying to have to hand cull my general 
>libraries for just those routines that I am actually using so that I can 
>fit the libraries in the segments that they would fit into anyway once the 
>smart linker got at them.  The current implementation kind of defeats the 
>purpose of libraries.

I don't think it's the segment size that's a problem here; it's the
library implementation.  I don't have a need for segments over 32K;
but I would like libraries that were.  So, let's have multi-segment
libraries.

I have another problem with libraries, or at least with included
projects: it's a pain to make and test changes.  It would be much
easier if more than one project could be open at once.  That, together
with using system 7's publish/subscribe mechanism (or something
similar) to track updates would make libraries far more useful to me.

					--Tom Lippincott
					  lippin@math.berkeley.edu

		"If it was so, then it would be,
		 and if it were so, then it could be,
		 but as it isn't, it ain't.  That's Logic."
					--Tweedledee