[net.sources.mac] Misinformation on C strings???

jww@sdcsvax.UUCP (Joel West) (07/29/85)

With regards to making C programs work (particularly under Megamax C),
the claim has been made that it is not possible to use RMaker to produce
a C string.  (For those who'v been in a cave, Lisa Pascal begins its strings
with a 1-byte length, and standard C ends its with a 0 byte).

I don't know if this is a question or an observation, but I don't think
this is really true. (OOPS).  As I had something to do with this belief,
I'm not sure what to say. :-(

For example, the recently posted SKEL goes to great length to get around
this supposed "bug":

>       v2.2.1C April 1,1985 whj:Added in-place conversion of Pascal strings
>       			       to C strings for the string resources.  Uses
> 			       new procedure "initStrRes", included in
> 			       this file.  This is a kludge required because
> 			       the RMaker program supplied does not
> 			       support C-Style strings.  v. 2.0 of Megamax C
> 			       is different in its handling of string
> 			       resources than v. 1.2, which necessitated this
> 			       change.  Strings resources must not be 
> 			       purgeable for this to work.  Also modified the
> 			       header file "qdvars.h" which was supplied with
> 			       Megamax C v. 2.0.  Use the new version in place
> 			       of the Megamax version; the interface will be
> 			       similar to the Lisa Pascal interface.
> 			       
> /*
> ############################   initStrRes   ##############################
> Changes strings in Resource Fork to NULL-terminated C formatted strings.
> All strings in Resource Fork must be unpurgeable for this to work.  Sorry.
> Perhaps this can go away when Apple provides an RMaker program that supports
> C strings.
> */
> 
> initstrres()
> {
> 	int i, numstrres;
> 	stringhandle str;
> 	numstrres = CountResources ("STR ");	/* Count the strings */
> 	for (i=1; i<=numstrres; i++)
> 	{
> 		str = GetIndResource ("STR ", i); /* Get Handle to string */
> 		ptocstr(*str);		/* Convert in place to C string */
> 	}
> }

However, with all the nifty resource editors shipped on the "May" supplement,
I thought I'd try one last time.  My "RMaker" has a fancy icon and the
"Get Info" says version 2.2, 10/18/84.  I fed it this program:

		text.exe


		type TEXT = GNRL
		 ,257
		.S
		Hello, world\00


		type TEXT = GNRL
		 ,258
		.S
		This is a simple string!\00

Nothing terribly exciting about that.  What I ended up with, according
to Redit, was two strings of resource type "TEXT", each beginning with
a capital letter and ending with $00.

Now, unless I miss my guess, Rmaker will handle C strings, albeit
manually.

	Joel West	CACI, Inc. - Federal (c/o Gould CSD)
	{decvax!sdcsvax,ihnp4!bonnie}!gould9!joel
	gould9!joel@NOSC.ARPA		(also joel@NOSC)

PS: Does anyone know a way (without writing a program) to convert
    to/from the Lisa RMAKER format (which REDIT, Dialog Creator
    use) and the MDS (Megamax) Format?  The differences seem
    primarily in the ordering of DLOG and WIND parameters.

bill@utastro.UUCP (William H. Jefferys) (08/02/85)

Joel West suggested the following method for creating C-style 
null-terminated resource strings:

> 		text.exe
> 
> 
> 		type TEXT = GNRL
> 		 ,257
> 		.S
> 		Hello, world\00
> 
> 
> 		type TEXT = GNRL
> 		 ,258
> 		.S
> 		This is a simple string!\00
> 
> Nothing terribly exciting about that.  What I ended up with, according
> to Redit, was two strings of resource type "TEXT", each beginning with
> a capital letter and ending with $00.
> 
> Now, unless I miss my guess, Rmaker will handle C strings, albeit
> manually.

The string can then be obtained using

	astrng = getresource("TEXT",id);

Many thanks to Joel for this *vast* improvement.  Except for one
thing (see below), this seems to solve the problem of getting C
strings into RMaker.  I will post a new version of SKEL incorporating
this idea in due course.

Before I do so, however, I'll mention a problem that Joel would not have
noticed with the strings he used, but which does exist with the strings
in SKEL.  That is, if the string includes periods (decimal points -
ASCII 2E) then the RMaker program as distributed with Megamax C will
not work properly.  It compiles a garbage string into the resource
fork.

I tried various obvious ways to get around this: \2E, \., \2\E, etc., 
none of which worked.  The only way I could figure to get around this
was to switch over to Hex (.H) mode in the middle of the string, drop in
the desired byte, then switch back to String (.S) mode, as follows:

.S
Here is the first part of the string
.H
2E
.S
  And here is the rest of it!\00

If anyone knows a better way to do this, I would like to incorporate
it in the new SKEL.  If no one can come up with a better idea within
the next week or so, I will post the version I have working now.  In
the meantime, you might want to experiment with this.

Can anyone at Apple address this?  The version of RMaker being used
is Andy Herzfeld's version dated 10/18/84.


-- 
"Men never do evil so cheerfully and so completely as when they do so from
	religious conviction."  -- Blaise Pascal

	Bill Jefferys  8-%
	Astronomy Dept, University of Texas, Austin TX 78712   (USnail)
	{allegra,ihnp4}!{ut-sally,noao}!utastro!bill	(uucp)
	bill%utastro.UTEXAS@ut-sally.ARPA		(ARPANET)