Mainline vs Embedded

SDL Development
1

At present, SDL is only designed to support applications,
sdl-config gives switches like these:

[OSX]
$ sdl-config --cflags
-I/Users/rfistman/include/SDL -D_THREAD_SAFE
$sdl-config --libs
-L/Users/rfistman/lib -lSDLmain -lSDL -framework Cocoa -framework OpenGL

$ sdl-config --libs
-L/usr/local/lib -lmingw32 -lSDLmain -lSDL -mwindows -mno-cygwin

[nocygwin]
$ sdl-config --cflags
-I/usr/local/include/SDL -Dmain=SDL_main -I/usr/include/mingw -DWIN32
-Uunix -mno-cygwin

Similarly on other platforms. The idea, I guess, is to support
’an SDL application’.

The effect is that (officially) SDL can’t be embedded.
I would really like to see this fixed (officially).

In fact embedded SDL seems to work just fine on Linux,
and possibly on Windows – I have stuff that works
on both without needing SDLmain. I see in the source a lot
of the mainline init code has been moved into
SDL_init – where, IMHO, it should be if possible.

Most of the SDLmain seems to do nothing more than
fiddling argc/argv, which I have no need of.
However there is also some code, eg on Windows registering
a main Window class if I remember correctly.

I have no problem with supporting platform independent
application development, but I’d like to see embedded
code work too. In such an environment, it isn’t acceptable
for a foreign mainline to take over. In particular in
my system, the mainline is a pre-built binary executable
and all user code is put in a DLL which it loads and
runs.–
John Skaller
Felix, successor to C++: http://felix.sf.net

2

I have no problem with supporting platform independent
application development, but I’d like to see embedded
code work too. In such an environment, it isn’t acceptable
for a foreign mainline to take over. In particular in
my system, the mainline is a pre-built binary executable
and all user code is put in a DLL which it loads and
runs.

The use of sdl-config and SDLmain is completely optional. :slight_smile:

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
3

So let me confirm, you’re saying everything will work as
advertised, whether or not one links SDLmain?

In which case … it would seem useless, so why is it there?
Is it exclusively just fiddling argc/argv?

BTW: if you like you can add to language binding page:

http://www.libsdl.org/languages.php

Currently, the SDL package is part of the core distribution.
I would like to do some basic portable GUI stuff and some
cool demos … SDL seems the best way of doing that because
it provides a portable abstraction layer. (Although there
seems not to be a Cygwin package for it)On Tue, 2006-02-21 at 21:04 -0800, Sam Lantinga wrote:

I have no problem with supporting platform independent
application development, but I’d like to see embedded
code work too. In such an environment, it isn’t acceptable
for a foreign mainline to take over. In particular in
my system, the mainline is a pre-built binary executable
and all user code is put in a DLL which it loads and
runs.

The use of sdl-config and SDLmain is completely optional. :slight_smile:

–
John Skaller
Felix, successor to C++: http://felix.sf.net

4

How would you explain this report from one of the Felix
developers? BTW: this is an OSX box, he’s claiming SDL_main
is not optional, and we have to call our main from inside
SDL_main … which is very nasty (since as mentioned,
our mainline is a prebuilt executable)On Tue, 2006-02-21 at 21:04 -0800, Sam Lantinga wrote:

I have no problem with supporting platform independent
application development, but I’d like to see embedded
code work too. In such an environment, it isn’t acceptable
for a foreign mainline to take over. In particular in
my system, the mainline is a pre-built binary executable
and all user code is put in a DLL which it loads and
runs.

The use of sdl-config and SDLmain is completely optional. :slight_smile:

=================
"sdl: 1.2.9
osx 10.4.4

Look, we know what the problem is, SDLmain has to call flx_run’s main to
set up its environ."

sdl_mac still not working (crashes). SDL_main needs to call flx_run’s main:

COMPILING GENERATED C++ TEST CODE: std dynamic
g++ -c -fno-common -Wall -Wno-invalid-offsetof -Wfatal-errors -Irtl -o
tut/examples/sdl100_dynamic.o -I/Users/gchilds/include/SDL
-D_THREAD_SAFE tut/examples/sdl100.cpp
tut/examples/sdl100.cpp: In member function ‘virtual flx::rtl::con_t*
flxusr::sdl100::flx_mixaudio::resume()’:
tut/examples/sdl100.cpp:384: warning: comparison between signed and
unsigned integer expressions
g++ -bundle -o tut/examples/sdl100.so tut/examples/sdl100_dynamic.o
-Lrtl -L/Users/gchilds/lib -lSDLmain -lSDL -framework Cocoa
-framework OpenGL -ldemux_dynamic -lfaio_dynamic -lflx_dynamic
bin/flx_run ./tut/examples/sdl100.so
2006-02-23 08:46:45.268 flx_run[26259] *** _NSAutoreleaseNoPool():
Object 0x5312b0 of class NSMutableParagraphStyle autoreleased with no
pool in place - just leaking
2006-02-23 08:46:45.269 flx_run[26259] *** _NSAutoreleaseNoPool():
Object 0x5316d0 of class NSCFDictionary autoreleased with no pool in
place - just leaking
2006-02-23 08:46:45.275 flx_run[26259] *** _NSAutoreleaseNoPool():
Object 0x525150 of class NSCFNumber autoreleased with no pool in place

  • just leaking
    2006-02

