Old school, coming back again.

Daniel T. wrote:

> I started programming for Mac back in the OS 5 days, through OS X
> 10.1, all the time using the (what is now called) the Carbon API.
>
> Now my boss has asked me to write an application for "low end Macs".
> I'm assuming that "low end" no longer means OS 9 or earlier, but it
> would probably still mean programming for G4s and G5s wouldn't it?
> Maybe G3s as well?

Only your boss knows for sure (hopefully!) but I guess nowadays 'low end
Mac' means: support for Mac OS X 10.3.9. You would do this by creating a
universal binary app that targets the 10.3.9 SDK for PPC Macs and the
10.4u SDK for intel Macs. You don't need to whorry about processor types
for your kind of application.

> Also, the program is basically a port of a Windows (not MFC)
> application that uses very little of the Toolbox (it's a kids video
> game.) Would it still be appropriate to use the Carbon library, or do
> I have to interface the C++ code to the Cocoa library?

Carbon is still a valid technology and, considering your experience,
may be the fastest route to a working port. However, if you want to
prepare yourself for the future using Cocoa is going to be a more
valueable experience. You can easilly integrate C++ code using
'Objective-C++'.

patrick
 >> Stay informed about: Old school, coming back again. 

On Feb 26, 12:44 pm, Gregory Weston wrote:
> In article
> ,
>  "Daniel T." wrote:
>
> > I started programming for Mac back in the OS 5 days, through OS X
> > 10.1, all the time using the (what is now called) the Carbon API.
>
> > Now my boss has asked me to write an application for "low end Macs".
> > I'm assuming that "low end" no longer means OS 9 or earlier, but it
> > would probably still mean programming for G4s and G5s wouldn't it?
> > Maybe G3s as well?
>
> Really depends on what your boss meant by that inherently ambiguous
> statement.
>
> > Also, the program is basically a port of a Windows (not MFC)
> > application that uses very little of the Toolbox (it's a kids video
> > game.) Would it still be appropriate to use the Carbon library, or do
> > I have to interface the C++ code to the Cocoa library?
>
> Erm. Even omitting MFC there are possibly Windows API calls and (worse)
> reliance on certain compiler behaviors that would complicate reusing the
> C++ code.
>
> > Any other tips or tricks that an old dog can learn would be great to
> > hear as well. :-)
>
> Really it depends on the details of the programming assignment. What are
> the target hardware and OS versions, and what's the real nature of the
> existing code. Although an extreme case, it's theoretically possible
> that your best option is to learn Cocoa and rewrite from the ground up.

