 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / February 2008Old school, coming back again.
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? 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? Any other tips or tricks that an old dog can learn would be great to hear as well. :-) > 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. [quoted text clipped - 3 lines] > 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 > 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 > > 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 [quoted text clipped - 3 lines] > 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 >> 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 [quoted text clipped - 8 lines] > - 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_develop ment/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 In article <d98a6168-3590-4fe2-8ee6-129ad621b9ac@p25g2000hsf.googlegroups.com>, > 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. [quoted text clipped - 3 lines] > 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. > In article > <d98a6168-3590-4fe2-8ee6-129ad621b...@p25g2000hsf.googlegroups.com>, [quoted text clipped - 26 lines] > 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. In article <78e881fd-c0b6-4edc-8e0c-f2acc287b21e@j28g2000hsj.googlegroups.com>, > > In article > > <d98a6168-3590-4fe2-8ee6-129ad621b...@p25g2000hsf.googlegroups.com>, [quoted text clipped - 11 lines] > 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 |
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.