–
John Skaller
Felix, successor to C++: http://felix.sf.net

5

How would you explain this report from one of the Felix
developers? BTW: this is an OSX box, he’s claiming SDL_main
is not optional, and we have to call our main from inside
SDL_main … which is very nasty (since as mentioned,
our mainline is a prebuilt executable)

Let me re-phrase… it’s completely optional, assuming you do all
the necessary platform specific setup yourself (see SDLmain for details). :slight_smile:

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
6

And how would we know what that is? That’s an implementation
detail application programmers should not need to know about.

I would like to know whether SDL can be used as a library
or not.

At the moment it seems like the answer is YES on Linux
and Windows and NO on OSX.

I would like to see this fixed – IF it is possible of course.On Wed, 2006-02-22 at 17:18 -0800, Sam Lantinga wrote:

How would you explain this report from one of the Felix
developers? BTW: this is an OSX box, he’s claiming SDL_main
is not optional, and we have to call our main from inside
SDL_main … which is very nasty (since as mentioned,
our mainline is a prebuilt executable)

Let me re-phrase… it’s completely optional, assuming you do all
the necessary platform specific setup yourself (see SDLmain for details). :slight_smile:

–
John Skaller
Felix, successor to C++: http://felix.sf.net

7

You know, this is an open-source project, if there is something your
unhappy with, why don’t you submit a patch? Your upset because your
only provided with 99% of the solution? If you want life to be easy
you should quit being a programmer. But I’m sure if you like one of us
will be glad to give you your money back on how much you paid for to
use SDL ;-)-----
Matt Johnson
Graphics Developer
VCom3D, Inc.

Let me re-phrase… it’s completely optional, assuming you do all
the necessary platform specific setup yourself (see SDLmain for details). :slight_smile:

And how would we know what that is? That’s an implementation
detail application programmers should not need to know about.

I would like to know whether SDL can be used as a library
or not.

At the moment it seems like the answer is YES on Linux
and Windows and NO on OSX.

I would like to see this fixed – IF it is possible of course.

8

if i believed in karma i’d ++ you

but i dont, so no cookie
-mikeOn Wednesday 22 February 2006 21:45, Matt J wrote:

You know, this is an open-source project, if there is something your
unhappy with, why don’t you submit a patch? Your upset because your
only provided with 99% of the solution? If you want life to be easy
you should quit being a programmer. But I’m sure if you like one of us
will be glad to give you your money back on how much you paid for to
use SDL :wink:

9

Oops, I got moderated so I joined the list. Moderator: please discard
moderated post. Ta.

How would you explain this report from one of the Felix
developers? BTW: this is an OSX box, he’s claiming SDL_main
is not optional, and we have to call our main from inside
SDL_main … which is very nasty (since as mentioned,
our mainline is a prebuilt executable)

Let me re-phrase… it’s completely optional, assuming you do all
the necessary platform specific setup yourself (see SDLmain for details). :slight_smile:

And how would we know what that is? That’s an implementation
detail application programmers should not need to know about.

I would like to know whether SDL can be used as a library
or not.

At the moment it seems like the answer is YES on Linux
and Windows and NO on OSX.

I think it’s more accurate to say that SDL cannot be loaded
as a dll (by dll that I mean as a plugin to an SDL naive app).
It’s either in from the beginning (main) or it’s not in at all.

I can see the reasoning behind SDL’s structure: it allows portable
multimedia apps to be written without worrying about the local
idea of “main” (WinMain, etc), but it unfortunately locks SDL out
of plugin apps.

It would be nice if most of the SDLmain work were factored into
SDLInit so that relinquishing main were (a bit more) optional.

I would like to see this fixed – IF it is possible of course.

Once SDL becomes a plugin it opens it up the problem of SDL becoming
re-entrant/running multiple copies. That probably wouldn’t be so great
on some of the OSes it supports (thinking of fullscreen modes, etc).
Whatever happened to SDL and re-entrancy? I find one mention of it
on the net as part of the 2.0 rewrite. I should probably join this
list to find out.On 2/23/06, skaller wrote:

