Mac OS X : Carbonised version of SDL.framework

SDL Development
1

Hi all,
Am I right in saying that the current Mac OS X version of
SDL.framework is only designed to work with Cocoa?

If so how can I build a version that works with Carbon?

Thanks,

Dominique.

2

You shouldn’t have any problems using SDL.framework with Carbon. SDLMain.m
requires Cocoa, so you’ll just need to link your app against both
Carbon.framework and Cocoa.framework.

I’ve never tried to use Carbon with SDL, mind you, but I don’t foresee any
issues since you can typically mix Cocoa and Carbon fairly liberally, I
think. Someone may correct me if I’m wrong.> ----- Original Message -----

From: dominique@savagesoftware.com.au (Dominique Louis)
To:
Sent: Friday, November 09, 2007 3:02 PM
Subject: [SDL] Mac OS X : Carbonised version of SDL.framework…

Hi all,
Am I right in saying that the current Mac OS X version of
SDL.framework is only designed to work with Cocoa?

If so how can I build a version that works with Carbon?

Thanks,

Dominique.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

3

If so how can I build a version that works with Carbon?

There isn’t a reason you can’t use Cocoa code in an otherwise Carbon
application on Mac OS X, so the Cocoa-based SDL should work fine.

That being said, the Mac OS 9 codebase can (mostly?) work on OS X as a
Carbonized library…but I don’t see a good reason to use it. Even if
you want a “Carbonized” application (one that works on both OS 9 and OS
X), we’re probably at the point where it’s worth shipping two packages.
Since you can’t use Mach-O for those, it means you still need to have a
CFM PowerPC build for OS 9 and PowerPC Mac OS X, and a separate Mach-O
Intel package for newer machines.

–ryan.

4

Quoting “Ryan C. Gordon” :

If so how can I build a version that works with Carbon?

There isn’t a reason you can’t use Cocoa code in an otherwise Carbon
application on Mac OS X, so the Cocoa-based SDL should work fine.

That being said, the Mac OS 9 codebase can (mostly?) work on OS X as a
Carbonized library…but I don’t see a good reason to use it. Even if
you want a “Carbonized” application (one that works on both OS 9 and OS
X), we’re probably at the point where it’s worth shipping two packages.
Since you can’t use Mach-O for those, it means you still need to have a
CFM PowerPC build for OS 9 and PowerPC Mac OS X, and a separate Mach-O
Intel package for newer machines.

i think you should really be able to trust users to be able to download the
right package, but if the program is small enough then just for vanitys sake
multiple binarys whatever they are called are a must ( used a mac for
the first
time in years the other day ) ( i still want my highscore table inside the
executable )

5

[…]

( i still want my highscore table inside the executable )

…but applications can’t rely on having write permission for their
bundle - let alone the actual executable, right…?

This could probably be an issue on Windows as well, and it’s nearly
always an issue on traditional Unix-like systems.

Basically, a normal application just has no business messing with it’s
executable (or any exectubles at all, for that matter!), and it
should not assume that it’s install directory belongs to the current
user.

//David Olofson - Programmer, Composer, Open Source Advocate

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Saturday 10 November 2007, neil at cloudsprinter.com wrote: