res2001

Используйте WinAPI для работы с реестром: https://docs.microsoft.com/en-us/windows/win32/sys...

Для передачи вы видимо используете TCP. В ТСР нет разделения на сообщения, все данные передаются в одном потоке в том порядке, в котором были отправлены. Т.е. вполне реальна ситуация, когда вы посылаете например 2 сообщения по 10 байт каждое, а читает 3 раза по 5, 10, 5 байт за раз. Таким образом разделять на сообщения вы должны на принимающей стороне самостоятельно.
РОСО тут не причем - эменно так работает протокол ТРС. Вместо TCP можете использовать UDP - тут будете принимать именно сообщениями. Но есть сложность с дефрагментацией - если размер сообщения больше MTU, то сообщение будет фрагментировано при передаче и не факт, что куски дойдут и соберуться. Ну и еще UDP не гарантирует доставку, т.е. сообщения могут теряться и ни получатель ни отправитель об этом не узнает.
Так же можно использовать протокол SCTP, он так же как UDP работает с сообщениями, но при этом гарантирует доставку. SCTP входит в стандартный стек TCP/IP. Есть ли его поддержка в POCO я не в курсе.

Внутреннее устройство Виндоуз Русиновича.
Никакая книга не сможет вместить описание всего API. Так что документация на сайте микрософта по любому нужна.

А что в плюсах уже стандартный std::sort перестал работать?
Зачем вы пишете собственную сортировку пузырьком? Лучше чем в std вряд ли получится.
Но учитывая, что

Размер файла может быть достаточно большим для загрузки всех данных в память одновременно

Нужно файл делить на несколько частей, помещающихся в память, каждую часть сортировать отдельно тем же std:sort, результаты сохранять в промежуточный файл. Затем результаты объединять с помощью сортировки слиянием.

Тут нет кода вывода на экран.
Возможно ctime() возвращает строку включающую CRLF.
Запустите под отладчиком, поставив точку останова после присваивания timee и посмотрите есть в ее содержимом CRLF. Так же можно поставить снифер, перехватить генерируемый трафик и посмотреть есть ли CRLF в пересылаемой информации.
Если таким образом не найдете CRLF - значит проблема при выводе на экран.

Сохрани исходники в UTF8 и пересобери. В Лине сейчас везде UTF8 по умолчанию стоит.
В старых версиях Линукс в русской локали была кодировка KOI8-R.

Массив Т в transposeMatric - это локальная переменная, вы пытаетесь вернуть указатель на локальную переменную. После выхода из функции все локальные переменные уничтожаются.
На что будет указывать возвращенный указатель? - на какое-то место в стеке, где ранее была правильная переменная, а сейчас может находится все что угодно.
В вашем случае Т надо выделять динамически или возвращать массив по значению.
Ну и
return *T;
вернет T[0][0], а не то что вы, видимо, хотите.
Крометого вы не правильно используете Т в main(). Объявив его как указатель:
double *T;
вы не сообщаете компилятору о размерности массива Т, поэтому индексация массива T[i][j] не может быть выполнена.
Раз уж вы все равно пишете на С++, то используйте std::vector для передачи и возвращения массива.

Это узкое место в вашей программе? Что-то не верится. Оптимизация не нужна.

Посмотрите в настройках проекта какая версия языка используется.
Не скажу на вскидку какие версии поддерживает cl от VS2010, в VS2017 за это отвечает опция /std. В VC2017 эта опция находится в Configuration Properties -> C/C++ -> Language -> C++ Language Standard
Поведение, которое вы описываете, характерно для лохматых версий Си.
Микрософт официально не поддерживает стандарты языка Си в своем компиляторе (хотя стандарты частично реализуются), поэтому в опциях компилятора нельзя это задать.
Если задать опцию /TP, то все файлы исходного кода будут компилироваться как С++ код, не зависимо от расширения файла. По умолчанию, если расширение .c - компилируется как Си код. Возможно эта опция поможет избавиться от ошибки, но есть шанс появления других ошибок. В VC2017 эта опция находится в Configuration Properties -> C/C++ -> Advanced -> Compile As

PS: номер и текст ошибки то же было бы не плохо сюда запостить.

Нужно знать частоту дискретизации и количество отсчетов в выборке.
Частота дискретизации - это количество отсчетов за 1 секунду. Соответственно, длительность звучания в секундах находится: количество отсчетов / частоту дискретизации.

Очевидно - запускать отдельным процессом компилятор с соответствующими параметрами, анализировать ошибки функции старта процесса, ждать завершения процесса компиляции и анализировать код возврата. Так же можно (нужно) перехватывать stdout и stderr и анализировать сообщения компилятора (или просто выводить пользователю).

К чему весь этот листинг?
Т.е. вы хотите из разных программ (процессов) обращаться к одному участку памяти?

Напрямую вы сможете использовать 1 переменную в разных программах только используя механизм shared memory ОС и разместив переменную в "расшаренном" участке памяти. В этом случае для синхронизации доступа к переменной в разных процессах вам необходимо будет использовать какие-либо именованные примитивы синхронизации, иначе будет состояние гонки и доверять содержимому переменной в этом случае будет нельзя.

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

На самом деле нужно знать задачу, чтоб выбрать наиболее правильный вариант реализации.

Из mass() возвращайте размер файла. Там где вызываете mass() суммируйте возвращенное значение.

unsigned mass(char filePath[]) {
   ...
  return fileSize;
}
...
unsigned sum_mass = 0;
sum_mass += mass("file1.txt");
sum_mass += mass("file2.txt");

Если сделать sum_mass глобальной, то она будет видна из всех функций данной единицы трансляции. И можно ее присваивать непосредственно в mass() и возвращать в endSumm(). Кстати endSumm() у вас не правильно объявлена.
Но я бы не советовал использовать глобальные переменные - плохая практика.

CRT - это реализация стандартной библиотеки Си/С++ для данного компилятора.
ОС обычно пишутся на Си и если в ОС нет реализации функций из стандарта Си, то они реализуются в стандартной библиотеке. Все классы из stdlib С++ реализованы в CRT.

CRT в VS может линковаться как статически так и динамически, в зависимости от опций компилятора. Линкуете статически - у вас распухает ваш исполняемый файл, динамически - пользователь должен предварительно поставить соответствующий vcredist (установку можно встроить в собственный инсталлятор). С точки зрения производительности оба варианта примерно одинаковы.

Вы можете не использовать стандартную библиотеку в принципе (отключив ее опциями компилятора) и работать на прямую с ОС, но это накладывает много ограничений и вы фактически остаетесь с кастрированным вариантом ЯП, т.к. например в С++ даже стандартный new/delete, на сколько я знаю, реализованы в стандартной библиотеке и прямого аналога в ОС нет. Обычно этим никто не заморачивается из-за возникающих проблем, решение которых заметно увеличит время реализации проекта, разве что вам необходимо сделать исполняемый файл минимального размера, максимально быстро стартующий и без зависимостей.