Что такое SDL?

Simple DirectMedia Layer (SDL) — это кроссплатформенная мультимедийная библиотека, реализующая единый программный интерфейс к графической подсистеме, звуковым устройствам и средствам ввода для широкого спектра платформ. Официально поддерживает такие операционные системы как: Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, и QNX. Приложения написанные с использованием SDL могут также работать и в следующих операционных системах: AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, и OS/2.

Использовать sdl вы можете соследующими языками программирования: Ada, C#, D, Eiffel, Erlang, Euphoria, Guile, Haskell, Java, Lisp, Lua, ML, Objective C, С++, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, Smalltalk и Tcl.

SDL распространяется по лицензии GNU LGPL второй версии. Эта лицензия позволяет вам свободно использовать SDL в комерческих программах.

Это официальное объяснение, теперь более понятное :). SDL — это библиотека которую вы можете использовать для создания 2d игр (и даже 3d).

Особенности
Независимость библиотеки от операционой системы и языка программирования
Внятная, понятная документация
Простая в использовании библиотека
Отрисовка графики через свой рендер, через OpenGL (что позволяет делать трехмерную игру) а при некотором старании и чтении документации с официального сайта возможность отрисовывать графику через DirectX.
Дополнительные библиотеки позволяющие расширить функциональность основной, такие как:
sdl image — позволяющая использовать разные графические форматы к примеру *.jpg или *.png.
sdl mixer — позволяет использовать разные звуковые форматы.
sdl net — повзоляет использовать сетевые возможности.
sdl rtf — позволит работать с тектовым форматом *.rtf. Например, можно будет записать в word’е справку и потом ее выводить в игре.
sdl ttf — позволяет использовать в игре любые ttf шрифты.
плюс разнообразные gui и оболочки для кода которые ожно найти на просторах интернета.

Что такое SDL?

Эту аббревиатуру конечный пользователь видит достаточно редко, однако это вовсе не означает, что он не сталкивается с ней никогда. Поэтому сегодня к длинному списку аббревиатур, которые мы уже рассмотрели ранее в нашей традиционной рубрике FAQ, добавится ещё одна, с которой, надеюсь, будет интересно и полезно познакомиться.

Итак, что же такое SDL? Как всегда, вариантов того, как можно интерпретировать аббревиатуру, великое множество, но мы остановимся только на одном. В данном случае расшифровывается это сокращение как Simple DirectMedia Layer. Так называется мощная программная библиотека, которая самым что ни на есть активным образом используется для разработки кросс-платформенных (и не только) мультимедийных приложений, в том числе игр. Библиотека SDL предоставляет единый интерфейс для доступа к графическим и звуковым устройствам, а также устройствам ввода. Основным преимуществом этой библиотеки перед другими аналогичными программными продуктами можно назвать как раз её кросс-платформенность, которая, в отличие от множества других библиотек, не ограничивается переносимостью между 32-разрядными версиями Windows и Linux. Список поддерживаемых программных платформ велик, и вы можете увидеть в нем даже довольно экзотические системы: BeOS, Mac OS, Mac OS X, FreeBSD, OpenBSD, BSD/OS, Solaris, IRIX, QNX. Список систем, не поддерживаемых официально, но, тем не менее, совместимых на практике с большинством возможностей библиотеки, ещё шире: он включает в себя такие системы, как AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, OS/2.

SDL является свободной библиотекой и распространяется под лицензией GNU GPL, благодаря этому (хотя, конечно, не только этому) она заслужила большую популярность у создателей мультимедийных проигрывателей и игр под Linux и другие POSIX-системы. Изначально SDL была предназначена для разработки приложений на C (ну и, конечно же, на C++), но со временем, благодаря своему качеству и большой популярности, были сделаны «обертки» для её функций для таких языков, как Ada, C#, D, Eiffel, Erlang, Euphoria, Guile, Haskell, Java, Lisp, Lua, ML, Objective C, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, Smalltalk,Tcl.

Стоит отметить, что, несмотря на свою популярность в мире Linux, под Windows SDL распространена намного меньше и используется, в основном, из соображений совместимости в силу того, что опирается на достаточно старые интерфейсы DirectX API 7-й версии.

