Re: 10.4 v. 10.5 SDK question
Ken; Thanks for the quick and helpful response! You seem to have assumed that you can only compile against the 10.4 SDK by going back to Xcode 2.5 (and thus using an earlier compiler). No I brought the application back to the 10.5 machine and have left it compiling against the 10.4 SDK for now. Trying to decide whether to return to using the 10.5 SDK was the genesis of my question. In general, your choice of SDK should be dictated by the latest features you want to use. If you don't want to use any 10.5-or- later-only features, sticking with the 10.4 SDK is safest. I want to deploy to 10.4 and have avoided using 10.5 features to keep the code base clean and simple. My plan was to prove out the product idea using the widest possible audience (10.4) using the simplest most widely understood and sampled code - 10.4 only. If successful, then version 2 would be a 10.5 only product developed using a by then more battle-tested 10.5. Version 2 is also then a clean code base because it also avoids all the OS-version conditionals you mentioned. Also, what do you mean the underlying code is cleaner? .. One caveat with simply using the 10.4 SDK, though -- the 10.5 frameworks contain a number of bug fixes That's what I meant. ...(bug fixes) which are only enabled for binaries linked against the 10.5 SDK. This is both a good and bad thing. It means your program works consistently on Tiger and Leopard, which makes testing easier. But it might behave consistently incorrectly due to the bugs. Check the various Leopard release notes for specifics. I'm afraid I don't understand this comment. What do you mean ..behave consistently incorrectly due to the bugs..? Can you refer me to a specific item you might be thinking of here? So in sum, I think what you are saying is: Stick w/ 10.4 SDK as the safest path. However there might be bug fixes which you could benefit from by using the 10.5 SDK. To determine whether or not you actually do benefit from 10.5 means you have to learn more about it by reading the Release Notes. Does that sound right? So based on this reading of your comments and a few minutes with the XCode documentation I scan the AppKit Release Notes for Leopard and find the following: NSCompoundPredicate For applications linked on Mac OS X 10.5 Leopard or later, initializing an NSCompoundPredicate now copies the subpredicates array rather than retaining it. Applications linked on Mac OS X 10.4 Tiger continue to only retain the subpredicates array for binary compatibility. Well this appears germane to my application as I do use compound predicates. Judging by the scope the Release Notes and the speed with which I could locate even one germane issue I am convinced that my original instinct to use the 10.5 SDK because the code base is better IS correct. But I am puzzled by your good and bad thing comment... Thanks Again, Steve On Oct 18, 2008, at 12:18 AM, Steve Cronin wrote: I have developed an application with XC 3.1 on a 10.5 Intel machine using the 10.5 SDK w/ a 10.4 deployment target. (No GC for me!) In testing I immediately ran into a few difficulties on a 10.4 PPC machine. In the course of tracking down these issues I ended up installing XC 2.5 on this 10.4 PPC machine. I actually compiled the application under the 10.4 SDK on this machine so I could run it in the debugger. (I had to make surprisingly few changes to get this to happen - none that I am unhappy about) Converting all .xib to .nib being one major aspect (and where I found the offending bug [filter predicate bindings...]) In fact, this exercise has left me with an increased confidence in the application's behavior in this environment. So I've moved the modified project back to the 10.5 Intel where it happily compiles and runs still using the 10.4 SDK and .nibs. So, given all that, am I correct in wanting to move the project back to the 10.5 SDK because the underlying code is cleaner and the compiler output is better? Also, what do you mean the underlying code is cleaner? You are linking against the frameworks dynamically. You get the framework for the OS on which you're running. Regardless of what SDK you link against at build time, you're still linking against the libraries of your runtime environment. In general, your choice of SDK should be dictated by the latest features you want to use. If you don't want to use any 10.5-or- later-only features, sticking with the 10.4 SDK is safest. The reason is that the compiler will warn you if you accidentally slip up and make use of a newer feature. If you want to make use of 10.5 features but still deploy to 10.4, you have to take extra care. That's why it's not good to do so accidentally. You need to conditionalize all uses of 10.5 features based on their availability at runtime (checking that symbols aren't NULL and using -respondsToSelector:) and provide
Re: 10.4 v. 10.5 SDK question
On Oct 18, 2008, at 1:36 AM, Steve Cronin wrote: ...(bug fixes) which are only enabled for binaries linked against the 10.5 SDK. This is both a good and bad thing. It means your program works consistently on Tiger and Leopard, which makes testing easier. But it might behave consistently incorrectly due to the bugs. Check the various Leopard release notes for specifics. I'm afraid I don't understand this comment. What do you mean ..behave consistently incorrectly due to the bugs..? I mean that, where there's a bug, an application linked against the 10.4 SDK will continue to get the buggy behavior from the framework, even when running on Leopard. Consistency. Whatever workaround you have for the bug will continue to work correctly on Leopard. If you link against the 10.5 SDK, then the application will get one kind of behavior when running on Tiger and get a different behavior when running on Leopard. Inconsistency. Any workaround for the Tiger bug may cause trouble when running on Leopard, but failure to work around the bug will cause trouble when running on Tiger. You have to write your code with this in mind, and you have to test both possibilities. Can you refer me to a specific item you might be thinking of here? Well, any of the bugs fixes listed in the release notes which note that the new behavior only occurs for applications linked against 10.5. For example, in the AppKit release notes, see the item titled KeyValueObserving notifications for IBOutlets during Nib loading. Consider how easy it would be to unwittingly code an application that relies either on the old behavior which would break with the new behavior, or vice versa. So in sum, I think what you are saying is: Stick w/ 10.4 SDK as the safest path. However there might be bug fixes which you could benefit from by using the 10.5 SDK. To determine whether or not you actually do benefit from 10.5 means you have to learn more about it by reading the Release Notes. Does that sound right? Yup. So based on this reading of your comments and a few minutes with the XCode documentation I scan the AppKit Release Notes for Leopard and find the following: NSCompoundPredicateFor applications linked on Mac OS X 10.5 Leopard or later, initializing an NSCompoundPredicate now copies the subpredicates array rather than retaining it. Applications linked on Mac OS X 10.4 Tiger continue to only retain the subpredicates array for binary compatibility. Well this appears germane to my application as I do use compound predicates. Judging by the scope the Release Notes and the speed with which I could locate even one germane issue I am convinced that my original instinct to use the 10.5 SDK because the code base is better IS correct. But I am puzzled by your good and bad thing comment... Well, consider this: if the bug fix were purely good, why would Apple maintain backward compatibility for apps which are linked against the 10.4 SDK? And remember, if you link against the 10.5 SDK but support deployment on 10.4, then you still have to cope with the case where NSCompoundPredicate merely retains rather than copying its subpredicates array, because that's what will happen when it's run on 10.4. So, your code has to be safe under both behaviors rather than just having one behavior to worry about. Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: 10.4 v. 10.5 SDK question
Ken; Once again, thanks for the exemplary response! (You are a great resource for the Cocoa community!) So... while yes, the 10.5 SDK does have bug fixes, using it and deploying to 10.4 potentially bifurcates the product into different behaviors. (It is really tough to determine where and when these differences might show up but the possibility exists -. maddening from a support perspective) Since my goal was to deploy to 10.4 all along, by using the 10.4 SDK, the app will behave the same on both 10.4 and 10.5 (and 10.6) -- simpler from a support perspective. In some cases the behavior might be consistently wrong perhaps but any such incorrectness can be cured on both OSes by the same workaround -- simpler development and testing Simpler development, simpler code, simpler testing, simpler support - yeah! Thanks for helping me better understand and for keeping my life simple! Steve On Oct 18, 2008, at 2:19 AM, Ken Thomases wrote: On Oct 18, 2008, at 1:36 AM, Steve Cronin wrote: ...(bug fixes) which are only enabled for binaries linked against the 10.5 SDK. This is both a good and bad thing. It means your program works consistently on Tiger and Leopard, which makes testing easier. But it might behave consistently incorrectly due to the bugs. Check the various Leopard release notes for specifics. I'm afraid I don't understand this comment. What do you mean ..behave consistently incorrectly due to the bugs..? I mean that, where there's a bug, an application linked against the 10.4 SDK will continue to get the buggy behavior from the framework, even when running on Leopard. Consistency. Whatever workaround you have for the bug will continue to work correctly on Leopard. If you link against the 10.5 SDK, then the application will get one kind of behavior when running on Tiger and get a different behavior when running on Leopard. Inconsistency. Any workaround for the Tiger bug may cause trouble when running on Leopard, but failure to work around the bug will cause trouble when running on Tiger. You have to write your code with this in mind, and you have to test both possibilities. Can you refer me to a specific item you might be thinking of here? Well, any of the bugs fixes listed in the release notes which note that the new behavior only occurs for applications linked against 10.5. For example, in the AppKit release notes, see the item titled KeyValueObserving notifications for IBOutlets during Nib loading. Consider how easy it would be to unwittingly code an application that relies either on the old behavior which would break with the new behavior, or vice versa. So in sum, I think what you are saying is: Stick w/ 10.4 SDK as the safest path. However there might be bug fixes which you could benefit from by using the 10.5 SDK. To determine whether or not you actually do benefit from 10.5 means you have to learn more about it by reading the Release Notes. Does that sound right? Yup. So based on this reading of your comments and a few minutes with the XCode documentation I scan the AppKit Release Notes for Leopard and find the following: NSCompoundPredicateFor applications linked on Mac OS X 10.5 Leopard or later, initializing an NSCompoundPredicate now copies the subpredicates array rather than retaining it. Applications linked on Mac OS X 10.4 Tiger continue to only retain the subpredicates array for binary compatibility. Well this appears germane to my application as I do use compound predicates. Judging by the scope the Release Notes and the speed with which I could locate even one germane issue I am convinced that my original instinct to use the 10.5 SDK because the code base is better IS correct. But I am puzzled by your good and bad thing comment... Well, consider this: if the bug fix were purely good, why would Apple maintain backward compatibility for apps which are linked against the 10.4 SDK? And remember, if you link against the 10.5 SDK but support deployment on 10.4, then you still have to cope with the case where NSCompoundPredicate merely retains rather than copying its subpredicates array, because that's what will happen when it's run on 10.4. So, your code has to be safe under both behaviors rather than just having one behavior to worry about. Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: 10.4 v. 10.5 SDK question
On Sat, Oct 18, 2008 at 9:55 AM, Steve Cronin [EMAIL PROTECTED] wrote: Since my goal was to deploy to 10.4 all along, by using the 10.4 SDK, the app will behave the same on both 10.4 and 10.5 (and 10.6) -- simpler from a support perspective. In some cases the behavior might be consistently wrong perhaps but any such incorrectness can be cured on both OSes by the same workaround -- simpler development and testing Perhaps I'm mistaken, but you seem to be putting far more weight behind this than it deserves. Code built using the 10.4 SDK can still break on the 10.5 SDK for all sorts of reasons, including but not limited to: - Not all bug fixes get the special casing described. Ones which Apple thinks have a significant installed base of workarounds do, if those workarounds would break on a fix. - New bugs are frequently introduced. Since these are almost by definition not known inside of Apple when they are created, they have no OS version special casing. - Details change without either being a new bug or a bug fix. Code which relies on bad assumptions will work before but not after. - The SDKs themselves can have bugs which prevent your app from working when it otherwise should. Please understand, I'm not saying that your decision is the wrong one. Quite the contrary, it makes some good sense. But you can't simply link against the 10.4 SDK and assume that your application will work consistently and correctly on all future OS versions, although Apple does try to make it that way to some extent. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
10.4 v. 10.5 SDK question
Folks; I have developed an application with XC 3.1 on a 10.5 Intel machine using the 10.5 SDK w/ a 10.4 deployment target. (No GC for me!) In testing I immediately ran into a few difficulties on a 10.4 PPC machine. In the course of tracking down these issues I ended up installing XC 2.5 on this 10.4 PPC machine. I actually compiled the application under the 10.4 SDK on this machine so I could run it in the debugger. (I had to make surprisingly few changes to get this to happen - none that I am unhappy about) Converting all .xib to .nib being one major aspect (and where I found the offending bug [filter predicate bindings...]) In fact, this exercise has left me with an increased confidence in the application's behavior in this environment. So I've moved the modified project back to the 10.5 Intel where it happily compiles and runs still using the 10.4 SDK and .nibs. So, given all that, am I correct in wanting to move the project back to the 10.5 SDK because the underlying code is cleaner and the compiler output is better? (Yes, I do understand the benefits of .xibs but let's leave that aside for now) Frankly, I would like to better understand all the implications of this choice. Thanks for any input! Steve ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: 10.4 v. 10.5 SDK question
On Oct 18, 2008, at 12:18 AM, Steve Cronin wrote: I have developed an application with XC 3.1 on a 10.5 Intel machine using the 10.5 SDK w/ a 10.4 deployment target. (No GC for me!) In testing I immediately ran into a few difficulties on a 10.4 PPC machine. In the course of tracking down these issues I ended up installing XC 2.5 on this 10.4 PPC machine. I actually compiled the application under the 10.4 SDK on this machine so I could run it in the debugger. (I had to make surprisingly few changes to get this to happen - none that I am unhappy about) Converting all .xib to .nib being one major aspect (and where I found the offending bug [filter predicate bindings...]) In fact, this exercise has left me with an increased confidence in the application's behavior in this environment. So I've moved the modified project back to the 10.5 Intel where it happily compiles and runs still using the 10.4 SDK and .nibs. So, given all that, am I correct in wanting to move the project back to the 10.5 SDK because the underlying code is cleaner and the compiler output is better? You seem to have assumed that you can only compile against the 10.4 SDK by going back to Xcode 2.5 (and thus using an earlier compiler). That's not so. If the compiler is your concern, you are certainly able to compile against the 10.4 SDK using Xcode 3.x. Also, what do you mean the underlying code is cleaner? You are linking against the frameworks dynamically. You get the framework for the OS on which you're running. Regardless of what SDK you link against at build time, you're still linking against the libraries of your runtime environment. In general, your choice of SDK should be dictated by the latest features you want to use. If you don't want to use any 10.5-or-later- only features, sticking with the 10.4 SDK is safest. The reason is that the compiler will warn you if you accidentally slip up and make use of a newer feature. If you want to make use of 10.5 features but still deploy to 10.4, you have to take extra care. That's why it's not good to do so accidentally. You need to conditionalize all uses of 10.5 features based on their availability at runtime (checking that symbols aren't NULL and using -respondsToSelector:) and provide fallback code for the case when the feature isn't available. One caveat with simply using the 10.4 SDK, though -- the 10.5 frameworks contain a number of bug fixes which are only enabled for binaries linked against the 10.5 SDK. This is both a good and bad thing. It means your program works consistently on Tiger and Leopard, which makes testing easier. But it might behave consistently incorrectly due to the bugs. Check the various Leopard release notes for specifics. Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
