Hello,
I am hoping someone can put my mind at rest about the
whole x86/Universal Binaries issue. I am developing an
app that will either be freeware or shareware, and
thus cannot afford the Transition Kit. I'm only just
now trying to get my head around Core Data as I had to
wait for the official release of Tiger to afford that,
and when I finally got it I found that a lot of code I
had spent a long time over was now redundant (not just
data stuff - I spent weeks and weeks on implementing
variable row heights in tables and lists in text
views). I'm not complaining, but it was frustrating.
And now it seems there is another major change coming
and again I won't be able to see how it affects my app
for some time
So am I safe in assuming - from reading various
comments and looking at the docs published with Xcode
2.1 - that the chances are that my app, which doesn't
do much more than use some custom views and use basic
AppKit/Foundation classes, will most likely just run
on an Intel machine once it is compiled as a Universal
Binary? It's not a big deal if the compatibility
issues are likely to be relatively minor and if it
will just mean ironing out some small bugs when the
new machines come out; what worries me is the idea of
having to rewrite hundreds of lines of code I'm
investing in right now a year or two down the line.
Sorry if this is a very basic question.
Cheers,
Keith
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com
This email sent to bsdarchive (AT) developershed (DOT) com

Many Cocoa apps don't have to do anything, however, can't say for
sure without seeing your sources or actually trying.

step in the process is to make sure your sources build with gcc
4.0, which is a stricter compiler. So you might run into few build
warnings or errors you would have to fix.

In addition, some problematic code (such as divide by zero, sending
C messages to nil and getting floats back, etc), act differently
on PowerPC and Intel; that could be another source of issues in your
bring-up, if you had such undetected problems in your code.

In any case, even if there are a few tweaks, it will likely not
require rearchitecting or rewriting hundreds of lines of code.

Ali

Begin forwarded message:

From: Keith Blount <keithblount (AT) yahoo (DOT) com>
Date: June 8, 2005 13:14:14 PDT
To: cocoa-dev (AT) lists (DOT) apple.com
Subject: Universal Binaries, x86 and compatibility
--
Hello,

I am hoping someone can put my mind at rest about the
whole x86/Universal Binaries issue. I am developing an
app that will either be freeware or shareware, and
thus cannot afford the Transition Kit. I'm only just
now trying to get my head around Core Data as I had to
wait for the official release of Tiger to afford that,
and when I finally got it I found that a lot of code I
had spent a long time over was now redundant (not just
data stuff - I spent weeks and weeks on implementing
variable row heights in tables and lists in text
views). I'm not complaining, but it was frustrating.
And now it seems there is another major change coming
and again I won't be able to see how it affects my app
for some time

So am I safe in assuming - from reading various
comments and looking at the docs published with Xcode
2.1 - that the chances are that my app, which doesn't
do much more than use some custom views and use basic
AppKit/Foundation classes, will most likely just run
on an Intel machine once it is compiled as a Universal
Binary? It's not a big deal if the compatibility
issues are likely to be relatively minor and if it
will just mean ironing out some small bugs when the
new machines come out; what worries me is the idea of
having to rewrite hundreds of lines of code I'm
investing in right now a year or two down the line.

Sorry if this is a very basic question.

Cheers,
Keith

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Keith,

I appreciate your frustration about Core Data, but it's not as though
the code you spent time working on doesn't work under Tiger. It's
just that now, there is an easier way to do it that minimizes your
code base. Unless you want to target only Tiger, there is no need to
throw that code out & replace it with Core Data.

Apple has generally been good about maintaining backwards
compatibility between S X releases. In all likelihood, your app
should run fine, as you plan to use Cocoa APIs. The real issue
between Intel & PPC is in endianness, so byte ordering becomes
important going thru the transition. Unfortunately, you can't test
that issue without an Intel Mac. The question you need to ask
yourself is how much of your target audience will be using the Intel
Macs before you buy one & migrate your code. Then ask yourself if
you can afford to have your app not be native while you transition
the code. I certainly wouldn't recommend releasing a Universal
Binary that hadn't been tested on an Intel Mac.