On Wed, 2006-02-22 at 17:18 -0800, Sam Lantinga wrote:

10

I might – but it would be pointless unless it was accepted.

The thing is, this is the sort of thing I suspect Sam would want to do
himself, since it is architectural (affects the organisation
and coherence of the whole platform).

It may be impossible! Do you think it is possible?
Is it a good idea?On Wed, 2006-02-22 at 21:45 -0500, Matt J wrote:

You know, this is an open-source project, if there is something your
unhappy with, why don’t you submit a patch?

–
John Skaller
Felix, successor to C++: http://felix.sf.net

11

Hello skaller,

Thursday, February 23, 2006, 1:50:04 AM, you wrote:

s> And how would we know what that is? That’s an implementation
s> detail application programmers should not need to know about.

The problem is Cocoa requiring setup code that every application must
have in order to work. If you were writing a bare Cocoa application,
you would have to do the work that SDLMain.m does yourself.

s> I would like to know whether SDL can be used as a library
s> or not.

Um, it’s perfectly usable as a library. Big deal, so you have to have
some startup code in there first. Go and blame Apple for making this a
requirement.

If you don’t like linking to SDLMain.lib, simply put SDLMain.m in your
XCode project or whatever. This is what I do, because I wanted to
customise certain aspects.

s> I would like to see this fixed – IF it is possible of course.

I don’t regard it as broken.–
Best regards,
Peter mailto:@Peter_Mulholland

12

skaller wrote:

Let me re-phrase… it’s completely optional, assuming you do all
the necessary platform specific setup yourself (see SDLmain for details). :slight_smile:

And how would we know what that is? That’s an implementation
detail application programmers should not need to know about.

I would like to know whether SDL can be used as a library
or not.

At the moment it seems like the answer is YES on Linux
and Windows and NO on OSX.

I can confirm that for Linux and OS X.

I would like to see this fixed – IF it is possible of course.

‘Fixed’ would imply that this is a bug, which it isn’t, since it’s clearly
documented. However, moving some of the initialization code from sdl’s main to
SDL_Init on OS X would certainly improve the usability of SDL on this plattform.

Anyway, the magic incantations under OS X are:

#import <SDL/SDL.h>
#import “SDLMain.h”

#import <Cocoa/Cocoa.h>

/* Portions of CPS.h */
typedef struct CPSProcessSerNum
{
UInt32 lo;
UInt32 hi;
} CPSProcessSerNum;

extern OSErr CPSGetCurrentProcess( CPSProcessSerNum *psn);
extern OSErr CPSEnableForegroundOperation( CPSProcessSerNum *psn, UInt32
_arg2, UInt32 _arg3, UInt32 _arg4, UInt32 _arg5);
extern OSErr CPSSetFrontProcess( CPSProcessSerNum *psn);

void CustomSDLMain()
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[ NSApplication sharedApplication ];
[ NSApp setMainMenu:[[NSMenu alloc] init] ];

 {
     CPSProcessSerNum PSN;
     /* Tell the dock about us */
     if (!CPSGetCurrentProcess(&PSN))
         if (!CPSEnableForegroundOperation(&PSN,0x03,0x3C,0x2C,0x1103))
             if (!CPSSetFrontProcess(&PSN))
                 [NSApplication sharedApplication];
 }

}

Call CustomSDLMain before your first call to SDL.

13

Hello skaller,

Thursday, February 23, 2006, 1:50:04 AM, you wrote:

s> And how would we know what that is? That’s an implementation
s> detail application programmers should not need to know about.

The problem is Cocoa requiring setup code that every application must
have in order to work.

There is some setup for Win32 as well.

If you were writing a bare Cocoa application,
you would have to do the work that SDLMain.m does yourself.

I have no problem linking to additional setup code.
The problem I have is when that code is not setup code,
but a subroutine which thinks it is the master,
and the user application a slave.

For example I’m perfectly happy to do this:

…
SDL_setup(); // setup SDL
…
// do SDL application
…

SDL_cleanup()

…

Such an architecture can be embedded: in a larger main
routine, in some subroutine with a short job, or
in a plugin. If SDL provides these routines it
would be great!

The existing SDLmain thing would then be:

.. fiddle with argv/argc
SDL_setup();
user_main();
SDL_cleanup()

which is provided so standard C ‘main()’ kinds of code
will run. This is the current situation – but of no
use in Felix.

I.e. all I’m asking for is two routines for setup and cleanup
instead of one main routine that calls another fixed routine.

