Станислав Макаров

Правильный путь: собрать deb-пакет и ставить его.
Быстрый путь: на целевой машине попробуйте запустить sudo ldconfig.

Таскать so-шник с бинарником не стоит. Если уж совсем туго, попробуйте слинковать статически.

• прикладное API различных операционных систем - разное. Если бы API было полностью одинаковое, то тогда операционные системы отличались бы только UX, набором софта и утилит, т.е. вместо Linux/Windows/BSD мы бы имели только Linux в разных дистрибуциях или только Windows в разных дистрибуциях. Ну т.е. по сути одну операционную систему, т.к. раз мы сейчас говорим о разработке прикладного софта, то нас интересует прежде всего API для прикладных приложений;
  
• т.к. API различных ОС отличается, требуется создание уровней абстракции, которые нивелируют эти различия. В других ответах уже достаточно примеров, я бы вспомнил например о разделителях в именах файлов;
  
• дополнительные уровни абстракции нередко сокращают доступное API, т.к. в большинстве случаев невозможно реализовать самому то, что нет в API какой-то из интересующих ОС. Следовательно, приходится оставлять только те интерфейсы, которые так или иначе есть везде;
  
• т.к. абстрагированные интерфейсы из пред. пункта более аскетичны, ими сложнее пользоваться, они дают не все возможности, соотв. какие-то задачи уже нецелесообразно решать кроссплатформенным кодом на базе этих асбтрагированных интерфейсов, проще написать несколько вариантов для разных ОС;
  
• оба предыдущих пункта - как достаточно успешные попытки сделать абстрагированные интерфейсы, так и наоборот, написание платформозависимого кода для каждой нужной платформы - удорожают разработку. Везёт только в случаях, когда абстрагированные интерфейсы уже есть и достаточно хорошо выполняют свою задачу, как например Asio. Или хорошие кроссплатформенные стандартые API вроде OpenGL, что делает возможным писать кроссплафторменные игры.
  
• разработчику ПО не нужно удорожание разработки там, где это не принесёт ощутимой выгоды.
  

Зависит от ваших текущих знаний и пожеланий, особенно от того, насколько вы готовы разбираться с каждой их технологий.

OpenGL это кроссплатформенное API, раньше было не очень удобно начинать работу с ним на Винде, сейчас доступны различные библиотеки (GLEW, GLFW) и это больше не проблема.
DirectX возможно даст вам больше возможностей, но там много заморочек с Windows-специфичными вещами, т.к. DirectX работает через технологию COM. Поначалу будет непривычно.

Я бы на вашем месте начал с OpenGL и посматривал на Vulkan. Знание OpenGL полезно ещё тем, что проще будет использовать родственные API, например WebGL, если захотите писать внутрибраузерный код.

1. Разработка крупных игровых проектов имеет как минимум те же особенности, что и разработка крупных приложений вообще. Раз вопрос о движках, не будем рассматривать прочие аспекты, такие как построение игровой модели, графический дизайн игры, написание сюжета и пр. Разработка движка, как большого проекта, требует:
- умение поставить начальные технические условия, которые будут заложены в архитектуру проекта (чтобы потом не было очень больно это всё менять);
- умение разбить движок на крупные подсистемы и выстроить между ними необходимые интерфейсы, чтобы каждую из подсистем отдать на разработку в отдельную команду;
- умение получить MVP в разумные сроки и строить дальнейшую разработку итеративно.

2. Как большой проект, связанный именно с компьютерной графикой, проект движка предполагает:
- что немалая часть кода будет писаться с учётом архитектурных особенностей аппаратуры - например, если ваш движок будет пытаться передавать слишком много данных по шине на видеокарту (постоянно гонять геометрию/текстуры), то скорость шины быстро станет узким местом и никакое новейшее оборудование вам не поможет.
- что графический код рано или поздно может потребовать мелких оптимизаций (вплоть до переписывания супернагруженных мест на ассемблере под каждую поддерживаемую аппаратную платформу);
- что графический код сегодня требует серьезного понимая физики света и цветовосприятия.

Для всех тех, кто понимает как реализовать вышеописанное, C++ и C# - лишь инструменты и жизненная необходимость, чтобы получить всё это, поэтому про знание языков даже говорить не буду, это подразумевается.

Advanced C and C++ Compiling
Linkers and Loaders.

Да, на английском. Советую таки читать в оригинале:
а) меньше неточностей;
б) будете привыкать к терминологии, рано или поздно будете понимать быстрее чем в переводе;
в) не все книги переведены (сильно не все, особенно такие).

https://msdn.microsoft.com/en-us/library/system.io... - значение этого параметра нужно выставить в Read. Не стоит велосипеды городить, стоит изучить стандартную библиотеку.

Берёте Qt и пишете. Заодно будет претензия на кроссплатформенность.
Можно ещё WTL, если уж очень хочется Windows-only и поближе к WinAPI.
Голый WinAPI не советую.