Владимир Дубровин

dumpbin -exports example.dll
но в общем случае ничего не делать, т.к. помимо функции надо знать какие у нее аргументы и какие соглашения вызова используются, что в принципе не всегда возможно.

В общем случае ваша задача не решается, т.к. в больших случайных данных есть ненулевая вероятность нахождения любой строки. Все зависит от данных, их формата и того, что за строки и как туда попадают.
Для выявления потенциальных строк в бинарном тексте можете посмотреть, например, утилиту strings из GNU binutils

Разница не в языках программирования, разница в подходах. Си в большинстве реальных задач требует полного понимания того что делает каждая строчка кода и как именно она работает, в то время как C++, особенно в последних версиях, позволяет программировать по "кукбукам". Это диктуется не столько языком, сколько теми задачами, для которых он используется, и вашей в частности.
Поэтому да, несмотря на то, что синтаксис Си вы практически уже знаете, если знаете C++, переучиваться вам все равно придется. Уделите при этом внимание не столько синтаксису языка, сколько постарайтесь понять что именно происходит и как это реализовано. По этой же причине учебники по Си написаны совершенно по другому, и читать их в любом случае стоит.

Как дефрагментируется память в языках без сборщика мусора

Как напишете - так и дефрагментируется. Если будете использовать стандартную кучу, то никак, поэтому постепенно будет расти потребление памяти, но, как правило оно будет стремиться с некоторому лимиту. Если это создает проблемы, то вариантов решения несколько:
- свой сборщик мусора с перемещением и дефрагментацией и реализация всех динамических объектов с использованием такого подхода
- реализация управления динамической памятью не приводящая к фрагментации, обычно с фиксированными размерами чанков, например на битмапах .
- минимизация запросов на выделение/освобождение динамической памяти, например, как уже упоминалось, через object pool'ы.

Правильно ли я понимаю, что языкам со сборкой мусора нужно ровно в два раза больше оперативной памяти т.к. нужно куда-то перемещать свободные блоки? Или там от алгоритма зависит? Если да, то какой средний оверхэд?

Сборка мусора не обязательно приводит к дефрагментации, дефрагментация происходит при перемещении. Перемещение обычно не требует никакого overhead'а.

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

А лингер (SO_LINGER) на сокет вы ставите? Если не ставится лингер и вы завершаете приложение сразу после отправки данных в сокет, то данные могут не успеть уйти.

P.S.
Судя по заголовку Proxy-Authorization вы еще и какой-то прокси используете, причем этот прокси ведет себя странно, т.к. этот заголовок наружу уходить не должен. Если не секрет, какой софт себя так ведет?

В Windows wchar_t 16 бит и всегда UTF-16, в gcc под Linux - 32 и потенциально любая кодировка, все зависит от локали. Поэтому вы не можете целиком считать даже один символ. Можно использовать ключ -fshort-wchar для gcc, но в общем-то это костыли.

Работа с аргументами обычно идет через va_start / va_arg / va_end. Но вам все равно надо каким-то образом передавать типы структур, как это делает printf() например, или хранить их описания в каком-то формате и передавать их.

Вы hd_src не проверяете, при проблемах с открытием файла будет обращение по нулевому указателю. А функцию read_callback вы определили?

sizeof(name) возвращает размер всей строки в массиве

тут вы что-то путаете, должен возвращать размер указателя, т.е. 4 или 8 в зависимости от разрядности платформы.

У вас в примере вообще нет массивов, кроме как в инициализаторе. Массив это

char name[]={...}

в таком случае name является константой указывающей на массив, sizeof для нее — размер массива, константа не обладает собственным адресом, поэтому &name в данном случае возвращает адрес массива, т.е. собственно name. Во всем остальном она полностью эквивалентна const char *, по этой причине можно использовать *(name +i).

То, что при инициализации в скобочках можно не указывать размер — это особенность инициализации в C, при наличии инициализатора размер вычисляется при компиляции.

char* name={...} отличается от предыдущего примера тем, что name является не константой, а переменной, под которую выделяется дополнительная память (4/8 байт на 32/64-битных системах соответственно). Соответственно, sizeof(name) возвращает размер переменной, а &name вернет адрес этой переменной.