Closed Bug 423672 Opened 12 years ago Closed 11 years ago
use runtime lookup for launch services APIs
In nsMacShellService.cpp, we wound up using some undocumented Launch Services APIs. These are in the applicationservices.framework umbrella in 10.4, but have moved to the coreservices.framework in 10.5. Building with the 10.5 SDK thus results in a build that won't start on 10.4 because it can't locate those symbols. We should be looking them up at runtime instead, because they've already moved once, so we'll need to guard against that.
I'm guessing the use of undocumented LS functions dates back to earlier Mac OS X versions; as of 10.4, it looks like we can achieve the required functionality using documented, public Launch Services APIs. I've checked that testing and setting the default browser works as expected using this patch. I've also patched GetDefaultFeedReader(), aiming to maintain the same behavior, but am not really sure how that's supposed to work, so testing would be appreciated.
This bug is one of the handful making it difficult to build with the 10.5 SDK for deployment on 10.4 as well as 10.5. Avoiding the private LaunchServices interfaces (which might change again, or disappear entirely) should reduce risk in the future, as well as resolving the immediate issue.
Attachment #370206 - Flags: review+ → review?(mstange)
Attachment #370206 - Flags: review?(mstange) → review+
Comment on attachment 370206 [details] [diff] [review] update patch so that GetDefaultFeedReader actually works > #define SAFARI_BUNDLE_IDENTIFIER NS_LITERAL_CSTRING("com.apple.Safari") >+ defaultHandlerID = ::CFStringCreateWithCString(kCFAllocatorDefault, >+ "com.apple.Safari", Please use SAFARI_BUNDLE_IDENTIFIER here (and drop the NS_LITERAL_CSTRING() part from the #define so that it works), or just remove the #define (since you're removing the only user).
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.