ppob's & byte-swapping

In article <181120051051429342%robert.stullerNO@SPAMsnet.net>, Bob
Stuller <robert.stullerNO.RemoveThis@SPAMsnet.net> wrote:

> 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/>.

In article <181120051051429342%robert.stullerNO@SPAMsnet.net>,
Bob Stuller <robert.stullerNO DeleteThis @SPAMsnet.net> wrote:

> 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.

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.

In article <181120050911586402%osxNOSPAM@jwwalker.com.invalid>, James
W. Walker <osxNOSPAM.RemoveThis@jwwalker.com.invalid> wrote:

> In article <181120051051429342%robert.stullerNO@SPAMsnet.net>, Bob
> Stuller <robert.stullerNO.RemoveThis@SPAMsnet.net> wrote:
>
> > 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/>.

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

In article <181120051259188682%robert.stullerNO@SPAMsnet.net>,
Bob Stuller <robert.stullerNO.RemoveThis@SPAMsnet.net> wrote:

> In article <181120050911586402%osxNOSPAM@jwwalker.com.invalid>, James
> W. Walker <osxNOSPAM.RemoveThis@jwwalker.com.invalid> wrote:
>
> > In article <181120051051429342%robert.stullerNO@SPAMsnet.net>, Bob
> > Stuller <robert.stullerNO.RemoveThis@SPAMsnet.net> wrote:
> >
> > > 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/>.
>
> 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.

> 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

--
Eric Albert ejalbert.RemoveThis@cs.stanford.edu
http://outofcheese.org/

David, Greetings!

In article <oster-C304ED.09114018112005.RemoveThis@newsclstr02.news.prodigy.com>,
David Phillip Oster <oster.RemoveThis@ieee.org> wrote:
> > 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.
>
> 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.

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

In article <181120051259188682%robert.stullerNO@SPAMsnet.net>, Bob
Stuller <robert.stullerNO.DeleteThis@SPAMsnet.net> wrote:

> In article <181120050911586402%osxNOSPAM@jwwalker.com.invalid>, James
> W. Walker <osxNOSPAM.DeleteThis@jwwalker.com.invalid> wrote:
>
> > In article <181120051051429342%robert.stullerNO@SPAMsnet.net>, Bob
> > Stuller <robert.stullerNO.DeleteThis@SPAMsnet.net> wrote:
> >
> > > 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/>.
>
> 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.

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!

In article <181120051919234242%richardb@sailmaker.co.nospam.uk>,
Richard Buckle <richardb.DeleteThis@sailmaker.co.nospam.uk> wrote:
> In article <181120051259188682%robert.stullerNO@SPAMsnet.net>, Bob
> Stuller <robert.stullerNO.DeleteThis@SPAMsnet.net> wrote:
> 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).

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