Как создавать безопасные системы. Краткое введение в SDL

При разработке любой программной системы, будь это простой вебсайт, десктоп-приложение или сложный трехзвенный комплекс, рано или поздно возникают вопросы безопасности. Нельзя исключить, что та система, которую вы разрабатываете, будет каким-то образом атакована. Причем, в зависимости от типа системы, ее сложности, применяемых технологических решений, векторы атак и их последствия могут иметь самый разный характер. Возможно, время от времени кто-то в команде проводит анализ безопасности разрабатываемой системы, проводится моделирование. Куда хуже если эти вопросы оставляются на потом. Результаты могут быть весьма плачевными, если вашу систему взламывают в режиме коммерческой эксплуатации и вам приходится впопыхах создавать исправления для обнаруженной бреши. Очевидно, что вопросы, связанные с безопасностью лучше решать, начиная с самых ранних этапов создания системы, таких как анализ требований и архитектурного моделирования. Но лучше всего это делать на всем жизненном цикле системы, интегрировав в процесс разработки специальные шаги, предназначенные для решения этих вопросов. Одним из таких процессов является Security Development Lifecycle – набор практик направленных на повышение безопасности разрабатываемых систем.

Что такое Security Development Lifecycle

SDL это процесс который позволяет убедиться в необходимом уровне безопасности разрабатываемой системы. SDL базируется на основе практик направленных на обучение команды, подготовку отчетности и непосредственные действия связанные с анализом безопасности разрабатываемой системы и имплементацией механизмов направленных на улучшение безопасности. Эти практики в виде конкретных шагов легко ложатся на привычный спиральный цикл разработки программного обеспечения.

Некоторые из этих практик сами по себе могут улучшить безопасность разрабатываемой системы. Но как показывает опыт, их применение в рамках процесса разработки позволяет значительно улучшить результат и снизить затраты.

Перед тем как внедрить SDL: Обучение

Все члены команды, перед тем как непосредственно начать разработку, должны пройти тренинг по безопасности и изучить важные моменты, связанные с текущими трендами в этой области. Базовый уровень этого тренинга должен включать в себя:

Безопасный дизайн

• Снижение областей атаки
• Глубокая защита
• Принцип наименьших привилегий
• Безопасность по умолчанию

Моделирование угроз, включая следующие темы:

• Обзор моделей угроз
• Влияние модели угроз на дизайн
• Ограничения для стиля кодирования, базирующиеся на модели угроз

Безопасное кодирование, включая следующие темы:

• Переполнение буфера (для приложений на C и C++)
• Ошибки целочисленной арифметики (для приложений на C и C++)
• Кросс-сайтовый скриптинг (для Веб-приложений)
• SQL-инъекции (для приложений взаимодействующих с БД)
• Слабая криптография

Тестирование безопасности, включая следующие темы:

• Различия между тестированием безопасности и функциональным тестированием
• Аудит рисков
• Методы тестирования безопасности

Обеспечение приватности, включая следующие темы:

• Типы приватной информации
• Приватность: лучшие практики дизайна
• Аудит рисков
• Приватность: лучшие практики разработки
• Приватность: лучшие практики тестирования

Конечно, при изучении этих тем необходимо учитывать роль (тестер, разработчик, менеджер, аналитик), тем не менее, очень важно чтобы все члены команды прошли этот тренинг.

Анализ требований: Что следует учитывать в контексте безопасности

Уже на уровне анализа требований к системе нужно учитывать важные аспекты, связанные с безопасностью. При этом важно разделять между собой «безопасные требования» и «требования безопасности». В SDL есть некоторый набор практик, и несколько таких из таких практик – «Анализ безопасности и приватности требований» может быть применена на этапе анализа требований. Эта практика предназначена для идентификации функциональных требований, у которых есть необходимость углубленного изучения вопросов связанных с безопасностью. Такой аудит может включать в себя следующую информацию:

1. Какая часть ПО требует анализа угроз перед релизом?
2. Какая часть ПО требует анализа дизайна в контексте безопасности?
3. Какая часть ПО требует дополнительного анализа угрозы проникновения независимой группой?
4. Есть ли дополнительные вопросы безопасности и риски, которые могут быть снижены?
5. Границы нечеткого тестирования в контексте безопасности.
6. Каков уровень угрозы разглашения приватных данных?

