[missing-sync-palmos-dev-talk] Conduit progress callback function

[Scott Gruby]

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.
<http://www.markspace.com/>

Please visit <http://www.markspace.com/support/> for assistance with  
Mark/Space products.