n00b mac programmer: Question about Carbon and Dynamic libraries

[tachyon]

Hi guys, I'm currently porting some win32 code to macintosh for work and have a couple of questions. Was starting to wonder where all the mac guru's were 'till i found this site lol. I have never even touched a mac before since this (though its starting to grow on me) so I hope my questions aren't too stupid.

I'm currently using codewarrior 8 in osx and developing using the carbon api. i have build targets set up for Mach-O as well as CFM. (we want to build for osx and os9). The Mach-0 target links to the carbon framework and CFM links to CarbonLib.

(#include <Carbon/Carbon.h> for Mach-O and #include <Carbon.h> for CFM)

The thing is , all my file processing code seems to work only with the "classic" type filepaths (ie Volume:directory:file) rather than the osx style (Volume/directory/file).

i'm using FSMakeFSSpec() and then FSpOpenDF() to open the files.

In an effort to work out what is going on, i took the file opening code and made a tiny simple app that just opens a file and compiled it using:

g++ test.cpp -framework Carbon

I run the code and it still only works with classic type filepaths. What is going on here? (The thing is, i have other binaries, which used the same method of opening files and they seem to work okay). Please help :cry:

Another question is about dynamic libraries. I would like to port the plugin functionality of the app. Can i just build dylibs and load them in as plugins? I read somewhere that i actually have to build bundles to do this, and can't us dylibs. Is this correct? Can someone direct me to some resources on building building bundles and how to load bundles (or dylibs at runtime)?

Anyway, thank you very much for your help guys :)

[NCarter]

Welcome to iDevGames, tachyon! :)

The thing is , all my file processing code seems to work only with the "classic" type filepaths (ie Volume:directory:file) rather than the osx style (Volume/directory/file).

i'm using FSMakeFSSpec() and then FSpOpenDF() to open the files.
Carbon file functions only work with old-style paths. If you want to use Unix paths you need to use other APIs (such as the C standard library).

Another question is about dynamic libraries. I would like to port the plugin functionality of the app. Can i just build dylibs and load them in as plugins? I read somewhere that i actually have to build bundles to do this, and can't us dylibs. Is this correct? Can someone direct me to some resources on building building bundles and how to load bundles (or dylibs at runtime)?
CFPlugIn (http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFPlugIns/index.html) from Core Foundation looks like it might do the job for you.

[OneSadCookie]

CFPlugIn is probably overkill; CFBundle should do the job.

CFBundle can load CFM Shared Libraries or Mach-O bundles, into both CFM and Mach-O programs, so it would let the same plug-in work on both Mac OS 9 and Mac OS X.

[tachyon]

thanks for the help guys, i was just wondering, I can just compile a normal library as a bundle right, without having to do anything funky?

also is there a function in the carbon API which can convert classic style filepaths into unix file paths, because i could have sworn that i saw the carbon file api working with unix paths before (which is why i was wondering why it wasn't working for me when i build my own programs).

I'm just not too keen on having sepearte file processing code for the Mach-o and CFM targets.

I was just reading this:
"Another obvious problem is the different path separators between HFS+ (colon, ':') and UFS (slash, '/'). This also means that HFS+ file names may contain the slash character and not colons, while the opposite is true for UFS file names. This was easy to address, though it involves transforming strings back and forth. The HFS+ implementation in the kernel's VFS layer converts colon to slash and vice versa when reading from and writing to the on-disk format. So on disk the separator is a colon, but at the VFS layer (and therefore anything above it and the kernel, such as libc) it's a slash. However, the traditional Mac OS toolkits expect colons, so above the BSD layer, the core Carbon toolkit does yet another translation. The result is that Carbon applications see colons, and everyone else sees slashes. This can create a user-visible schizophrenia in the rare cases of file names containing colon characters, which appear to Carbon applications as slash characters, but to BSD programs and Cocoa applications as colons."

from:
http://www.wsanchez.net/papers/USENIX_2000/

is there just a function or something in carbon i can call to translate filepaths?

sorry if this question is silly, once again thank you very much for your help :)