Дизайн с учетом безпасности

При дизайне приложений так же можно применить ряд практик, которые помогут повысить безопасность приложения. В первую очередь это снижение площади поверхности возможных атак (Attack Surface Reduction) и моделирование угроз. Несмотря на близкую взаимосвязь этих двух понятий, первый механизм подразумевает активное снижение возможностей злоумышленника на эксплуатацию неизвестных брешей в безопасности. Для снижения площади возможных атак можно применять механизмы послойной защиты и принципы наименьших привилегий. Моделирование угроз в свою очередь позволяет предположить, какие компоненты системы могут быть рассмотрены в качестве векторов атак. Удобным инструментом для моделирования угроз является Microsoft Thread Modeling Tool базирующийся на классификации STRIDE.

Реализация с учетом безопасности

Этап реализации, как правило, наиболее трудоемкая часть проекта. Чтобы облегчить эту задачу используется множество средств, технологий и готовых компонент. В контексте безопасности важно чтобы перечень этого инструментария был заранее зафиксирован. Рекомендованным подходом является формирование перечня разрешенных при имплементации инструментов. Везде где только можно следует исключать или специально обозначать использование небезопасных или вышедших из употребления функций и компонент. В дополнение, важно использование автоматизированных средств, таких как статический анализ кода.

Фаза верификации (тестирования) с учетом безопасности

На этой фазе возможно использование таких практик как динамический анализ кода (во время выполнения) который позволяет быстро выявить аномальное поведение функций, порчу памяти, использование привилегированных функций и другие критические проблемы. Одним из инструментов который может пригодится для решения этой задачи является AppVerifier. В дополнение к стандартным функциональным тестам так же следует добавить плавающее тестирование которое предназначено для проверки приложения в режиме ввода неверных данных, неправильно сформированных параметров и других условий которые могут привести к аномальному поведению но при этом все равно система должна быть в безопасном состоянии. Так же на этом этапе важным является проверка смоделированных векторов атак на предыдущих фазах для того чтобы убедиться в корректности сформированных моделей.

Фаза Выпуска с учетом безопасности

На этой фазе важно создание плана по реакции инцидентов связанных с безопасностью, в которых будет задекларирован порядок взаимодействия и реакции на выявленные угрозы или проникновение. Финальные релизы (RTM,RTW) должны соответствовать всем заранее обговоренным на стадии дизайна условиям безопасности перед развертыванием. Если это не так, даже при соблюдении всех функциональных требований, необходим повтор стандартного цикла разработки для фиксации проблем связанных с безопасностью.

Что дальше

Конечно, эта заметка раскрывает только самые основные аспекты SDL и для успешного применения требуется дополнительное изучение. Помочь в этом может центр безопасности MSDN.

Если вы хотите узнать более подробно о SDL, посмотрите завтра прямую трансляцию докладов конференции «Microsoft Secure Software Development Conference». В том числе там будут доклады Алекса Лукаса «Эволюция цикла безопасной разработки SDL», Гленна Питавея «Внедрение SDL».

Цикл уроков по SDL 2.0: урок 1

От переводчика: вдохновившись циклом статей, я решил попробовать свои силы в SDL. Да вот незадача, каких-либо толковых уроков по SDL версии 2.0 на русском языке найти мне не удалось. Это и подтолкнуло меня к переводу замечательной серии туториалов Twinklebear, в оригинале доступных тут.

Добро пожаловать!

Цель данных уроков — познакомить вас с основами SDL 2.0 и гейм-дева на С++. Подразумевается, что у читателя есть некоторый опыт программирования на С++ и минимальные знания массивов, векторов, управляющих структур, функций и указателей.

Если вы испытываете трудности при разборе кода в примерах, воспользуйтесь одной из книг, представленных в этом чудесном списке на StackOverflow.

Если вы хотите увидеть полный исходник или же скачать ресурсы для уроков, то все это можно получить на GitHub’е. Но не копируйте!

