Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!europa.asd.contel.com!noc.sura.net!haven.umd.edu!ni.umd.edu!ni.umd.edu!zben
From: zben@ni.umd.edu (Ben Cranston)
Newsgroups: comp.sys.mac.programmer
Subject: Re: GetIndString and System 7
Summary: Could still do this for *huge* STR# resource
Message-ID: <1991Jun27.190322.3841@ni.umd.edu>
Date: 27 Jun 91 19:03:22 GMT
Article-I.D.: ni.1991Jun27.190322.3841
References: <1991Jun26.152232.27719@ux1.cso.uiuc.edu> <54390@apple.Apple.COM>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: University of Maryland at College Park
Lines: 17
Nntp-Posting-Host: ni.umd.edu

In article <54390@apple.Apple.COM> nerm@Apple.COM (Dean Yu) writes:

>  GetIndString has always been a glue routine that is implemented by whoever
> sells compilers, so we couldn't really re-write it using Partial Resource
> calls.  At any rate, you can't really use [them] to implement GetIndString
> since ReadPartialResource takes a byte offset from the beginning of the
> resource, and you can't know where a string starts in a 'STR#'.

I think the original poster was thinking more along the lines of truly
*huge* STR# resources, where there might not be enough free memory to read
the whole thing in at once.  I could certainly see an implementation of
GetIndString with a fixed-size buffer (maybe on the lines of 10K or so)
that under most conditions of fairly short resources would be about the same
performance as current versions but would gracefully degrade to skipping
through 10K chunks if necessary.  Dean is correct, however, in saying that
the whole resource (up to the desired string) would have to be read because
you cannot compute where the desired string is going to be.