 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / CodeWarrior / November 2005ppob's & byte-swapping
Folks, Greetings! What are people doing about byte-swapping PPOB's? The shift to Intel is looming. I guess that my preference would be to detect any mis-match situation early, e.g. during application initialization, & swap the whole global PPOB space & re-store them all in the new endian kind of way. At this point, my plan (sketched on a napkin admittedly) is to have an 'endian' resource (whose absence equals ppc). That resource would be accessed before any PPOB &, if at odds with the endianness of the code, the PPOB s of the application would be transversed, modified & stored. My sketch includes adding a second stored function to URegistrar::RegisterClass. This second function would be ByteSwapPPOB or some such. Then each PPOB's classes would know how to byte-swap itself as it currently knows how to create itself. Does this make any sense? Is anyone else doing anything similar? Is anyone else taking a different approach? Peace, Bob We are cups, constantly and quietly being filled. The trick is, knowing how to tip ourselves over and let the beautiful stuff out. - Ray Bradbury > What are people doing about byte-swapping PPOB's? The shift to Intel > is looming. I guess that my preference would be to detect any > mis-match situation early, e.g. during application initialization, & > swap the whole global PPOB space & re-store them all in the new endian > kind of way. You need to read the appendix on PowerPlant in <http://developer.apple.com/documentation/MacOSX/Conceptual/universal_bi nary/>. > > What are people doing about byte-swapping PPOB's? The shift to Intel > > is looming. I guess that my preference would be to detect any [quoted text clipped - 5 lines] > <http://developer.apple.com/documentation/MacOSX/Conceptual/universal_bi > nary/>. As you can imagine, I've seen that appendix. Altho it has a lot of useful code that would find its way into a plan such as mine, it had a couple of problems. The first & most obvious: It only covers the standard PP classes. Unfortunately, there is a more fundamental problem. This endian situation is not going away. We cannot plan for a transitional patch with a lifetime of a year or two. We will alway be confronting the issue of our software being installed on one architecture and then moved to a computer of the other architecture. Which means that the case statement at the heart of the universal_binary example code will be a maintenance burden. Every time that a new class gets written, that case statement will need to have a new case added. But, yeah, I was planning on grabbing chunks of that code to create the standard PP classes' ByteSwap functions. Meanwhile, I am considering bagging on the whole issue & throwing up an alert saying, "Please reinstall an architecture-appropriate version of this software." That said: Is there a way for the application to know when it's running under Rosetta? Peace, Bob Compassion is the radicalism of this age. - The Honorable Dalai Lama > > > What are people doing about byte-swapping PPOB's? The shift to Intel > > > is looming. I guess that my preference would be to detect any [quoted text clipped - 10 lines] > couple of problems. The first & most obvious: It only covers the > standard PP classes. > Which means that the case statement at the heart of the > universal_binary example code will be a maintenance burden. Every time > that a new class gets written, that case statement will need to have a > new case added. I think you're describing the original version of the Universal Binary Programming Guidelines' appendix. It's been revised since that version to be significantly better, largely thanks to a lot of great feedback from people reading this newsgroup and the carbon-dev mailing list. In particular, if you do things the way it describes them today, custom classes will work automatically unless they call ReadData or WriteData, but those cases are simple to find and fix. -Eric  SignatureEric Albert ejalbert@cs.stanford.edu http://outofcheese.org/ > > > What are people doing about byte-swapping PPOB's? The shift to Intel > > > is looming. I guess that my preference would be to detect any [quoted text clipped - 10 lines] > couple of problems. The first & most obvious: It only covers the > standard PP classes. There's now a second edition of that document and the appendix D has now been revised with a different and much better approach. It now gives code for adding byte-swapping to LStream, which reduces the problem to one of dealing with classes that call LStream::ReadData (and for all the standard classes, the appendix provides replacement code for all such cases). This solves the maintance nightmare you rightly objected to (I raised the same objection when the document was first released). > We will alway be confronting the > issue of our software being installed on one architecture and then > moved to a computer of the other architecture. I think you might be labouring under a misconception here. The data on disk is always in one, defined byte-order (in the case of PPOB resources this is big-endian). It is only the data in RAM that needs to be in host byte-order. Moreover, in the case of Rosetta, your entire process is effectively running in a 'virtual host' that has big-endian byte-order. Rosetta has the smarts to swap any data that crosses the boundary from this 'virtual host' to little-endian-land, subject to the exceptions documented in the Apple's paper. The upshot is that if you follow Apple's revised guidlelines, and deal with any usage of LStream::ReadData in any custom PPOBs that you use, you'll be fine, whether it's a PPC build running on a PPC machine, a PPC build running under Rosetta, or an x86 build running on an x86 machine. All in all, I think Apple's new approach for PPOBs is quite viable. I'm sure it'll be rolled into the open-source release of PowerPlant. Take a look at the second edition of the doc, I think you'll be pleasantly surprised. HTH, Richard. Richard (& others), Greetings! > There's now a second edition of that document and the appendix D has > now been revised with a different and much better approach. It now [quoted text clipped - 4 lines] > objected to (I raised the same objection when the document was first > released). Hmmm... Okay, I did bring in the second edition of that universal_binary document... and did find the modification of the stream classes to be a manageable solution to the problem. I had hoped to implement a 'fix the data on disk' solution but I certainly see some problems with that, e.g. David's example of the non-writable app. It certainly makes a certain sort of logic to standardize on big-endian disk-data: Networks already do that. Many thanks to you & the others who weighed in on this topic, a nice expression of the CodeWarrior community. Peace, Bob The way I see it, if you want the rainbow, you gotta put up with the rain. - Dolly Parton > What are people doing about byte-swapping PPOB's? The shift to Intel > is looming. I guess that my preference would be to detect any [quoted text clipped - 11 lines] > or some such. Then each PPOB's classes would know how to byte-swap > itself as it currently knows how to create itself. Wouldn't it make more sense to go through each class in PP, and make sure it reads one field at a time from the PPob, where the field reader does the swap as necessary? Once PP is open source, this work could be shared by everyone using PP, so it would only need to be done once by the entire community. I certainly don't want to implement the one-time swap you've described, because it assumes that the application can either write to itself, or write pieces of "itself" somewhere else, which seems like a security hole to me. David, Greetings! > > What are people doing about byte-swapping PPOB's? The shift to Intel > > is looming. I guess that my preference would be to detect any [quoted text clipped - 17 lines] > shared by everyone using PP, so it would only need to be done once by > the entire community. Altho attractive in one sense, that also means that the checking of the endian flag &, conditionally, the byte-swapping is done every time the ppob is read... forever. > I certainly don't want to implement the one-time swap you've described, > because it assumes that the application can either write to itself, or > write pieces of "itself" somewhere else, which seems like a security > hole to me. Now you have touched on would be a real problem for my plan: What if a non-admin user runs a PPC app on an Intel box & the app is stymied when trying to revise itself? Sadly, the answer would have to be: Call tech support & be guided through the process of running the app from an admin account. Part of the back-story here: The suite of apps that I am responsible for write data files that contain ppob data... with literally hundreds of classes. Oy! Ummm... "January?? I thought you said, 'June'!!" B-) Peace, Bob One measurement is worth a thousand guesses. - Anonymous My current plan is to make C++ classes which represent endian-neutral integers in the various sizes and then re-define the PPob structures to utilize my classes. The iostream operators can do the byte swapping and I believe, no changes to the implementation code will be necessary. I haven't written any code yet - I tend to think things through thoroughly before running the hatchet over someone else's (in this case well-written) source code. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.