Reorganization Proposal

SDL Development
1

Note: This is only going to change SDL 0.9.x – 0.8.x will remain the
same.

I’ve been thinking about splitting SDL into several libraries, based
on functionality:
SDLcore – Base functionality: error handling, threads, etc.
(will probably go in libSDL.a)
SDLvideo – Video/Mouse/Keyboard
SDLaudio – Audio
SDLcd – CD-ROM control

And eventually:
SDLnet – Network (sockets) wrapper
SDLmidi – MIDI interface
SDLjoy – Joystick input
SDLgui – Very basic GUI framework (plug-in your widgets and run)

The advantage of this is you only load the modules you need in your
application, to keep a smaller memory footprint, and I’d be much more
likely to add things like MIDI support and network support, because
then the people who don’t need them don’t have to use them.

The disadvantage of this is we break 8.3 filename limitations on Win32
(which shouldn’t be a problem) and suddenly now we have a plethora of
library files cluttering up the installation directories.

I would probably rename some of the functions to more accurately reflect
the portion of SDL in which they reside. This would require slight code
changes in your 0.9.x based applications.

Thoughts? Comments?

I’ll probably do this very soon if people like the idea.

  1. I think it’s basicly a good idea for the reasons you’ve given
  2. I can imagine that this might make everything more difficult
    really, you know, several dlls. I like the idea of a single dll
    that does all the things and different add-on static libs you
    use. If you say the memory footprint is smaller, I could say
    you normally have only one game at a moment running and
    this is not like a kernel or window manager which are essential
    but more multimedia-like so I don’t mind 50k more memory
    usage.
  3. The network library is for example not going to become that
    large anyway, so why don’t we just link that statically? It makes
    life easier…

I might be wrong the points 2 and 3

Paulus Esterhazy (@Paulus_Esterhazy)

2

Note: This is only going to change SDL 0.9.x – 0.8.x will remain the same.

I’ve been thinking about splitting SDL into several libraries, based
on functionality:
SDLcore – Base functionality: error handling, threads, etc.
(will probably go in libSDL.a)
SDLvideo – Video/Mouse/Keyboard
SDLaudio – Audio
SDLcd – CD-ROM control

And eventually:
SDLnet – Network (sockets) wrapper
SDLmidi – MIDI interface
SDLjoy – Joystick input
SDLgui – Very basic GUI framework (plug-in your widgets and run)

The advantage of this is you only load the modules you need in your
application, to keep a smaller memory footprint, and I’d be much more
likely to add things like MIDI support and network support, because
then the people who don’t need them don’t have to use them.

The disadvantage of this is we break 8.3 filename limitations on Win32
(which shouldn’t be a problem) and suddenly now we have a plethora of
library files cluttering up the installation directories.

I would probably rename some of the functions to more accurately reflect
the portion of SDL in which they reside. This would require slight code
changes in your 0.9.x based applications.

Thoughts? Comments?

I’ll probably do this very soon if people like the idea.

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

3

Note: This is only going to change SDL 0.9.x – 0.8.x will remain the same.

I’ve been thinking about splitting SDL into several libraries, based
on functionality:
SDLcore – Base functionality: error handling, threads, etc.
(will probably go in libSDL.a)
SDLvideo – Video/Mouse/Keyboard
SDLaudio – Audio
SDLcd – CD-ROM control

These are good, but they must be orthogonal for this to be anyway useful.

njhOn Fri, 6 Nov 1998, Sam Lantinga wrote:

4

These are good, but they must be orthogonal for this to be anyway useful.

What do you mean by orthogonal?

You know, having no common parts (well, except for the ‘kernel’ hehe I’ve
been doing to much hilbert spaces… :-), each providing the minimum stuff
to do everything in a particular direction…

basically they have to work together, but not required each other(unlike
gnome, e.g.).

njhOn Fri, 6 Nov 1998, Sam Lantinga wrote:

5

basically they have to work together, but not required each other(unlike
gnome, e.g.).

Yup, that will be the case.
Good! :slight_smile:

If anything requires another part, the other part will be automatically
loaded. And, should that other part be loaded again, it will just
return successfully.

I’m not sure I like this - a library upgrade could make a 10K program take
2Mb simply because there are such interactions. This is perhaps the
biggest drawback of dynamic libraries - their tendency to interact.

