Дмитрий

Ну, так скомпилируйте с его поддержкой, в чём проблема то?

Ставьте хуки на функции работы с сокетами, типа send/sendto/recv/recvfrom. И в них можно изменять что угодно.

C++ -- это инструмент для "обёрток" над низкоуровневыми вещами. Трудно что-то на нём удачно писать, не зная при этом устройство ОС, работы менеджеров памяти, тонкостей реализации каких-то фич. Также обязательно знать ассемблер, уметь отлаживать код, юзать отладчики. Понимать что такое кэш, предсказатель переходов, как работать с этим всем, оптимизировать.
Библиотеки, фреймворки -- это всё для более высокоуровневых языков, в С++ только с этими знаниями будет очень тяжко. Ибо за вас он ничего не будет делать, к счастью.

Чтобы что-то изучить, нужно сначала придумать, зачем вам это изучать.
Если есть цель, то книга сама выберется, по сложности, по восприятию, по удобной терминологии. Ей вы будете пользоваться не очень много.
А если цель выучить, чтоб выучить, то с любой книгой можно много времени убить и ничего не сделать.

Придумайте задачу, проект. Который будет интересен независимо от языка, который захочется делать хоть на брейнфаке. Тогда любая книга подойдёт. Главное, чтоб не откровенная устаревшая херня была. Желательно сразу учить начинать с С++11 или С++14, ибо они прилично отличаются от классического языка, и много чего объявлено устаревшим и удалено в следующих версиях.

Ну, во-первых, какая кодировка у вашего файла? Просто так лихо добавлять чего-то 13 к позиции, неправльно. Т. к. это может работать, а может и нет, в зависимости от кодировки исходного файла.

Во-вторых, какая у вас стоит локаль терминала? Когда вы делаете вывод в консоль, данные идут в кодировке файла, а кодировка у терминала может отличаться, отсюда и идёт мусор.

Две самые популярные библиотеки:
Boost.Asio
и
POCO::Network.

POCO имеет реализацию вебсокетов.

kkrieger — это высший пилотаж. Там используются особенности загрузчика Windows, соответственно, его предварительно дизассемблировали и изучили, чтобы подстроиться под его косяки и убрать ненужные заголовки, которые будут занимать место.

Далее, там используется процедурное генерирование. Т. е. текстуры, звуки, эффекты генерируются по формулам, каким-то шаблонам, фракталам, и т. д.

Всё это, по сути, спорт, состязание демо-групп. Реальные вещи на этом делать слишком долго и затратно. Но в плане теории, можно хорошо подтянуться. Поковыряйте исходники движка, на котором написан кригер, они открыты, но довольно устарели уже.

Для реальных вещей, начните учить, например, OpenGL 3.2+, шейдеры, различные технологии, типа abmient occlusion, post processing effects.

А 40 мегабайт планка... это МНОГО. Если учить чистое графическое АПИ, и ничего лишнего не писать, у вас будет всё весить сотни килобайт. Но, опять же, это всё необходимо только для изучения основ и понимания, как оно всё там работает. Для реального продакшена или даже прототипирования лучше возьмите попсовый движок, тот же юнити или анрил. Будет и проще, и быстрее, и удобнее. Ибо, мобильные видеоадаптеры это костыль-driven development. Обычно видео-драйверы там ОЧЕНЬ сырые, ОЧЕНЬ баганые, их реализации графических апи могут абсолютно не соответствовать стандарту. То, что у вас запустилось на Mali, может совершенно не работать на PowerVR или другом чипе. Поэтому не советую привязываться к низкому уровню в мобильной разработке, берите уже проверенный временем движок, в котором решена большая часть этих проблем, и костыли уже расставлены на своих местах. Иначе, будете биться с косяками производителей видеочипов, а не работать с графикой.

Как уже сказали в комментах, открывайте с флагом binary. Строки -- это строки, а двоичные данные -- двоичные данные ©Кэп. Каждая функция предназначена для своей задачи, и не стоит её использовать для других. Если ваш пример иногда работает, а иногда нет, это заслуга только рака, который иногда свистит на горе, а иногда ленится. Это во-первых.

Во-вторых, в C++ нет стандартных средств для поиска в бинарных файлах. Придётся писать свою функцию, либо просто скопипастить со StackOverflow, там таких вопросов миллионы. Реализация давно уже написана за вас.

Подсказка: гуглите реализацию функции memmem().

Во-первых, код, который вы привели, полностью валиден и должен собираться любым компилятором (если не считать stdafx). Если он выбрасывает ошибку, значит вы что-то натыкали лишнего в вижуал студии.

Во-вторых, нет таких книг "под компилятор". Есть различные стандарты. Из современных сейчас практически полностью реализован во многих популярных компиляторах -- С++14. С++11 реализован на 99.99% обычно.
Сначала нужно решить, какой стандарт начать изучать -- 03 или 11/14. Т. к. 14-й -- это, по сути, минорный апдейт 11-го.

Чистый С++14 без всяких там костылей и экстеншенов лучше изучать на компиляторе clang с максимальными флагами ворнингов, педантиков и т. д. Это научит отличать стандартизованный С++ от миллионов расширений и костылей, которые в него успели внести за время его развития. Да и сообщения об ошибках у клэнга на порядок адекватнее, чем наркоманские простыни неверного инстанцирования шаблонов вижуал студии.