Также документация по SDL 2.0 доступна для чтения в этой вики.

Урок 1: Hello World!

В этом уроке мы научимся открывать окно, создавать контекст рендеринга и рисовать загруженное изображение на экране. Ниже вы можете забрать BMP картинку, которую мы будем рисовать. Сохраните ее где-нибудь в своем проекте. Так давайте уже начнем!

Запуск SDL

Первый шаг обычно заключается в подключении заголовочного файла SDL.

Для того, чтобы начать работать с SDL, нам необходимо инициализировать различные SDL подсистемы, которые мы хотим использовать. Это можно сделать с помощью функции SDL_Init, которая принимает набор флагов, указывающих, какие подсистемы мы хотим инициализировать. Сейчас мы просто скажем, что хотим инициализировать все, но если хотите, вы можете это изменить. Минимум, что необходимо для нашего урока — это SDL_INIT_VIDEO. Если все пройдет успешно, SDL_Init вернет 0, в противном случае мы напечатаем ошибку и выйдем.

Заметка для пользователей Visual Studio: если вы установили значение системы как Windows в настройках компоновщика, то вы не получите стандартный вывод в консоль. Чтобы этого не произошло, вам необходимо изменить значение системы на Console.

Открытие окна

Нам нужно окно, чтобы можно было в нем отображать на рендер. Мы можем создать его, используя функцию SDL_CreateWindow, которая принимает название окна, его координаты, высоту, ширину и некоторые флаги, чтобы задать параметры окна. Данная функция возвращает SDL_Window*. Этот указатель будет NULL, если что-нибудь пойдет не так при создании окна.

Создание рендерера

Теперь мы можем создать рендерер, с помощью SDL_CreateRenderer. Это необходимо для того, чтобы получить возможность рисовать в окне. Данная функция принимает указатель на окно, с которым необходимо ассоциировать рендерер, индекс драйвера, который будет использоваться для рендеринга (или -1, чтобы выбрать первый подходящий под наши требования) и различные флаги, использующие для указания типа рендерера, который нам нужен. В данном случае мы запрашиваем рендерер с аппаратным ускорением и включенной вертикальной синхронизацией. Мы получим SDL_Renderer*, который будет NULL, если что-то пошло не так.

Загрузка BMP изображения

Для того, чтобы отрендерить BMP картинку, нам необходимо сначала загрузить ее в память, а затем в устройство рендеринга, которое мы используем (в данном случае GPU). Мы можем загрузить изображение с помощью SDL_LoadBMP. Эта функция возвращает SDL_Surface*, которую мы можем загрузить в SDL_Texture, чтобы ей мог воспользоваться рендерер.

SDL_LoadBMP принимает путь к нашему изображению, который вы должны изменить, чтобы он соответствовал структуре вашего проекта, и возвращает SDL_Surface* или NULL, в случае ошибки.

Теперь мы можем загрузить изображение в рендерер, используя SDL_CreateTextureFromSurface. Мы передаем контекст рендеринга и картинку в памяти (SDL_Surface), а получаем загруженную текстуру. В случае, если что-то пошло не так, мы получим NULL. Также SDL_Surface нам больше не потребуется, поэтому мы освободим занимаемую ей память.

Отрисовка текстуры

Все, что осталось сделать, это получить нашу текстуру на экране! Сперва мы очистим рендерер, после отрендерим текстуру, а затем покажем обновленный экран, чтобы увидеть результат. Так как мы хотим отрендерить изображение целиком и заставить его растянутся по размеру экрана, мы передадим NULL как исходный и целевой прямоугольники для SDL_RenderCopy. Также мы хотим сохранить окно открытым на некоторое время, чтобы увидеть результат до завершения программы, поэтому мы добавим вызов SDL_Delay.

Уборка мусора

Перед тем, как выйти, мы должны уничтожить все созданные нами объекты с помощью различных SDL_DestroyX функций и завершить SDL.

Конец урока

В случае успеха, при запуске вы должны увидеть изображение во все окно, а через две секунды программа завершится. В случае проблем убедитесь, что SDL установлена и настроена правильно. Подробная инструкция по установке и настройке SDL под различные платформы доступна тут.