I tend to determine purchases based on how I value my time. I'm at
the beginning of a development cycle, but the app I'm working on will
be CPU & graphics intensive, so it's better to be native. $999 buys
me the ability to cross-develop before official Intel macs ship. The
coding decisions I make now will be checked on both PPC & Intel. I
can save a lot of time if I make a coding assumption based on PPC
that doesn't work on Intel, since I can notice the problem while I'm
developing, instead of completing the app & noticing the problem when
the actual machines ship. While I may not have that problem, the
$999 buys me peace of mind & a full year's head-start on porting.

In your case, the Core Data functionality duplicated much of the code
you spent weeks working on. $500 for a select membership would have
gotten you early access to Tiger & thus could have saved you weeks of
work if you wanted to use Core Data & Tiger as minimum specs. Your
concern about possibly needing to change hundreds of lines of code a
year or two down the year is a valid one, unfortunately, it depends
on how you code your app as to what migration headaches you may
have. Ultimately, you need to decide for yourself how much you value
your time in determining if the transition kit would be a better bet
than waiting till the Intel Macs come out. It may be worth
considering your experience with Core Data in deciding that.

Good luck,

Niels

Jun 8, 2005, at 4:14 PM, Keith Blount wrote:

Hello,

I am hoping someone can put my mind at rest about the
whole x86/Universal Binaries issue. I am developing an
app that will either be freeware or shareware, and
thus cannot afford the Transition Kit. I'm only just
now trying to get my head around Core Data as I had to
wait for the official release of Tiger to afford that,
and when I finally got it I found that a lot of code I
had spent a long time over was now redundant (not just
data stuff - I spent weeks and weeks on implementing
variable row heights in tables and lists in text
views). I'm not complaining, but it was frustrating.
And now it seems there is another major change coming
and again I won't be able to see how it affects my app
for some time

So am I safe in assuming - from reading various
comments and looking at the docs published with Xcode
2.1 - that the chances are that my app, which doesn't
do much more than use some custom views and use basic
AppKit/Foundation classes, will most likely just run
on an Intel machine once it is compiled as a Universal
Binary? It's not a big deal if the compatibility
issues are likely to be relatively minor and if it
will just mean ironing out some small bugs when the
new machines come out; what worries me is the idea of
having to rewrite hundreds of lines of code I'm
investing in right now a year or two down the line.

Sorry if this is a very basic question.

Cheers,
Keith
>
>
>

Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%
40mac.com

This email sent to nmeersschaert (AT) mac (DOT) com

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

8. jun 2005, at 13.33, Ali wrote:

sending C messages to nil and , act differently on
PowerPC and Intel;

Huhm, why is this? As far as I remember Rhapsody on Intel didn't have
a problem (or acted differently than Rhapsody on PPC) sending
messages to nil objects.

Kind Regards,
Geert B. Clemmensen
www.frontbase.com

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jun 8, 2005, at 1:14 PM, Keith Blount wrote:

Hello,

I am hoping someone can put my mind at rest about the
whole x86/Universal Binaries issue. I am developing an
app that will either be freeware or shareware, and
thus cannot afford the Transition Kit.

Compile to G3 optimized PPC code (do not use AltiVec)
and the Rosetta emulator will run it just fine. I kid you not.

I'm only just
now trying to get my head around Core Data as I had to
wait for the official release of Tiger to afford that,
and when I finally got it I found that a lot of code I
had spent a long time over was now redundant (not just
data stuff - I spent weeks and weeks on implementing
variable row heights in tables and lists in text
views). I'm not complaining, but it was frustrating.
And now it seems there is another major change coming
and again I won't be able to see how it affects my app
for some time

So am I safe in assuming - from reading various
comments and looking at the docs published with Xcode
2.1 - that the chances are that my app, which doesn't
do much more than use some custom views and use basic
AppKit/Foundation classes, will most likely just run
on an Intel machine once it is compiled as a Universal
Binary? It's not a big deal if the compatibility
issues are likely to be relatively minor and if it
will just mean ironing out some small bugs when the
new machines come out; what worries me is the idea of
having to rewrite hundreds of lines of code I'm
investing in right now a year or two down the line.

