MacOS (X) and other questions

Hello!

A few questions from a persistent lurker who hasn’t been paying attention
recently.

How is the MacOS X port going? What architecture does SDL on MacOS support:
Classic, Carbon, Cocoa or some variation thereof? I’m willing to lend a hand
on any of the former two projects.

Once SDL is ported to MacOS X it would make a let of sense (IMHO) to use SDL
as the root display device of a XFree86 server. Has anyone tried this?

Thanks.

Jon.

Jonathan Wight wrote:

How is the MacOS X port going? What architecture does SDL on MacOS support:
Classic, Carbon, Cocoa or some variation thereof? I’m willing to lend a hand
on any of the former two projects.

Sam incorporated my patches a few days ago, presumably that means they’ll
be in 1.1.5. I based them on Carbon, just carbonizing the existing
Mac bits. Works for porting various games, at least if you like
silence :-), but I’ve just found out that Apple has already published
sample code to emulate double-buffered sound playing, so that’s fixable.

Other big holes are lack of joystick support (no Input Sprockets on X,
and no replacement library finished yet, sigh), CD playing (I think
there’s sample code for this too), or mouse warping (essential to SDL
Doom, may never be possible for OS X but still researching).

Once SDL is ported to MacOS X it would make a let of sense (IMHO) to use SDL
as the root display device of a XFree86 server. Has anyone tried this?

Definitely has amusing possibilities, but I don’t think anybody has
tried this yet. A similar amusing idea is to port the lower layer of Gtk
to SDL.

Stan

Other big holes are lack of joystick support (no Input Sprockets on X,
and no replacement library finished yet, sigh), CD playing (I think
there’s sample code for this too), or mouse warping (essential to SDL
Doom, may never be possible for OS X but still researching).

On that note, any idea when good development tools on MacOS X will be
available to us mortals? :slight_smile:

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Ah, CodeWarrior 6 (which just came out) supports MacOS X. Saw it on their
website.

-ryan

“Sam Lantinga” wrote in message
news:E13cLeh-0006qx-00 at roboto.devolution.com…> > Other big holes are lack of joystick support (no Input Sprockets on X,

and no replacement library finished yet, sigh), CD playing (I think
there’s sample code for this too), or mouse warping (essential to SDL
Doom, may never be possible for OS X but still researching).

On that note, any idea when good development tools on MacOS X will be
available to us mortals? :slight_smile:

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

Other big holes are lack of joystick support (no Input Sprockets on X,
and no replacement library finished yet, sigh), CD playing (I think
there’s sample code for this too), or mouse warping (essential to SDL
Doom, may never be possible for OS X but still researching).

On that note, any idea when good development tools on MacOS X will be
available to us mortals? :slight_smile:

Well my copy of CodeWarrior Pro 6 arrived today (woohoo). The IDE itself
works pretty well under carbon but as webshots still hasn’t been carbonised
yet I can’t really test its debugging abilities. Wan’t impressed with CW’s
debugging skills during the CW beta.

The MacOS X developer CD is arriving at people’s doors at the moment. It
hasn’t arrive at mine yet. Boo hiss.

I’ve also installed GCC (and other command line gizmos) from the Darwin
project onto my MacOS X public beta which would theoretically be enough to
port SDL to Darwin and maybe even Cocoa. I’ve also heard encouraging
comments from people who have installed the MacOS X DP4 dev tools onto MacOS
X Public Beta 1. But as my dev CD is on it’s way I haven’t seen the need.

There go Sam, spoilt for choice. Are you on the Apple Dev program?

Jon.On 9/22/00 12:45 AM, "Sam Lantinga" <slouken at devolution.com> wrote:

Sam incorporated my patches a few days ago, presumably that means they’ll
be in 1.1.5. I based them on Carbon, just carbonizing the existing
Mac bits. Works for porting various games, at least if you like
silence :-), but I’ve just found out that Apple has already published
sample code to emulate double-buffered sound playing, so that’s fixable.

Look forward to checking this out.

Once SDL is ported to MacOS X it would make a let of sense (IMHO) to use SDL
as the root display device of a XFree86 server. Has anyone tried this?

Definitely has amusing possibilities, but I don’t think anybody has
tried this yet. A similar amusing idea is to port the lower layer of Gtk
to SDL.

I think it would be a great way to get X Windows running in MacOS X, and
also provide an easy path for any platform that supports SDL to support X
Windows. The only non-commercial X Windows project for MacOS X seems to have
ceased development somewhere before the realise of DP4.

What would be involved with getting X Windows running ‘in’ SDL? Anyone here
an X Windows guru?