Um, it’s perfectly usable as a library. Big deal, so you have to have
some startup code in there first. Go and blame Apple for making this a
requirement.

That isn’t the problem. It isn’t that startup code is needed,
its that the startup code can only be used as the application
main() function, which calls the client application.

Felix drivers – which are a an OS abstraction layer –
already do that. If you take away that layer, you’d have
to write your own scheduler, manage asynchronous I/O
yourself, etc.

s> I would like to see this fixed – IF it is possible of course.

I don’t regard it as broken.

It is broken in several senses: it isn’t documented,
it defeats embedding by taking control away.

Many other systems also do that. The very reason we’re
using SDL is that main library code does NOT do this.
It is up to the user to fetch events, draw graphics
when they want to, etc. The user is in control.
This is how it should be IMHO.
Callbacks suck – its my dang computer, it will do what
I tell it when I tell it to! :))

This, IMHO, is why SDL is so good.

And yet it seems that the very top level of SDL
requires a fat callback – your whole application – and
perhaps only on some platforms – without really needing to.

So I think it is broken, because it fails to preserve the
most important invariant the rest of the system provides:
it leaves the application programmer as master at all times.
It’s a toolkit – not a framework (or would be bar this
one small issue).On Thu, 2006-02-23 at 08:47 +0000, Peter Mulholland wrote:

–
John Skaller
Felix, successor to C++: http://felix.sf.net

14

skaller wrote:

I would like to see this fixed – IF it is possible of course.

‘Fixed’ would imply that this is a bug, which it isn’t, since it’s clearly
documented.

Can you tell me where?

But I think it is broken anyhow, in another sense:
as mentioned in prior email, SDL’s most important attribute is
that the application programmer is master, and SDL is a
slave – a collection of subroutines.

I think this is one of the reasons Simple DL is in fact
so good and why it is so simple (to use I mean!).

However, moving some of the initialization code from sdl’s main to
SDL_Init on OS X would certainly improve the usability of SDL on this plattform.

Anyway, the magic incantations under OS X are:

Thanks!!

[CustomSDLMain]

Call CustomSDLMain before your first call to SDL.

That looks perfect! Is any cleanup required?
For example, could one do the setup, run some SDL,
cleanup, then run the setup again and repeat?On Thu, 2006-02-23 at 10:49 +0100, Ulrich von Zadow wrote:

–
John Skaller
Felix, successor to C++: http://felix.sf.net

15 
    SDL-announce)"  <sdl at libsdl.org>

Message-ID: <1140701698.25493.59.camel at rosella.wigram>
Content-Type: text/plain

[…]

That looks perfect! Is any cleanup required?

All the main entry points are in src/main:
375 ./macosx/SDLMain.m
129 ./epoc/SDL_main.cpp
4 ./arch.c
13 ./dummy/SDL_dummy_main.c
562 ./macos/SDL_main.c
362 ./win32/SDL_win32_main.c
37 ./beos/SDL_BeApp.h
11 ./macosx/SDLMain.h
1493 total

For example, could one do the setup, run some SDL,
cleanup, then run the setup again and repeat?

There must be a way to make this work as it stands…
just lookat the number of SDL bindings:
(http://www.libsdl.org/languages.php).

How were they made to work? How were those languages bound to SDL
and not the other way around?

Take as an example pygame (the python SDL binding):
It must either

a) let SDL own its main, creating the necessity for SDL_python
interpreter binaries.

b) not use SDLmain and exclude all the platforms with non-trivial
src/main implementations (macosx, win32, beos).

c) have found some other way that we don’t know about.

http://pygame.seul.org/wiki/about says that pygame is highly portable,
which puts b) in doubt. a) also seems extra unlikely, because it would
result in python scripts incompatible with the python interpreter.
and what python game programmer would accept the following debacle as part
of his daily life?:

$ python game.py
[NSMemory pool complaints]
(segfault)

oops, always invoke game.py with SDLpython!

SDLpython game.py
[all singing, all dancing]

That leaves the elusive c).
Time to read pygame, uh spose.> From: skaller

Subject: Re: [SDL] Mainline vs Embedded
To: "A list for developers using the SDL library. (includes
On Thu, 2006-02-23 at 10:49 +0100, Ulrich von Zadow wrote:

16

For example, could one do the setup, run some SDL,
cleanup, then run the setup again and repeat?

There must be a way to make this work as it stands…
just lookat the number of SDL bindings:
(http://www.libsdl.org/languages.php).

How were they made to work? How were those languages bound to SDL
and not the other way around?

Take as an example pygame (the python SDL binding):
It must either

a) let SDL own its main, creating the necessity for SDL_python
interpreter binaries.