[OneSadCookie]

Why do you want to translate file paths? Why not just use HFS+ (:-separated) paths for both targets?

It might be worthwhile using CFURLRef rather than paths; it has a method to get an FSRef for actually opening the files...

[tachyon]

Why do you want to translate file paths? Why not just use HFS+ (:-separated) paths for both targets?

because it is the user that enter's in the filepath to the program. Okay, here goes another stupid question: People typically use unix style file paths on osx and : style paths in earlier mac os's right?

I looked at the API documentation and can't find a method that turns a CFURL into a FSRef? This is what you meant wasn't it. CFURL works on os9 as well as osx doesn't it? Also, does CoreFoundation have anything to do with Carbon?

I also noticed that all the carbon functions to open a file take in a FSSpec, rather than an FSRef, are they the same thing?

Thanks, you guys are awesome

[OneSadCookie]

Nobody ever types file paths on the Macintosh, and they're seldom presented to the user as paths (though see the search results in the Finder).

Give 'em an open dialog!

[tachyon]

I'm actually building a library, and some of the functions in the library take in a filepath. (ie LoadImage(filePath). So i gues by people, i meant developers

[OneSadCookie]

that's a little more problematic.

I guess you're bound to the existing API?

[tachyon]

yep, we want to keep the api consistent across all platforms.

[OneSadCookie]

Well then I guess the right thing to do is probably simply to write two different ports... one for Mac OS 9 (if you really still need this, which is less and less likely by the day), and one for Mac OS X. Depending on how you write things (and precisely what this library does), the Mac OS X port might just about work on Linux, too.

[NCarter]

I looked at the API documentation and can't find a method that turns a CFURL into a FSRef? This is what you meant wasn't it. CFURL works on os9 as well as osx doesn't it?
You're looking for CFURLGetFSRef() (http://developer.apple.com/documentation/CoreFoundation/Reference/CFURLRef/Reference/function_group_3.html#//apple_ref/doc/uid/20001206/F16227). Yes, CFURL works on OS9 as well as OSX, although it's possible that the precise format of the URL will vary between the two systems.

Also, does CoreFoundation have anything to do with Carbon?
Core Foundation is in CarbonLib, but it isn't exactly part of Carbon; it's really an independent set of functions. In practice you don't really need to worry about this distinction, except in the sense that it's annoying that (for example) Carbon file functions generally don't directly accept CF datatypes.

Be aware that a few CF functions are not in CarbonLib and therefore won't work on OS9. Check Apple's API reference - it always says at the bottom of the section which version of CarbonLib (if any) supports a particular function.

I also noticed that all the carbon functions to open a file take in a FSSpec, rather than an FSRef, are they the same thing?
Nope. FSSpecs are the old way of doing things, and when used on their own are limited to 31 character filenames. FSRefs are a modern abstraction of the same thing. If you use FSSpecs in conjunction with FSRefs you can work with much longer filenames.

To convert between the two, use FSpMakeFSRef() (http://developer.apple.com/documentation/Carbon/Reference/File_Manager/file_manager/function_group_11.html#//apple_ref/doc/uid/TP30000107/TPXREF113) or FSGetCatalogInfo() (http://developer.apple.com/documentation/Carbon/Reference/File_Manager/file_manager/function_group_1.html#//apple_ref/doc/uid/TP30000107/F13082) (the latter looks scarier than it really is!).

[Steven]

As a side note, I find it really annoying when any function requires an old :-separated path. Many developers will be your new best friend if you make your APIs take the /-separated paths :)

[Hog]

... one for Mac OS 9 (if you really still need this, which is less and less likely by the day).

the more and more you think about it a Mac OS 9 port is not really necisary. if i think back to times just before OS X came i remember there were alot of people bitching about your apps not running on their system (OS 8.3 or something) because they refused to upgrade. so probably if someone is still using an antique Mac OS there is a chance of them not having any Carbon support at all.

[tachyon]

thanks for all your help guys, the mac dev community is awesome :) i agree that a mac os9 port probably isn't necessary but unfortunately it isn't up to me.