Если работаете под виндой, советую поставить Cygwin и на него clang и, если позволяет религия, vim. Можно clion, для новичка он неплохо поможет. Лучше сразу задать параметр -std=c++14, чтоб компилировать под 14-й стандарт. Чтобы отключить всевозможные расширения и не пропускать ни одного предупреждения, нужно добавить параметры -Weverything -Werror -pedantic-errors -Wno-c++98-compat.

Ещё, советую не использовать хидеры, начинающиеся на c*, т. к. они оставлены для совместимости с чистым языком Си. Ибо, используя их, будете путать и не различать чистый Си и C++. Лучше использовать чистый STL и пространство имён std, там всё необходимое есть для начала.

Референсы и хидеры для всяких фич лучше смотреть на C++ reference, ибо там всё по стандарту расписано более-менее.

ПС Ещё, существует два холиварных направления в C++: чистый STL, который предлагает Страуструп и Ко. Там, в основном, используются "3 кита языка: контейнеры, алгоритмы и итераторы". Это типа "тру C++", который изначально придумывался. В основном сюда хорошо накладываются паттерны GoF.
Второе направление -- "Си с классами", это когда, по сути, из ООП используется только полиморфизм, да и то, не там, где нужно. Здесь обычно мешают всё подряд: и Си, и С++, и STL, и макросы, и ещё чёрт знает что. Его использует большинство тех, кто перешёл из Си в С++. Много книг так же написано в данном стиле.
Лично я рекомендовал бы на случай ООП разработки всё-таки приучать себя использовать "тру C++", ибо там есть всё, что нужно, для нормального ООП. Ну, а если хочется просто учить прикладной язык и не париться насчёт хорошего кода, то можно учить как угодно.

Да не слушай ты этот бред, который пишут: "То бросай, это бросай, вакансий нету, всё пропало!".
Всё есть, если есть интерес.
Учить не важно какой движок, они все используют одни и те же концепции, паттерны примерно одинаковые.

Внезапно(!), но везде есть и текстуры, и спрайты, и шейдеры. И игровой цикл даже есть!
Изучив один движок, и написав пару игрушек, потом сам поймёшь, когда стоит перейти на что-то более функциональное и удобное. Придёт осознание, каких фич не хватает, и в каких движках они есть, и т. п.

А все эти анрилы и юнити только ключевыми словами, по сути, отличаются. Ну, и общий дизайн у них чуть более удобен в плане декомпозиции кода, грамотной архитектуры. Но, пока сам не дойдёшь до необходимости использовать эту декомпозицию, ничего особо не выиграешь, только запутаешься. При переходе достаточно будет ознакомиться с паттернами Gang of Four и всё станет ясно более-менее.

ПС Знаю разработчиков Юнити, которые начинали геймдев с этого движка и в шоке от того, что кто-то программирует не мышкой. Азы оптимизации им просто недоступны, ибо они даже понятия не имеют о нижележащем уровне API. Они искренне удивляются, как это знать чистый OpenGL и писать всё самому, а разве так можно? Точно так же, кстати, удивляются многие кодеры на плюсах: "А зачем мне знать ассемблер? Я с ним не сталкиваюсь никогда..."

ППС Вот ещё можно почитать чуть позже, самая крутая книга по геймдеву, которую я видел. Правда, она для тех, уже, кто нашёл в своих движках какие-то изъяны и ищет решения. Но и основы игрового цикла есть там, обработки ввода, множество примеров декомпозиции.

А уж, если хочется просто изучить полезный скилл зарабатывания денег и как зомби рубить бабки, то тут, как описали выше, 2 варианта по сути: Unity (C#), Unreal (C++). По ним вакансий немерено.

Precompiled headers, же! И всё влёт собирается.
Ну, или для совсем тяжёлых случаев, можно юзать Ниндзю.

А писать однозначно на бусте.

На самом деле, если есть знания, кодить можно где угодно. На прошлой работе, когда пришёл, рабочей машиной был одноядерный селерон 1.6ГГц, кодил в юниксовом терминале в vim'е. Отлаживал и анализировал коры в gdb. Купили новую машину, поставил гуй, продолжил кодить в vim.

А для учёбы, отвечу так -- из лучших IDE для плюсов на данный момент:

• Если нет ограничений в виде Win-only, крайне рекомендую связку Clion+clang. У Clion'а есть бесплатная лицензия для студентов. Clang поддерживает полностью C++14, и постоянно запиливают C++17. Плюсом будут всякие санитайзеры и прочие полезные штуки, которые приучают к безопасному коду. А ещё clang может похвастаться очень информативными и понятными сообщениями об ошибках компиляции, в отличие от той же Вижуал Студии, где надо быть шаманом, чтобы понять, что у тебя не верно. Это ой как облегчает обучение.
  Всё это для Линукса. Для винды clang пока не сильно фичастый, вместо него ставить Mingw. Который так же поддерживает C++14.
  
• Для Win-only бесплатная Visual Studio 2015 Community RC + ReSharper 9.1, который так же имеет бесплатную лицензию для студентов.
  

Описанный выше QtCreator не рекомендую, только если не собираетесь учить сам Qt. Функций чуть больше, чем в блокноте, а падает и глючит с завидной регулярностью.

А чем не угодил std::lock_guard?

Не знаю, что за бредовый код вы привели, но типичной ошибкой немедленной выгрузки DLL после загрузки является забывчивость брякнуть case-условие после выборки DLL_PROCESS_ATTACH или DLL_THREAD_ATTACH::

switch (ul_reason_for_call)
{
case DLL_PROCESS_ATTACH:
	break;
case DLL_THREAD_ATTACH:
	break;
case DLL_THREAD_DETACH:
	break;
case DLL_PROCESS_DETACH:
	break;
}