Sorry if this is a very basic question.

Cheers,
Keith
>
>
>

Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40digigami.com

This email sent to gk0001 (AT) digigami (DOT) com
--

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Geert,

9.6.2005, at 2:08, Geert B. Clemmensen wrote:

>sending C messages to nil and , act differently on
>PowerPC and Intel;
>>
>
Huhm, why is this? As far as I remember Rhapsody on Intel didn't
have a problem (or acted differently than Rhapsody on PPC) sending
messages to nil objects.

This is not a problem, just a different behaviour of *unsupported*
code. Namely, using a return value of nil-sent if it happens to be a
float. (Self-evidently, depends on the ABI for float-value returns.)

Actually, it remains to be seen what it does on Intel, for on PPC it
*does not* do what the docs say :)))

ada
CSoftware: ocs (AT) ocs (DOT) cz http://www.ocs.cz
private ondra (AT) ocs (DOT) cz http://www.ocs.cz/oc

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

I have a couple of shareware programs, but I think I can wait until
the first commercial Intel platforms come out and start testing my
Intel binaries then. The cheapest (Mac Mini) is supposed to be one of
the first -- so much the better. I will simply buy one of these as
soon as I can.

The way I look at it is this: when they start selling these machines,
on day one the total share of installed PPC Macs will be 100% and the
total share of installed Intel Macs will be 0%. It will take a while
for the share of Intel Macs to ramp up. course, new computer
owners tend to be the biggest purchasers of software, so you don't
want to wait too long to get on board. But, I figure most Cocoa
programs are going to be pretty close and it might take a week or two
of tweaking at the most to get my applications in shape. Saving that
week or two is not nearly enough incentive for me to spend a thousand
dollars on hardware I have to give back anyway.

Now, for the big software vendors it is obviously worth it to be
ready; when all of those new Intel Mac owners show up with cash in
their fists looking for native code to run on their new machines, you
want to be there ready to accept their cash. However, most shareware
doesn't generate enough income to be significant during that initial
period, and anyway I think the window on buying $20 apps will be a
bit longer than the window for buying $200 apps.

I think most shareware authors are in the same boat. You may see a
few of the big ones, like Graphicconverter, are ready on day 1, but
I'll bet there will be a dearth of native Intel shareware programs
for the first few days, and then a flood.

In the meantime, look out for those endian issues and you should be
K. Saving to file is a big focus, you have to do it in an endian-
independent way if the file is to be shared between Intel and PPC
machines. That's an area where you want to put your house in order
right away, you don't want your users to be saving files they can't
read when they get a new Intel machine.
- Dennis D.

Jun 8, 2005, at 1:14 PM, Keith Blount wrote:

Hello,

I am hoping someone can put my mind at rest about the
whole x86/Universal Binaries issue. I am developing an
app that will either be freeware or shareware, and
thus cannot afford the Transition Kit. I'm only just
now trying to get my head around Core Data as I had to
wait for the official release of Tiger to afford that,
and when I finally got it I found that a lot of code I
had spent a long time over was now redundant (not just
data stuff - I spent weeks and weeks on implementing
variable row heights in tables and lists in text
views). I'm not complaining, but it was frustrating.
And now it seems there is another major change coming
and again I won't be able to see how it affects my app
for some time

So am I safe in assuming - from reading various
comments and looking at the docs published with Xcode
2.1 - that the chances are that my app, which doesn't
do much more than use some custom views and use basic
AppKit/Foundation classes, will most likely just run
on an Intel machine once it is compiled as a Universal
Binary? It's not a big deal if the compatibility
issues are likely to be relatively minor and if it
will just mean ironing out some small bugs when the
new machines come out; what worries me is the idea of
having to rewrite hundreds of lines of code I'm
investing in right now a year or two down the line.