We use a propitary framework that I ported before. Aparently the code
was lost so I would have to re-port the framework. :-(

Developing from the ground up is not an option (management reasons.)
All interface elements are custom (no API calls for buttons and such.)
Before, I just opened a window and drew directly into it (just like
the Windows verson does,) and used WaitNextEvent to handle input.
 >> Stay informed about: Old school, coming back again. 

On 2008-02-26 07:16:00 -0800, noreply.DeleteThis@mail.invalid (Patrick Machielse) said:

> Only your boss knows for sure (hopefully!) but I guess nowadays 'low end
> Mac' means: support for Mac OS X 10.3.9. You would do this by creating a
> universal binary app that targets the 10.3.9 SDK for PPC Macs and the
> 10.4u SDK for intel Macs.

No, no, no, no, NO. People keep saying this and it's *not true*. Please stop.

You can use the Mac OS X 10.5 SDK if you want to and *still* target
10.3.9 on PowerPC hardware and 10.4.3 on Intel hardware. The SDK only
determines the maximum version of Mac OS X from which you can use
features.

To ensure your software can *run* on Mac OS X 10.3.9 on PowerPC
machines, you need to set your Mac OS X Deployment Target to 10.3 when
building for PowerPC, and avoid using any new-in-10.4 (or later) APIs.
That's it. You don't have to do development on Tiger, you don't have
to use the 10.3.9 SDK, you don't have to use Xcode 2.5, you don't have
to use GCC 3.3.

The only reason you need to use a GCC earlier than GCC 4 is to run C++
code on an OS earlier than 10.3.9.

To summarize:

SDK = maximum version of the OS from which you want to use features
Deployment Target = minimum version of the OS on which you want to run
Compiler version = GCC 4.0 or later for 10.3.9 or above will work fine

Hope this helps.

-- Chris
 >> Stay informed about: Old school, coming back again. 

In article
,
"Daniel T." wrote:

> On Feb 26, 12:44 pm, Gregory Weston wrote:
> > In article
> > ,
> >  "Daniel T." wrote:
> >
> > > Now my boss has asked me to write an application for "low end Macs".
> > > I'm assuming that "low end" no longer means OS 9 or earlier, but it
> > > would probably still mean programming for G4s and G5s wouldn't it?
> > > Maybe G3s as well?
>
> We use a propitary framework that I ported before. Aparently the code
> was lost so I would have to re-port the framework. :-(
>
> Developing from the ground up is not an option (management reasons.)
> All interface elements are custom (no API calls for buttons and such.)
> Before, I just opened a window and drew directly into it (just like
> the Windows verson does,) and used WaitNextEvent to handle input.

You should consider OpenGL
<http://developer.apple.com/graphicsimaging/opengl/> and GLUT
<http://www.opengl.org/documentation/specs/glut/spec3/spec3.html>. That
might lead to a code base that is largely shared between platforms.

Reinder
 >> Stay informed about: Old school, coming back again. 

Chris Hanson wrote:

> On 2008-02-26 07:16:00 -0800, noreply DeleteThis @mail.invalid (Patrick Machielse) said:
>
> > Only your boss knows for sure (hopefully!) but I guess nowadays 'low end
> > Mac' means: support for Mac OS X 10.3.9. You would do this by creating a
> > universal binary app that targets the 10.3.9 SDK for PPC Macs and the
> > 10.4u SDK for intel Macs.
>
> No, no, no, no, NO. People keep saying this and it's *not true*. Please
> stop.

relax.

> To ensure your software can *run* on Mac OS X 10.3.9 on PowerPC
> machines, you need to set your Mac OS X Deployment Target to 10.3 when
> building for PowerPC, and avoid using any new-in-10.4 (or later) APIs.
> That's it.

Yes, that works. However, in practice this means that it's all too easy
to build a product that *won't run* on older systems. The availability
macro's are a fine mechanism (and should be used), but they don't
provide full coverage:

- Not even all Cocoa frameworks use it (f.i. WebKit). Availability is
mostly mentioned in the documentation.

- Most lower level libraries don't use it (f.i. OpenGL). Availability
can be determined only from the SDK headers.

In my opinion, the best advise to the original poster is to use matching
SDK and Deployment Target settings. This will detect unavailable symbols
at the earliest possible stage. Using a newer SDK with an older
deployment target is an advanced technique that allows one to take
advantage of newer API at the expense of hiding availability conflicts
for older targets.

I say this based on my own experience and reading Apple documentation
such as the weak linking technote (5 years old by now, but "check back
here periodically for updates on tools and OS support"). If I missed
some important aspect, or if you can share more up-to date inside
information on the subject, I would certainly be interested.

patrick
 >> Stay informed about: Old school, coming back again. 

On 2008-02-27 07:48:31 -0600, noreply.RemoveThis@mail.invalid (Patrick Machielse) said:

> Chris Hanson wrote:
>> To ensure your software can *run* on Mac OS X 10.3.9 on PowerPC
>> machines, you need to set your Mac OS X Deployment Target to 10.3 when
>> building for PowerPC, and avoid using any new-in-10.4 (or later) APIs.
>> That's it.
>
> Yes, that works. However, in practice this means that it's all too easy
> to build a product that *won't run* on older systems. The availability
> macro's are a fine mechanism (and should be used), but they don't
> provide full coverage:
>
> - Not even all Cocoa frameworks use it (f.i. WebKit). Availability is
> mostly mentioned in the documentation.


The problem here is that WebKit is not tied to the OS. It's tied to
what version of Safari is installed, which is sort of tied to the OS
but only indirectly (so for example, Safari 3.0 features found in 10.5
are available on 10.4, but only 10.4.11 or later). As a result,
there's no practical way to use the availability macros like this.

The Quicktime features are even worse...


>
> - Most lower level libraries don't use it (f.i. OpenGL). Availability
> can be determined only from the SDK headers.

OpenGL provides its own (cross platform-ish) way of determining what
features are available (which are ultimately tied to the display card
and drivers)

>
> In my opinion, the best advise to the original poster is to use matching
> SDK and Deployment Target settings. This will detect unavailable symbols
> at the earliest possible stage. Using a newer SDK with an older
> deployment target is an advanced technique that allows one to take
> advantage of newer API at the expense of hiding availability conflicts
> for older targets.

It is, however, the "recommended" way to do things. For example, from
<http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/UniversalBinaries/chapter_4_section_1.html>:

To

support versions of Mac OS X prior to Mac OS X v10.4 for PowerPC, you
can specify separate deployment OS versions for Intel and PowerPC-based
builds. To do so, use the per-architecture variants of the
MACOSX_DEPLOYMENT_TARGET build setting
 >> Stay informed about: Old school, coming back again.