res2001

Собрать программу можно и без наличия dll, главное чтоб был lib файл от этой dll и файлы заголовки для статического связывания.
В случае динамического связывания (с помощью LoadLibrary() и GetProcAddress()) не нужен и lib файл.
Какое именно связывание используется у вас - вам виднее.
DLL понадобится на этапе исполнения программы. В случае статического связывания без DLL программа не загрузится с соответствующей ошибкой от ОС. В случае динамического связывания LoadLibrary() вернет ошибку, если dll не доступна.

Обратите внимание на то как объявлена функция:
int sum (int n, int matrix[n][n])
И на то как вы ее вызываете:
sum_of = sum(matrix[][]);
Надеюсь дальше разберетесь сами.

cos(x) * n

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

Кстати, вы не привели объем ОЗУ вашего компа.

Использовать библиотеки для больших/длинных чисел.

Можно. Пишите в Микрософт.

Это проявления буферизированного вывода. Т.е. по факту printf до ввода уже выполнился, но на экране еще не отобразился.
Между printf и scanf вставьте fflush(stdin).

Алгоритм циклического сдвига массива "на месте" описан в "Жемчужинах программирования" Джона Бентли 2-е издание, Addison-Wesley, Питер, 2002, Глава 2, раздел 2.3.
Вот пример реализации. Там же видел реализацию того же алгоритма поприличней (в плане оформления кода), но сходу найти не могу.

Алгоритм сдвига не "на месте" (с выделением памяти под массив результата) простой, реализуется двумя операциями копирования памяти.

Дать компилятору эту библиотеку, иначе не соберется проект.

У вас дочерние процессы висят на system("pause"); и не завершаются самостоятельно.
Просто удалите эту команду в дочках, оставьте только в главном процессе и не надо будет ничего мутить с CTRL_BREAK.

1.Если по тупому, то запускайте софтину, она будет ругаться на отсутствие библиотеки, эту библиотеку ищите в недрах mingw копируете в каталог с исполняемым файлом. Повторяете процедуру до тех пор пока софтина не перестанет ругаться на отсутствие библиотек.

2.Чуть по технологичнее: берете dependency walker открываете им ваш исполняемый файл, смотрите от каких библиотек он зависит (в глубину то же нужно смотреть, а не только первый уровень) ищите и копируете библиотеки аналогично п.1.

3.По умному: прописываете путь mingw/bin в переменной окружения PATH и наслаждаетесь. При этом ничего копировать не придется.
Но если вы задумаете распространять ваш софт другим людям, это не избавит вас от необходимости устранять зависимости, т.е. вы все равно должны будете либо собрать все библиотеки в одном каталоге с исполняемым файлом, либо обязать пользователя устанавливать mingw и прописывать его путь в переменную PATH.

Не зависимо в какой ОС вы работает и какой IDE пользуетесь схема одна и та же:
1. Для того что бы в своих исходниках вы могли использовать вызовы сторонней библиотеки вы должны включить заголовочные файлы библиотеки с помощью директивы #include.
2.Чтоб компилятор смог откомпилировать ваш код вы должны задать ему место расположение заголовочных файлов сторонней библиотеки с помощью опции -I компилятора. В линуксе, если библиотека установлена штатным пакетным менеджером, возможно это не потребуется, т.к. заголовочные файлы будут доступны по стандартным путям поиска заголовочных файлов.
3.Чтоб линковщик смог собрать исполняемый файл вы должны указать ему путь и имя двоичных файлов библиотеки с помощью опции -L и -l. Опять же в линуксе, возможно, путь (-L) указывать не потребуется (см.п.2), только имя библиотеки (-l).
4.Если библиотека установлена не в стандартные каталоги, то загрузчик исполняемых файлов может ее не найти. Чтоб это исправить возможно потребуется запустить утилиту ldconfig или даже добавить каталог библиотеки в конфигурационный файл ldconfig. Как вариант добавить в переменную окружения LD_LIBRARY_PATH путь к библиотечным бинарным файлам перед запуском программы.
В винде ldconfig нет - библиотечные файлы должны быть либо в каталоге где лежит исполняемый файл программы, либо в одном из путей, заданных в переменной окружения PATH.

Когда вы запускаете сборку в IDE, то обычно опции компилятора из пп.1-3 вы должны указывать в свойствах проекта.

Задать дополнительный каталог для поиска библиотеки можно с помощью опции компилятора:
-L <новый путь к библиотекам>

И FTP и POP3, а так же SMTP, IMAP и многие другие являются текстовыми протоколами, там так же можно определить протокол по содержимому пакета.
В двоичных протоколах такой метод то же может работать, только анализировать нужно уже двоичную информацию, а не текстовую.
В любом случае для анализа нужно знать сам протокол хоть текстовый, хоть двоичный.
Но, конечно, не все так можно определить. Например, если любой из протоколов спрятан за SSL, то снаружи вы увидите шифрованный трафик, а что внутри без расшифровки понять уже не возможно.

Кроме того определение протокола по номеру порта - так себе идея, т.к., наверное, любой сервер поддерживает возможность смены порта.

Eclipse работает автономно, есть сборки со встроенной JRE, в этом случае и ява не нужна на компе.
Но с компилятором могут быть проблемы - в эклипсе (да и в остальных IDE) нет своего компилятора.
Обычно под виндой используется MSVC или mingw.
MSVC скорее всего так же нельзя сделать переносимым.
mingw - можно. Но что бы использовать его в Eclipse нужно настраивать переменные окружения винды. Это можно сделать запуская Eclipse из батника, в котором сначала устанавливаются значения для нужных переменных окружения и только потом запускается IDE.
С другими IDE, думаю, схема будет примерно такая же.