docs/README-dynapi.md
author Philipp Wiesemann <philipp.wiesemann@arcor.de>
Sun, 15 Mar 2015 19:25:10 +0100
changeset 9383 62164ad0b7d5
parent 9025 d09d4b578e77
child 9754 fe6acfd4652c
permissions -rw-r--r--
Updated name of assert type in test program.
gabomdq@9023
     1
Dynamic API
gabomdq@9023
     2
================================================================================
gabomdq@9023
     3
Originally posted by Ryan at https://plus.google.com/103391075724026391227/posts/TB8UfnDYu4U
gabomdq@9023
     4
gabomdq@9023
     5
Background:
gabomdq@9023
     6
gabomdq@9023
     7
- The Steam Runtime has (at least in theory) a really kick-ass build of SDL2, 
gabomdq@9023
     8
  but developers are shipping their own SDL2 with individual Steam games. 
gabomdq@9023
     9
  These games might stop getting updates, but a newer SDL2 might be needed later. 
gabomdq@9023
    10
  Certainly we'll always be fixing bugs in SDL, even if a new video target isn't 
gabomdq@9023
    11
  ever needed, and these fixes won't make it to a game shipping its own SDL.
gabomdq@9023
    12
- Even if we replace the SDL2 in those games with a compatible one, that is to 
gabomdq@9023
    13
  say, edit a developer's Steam depot (yuck!), there are developers that are 
gabomdq@9023
    14
  statically linking SDL2 that we can't do this for. We can't even force the 
gabomdq@9023
    15
  dynamic loader to ignore their SDL2 in this case, of course.
gabomdq@9023
    16
- If you don't ship an SDL2 with the game in some form, people that disabled the
gabomdq@9023
    17
  Steam Runtime, or just tried to run the game from the command line instead of 
gabomdq@9023
    18
  Steam might find themselves unable to run the game, due to a missing dependency.
gabomdq@9023
    19
- If you want to ship on non-Steam platforms like GOG or Humble Bundle, or target
gabomdq@9023
    20
  generic Linux boxes that may or may not have SDL2 installed, you have to ship 
gabomdq@9023
    21
  the library or risk a total failure to launch. So now, you might have to have 
gabomdq@9023
    22
  a non-Steam build plus a Steam build (that is, one with and one without SDL2 
gabomdq@9023
    23
  included), which is inconvenient if you could have had one universal build 
gabomdq@9023
    24
  that works everywhere.
gabomdq@9023
    25
- We like the zlib license, but the biggest complaint from the open source 
gabomdq@9023
    26
  community about the license change is the static linking. The LGPL forced this 
gabomdq@9023
    27
  as a legal, not technical issue, but zlib doesn't care. Even those that aren't
gabomdq@9023
    28
  concerned about the GNU freedoms found themselves solving the same problems: 
gabomdq@9023
    29
  swapping in a newer SDL to an older game often times can save the day. 
gabomdq@9023
    30
  Static linking stops this dead.
gabomdq@9023
    31
gabomdq@9023
    32
So here's what we did:
gabomdq@9023
    33
gabomdq@9023
    34
SDL now has, internally, a table of function pointers. So, this is what SDL_Init
gabomdq@9023
    35
now looks like:
gabomdq@9023
    36
gabomdq@9023
    37
    UInt32 SDL_Init(Uint32 flags)
gabomdq@9023
    38
    {
gabomdq@9023
    39
        return jump_table.SDL_Init(flags);
gabomdq@9023
    40
    }
gabomdq@9023
    41
gabomdq@9023
    42
Except that is all done with a bunch of macro magic so we don't have to maintain
gabomdq@9023
    43
every one of these.
gabomdq@9023
    44
gabomdq@9023
    45
What is jump_table.SDL_init()? Eventually, that's a function pointer of the real
gabomdq@9023
    46
SDL_Init() that you've been calling all this time. But at startup, it looks more 
gabomdq@9023
    47
like this:
gabomdq@9023
    48
gabomdq@9023
    49
    Uint32 SDL_Init_DEFAULT(Uint32 flags)
gabomdq@9023
    50
    {
gabomdq@9023
    51
        SDL_InitDynamicAPI();
gabomdq@9023
    52
        return jump_table.SDL_Init(flags);
gabomdq@9023
    53
    }
gabomdq@9023
    54
gabomdq@9023
    55
SDL_InitDynamicAPI() fills in jump_table with all the actual SDL function 
gabomdq@9023
    56
pointers, which means that this _DEFAULT function never gets called again. 
gabomdq@9023
    57
First call to any SDL function sets the whole thing up.
gabomdq@9023
    58
gabomdq@9023
    59
So you might be asking, what was the value in that? Isn't this what the operating
gabomdq@9023
    60
system's dynamic loader was supposed to do for us? Yes, but now we've got this 
gabomdq@9023
    61
level of indirection, we can do things like this:
gabomdq@9023
    62
gabomdq@9023
    63
    export SDL_DYNAMIC_API=/my/actual/libSDL-2.0.so.0
gabomdq@9023
    64
    ./MyGameThatIsStaticallyLinkedToSDL2
gabomdq@9023
    65
gabomdq@9023
    66
And now, this game that is staticallly linked to SDL, can still be overridden 
gabomdq@9023
    67
with a newer, or better, SDL. The statically linked one will only be used as 
gabomdq@9023
    68
far as calling into the jump table in this case. But in cases where no override
gabomdq@9023
    69
is desired, the statically linked version will provide its own jump table, 
gabomdq@9023
    70
and everyone is happy.
gabomdq@9023
    71
gabomdq@9023
    72
So now:
gabomdq@9023
    73
- Developers can statically link SDL, and users can still replace it. 
gabomdq@9023
    74
  (We'd still rather you ship a shared library, though!)
gabomdq@9023
    75
- Developers can ship an SDL with their game, Valve can override it for, say, 
gabomdq@9023
    76
  new features on SteamOS, or distros can override it for their own needs, 
gabomdq@9023
    77
  but it'll also just work in the default case.
gabomdq@9023
    78
- Developers can ship the same package to everyone (Humble Bundle, GOG, etc), 
gabomdq@9023
    79
  and it'll do the right thing.
gabomdq@9023
    80
- End users (and Valve) can update a game's SDL in almost any case, 
gabomdq@9023
    81
  to keep abandoned games running on newer platforms.
gabomdq@9023
    82
- Everyone develops with SDL exactly as they have been doing all along. 
gabomdq@9023
    83
  Same headers, same ABI. Just get the latest version to enable this magic.
gabomdq@9023
    84
gabomdq@9023
    85
gabomdq@9023
    86
A little more about SDL_InitDynamicAPI():
gabomdq@9023
    87
gabomdq@9023
    88
Internally, InitAPI does some locking to make sure everything waits until a 
gabomdq@9023
    89
single thread initializes everything (although even SDL_CreateThread() goes 
gabomdq@9023
    90
through here before spinning a thread, too), and then decides if it should use
gabomdq@9023
    91
an external SDL library. If not, it sets up the jump table using the current 
gabomdq@9023
    92
SDL's function pointers (which might be statically linked into a program, or in
gabomdq@9023
    93
a shared library of its own). If so, it loads that library and looks for and 
gabomdq@9023
    94
calls a single function:
gabomdq@9023
    95
gabomdq@9023
    96
    SInt32 SDL_DYNAPI_entry(Uint32 version, void *table, Uint32 tablesize);
gabomdq@9023
    97
gabomdq@9023
    98
That function takes a version number (more on that in a moment), the address of
gabomdq@9023
    99
the jump table, and the size, in bytes, of the table. 
gabomdq@9023
   100
Now, we've got policy here: this table's layout never changes; new stuff gets 
gabomdq@9023
   101
added to the end. Therefore SDL_DYNAPI_entry() knows that it can provide all 
gabomdq@9023
   102
the needed functions if tablesize <= sizeof its own jump table. If tablesize is
gabomdq@9023
   103
bigger (say, SDL 2.0.4 is trying to load SDL 2.0.3), then we know to abort, but
gabomdq@9023
   104
if it's smaller, we know we can provide the entire API that the caller needs.
gabomdq@9023
   105
gabomdq@9023
   106
The version variable is a failsafe switch. 
gabomdq@9023
   107
Right now it's always 1. This number changes when there are major API changes 
gabomdq@9023
   108
(so we know if the tablesize might be smaller, or entries in it have changed). 
gabomdq@9023
   109
Right now SDL_DYNAPI_entry gives up if the version doesn't match, but it's not 
gabomdq@9023
   110
inconceivable to have a small dispatch library that only supplies this one 
gabomdq@9023
   111
function and loads different, otherwise-incompatible SDL libraries and has the
gabomdq@9023
   112
right one initialize the jump table based on the version. For something that 
gabomdq@9023
   113
must generically catch lots of different versions of SDL over time, like the 
gabomdq@9023
   114
Steam Client, this isn't a bad option.
gabomdq@9023
   115
gabomdq@9023
   116
Finally, I'm sure some people are reading this and thinking,
gabomdq@9023
   117
"I don't want that overhead in my project!"  
gabomdq@9023
   118
To which I would point out that the extra function call through the jump table 
gabomdq@9023
   119
probably wouldn't even show up in a profile, but lucky you: this can all be 
gabomdq@9023
   120
disabled. You can build SDL without this if you absolutely must, but we would 
gabomdq@9023
   121
encourage you not to do that. However, on heavily locked down platforms like 
gabomdq@9023
   122
iOS, or maybe when debugging,  it makes sense to disable it. The way this is 
gabomdq@9023
   123
designed in SDL, you just have to change one #define, and the entire system 
gabomdq@9023
   124
vaporizes out, and SDL functions exactly like it always did. Most of it is 
gabomdq@9023
   125
macro magic, so the system is contained to one C file and a few headers. 
gabomdq@9023
   126
However, this is on by default and you have to edit a header file to turn it 
gabomdq@9023
   127
off. Our hopes is that if we make it easy to disable, but not too easy, 
gabomdq@9023
   128
everyone will ultimately be able to get what they want, but we've gently 
gabomdq@9023
   129
nudged everyone towards what we think is the best solution.