Jon.On 9/22/00 12:28 AM, "Stan Shebs" <shebs at shebs.cnchost.com> wrote:

What would be involved with getting X Windows running ‘in’ SDL?

That should not be too hard - it’s basically a semi-dumb framebuffer.
Some glue code would be needed. SDL doesn’t cover the communication part
(sockets), so that would have to be done by hand.

Performance would not be great, though, but with accelerated block copies
and fills (and maybe colour key blits for text drawing) it could be bearable

Didn’t John Carmack do a quick-and-dirty port of an X11 server to MacOS X?

What would be involved with getting X Windows running ‘in’ SDL? Anyone here
an X Windows guru?
Argh! I’m pretty sure there are faster and more reliable ways to run a X
server than on top of SDL.
This evil topic has been discussed zillions of times before.

MartinOn Fri, 22 Sep 2000, Jonathan Wight wrote:

Bother! said, Pooh, as he was taken to the Body Bank

Other big holes are lack of joystick support (no Input Sprockets on X,
and no replacement library finished yet, sigh), CD playing (I think
there’s sample code for this too), or mouse warping (essential to SDL
Doom, may never be possible for OS X but still researching).

On that note, any idea when good development tools on MacOS X will be
available to us mortals? :slight_smile:

CodeWarrior 6 is out, it supports and can run in Classic and OS X. Besides
that, Apple is releasing Developer Tools for MacOS X Public Beta in late
October (gcc, ProjectBuilder, etc). For the time being, I believe it is
possible to use Darwin distribution to install gcc on MacOS PB.On Thu, 21 Sep 2000, Sam Lantinga wrote:

What would be involved with getting X Windows running ‘in’ SDL?

Performance would not be great, though, but with accelerated block copies
and fills (and maybe colour key blits for text drawing) it could be bearable

I don’t see performance being too much of a nightmare, people have ported X
Windows to MacOS classic before and it was pretty sweet.

Didn’t John Carmack do a quick-and-dirty port of an X11 server to MacOS X?

Um yes and no. Carmack ported most of it to Darwin (the lowest layer of
MacOS X) and other people completed it. Unfortunately it means having to
kill your MacOS X GUI and run X Windows instead. I’m thinking using SDL
might be a nice and portable way of getting MacOS X applications to run side
by side with X Windows applications. The best of both worlds.

Argh! I’m pretty sure there are faster and more reliable ways to run a X
server than on top of SDL.

I’m sure there are, but running it like that would serve a purpose.

This evil topic has been discussed zillions of times before.

But unfortunately I must have missed it. Which is why I’m asking about it
again.

Jon.On 9/22/00 3:08 AM, "Mattias Engdeg?rd" <f91-men at nada.kth.se> wrote:

On 9/22/00 5:56 AM, “Martin Donlon” wrote:

On Fri, 22 Sep 2000, Jonathan Wight wrote:

Darrell Walisser wrote:

CodeWarrior 6 is out, it supports and can run in Classic and OS X.

I don’t think it produces Mach-O executables yet though, your apps
would run in Classic mode. But don’t quote me, I haven’t actually
looked at a CW 6 myself.

Besides
that, Apple is releasing Developer Tools for MacOS X Public Beta in late
October (gcc, ProjectBuilder, etc). For the time being, I believe it is
possible to use Darwin distribution to install gcc on MacOS PB.

The October timeframe is for free downloads I believe. The developer
CDs started shipping at the beginning of the week, have been showing
up on people’s doorsteps one by one. (Do Windows developers count
the days to MSDN CDs? :slight_smile: ) And yes, the folks wanting to be on
the bleeding edge - or at least bleeding :slight_smile: - can also use Darwin
bits. The Darwin CVS repository actually leads OS X releases, so
the true low-level aficionados can get a good look at what’s going
to be in the next release (but no, unannounced products won’t show
up there!).

Incidentally, part of my day job is to make FSF and Apple GCCs
track each other more closely, so you’ll be able to take advantage
of GCC improvements as soon as they become available…

Stan

In article <39CB8A94.324F025F at shebs.cnchost.com>, sdl at lokigames.com wrote:

CodeWarrior 6 is out, it supports and can run in Classic and OS X.

I don’t think it produces Mach-O executables yet though, your apps
would run in Classic mode. But don’t quote me, I haven’t actually
looked at a CW 6 myself.

There are 3 different types of MacOS/PowerPC executables:

Classic: CFM linked to InterfaceLib (MacOS7+8+9 native, OSX in emulation)
Carbon: CFM linked to CarbonLib (MacOS8+9 w/ CarbonLib, OSX natively)
Cocoa/BSD: Mach-O (OSX only)

