dce@smsc.sony.com (David Elliott) (09/05/90)
As a Unix programmer, I've learned that it is usually a bad idea to write the contents of a struct to a file, since there is no way to know if every machine can read it back correctly. As you may already know, data written on a big-endian machine, such as a 680x0, will have a different format than on a little-endian machine, such as a Vax or a DEC MIPS-based machine. In addition, machines may have different alignment rules. For example, a Sun 3 (68020) allows a long (32 bit integer) to be aligned on half-word (16-bit) boundaries, whereas the SPARC-based machines require full-word alignment. As a result, a struct written on a Sun 3 may have to be handled specially when read back on a Sun 4 (a typical method is to define the struct as containing shorts and then convert the shorts to longs by copying). Is it common practice to read and write structs as resources on the Mac? If so, is there any worry that these resources will not be compatible if Apple were to go to a platform with different alignment restrictions (I assume byte order isn't an issue)? If not, what is the recommended procedure for putting lots of data into a resource and getting it back easily? -- ...David Elliott ...dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce ...(408)944-4073 ...Krusty says: Give a hoot, read a book!
hawley@adobe.COM (Steve Hawley) (09/06/90)
In article <1990Sep5.145717.13291@smsc.sony.com> dce@smsc.sony.com (David Elliott) writes: >Is it common practice to read and write structs as resources on the >Mac? If so, is there any worry that these resources will not be >compatible if Apple were to go to a platform with different alignment >restrictions (I assume byte order isn't an issue)? If not, what >is the recommended procedure for putting lots of data into a resource >and getting it back easily? OK - as far as reading/writing structures is concerned, you should have no problem doing this on the Macintosh platform, since they have done remarkably well in maintaining compatability. Famous last words, but I say go ahead because a change in the operating/file system that causes a change in byte ordering will break a HUGE number of applications --more than such a change could possibly help. The biggest danger to you is your compiler/interpretter changing the way it allocates structures. If you're really terrified, remmeber that you can always break the structure down to the byte level (since bytes are bytes, right?) piecemeal from the elements and put the resulting bytes into a buffer, then ship it out to disk. This is of course, tedious and slow (but surely not slower than the bottleneck of your bulk storage). As far as "putting lots of data into a resource", please do not stumble into the habit of using the resource fork of a file as a pigpen for data. The reason being that 1) any custom data format will be managed much more efficiently by you 2) if you try to write an application that writes into its own resource fork, you will have endless problems working with a fileserver. Remember, the data fork of a file is for data. Steve Hawley hawley@adobe.com -- "I can always telephone, but I can't tell it much." -Roy Blount
pepke@gw.scri.fsu.edu (Eric Pepke) (09/07/90)
In article <1990Sep5.145717.13291@smsc.sony.com> dce@smsc.sony.com (David Elliott) writes: > Is it common practice to read and write structs as resources on the > Mac? Yup. > If so, is there any worry that these resources will not be > compatible if Apple were to go to a platform with different alignment > restrictions (I assume byte order isn't an issue)? Apple has done a rather remarkable job of keeping compatibility across the line. So far the alignment on newer machines has become more lax rather than more restrictive. Even if this were to change, the ability to read structures from resources is so basic that compiler writers would have to build in transparent compatibility measures. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.