njhOn Fri, 6 Nov 1998, Sam Lantinga wrote:

6

“Sam” == Sam Lantinga writes:

Sam> Note: This is only going to change SDL 0.9.x -- 0.8.x will
Sam> remain the same.  I've been thinking about splitting SDL into
Sam> several libraries, based on functionality:

Sam> 	SDLcore -- Base functionality: error handling,
Sam> threads, etc.  (will probably go in libSDL.a)
Sam> 	SDLvideo -- Video/Mouse/Keyboard
Sam> 	SDLaudio -- Audio
Sam> 	SDLcd -- CD-ROM control

Sam> And eventually:

Sam> 	SDLnet -- Network (sockets) wrapper
Sam> 	SDLmidi -- MIDI interface
Sam> 	SDLjoy -- Joystick input
Sam> 	SDLgui -- Very basic GUI framework (plug-in your
Sam> widgets and run)

Sam> The advantage of this is you only load the modules you need
Sam> in your application, to keep a smaller memory footprint, and
Sam> I'd be much more likely to add things like MIDI support and
Sam> network support, because then the people who don't need them
Sam> don't have to use them.

You mean if you didn’t split the source and you added things people
didn’t need, they’d have to use them? It sounds like you’re
counting the smaller memory footprint twice. On demand-paged systems
the smaller memory footprint will only barely be measureable.

Sam> The disadvantage of this is we break 8.3 filename limitations
Sam> on Win32 (which shouldn't be a problem) and suddenly now we
Sam> have a plethora of library files cluttering up the
Sam> installation directories.

It’s much worse than that. The disadvantage is the combinatorial
explosion of testing requirements. You’ll have some testers who are
mixing and matching combinations that other people aren’t using and
there may wind up being subtle bugs that only occur in certain
situations.

Sam> I would probably rename some of the functions to more
Sam> accurately reflect the portion of SDL in which they reside.
Sam> This would require slight code changes in your 0.9.x based
Sam> applications.

Sam> Thoughts?  Comments?

Sam> I'll probably do this very soon if people like the idea.

If there aren’t better reasons for doing it, it’s a bad idea.

It’s like premature optimization; it always sounds good when you first
think of it, but it’s almost always a waste of development resources
and support resources. Now it may be that SDL is easier to develop
and to support if you make big boundaries between the modules, but
that’s an issue you haven’t raised.

Sam> See ya!  -Sam Lantinga (slouken at devolution.com)

Sam> -- Author of Simple DirectMedia Layer -
Sam> http://www.devolution.com/~slouken/SDL/ --

–Cliff
@Clifford_T_Matthews

7

“Sam” == Sam Lantinga writes:

>> You mean if you didn't split the source and you added things
>> people didn't need, they'd *have to* use them?  It sounds like
>> you're counting the smaller memory footprint twice.  On
>> demand-paged systems the smaller memory footprint will only
>> barely be measureable.

Sam> Hum, I didn't think of that.

>> It's much worse than that.  The disadvantage is the
>> combinatorial explosion of testing requirements.  You'll have
>> some testers who are mixing and matching combinations that
>> other people aren't using and there may wind up being subtle
>> bugs that only occur in certain situations.

Sam> This shouldn't be that much of a problem because all
Sam> libraries will have the same version number, and if one has a
Sam> mismatched version, the user will be warned.  Or are you
Sam> referring to something else?

Aha. Well, if they all have the same version number and are all kept
in sync, it’s no longer an obviously bad idea, although it’s still
not obvious yet that it’s a good idea.

>> If there aren't better reasons for doing it, it's a bad idea.

Sam> Conceptually I will never add GUI or graphic drawing to SDL.
Sam> However if people are able to pick it up as a separate
Sam> library with additional functionality I have no problem with
Sam> that.  That's the biggest reason for my doing it.  It's also
Sam> easier to manage smaller modules of code, both in
Sam> initializing it and developing it.

Well, if the GUI code isn’t part of SDL, it should be a separate
project, even if you wind up being the major author of both and even
the librarian. At that point the GUI code should not have version
numbers that are kept in lockstep with SDL and so there you have the
potential problem of weird version interactions, but if it’s SDL and
NEWGUI only, you don’t really see much of a combinatorial hit.
2^(n-1) is no different from 2*n when n is 2. That’s not the case
when n is 6.

>> It's like premature optimization; it always sounds good when
>> you first think of it, but it's almost always a waste of
>> development resources and support resources.

Sam> It would be really easy to do.  The biggest work is rewriting
Sam> the configuration script to support multiple modules.

Well, if everything moves in lockstep, then it’s really more of a
packaging issue. I don’t see the big win you get from restructuring,
but I also don’t see the big loss, either. Sounds to me it’s a wash,
but it takes time, so it’s a small net lose.

Sam> See ya!  -Sam Lantinga (slouken at devolution.com)

Sam> -- Author of Simple DirectMedia Layer -
Sam> http://www.devolution.com/~slouken/SDL/ --

–Cliff
@Clifford_T_Matthews

8

The advantage of this is you only load the modules you need in your
application, to keep a smaller memory footprint, and I’d be much more
likely to add things like MIDI support and network support, because
then the people who don’t need them don’t have to use them.

I was always told that using libraries loads only the code your program
needs, not the whole thing. Have I been lied to my whole (Linux) life?

The disadvantage of this is we break 8.3 filename limitations on Win32
(which shouldn’t be a problem) and suddenly now we have a plethora of
library files cluttering up the installation directories.

This is true, and I’m a little hesitant to to start adding several
files (Especially since I micro-manage my libraries).

I would probably rename some of the functions to more accurately reflect
the portion of SDL in which they reside. This would require slight code
changes in your 0.9.x based applications.

Is there a reason besides the splitting of the libraries to rename the
functions? I realize some of them could use some more descriptive
names, but then there’s overkill (gtk_scrollbar_set_width_adjust)

I’ll probably do this very soon if people like the idea.

I don’t mind the idea, but SOMEBODY had to play devil’s advocate. :)On 6 Nov, Sam Lantinga wrote:

–

| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

9

use. If you say the memory footprint is smaller, I could say
you normally have only one game at a moment running and
this is not like a kernel or window manager which are essential
but more multimedia-like so I don’t mind 50k more memory
usage.

I don’t want to start saying, "Well, what’s 50k? We can waste that much."
Things like that grow, and it’s always better to save what you can as long
as it’s not prohibitively difficult. (I don’t think using separate dlls
for different SDL components is prohibitively difficult, either. In fact,
I was going to suggest that soon enough…)

  1. The network library is for example not going to become that
    large anyway, so why don’t we just link that statically? It makes
    life easier…

That may be, but on a conceptual level, I like the fact that if my program
doesn’t use it, I can leave it out.

We just have to make sure the individual libraries don’t start getting
weird version cross-dependencies… I hate it when I install a video card
in Winblows that replaces my DirectDraw which then breaks DirectSound.
(Somebody tell me why DS is dependent upon DD…???) Ehh whatever.
Anyway, I guess I’m just saying don’t do anything stupid. I guess you
knew that.

-Chuck

10

use. If you say the memory footprint is smaller, I could say
you normally have only one game at a moment running and
this is not like a kernel or window manager which are essential
but more multimedia-like so I don’t mind 50k more memory
usage.

I don’t want to start saying, "Well, what’s 50k? We can waste that much."
Things like that grow, and it’s always better to save what you can as long
as it’s not prohibitively difficult.

Cliff had a really good point. On modern memory managers with demand paging,
the code resides on disk until it’s actually run for the first time.
This means it takes virtual memory, but usually doesn’t take real memory.
This is of course modified by the memory management algorithms, available
memory, etc. But in general having a large code size isn’t as bad as I
originally thought.

  1. The network library is for example not going to become that
    large anyway, so why don’t we just link that statically? It makes
    life easier…

That may be, but on a conceptual level, I like the fact that if my program
doesn’t use it, I can leave it out.

I agree. That’s the real reason why splitting SDL is attractive.

We just have to make sure the individual libraries don’t start getting
weird version cross-dependencies.

All libraries will have the same version. I guess the main reason to do
the split was to reduce code size, which as Cliff pointed out, isn’t that
big a deal.

Anyway, I guess I’m just saying don’t do anything stupid. I guess you
knew that.

Thanks. :slight_smile:

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/