CodeWarrior only generates CFM apps (but there’s no real reason they couldn’t
target Mach-O at some point). ProjectBuilder/gcc only generates Mach-O binaries.

An interesting upshot of all this is that a Carbon app cannot call any BSD APIs
natively. There is some sort of support in the CFPlugin wrapper for loading a
shared library in another format (not Classic tho), but I’m still hoping they
provide some sort of shim to get access to the Cocoa APIs from Carbon.

Incidentally, part of my day job is to make FSF and Apple GCCs
track each other more closely, so you’ll be able to take advantage
of GCC improvements as soon as they become available…

Very cool, keep up the good work Stan.

Matt–
/* Matt Slot * Bitwise Operator * http://www.ambrosiasw.com/~fprefect/ *

  • "Did I do something wrong today or has the world always been like this *
  • and I’ve been too wrapped up in myself to notice?" - Arthur Dent/H2G2 */

CodeWarrior only generates CFM apps (but there’s no real reason they couldn’t
target Mach-O at some point). ProjectBuilder/gcc only generates Mach-O
binaries.

CWPro6 contains some beta Mach-O tools in the “thrill-seekers” folder…

An interesting upshot of all this is that a Carbon app cannot call any BSD
APIs
natively. There is some sort of support in the CFPlugin wrapper for loading a
shared library in another format (not Classic tho), but I’m still hoping they
provide some sort of shim to get access to the Cocoa APIs from Carbon.

Me too. Didn’t know that there was a CFPlugin class going to have to check
that out. I thought I was going to have to hack up my own.

Jon.On 9/22/00 7:44 PM, "Matt Slot" <nospam at ambrosiasw.com> wrote:

Matt Slot wrote:

There are 3 different types of MacOS/PowerPC executables:

Classic: CFM linked to InterfaceLib (MacOS7+8+9 native, OSX in emulation)
Carbon: CFM linked to CarbonLib (MacOS8+9 w/ CarbonLib, OSX natively)
Cocoa/BSD: Mach-O (OSX only)

Close, but not quite right about Carbon. There are actually two ways
to “do Carbon” on OS X; the first is as you describe, except that CFM
executables always run in Blue Box aka Classic. The second is to build
a Mach-O executable that uses the Carbon API. This second way is actually
how I got SDL running on OS X, so I’m pretty sure it works. :slight_smile:

ProjectBuilder/gcc only generates Mach-O binaries.

We have somebody slaving away at PEF generation these days. We can
cross-build basic apps, and are working on cross-compiling libstdc++;
amusingly, it’s proven useful to borrow some of the bits I wrote years
ago to port GNU tools to MPW…

An interesting upshot of all this is that a Carbon app cannot call any BSD APIs
natively.

Not true. A native OS X executable can make Carbon, Cocoa, and BSD calls
in any combination it desires; they all go through the same Mach-O runtime.
You can see this by going to /System/Library/Frameworks and rooting around,
all the app frameworks are structured the same way, as Mach-O dynamically
loadable shared libraries. This is the fruit of the whole carbonization
process - Mac toolbox usage is no longer the quasi-system programming
activity where a little mistake around WaitNextEvent takes out your
whole machine.

Stan

I guess there is some terminology confusion going on here. I used "Carbon"
to describe CFM apps linked to CarbonLib, but I didn’t mean that Mach-O apps
couldn’t use the Carbon APIs as well.

We have somebody slaving away at PEF generation these days. We can
cross-build basic apps, and are working on cross-compiling libstdc++;
amusingly, it’s proven useful to borrow some of the bits I wrote years
ago to port GNU tools to MPW…

Sweet, I’m looking forward to that.

An interesting upshot of all this is that a Carbon app cannot call any
BSD APIs natively.

Not true. A native OS X executable can make Carbon, Cocoa, and BSD calls
in any combination it desires; they all go through the same Mach-O runtime.

Again, when I said Carbon I meant a Carbon/CFM application couldn’t use the
BSD and Cocoa APIs directly.

It’s a bad habit, I guess, because Carbon was marketed as a transition from
OS9 to OSX APIs and CFM the only form of Carbon many of us have had access
to until now.

Thanks for the clarifications!

Matt–
/* Matt Slot * Bitwise Operator * http://www.ambrosiasw.com/~fprefect/ *

  • "Did I do something wrong today or has the world always been like this *
  • and I’ve been too wrapped up in myself to notice?" - Arthur Dent/H2G2 */