On MacOS X 10.5.6 Intel targeting 10.3.9 PPC:

What are the gotchas with respect to calling C functions from FPC?

For example if I wanted to be able to make use some of Apple's Serial example code <http://developer.apple.com/samplecode/SerialPortSample/index.html> but don't want to go to all the trouble of converting all to Pascal.

Is there better examples somewhere?

Are there Xcode options that need to be set so that Pascal to C calling conventions match or does it all just work?

Is there good reading available for this somewhere?

What other issues might I have to watch out for?

Thx for any tips,
Ken G. Brown

Ken G. Brown wrote

On MacOS X 10.5.6 Intel targeting 10.3.9 PPC: What are the gotchas with respect to calling C functions from FPC?

Mark the external C functions you import in your Pascal code as "cdecl", e.g.

procedure cTest; cdecl; external;

What other issues might I have to watch out for?

Make sure that the types in your Pascal and C code match. The easiest is to use the ctypes unit. Then you can use the common C-types by prefixing them with "c" (e.g., cint, clong, clonglong, cuint, culong, culonglong, cfloat, ...). And don't try to free pointers allocated in the C code in Pascal code and vice versa.

Jonas

procedure cTest; cdecl; external;

it's true for unix functions, but Carbon functions are using mwpascal convention, right?

dmitry boyarintsev wrote

> procedure cTest; cdecl; external; it's true for unix functions, but Carbon functions are using mwpascal convention, right?

mwpascal is the same as cdecl, except that it always passes "const" parameters that are record types by reference (because that's what MetroWerks Pascal, aka mwpascal, did).

Jonas

huh?!!
well thanks! because i always thought that 'mwpascal' is the same as 'fastcall' (register), except for 'const' parameters.

dmitry boyarintsev wrote

huh?!! well thanks! because i always thought that 'mwpascal' is the same as 'fastcall' (register), except for 'const' parameters.

On non-i386, all calling conventions are identical (to the standard calling convention defined in the ABI) except for some small Pascal- level details (such as the const parameters in case of mwpascal). And on all architectures except for i386, the standard calling conventions pass a number of parameters in registers.

Jonas

Is there any way to use cocoa libraries instead of the carbon ones that have the headers shipped with fpc on osx?
The carbon apis are no longer supported by apple, and it would be nice to have cocoa apis supported, because of their better integration to the system, and their accessibility features that are basically free when used properly.
Is this something that can be done, is being done, planned to be done, or is it something I can do?
Honestly, I'm not tht great at C, and even using the carbon headers already provided are giving me enough troubles (are there any samples available?) but if we could use cocoa apis instead, fpc applications would fall right inline with accessibility guidelines, and make fpc programs accessible to many more folks using osx.

See this page: http://wiki.freepascal.org/PasCocoa

The carbon apis are no longer supported by apple,

Has apple anounced that?

and it would be nice to have cocoa apis supported, because of their better integration to the system, and their accessibility features that are basically free when used properly.

what do you mean by "accessibility features"?
http://developer.apple.com/documentation/Carbon/Conceptual/MakingAppsAccessible/AXCarbonIntro/chapter_1_section_1.html

Thanks,
Dmitry

dmitry boyarintsev wrote

See this page: http://wiki.freepascal.org/PasCocoa

Thanks for that, will check it out.

Voiceover (the screen reader that ships with osx) and the other accessibility features such as reading outloud, screen contrast, larger/smaller text, background/foreground colors and so on) are all basically free when using cocoa apis, as the features are built-in to the cocoa apis, and require very little (if any) coding on the developers part to make the programs usable by users of these technologies.
Being a voiceover user myself, I'm of course all for this modification. Carbon aps can be made accessible, but it takes additional work on the developers part, and generally, they're still a bit more difficult to use (I.E. vo users need to use simulated mouse clicks instead of using voiceover generated button clicks) as well as labels for things like buttons, tables and scroll bars. All these things are much simpler under cocoa than they ae using carbon equivalents.

http://developer.apple.com/documentation/Carbon/Conceptual/MakingAppsAccessible/AXCarbonIntro/chapter_1_section_1.html As opposed to the one for cocoa at:

http://developer.apple.com/documentation/Cocoa/Conceptual/Accessibility/cocoaAXIntro/cocoaAXintro.html There's considerably less work to access enable a cocoa app then there is for a carbon one, as evidenced by comparisons between these two document trails.
On the surface, it looks similar, but do some digging, and you'll see there's a world of difference.
A lot of things you get for free with cocoa takes specific coding on the carbon apis.
That's why I'm trying for cocoa support (preferrably by default) as that would make more apps accessible right out of the box.