b) not use SDLmain and exclude all the platforms with non-trivial
src/main implementations (macosx, win32, beos).

c) have found some other way that we don’t know about.

pygame uses ©, it replicates the necessary bits of SDLmain for its
supported platforms in such a way that makes sense for Python (it
calls this platform setup stuff just before the video subsystem is
initialized). The OS X implementation actually uses a Python
Objective-C binding to do the necessary Cocoa init stuff.

Specifically, the pygame Mac OS X support is in lib/macosx.py, which
is called through an #ifdef in src/base.c in the PyGame_Video_AutoInit
() function. The pygame windows support is in anything that checks
#ifdef MS_WIN32 or #ifdef WIN32 (they are interchangeable, MS_WIN32
is what Python expects to see, and WIN32 is what SDL expects to see…
the pygame source uses these inconsistently, in whatever revision my
checkout is at anyway). I’m not sure if pygame supports special
initialization and finalization hooks for other platforms, you’d have
to read the code more carefully yourself. I can only really comment
on the Mac OS X support because I wrote it.

-bobOn Feb 23, 2006, at 5:21 PM, Rhythmic Fistman wrote:

From: skaller

17

[…]

Take as an example pygame (the python SDL binding):
It must either

a) let SDL own its main, creating the necessity for SDL_python
interpreter binaries.

b) not use SDLmain and exclude all the platforms with non-trivial
src/main implementations (macosx, win32, beos).

c) have found some other way that we don’t know about.

pygame uses ©, it replicates the necessary bits of SDLmain for its
supported platforms in such a way that makes sense for Python

Is there any reason that this replicated code couldn’t be conditionally
called from SDL_Init? If not, would there be any objection to such a patch
being submitted?

The removal of control over main can be quite nasty and have subtle
consequences. One not-so-far-fetched possibility: if you don’t own
main you can’t reliably use sigwait or even globally set the signal
mask, because SDL may have already spawned threads that are beyond
your control. Is this the case?

RF.> From: Bob Ippolito

On Feb 23, 2006, at 5:21 PM, Rhythmic Fistman wrote:

18

Is there any reason that this replicated code couldn’t be conditionally
called from SDL_Init? If not, would there be any objection to such a patch
being submitted?

It’s generally code that can’t be called from SDL_Init(), but it’s code that
you can call from your main application - that’s why the various initialization
functions are defined in SDL_main.h

SDL’s main() overriding is purely a convenience. If you want to roll your
own, you’re more than welcome to. That’s why the SDLmain code is all in the
public domain - for you to use/reuse/abuse as you like. :slight_smile:

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
19

Sam Lantinga wrote:

Is there any reason that this replicated code couldn’t be conditionally
called from SDL_Init? If not, would there be any objection to such a patch
being submitted?

It’s generally code that can’t be called from SDL_Init(), but it’s code that
you can call from your main application - that’s why the various initialization
functions are defined in SDL_main.h

I think the issue at the moment is that there’s some code in the OS X main()
that doesn’t conform to this (the mail I sent on Feb. 23 contains precisely that
code). Currently, just leaving away SDL_main is broken on OS X because of this
issue. This code could be moved to SDL_Init without causing problems - I’m
executing it directly before SDL_Init in libavg.

Anyway, I’d already asked Sam if a patch for this was ok and gotten a yes, but I
probably won’t have the time to do it, so…

Regards,

Uli

20

Hey.

Could you send or point me to the code snippet in question?

I’m in charge of Lua SDL binding, and this issue of main ownership is
biting there, too. Making me need separate Lua binary on OS X if SDL
support is required. Perhaps I could simply attach the support within
the SDL module, instead.

Thanks, - asko

Ulrich von Zadow kirjoitti 1.3.2006 kello 12.03:> Sam Lantinga wrote:

Is there any reason that this replicated code couldn’t be
conditionally
called from SDL_Init? If not, would there be any objection to
such a patch
being submitted?

It’s generally code that can’t be called from SDL_Init(), but it’s
code that
you can call from your main application - that’s why the various
initialization
functions are defined in SDL_main.h

I think the issue at the moment is that there’s some code in the OS
X main()
that doesn’t conform to this (the mail I sent on Feb. 23 contains
precisely that
code). Currently, just leaving away SDL_main is broken on OS X
because of this
issue. This code could be moved to SDL_Init without causing
problems - I’m
executing it directly before SDL_Init in libavg.

Anyway, I’d already asked Sam if a patch for this was ok and gotten
a yes, but I
probably won’t have the time to do it, so…

Regards,

Uli

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl