13 - Differences with classical SDL

It is difficult to list all the differences between SDL-RT and SDL even though an SDL developer would understand SDL-RT and vice versa. Still to be able to clearly state the differences between these languages we will pinpoint the main differences in the paragraphs below.

13.1 - Data types

This is the most significant difference between SDL and SDL-RT. Classical SDL has its own data types and syntax where SDL-RT basically uses ANSI C language. Some symbols have a specific syntax with SDL-RT since there is no C equivalent instruction such as output, input, save, or semaphore manipulations.
The advantages are obvious:

13.2 - Semaphores

Semaphore is a key concept in real time systems that classical SDL misses. Specific semaphore symbols have been introduced in SDL-RT to answer the real time developer needs.

13.3 - Inputs

Classical SDL has nice concepts when it comes to dealing with message exchanges. But these concepts are not so interesting in real time development and are quite tricky to implement on a real target or operating system. That is why SDL-RT has removed the following concepts: enabling conditions when receiving a message, internal messages, two levels priority messages.

13.4 - Names

Classical SDL uses exotic names for some well known concepts such as "signal" where it is basically related to a "message". Since "message" is the usual name in Real Time Operating Systems SDL-RT uses the same term.
When it comes to object orientation classical SDL talks about "type" instead of the usual "class" term. SDL-RT uses the common developer word "class".

13.5 - Object orientation

Classical SDL uses "virtual", "redefined", and "finalized" when it comes to object oriented concepts. For example a super class should specify a transition is "virtual" so that the sub class is allowed "redefine" or "finalize" it. This is C++ like but actually quite painful when it comes to write and does not make things any clearer. SDL-RT takes the Java notation instead where there is no need to specify anything to be able to redefine it in a sub class.