Sorry if this is a very basic question.

Cheers,
Keith
>
>
>

Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%
40fractaldomains.com

This email sent to demars (AT) fractaldomains (DOT) com
>
>
>

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jun 8, 2005, at 1:14 PM, Keith Blount wrote:

<<<<<<< munch

So am I safe in assuming - from reading various
comments and looking at the docs published with Xcode
2.1 - that the chances are that my app, which doesn't
do much more than use some custom views and use basic
AppKit/Foundation classes, will most likely just run
on an Intel machine once it is compiled as a Universal
Binary? It's not a big deal if the compatibility
issues are likely to be relatively minor and if it
will just mean ironing out some small bugs when the
new machines come out; what worries me is the idea of
having to rewrite hundreds of lines of code I'm
investing in right now a year or two down the line.

I started developing on NextStep sometime in 1991.
By around early 1993 I had about ten shipping
applications. Around that time, NextStep was opened up
and ported to Intel 486, HP Snakes, Sun Sparc, and (never
released) the Motorollah 88000.

When the Intel port was available, I selected the appropriate
switches in Project Builder to compile for Next and Intel,
generated the (fat) binaries, and all ten apps ran quite
flawlessly without my having to change a single line of code.

There was no time spent on chip-specific code, and no time
spent on debugging. Everything Just Worked . . .

Around the same time period, the Step project started,
running on Next boxen and Sun Sparcen. Same old story
(modulo Sun not knowing what the hell they were about):
Everything Just Worked . . .

Here we are, ten or so years on, and the Great Mandala
continues turning. can make several assumption-based
analyses of how this twelve-year old 'transition' will
likely play out:

o the underlying Mac(h) kernel, BSD layer, and all that stuff
are very mature, and have been ported to multiple chip
architectures over a period of around fifteen years . . .

o the old NextStep/Step AppKit and Foundation Kit are
very mature, and have been ported to multiple chip
architectures over a period of around fifteen years . . .

o for the past four years, I have been writing code to a set
of APIs (NS, NSView, NSWindow, for examples) that look
pretty much the same to me today as they were fifteen years
ago (, View, Window) . . .

o the Apple engineering team many of whom came from Next
in the first place know what they are about, have been
through this process in the past, and understand the issues
very well . . .

o Even on Panther, if you look though the .h files for
the system, you will see massive numbers of references
to i386. That indicates to me that the Apple engineering
team have been worrying about this for some time . . .

At the end of the day, I have minimal concern about the transition
to Intel chips. What I am spending my time on right now is
developing new apps, with confidence in the ability of the Apple
engineering team to provide me a programming platform that will
Just Work . . .

Cheers,
. . . . . . . . Henry

Henry McGilton, Boulevardier | Trilithon Software
C/Java Composer | Seroia Research
+
mailto:henry (AT) trilithon (DOT) com | http://www.trilithon.com
|

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

9 jun 2005, at 08.12, Henry McGilton wrote:

When the Intel port was available, I selected the appropriate
switches in Project Builder to compile for Next and Intel,
generated the (fat) binaries, and all ten apps ran quite
flawlessly without my having to change a single line of code.

Exactly my experience, too. The Intel transition will be a no-brainer.

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

This is very much the route that I'm going to take, I'm compiling
Universal Binaries for everything now but I can't test the Intel
version until hardware ships.

My concern is that when the first Intel machines are available it's
likely going to take weeks to get one and there's no guarantee that I
(as a developer on the basic free ADC membership) will get mine
before my customers. Also when the first machine are available I'm
hoping that the Mac mini will be first, again so that small
developers can afford to have an Intel machine in with my collection
of PPC stuff.

Regards, Rob.

9 Jun 2005, at 03:20, Dennis C. De Mars wrote:

The way I look at it is this: when they start selling these
machines, on day one the total share of installed PPC Macs will be
100% and the total share of installed Intel Macs will be 0%. It
will take a while for the share of Intel Macs to ramp up.

- Dennis D.

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com