From xorandor at gmail.com Tue May 16 18:09:43 2006 From: xorandor at gmail.com (Joe Goh) Date: Tue May 16 18:09:46 2006 Subject: [missing-sync-palmos-dev-talk] Using Cocoa in a Carbon conduit Message-ID: <32b179b00605161809w1d177825g53f1c78c6c627687@mail.gmail.com> Hi everyone, Is it possible to use Cocoa functionality within a Carbon conduit, that is targeted for both Missing Sync and HotSync Manager? According to this document ( http://developer.apple.com/documentation/Cocoa/Conceptual/CarbonCocoaDoc/Articles/CocoaInCarbon.html ), its supposedly possible for generic applications, but does the bridge library or anything else prevent this from working? Thanks, Joe From sgruby at markspace.com Tue May 16 18:16:07 2006 From: sgruby at markspace.com (Scott Gruby) Date: Tue May 16 18:16:13 2006 Subject: [missing-sync-palmos-dev-talk] Using Cocoa in a Carbon conduit In-Reply-To: <32b179b00605161809w1d177825g53f1c78c6c627687@mail.gmail.com> References: <32b179b00605161809w1d177825g53f1c78c6c627687@mail.gmail.com> Message-ID: <975D5D3A-B2D4-4486-A7F2-7DA0404D3BC0@markspace.com> On May 16, 2006, at 6:09 PM, Joe Goh wrote: > Hi everyone, > > Is it possible to use Cocoa functionality within a Carbon conduit, > that is targeted for both Missing Sync and HotSync Manager? According > to this document ( > http://developer.apple.com/documentation/Cocoa/Conceptual/ > CarbonCocoaDoc/Articles/CocoaInCarbon.html > ), its supposedly possible for generic applications, but does the > bridge library or anything else prevent this from working? > The bridge library doesn't do anything to explicitly prevent this. However, we've never tried this so you're on your own. We'd love to know how things fair after you go down this path. -- Scott Gruby Mark/Space, Inc. Please visit for assistance with Mark/Space products. From samalone at llamagraphics.com Wed May 17 05:05:55 2006 From: samalone at llamagraphics.com (Stuart A. Malone) Date: Wed May 17 05:06:02 2006 Subject: [missing-sync-palmos-dev-talk] Using Cocoa in a Carbon conduit In-Reply-To: <32b179b00605161809w1d177825g53f1c78c6c627687@mail.gmail.com> References: <32b179b00605161809w1d177825g53f1c78c6c627687@mail.gmail.com> Message-ID: <0DEE400D-A4B8-41A5-A05D-0A4B56704BCA@llamagraphics.com> > Is it possible to use Cocoa functionality within a Carbon conduit, > that is targeted for both Missing Sync and HotSync Manager? Our main application and our conduit are both mainly Carbon code with a little Cocoa mixed in, and both use libMissingSyncBridge.a. So far everything is working pretty smoothly under both Missing Sync and the HotSync Manager. We're using NSImage, NSBundle, NSWorkspace, NSSound and NSAutoreleasePool and so far have not had any problems with them. There are just a few tricks that we have discovered, though they don't really have anything to do with Cocoa: For conduits: 1. For the conduit to show up under Palm Desktop, the bundle bit has to be set. The sample projects from Mark/Space do this, but be aware that there are several tools (such a the Copy Files build phase in Xcode) that do not preserve this bit. 2. When displaying a conduit settings sheet using Carbon's RunAppModalLoopForWindow function, we discovered that mouse clicks in our sheet would not bring the Missing Sync application to the front. We fixed the problem by adding a kEventClassMouse/kEventMouseDown Carbon event handler to our window that does: ProcessSerialNumber me = { 0, kCurrentProcess }; SetFrontProcess(&me); return eventNotHandledErr; 3. Although I don't remember it being documented for Palm Desktop, both Palm Desktop and Missing Sync are able to use conduits located in ~/Library/Application Support/Palm HotSync/Conduits. If you have an installer, it's nice to offer users the option of installing into this directory because it does not require administrative rights. For applications: 1. When linking an application with libMissingSyncBridge.a, you also need to weak link with Missing Sync using "OTHER_LDFLAGS = - weak_framework MissingSync". 2. A universal application running natively on Intel works with Missing Sync 5.1 (which is also native), but not with Palm Desktop 4.2.1 (which is in emulation under Rosetta). A workaround is to tell users to turn on the "Open using Rosetta" checkbox in the Get Info window for your application. However, for this to work your application must NOT have an "LSPrefersCarbon" key in its Info.plist file. I hope these tips save you a little trouble. Best wishes, --Stuart A. Malone Llamagraphics, Inc. Makers of Life Balance personal coaching software http://www.llamagraphics.com/ From xorandor at gmail.com Wed May 17 06:49:00 2006 From: xorandor at gmail.com (Joe Goh) Date: Wed May 17 06:49:02 2006 Subject: [missing-sync-palmos-dev-talk] Using Cocoa in a Carbon conduit In-Reply-To: <0DEE400D-A4B8-41A5-A05D-0A4B56704BCA@llamagraphics.com> References: <32b179b00605161809w1d177825g53f1c78c6c627687@mail.gmail.com> <0DEE400D-A4B8-41A5-A05D-0A4B56704BCA@llamagraphics.com> Message-ID: <32b179b00605170649u6855913qcc323e02a46fa219@mail.gmail.com> On 5/17/06, Stuart A. Malone wrote: > I hope these tips save you a little trouble. Thanks Stuart! These tips will surely save me ALOT of trouble in the future. I'm planning on using CoreData with my conduit, sure hope I don't run into some hidden "gotcha". Thanks again, Joe From samalone at llamagraphics.com Thu May 18 11:17:46 2006 From: samalone at llamagraphics.com (Stuart A. Malone) Date: Thu May 18 11:17:49 2006 Subject: [missing-sync-palmos-dev-talk] Conduit progress callback function Message-ID: Hi all, I've been spending some time tracking down a crash in the next version of our conduit, which will be built using libMissingSyncBridge.a. The crash is occurring when we try to call the PROGRESSFNCARBON which is passed into OpenConduitCarbon. Scott told me before about setting the first slot in the 'CInf' resource to 2, which tells something (Missing Sync? the bridge library?) that this is a Mach-O conduit and not a CFM conduit. That was enough to get the progress callback working under Missing Sync. But the conduit was crashing under Palm Desktop. I downloaded a fresh copy of the Sample Mach-O Conduit, and see that it now contains code to patch the progress callback: PROGRESSFNCARBON inProgressCallBack = (PROGRESSFNCARBON) MachOFunctionPointerForCFMFunctionPointer((void *) inCFMProgressCallBack); The problem is that this provides you with two different progress callbacks (inProgressCallBack and inCFMProgressCallBack) but doesn't tell you which one to call! And if you guess wrong, you crash. Clearly the solution is to detect whether we're running under Palm Desktop or Missing Sync, and only patch the callback if we're running under Palm Desktop. So far the best solution I've come up with is to test the identifier of the main bundle: if (::CFStringCompare(::CFBundleGetIdentifier(::CFBundleGetMainBundle ()), CFSTR("com.palm.HotSync.ConduitManager"), 0) == kCFCompareEqualTo) { inProgressCallBack = (PROGRESSFNCARBON) MachOFunctionPointerForCFMFunctionPointer((void *)inProgressCallBack); } This seems to work, but I'd actually be more comfortable if I could detect whether the main bundle is CFM or Mach-O directly, rather than assuming that the Conduit Manager is CFM and will always remain so. Do other folks know of a way to tell if a process is CFM or Mach-O? Or does anyone have a better idea about how to solve this problem? Best wishes, --Stuart A. Malone Llamagraphics, Inc. Makers of Life Balance personal coaching software http://www.llamagraphics.com/ From xorandor at gmail.com Fri May 19 01:13:41 2006 From: xorandor at gmail.com (Joe Goh) Date: Fri May 19 01:13:44 2006 Subject: [missing-sync-palmos-dev-talk] Using Cocoa in a Carbon conduit In-Reply-To: <0DEE400D-A4B8-41A5-A05D-0A4B56704BCA@llamagraphics.com> References: <32b179b00605161809w1d177825g53f1c78c6c627687@mail.gmail.com> <0DEE400D-A4B8-41A5-A05D-0A4B56704BCA@llamagraphics.com> Message-ID: <32b179b00605190113u8b9b224va3373c4406ee1cf2@mail.gmail.com> On 5/17/06, Stuart A. Malone wrote: > Our main application and our conduit are both mainly Carbon code with > a little Cocoa mixed in, and both use libMissingSyncBridge.a. So far > everything is working pretty smoothly under both Missing Sync and the > HotSync Manager. We're using NSImage, NSBundle, NSWorkspace, NSSound > and NSAutoreleasePool and so far have not had any problems with them. Is there any need to bundle all the Cocoa functionality into a seperate bundle and load it lazily like that mentioned http://developer.apple.com/documentation/Cocoa/Conceptual/CarbonCocoaDoc/Articles/LazyCocoaLoading.html in order to let the conduit work under Palm Desktop? I ask because it says in the article, "You may want to use lazy initialization if the Cocoa functionality that you need is not always required by all users or your application uses CFM." Thanks! Joe From sgruby at markspace.com Sun May 21 07:39:18 2006 From: sgruby at markspace.com (Scott Gruby) Date: Sun May 21 07:39:24 2006 Subject: [missing-sync-palmos-dev-talk] Conduit progress callback function In-Reply-To: References: Message-ID: On May 18, 2006, at 11:17 AM, Stuart A. Malone wrote: > > Hi all, > > I've been spending some time tracking down a crash in the next > version of our conduit, which will be built using > libMissingSyncBridge.a. The crash is occurring when we try to call > the PROGRESSFNCARBON which is passed into OpenConduitCarbon. > > Scott told me before about setting the first slot in the 'CInf' > resource to 2, which tells something (Missing Sync? the bridge > library?) that this is a Mach-O conduit and not a CFM conduit. > That was enough to get the progress callback working under Missing > Sync. > > But the conduit was crashing under Palm Desktop. I downloaded a > fresh copy of the Sample Mach-O Conduit, and see that it now > contains code to patch the progress callback: > > PROGRESSFNCARBON inProgressCallBack = > (PROGRESSFNCARBON) MachOFunctionPointerForCFMFunctionPointer((void > *)inCFMProgressCallBack); > > The problem is that this provides you with two different progress > callbacks (inProgressCallBack and inCFMProgressCallBack) but > doesn't tell you which one to call! And if you guess wrong, you > crash. > > Clearly the solution is to detect whether we're running under Palm > Desktop or Missing Sync, and only patch the callback if we're > running under Palm Desktop. So far the best solution I've come up > with is to test the identifier of the main bundle: > > if (::CFStringCompare(::CFBundleGetIdentifier > (::CFBundleGetMainBundle()), > CFSTR("com.palm.HotSync.ConduitManager"), 0) > == kCFCompareEqualTo) { > inProgressCallBack = (PROGRESSFNCARBON) > MachOFunctionPointerForCFMFunctionPointer((void *)inProgressCallBack); > } > > This seems to work, but I'd actually be more comfortable if I could > detect whether the main bundle is CFM or Mach-O directly, rather > than assuming that the Conduit Manager is CFM and will always > remain so. Do other folks know of a way to tell if a process is > CFM or Mach-O? Or does anyone have a better idea about how to > solve this problem? > Your solution seems like a good one (ignore the CInf mess as that is not a great solution, but was one that I thought would work a long time ago). I only found a few references to determine if something is MachO or CFM and that is a hacky way of reading the first few bytes of the executable. BTW, thanks for your tips about conduit development; eventually I'll assemble all of them and update our documentation. -- Scott Gruby Mark/Space, Inc. Please visit for assistance with Mark/Space products. From samalone at llamagraphics.com Fri May 26 07:28:44 2006 From: samalone at llamagraphics.com (Stuart A. Malone) Date: Fri May 26 07:28:51 2006 Subject: [missing-sync-palmos-dev-talk] Using Cocoa in a Carbon conduit In-Reply-To: <32b179b00605190113u8b9b224va3373c4406ee1cf2@mail.gmail.com> References: <32b179b00605161809w1d177825g53f1c78c6c627687@mail.gmail.com> <0DEE400D-A4B8-41A5-A05D-0A4B56704BCA@llamagraphics.com> <32b179b00605190113u8b9b224va3373c4406ee1cf2@mail.gmail.com> Message-ID: Joe, I think you may have been onto something when you wrote: > Is there any need to bundle all the Cocoa functionality into a > seperate bundle and load it lazily like that mentioned > http://developer.apple.com/documentation/Cocoa/Conceptual/ > CarbonCocoaDoc/Articles/LazyCocoaLoading.html > in order to let the conduit work under Palm Desktop? > > I ask because it says in the article, "You may want to use lazy > initialization if the Cocoa functionality that you need is not always > required by all users or your application uses CFM." I believe that I have just run into this issue. Palm Desktop crashes when it attempts to unload my mixed Carbon/Cocoa bundle under Panther. I'm still researching the issue, but I wanted to mention it right away so that we can put our heads together and work out a solution. The crash looks like this: Thread 3 Crashed: 0 libobjc.A.dylib 0x9086be80 _objc_trap + 0 1 libobjc.A.dylib 0x9086be14 _objc_fatal + 0x48 2 libobjc.A.dylib 0x90867c44 _objc_fatalHeader + 0x44 3 dyld 0x8fe182c0 call_funcs_for_remove_image + 0x8c 4 dyld 0x8fe13220 _dyld_unlink_module + 0xcc 5 libSystem.B.dylib 0x9003db4c NSUnLinkModule + 0x68 6 com.apple.CoreFoundation 0x90236290 _CFBundleDYLDUnloadBundle + 0x3c 7 com.apple.CoreFoundation 0x9021da00 CFBundleUnloadExecutable + 0xe8 8 Conduit Manager 0x0040dcc0 0x405000 + 0x8cc0 Some searching turned up a couple of interesting messages from Apple's mailing lists: http://lists.apple.com/archives/cocoa-dev/2001/Dec/msg00592.html http://lists.apple.com/archives/carbon-development/2003/Nov/ msg01760.html The Cocoa documentation from 2003-01-13 says: Due to a limitation in the Objective-C runtime system, at the time of writing there is no way to unload Cocoa loadable bundles. There is a similar warning at the bottom of : Because of a limitation in the Objective-C runtime system, NSBundle cannot unload executable code. Since CFBundle does not know about Objective-C symbols, do not use the CFBundle loading and unloading routines on NSBundle objects. You can, however, create a CFBundle object for a Cocoa bundle and use the other routines?unrelated to loading and unloading?without trouble. So I think the solution is probably to follow Apple's instructions for "Loading Cocoa Lazily Into Your Carbon Application": First, I'm going to see if I can isolate and eliminate our conduit's dependencies on Cocoa, but if that's not possible, I'll try following Apple's instructions for lazy loading. I'll let you all know how it goes. I'd also welcome thoughts on other solutions. Best wishes, --Stuart A. Malone Llamagraphics, Inc. Makers of Life Balance personal coaching software http://www.llamagraphics.com/ From florent at florentpillet.com Sun May 28 01:51:20 2006 From: florent at florentpillet.com (Florent Pillet) Date: Sun May 28 01:51:26 2006 Subject: [missing-sync-palmos-dev-talk] Using Cocoa in a Carbon conduit In-Reply-To: References: <32b179b00605161809w1d177825g53f1c78c6c627687@mail.gmail.com> <0DEE400D-A4B8-41A5-A05D-0A4B56704BCA@llamagraphics.com> <32b179b00605190113u8b9b224va3373c4406ee1cf2@mail.gmail.com> Message-ID: <7AB650BF-A1DC-4816-A975-2EEA14B199F1@florentpillet.com> You can't unload a module that used / uses the objc runtime. It's simply not supported by the system (at least wasn't last time I checked on Panther, it may have evolved on Tiger). Florent On 26 mai 06, at 16:28, Stuart A. Malone wrote: > I believe that I have just run into this issue. Palm Desktop > crashes when it attempts to unload my mixed Carbon/Cocoa bundle > under Panther. I'm still researching the issue, but I wanted to > mention it right away so that we can put our heads together and > work out a solution. -- Florent Pillet http://www.florentpillet.com Freelance software consultant - Palm OS, Windows Mobile, Mac OS X Skype callto://florent.pillet From samalone at llamagraphics.com Wed May 31 13:18:02 2006 From: samalone at llamagraphics.com (Stuart A. Malone) Date: Wed May 31 13:18:10 2006 Subject: [missing-sync-palmos-dev-talk] Crashes at exit under Palm Desktop on Panther Message-ID: <92C05953-FA63-4941-AF64-26E4784FB5E5@llamagraphics.com> After a couple days of tough debugging, Catherine and I have another tip to share with developers who are writing conduits under Xcode that will be running under Palm Desktop on Panther. The symptom is that both the HotSync Manager and the Conduit Manager crash on exit on Palm Desktop under Panther. The stack trace is very short, only a few frames, and does not point to the conduit code. In our case it was pointing to OpaqueICInstance. The conduit runs fine, but the parent application crashes on exit. Removing the conduit from the Conduits folder eliminates the crash. Tiger, Missing Sync, and Intel Macs do not seem to be affected by this problem. The crash only occurs if the conduit calls atexit(), so many conduits will not be affected. However, any C++ code that contains static destructors implicitly calls atexit(), so this does affect any conduits written in C++ that have globally or statically allocated objects with destructors. The problem seems to be that the destructors for the conduit are being registered with the main application, and when the main application quits it tries to call the (no longer loaded) destructors in the conduit. This problem is more likely to affect developers porting conduits from CodeWarrior, since CodeWarrior used a different technique for calling static destructors that worked properly in conduits. If you suspect that your conduit may be suffering from this problem, it is simple enough to check: nm -u /path/to/Conduit.plugin/Contents/MacOS/Conduit | fgrep atexit If you get a line containing "U ___cxa_atexit", then your conduit will probably crash under Palm Desktop on Panther. Of course, one solution is to rewrite the conduit to not call atexit () or use any static C++ objects. If this is not practical, there is some code available from the folks at OmniGroup that redefines atexit () so that it stores termination handlers for the conduit separately from the main application. I have not tried this code yet, but I will be soon. I have some concerns that their code seems to be relying on a static destructor to trigger the cleanup, which seems a bit too self-referential to actually work, but perhaps there is something subtle going on that I have missed. In any case, it seems that something similar to their solution should work: I'll let you know when we have tested their solution more thoroughly. In the meantime, we'd love to hear from anyone else who may have encountered this problem. Best wishes, --Stuart A. Malone Llamagraphics, Inc. Makers of Life Balance personal coaching software http://www.llamagraphics.com/