Flipping Out
I've seen quite a few people comment in blogs that the endian issue I mentioned yesterday won't turn out to be much of an issue. Well, you can't say I didn't warn you about drinking the Kool-Aid, but it you still have some lingering doubts that there isn't a significant number of developers out there who are going to have issues, go wade your way through this stuff.
For a more concrete example, Apple have produced documentation for developers who use PowerPlant. PowerPlant uses various resources to describe the UI objects that are created--windows, menus, dialog boxes, etc. Reading these resources correctly in the context of a universal binary will be crucial. They've included some sample code to flip bytes in PowerPlant resources. It's more than 780 lines of code--780 lines of tedious, byte flipping code.
Now, there are quite a few people who are likely to say that this is really just an extreme example of where byte-swapping is problematic; that, if developers followed all the "rules" they will have no problem. The fact is that these "rules" are nothing more than rules-of-thumb--general guidelines that many developers will disregard for very legitimate reasons.
Consider a drawing program like Adobe Illustrator (I almost said FreeHand--does that date me?). Undo is an important feature in a drawing program. There are two ways to do Undo: save off an entire copy of an object for each user action, or encode user actions as operation codes that can be transacted. In the latter case, you save the object in its original state plus all of the changes the user made to the object as opcodes. Chances are that the opcode solution will result in much smaller files. It does, however, break the "rules" that unknowing people tend to tout when these kinds of discussions arise.
No. The PowerPlant resource example isn't extreme. It's just a common, specific example for which Apple have been kind enough to provide a solution. Anyone shipping serious applications that have not already had to solve this problem for cross-platform scenarios has quite a bit of tedious work to do. While I've welcomed this change for my own circumstances, I don't envy the position in which a number of my compatriots down in San Jose find themselves.
Rick
Currently playing in iTunes: If 6 Was 9 by Jimi Hendrix
Comments
- Anonymous
June 07, 2005
There are sound reasons for why Word/Office didn't switch to Cocoa from Carbon, but would this switch have been easier for you if you had switched to Cocoa? - Anonymous
June 07, 2005
Scott, it would have been easier for Entourage, because they use PowerPlant. For Word, Excel and PPT, the Cocoa vs. Carbon issue is a no-op.
We will, however, have to move from CFM to Mach-O in order to run on Intel machines. We'd already planned on doing this for the next release of Office. I won't say when or if we've already done this, but figuring out when it would make the most sense to switch from CFM to Mach-O isn't rocket science... - Anonymous
June 07, 2005
Funny thing about this switch is that now it makes all the stupidness and lameness in the Mach-O ABI moot. PC relative addressing, not using the RTOC register on PPC are just two examples of non-issues on x86. - Anonymous
June 08, 2005
Our Word importer/exporter used a lot of resources. For Windows compilation we had made it a rule to keep the resources as it is. i.e Big Endian. These were all custom resources and we have not faced any problems while porting. The code base we used was almost 4 years old and we had a working port within a day.
As I went to the Universal Binary document(not completely) it almost reflects the kind of research we did before doing the porting. - Anonymous
June 08, 2005
Anyone claiming "not a big deal" has obviously never done any serious programming. :-)
There is however a canonical format for larger than byte-sized POD integers for all systems having an IP stack, and what do you know - it's big-endian.
Still doesn't ring a bell? ntohs/htons and ntohl/htonl.
For a developer (that uses and needs hex views of memory), big-endian is more logical. If you don't believe me, how many times have you been forced to reverse the byte order of a hex view of memory just to see what (if any) address is referred? For me, it's the wrong side of 10^4 - likely more.
Little-endian has AFAIK but a single thing speaking for it, and that thing is actually more of a source of bugs than a feature - you can treat e.g. a 32-bit int as a 16-bit short on the same memory address, and pray the number isn't larger than 65535. - Anonymous
June 08, 2005
The comment has been removed - Anonymous
June 08, 2005
The comment has been removed - Anonymous
June 09, 2005
Rick,
I agree with you at that point.
In your last topic I had commented that I wish processor would be able to do both the type of calculation.
But your compiler thing is brilliant. Is it something like this
#ifdef ENDIAN_DATA_
struct mystruct{
.......
};
#endif
So whenever you access mystruct data members compiler will put the byte swap code prior to accessing the data. - Anonymous
June 10, 2005
Rajesh,
You're talking about intrinsic compiler support. Unless one has access to the compiler itself, that's not an option.
Rather, what we've done is implement a special compiler that just generates a description of the size of the fields in the data structure (i.e. whether each successive field is 1 byte, 2 bytes or 4 bytes in size). We then have code that will take that description and a pointer to the particular data structure so described, and will swap that data structure accordingly. It saves having to write a byte-swapping routine for every data structure that gets written to the file. With more than 170 such data structures, writing all those byte-swapping routines for Word would have been horribly tedious without this solution.
You still have to call this byte-swapping routine whenever something is either read from or written to disk. The pain is reduced by this solution, but it's not completely eliminated. - Anonymous
June 13, 2005
That Apple example is truly horrible.
A much better way is to override UReanimator::ReadObjects to use a byte-order swapping version of LDataStream (or put optional byte-order swapping into LStream).
Then implement the byte-swapping in methods like
LStream& operator>>(SInt16 &outNum)
The whole point of object oriented is to put the varying code in well-encapsulated classes. Spreading swapping code all over the place goes against that idea.
This way the majority of changed code resides in one class. Other classes, like those that read Ppob resources, need no changes or only minimal ones. - Anonymous
June 15, 2005
Dave Winer is looking for a Mac developer with knowledge of Frontier and MacBird to work on his latest... - Anonymous
June 09, 2009
PingBack from http://jointpainreliefs.info/story.php?id=2486