Path: utzoo!attcan!uunet!lll-winken!xanth!ames!mailrus!tut.cis.ohio-state.edu!ucbvax!UIAMVS.BITNET!AWCTTYPA From: AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") Newsgroups: comp.sys.apple Subject: why resources are good (GS) Message-ID: <8902061835.ac01435@SMOKE.BRL.MIL> Date: 7 Feb 89 00:40:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 71 X-Unparsable-Date: Monday 06 Feb 89 4:46 PM CT >Date: Sun, 5 Feb 89 06:32:10 GMT >From: Christopher Hassell >Subject: Re: Why resources on the GS will be _great_ >I'm for actually putting ALL of the true user-interface >object-templates up for grabs in it. How about having ALL objects >definable there, with defaults if not mentioned? Anything can be put in a resource. If the system doesn't support it directly, the application can still invent its own type of resource, but of course things are nicest when there's a system-defined standard for a particular kind of object. I don't know whether defaults are typically stored in the resources on the Mac or not, but it would certainly be a Good Thing. If it's not supported automatically in general, applications can still do a little work and keep defaults in separate resources. >NOW my main concern is this... Is it SMALLER? The calls and their >setting up and their actual code are rather tedious but IS IT BETTER? >If it is, as it certainly could be, compressed and optimized as a >list of object-creations w/little proc-codes or something then I'd >certainly vote for that! Many resources are just templates to be loaded into memory; these take the same space that the same templates would take if they were hard-coded into the program in the first place. But most Pascals don't provide a way to hard-code data structures, so more code is needed--resources will eliminate the need for setting up data structures that are set up clumsily in some high-level languages. It will make things smaller in some cases because the resources can be loaded from disk automatically when needed rather than loaded as part of the program. (But applications can load the resources all at the beginning to avoid causing extra disk swaps.) >That is certainly a hot option! Making code modular in its CODE >form, no less. Companies could come along and simply give you little >patchers to upgrade to the just-released-wild-new-machine-x for their >entire line. That kind of "carrying-ROM-with-you" may be a bit large >on the size side. Ideally (and in most cases) applications are compatible with future machines just by following the rules. There are certainly plenty of interesting ways to use code in resources, though. I suppose it remains to be seen whether people will organize their applications well enough that they can change big things about their programs by adding or replacing code segments. More typically they will probably be used where the modularity is already built into the application/etc somehow. >My other question is whether or not this would tax the already-loaded >processor speed and, not to mention, memory images. Adaptible code >that can be "inserted" once for machine-configuration would become >more common, BUT do all of these things need 1200K more in the >operating system? I don't know how much RAM the Resource Manager will take...we'll see. Overall I expect RAM requirements will go _down_ at the expense of doing more disk access during an application. I hope either the system or applications will provide the option of automatically loading all the resources (or all the _appropriate_ resources) into RAM when the application starts up, marking them "purgable" in memory so that no extra disk access is needed mid-application unless you're actually running out of RAM. >### C>H> ### --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons