res2001

error=unable to get local issuer certificate:

У вас проблема с сертификатами.
Возможно закончился срок действия вашего сертификата или сертификата ЦА или на сервере сменили сертификат ЦА и свой серверный. В общем комбинаций несколько, т.к. в цепочке подключения обычно используются 3 сертификата (ваш, сервера, ЦА).
В конфиге openvpn в соответствующих директивах указаны пути к файлам сертификатов, проверьте их. Обычно их содержимое в читабельном виде, но могут быть варианты.

Вам нужен батник, который это делает?
file1.js стартуйте через команду start
file2.js - старутйте обычным образом (без start).
Они, конечно, стартуют не одновременно, но по крайней мере file2.js запустится сразу после того как стартанет file1.js. При этом батник будет ждать когда закончит выполнение file2.js и только после этого продолжит выполняться дальше.
В конце стартуйте file3.js.
Если до старта file3.js нужно убедится что точно file1.js и file2.js завершили работу (file2.js точно уже завершил работу, а вот file1.js все еще может работать, т.к. запускался через start и с ним батник никак не синхронизирован), то перед его стартом нужно с помощью tasklist в цикле с паузой проверять работает ли еще file1.js.

маршруты до сетей прописаны, локальные сети между собой взаимодействуют

Если это так, то локальный адрес веб сервера должен быть доступен из второй сети. Не нужно ничего пробрасывать. Все работает.
Если веб сервер не доступен, то что вы имели ввиду под этой фразой? Какой-то противоречие тут.

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

Делайте перенаправление вывода второго скрипта в файл, тогда по размеру файла вы сможете определить, что он какое-то время бездействует.
Либо можно более технологично - в запускающем скрипте делаете перенаправление в pipe для запускаемого и работаете с каналом, а не с файлом.
Но лучше бы выяснить причины зависания скрипта и бороться с ними, а не придумывать костыли.

IDE включает в себя в том числе и текстовый редактор, заточенный именно под создание кода.

В винде MSVS не плох, но имейте ввиду, что компилятор по умолчанию (микрософтовский cl) официально не поддерживает стандарты Си. Возможно поддерживает ANSI C, но тут я не в курсе, т.к. он не актуален. Какие-то вещи из свежих стандартов работают, другие нет, некоторые работают, но не совсем так как в стандарте.
gcc, clang - поддерживают стандарты.
Я использую qtcreator. Его можно использовать даже если в проекте не применяется Qt и нет С++.
Раньше использовал eclipse, но он написан на Java, соответственно тормоза в самый не подходящий момент, изрядно подбешивал этим.

Тут еще важен момент, какую систему сборки использовать. Если используете MSVS + cl, то система сборки будет msbuild ну и там особо заморачиваться не нужно - конфигурируете проект в студии и все применяется как надо, по сути вы и не видите систему сборки, но она есть, как суслики.
Так же MSVS поддерживает и другие компиляторы и системы сборки, например cmake, но тут уже придется изучать язык управления системой сборки и писать свои сборочные скрипты.
В qtcreator по умолчанию используется qmake, так же умеет из коробки cmake. То же нужно писать сборочные скрипты.
Eclipse - тут можно без системы сборки, через свойства проекта все делать. Eclipse сам все соберет. Но местами довольно запутано, хотя быстро привыкаешь. Кроме того в конце концов вам понадобится собрать проект без IDE (например у заказчика), вот тут вам и понадобится система сборки, которой вы не обзавелись в Eclipse и придется как-то выходить из положения. Я писал makefile в этом случае, мне казалось это самым простым вариантом. Сейчас я так не думаю - проще сразу делать проект используя какую-то систему сборки. В том числе и по этому отказался от Eclipse.

Вы не правильно понимаете.
При таком использовании как сейчас у вас смысла в poll особого нет, а так же нет особого смысла использовать его в блокирующем режиме сокета, т.к. в этом режиме recv (send) не вернет управление пока не сделает свою работу или пока не возникнет ошибка или пока не придет сигнал.

Если вы не стремитесь сделать некоторый вариант асинхронной работы с сетью, то poll и неблокирующие сокеты можно вообще не использовать.
В блокирующем режиме poll может быть полезен тем, что он поддерживает timeout, что может быть полезно, например для проверки флага не пора ли завершить поток или что-то в этом роде. Но и в этом случае нет гарантии, что recv (send) выполнятся без блокировки и сразу вернут управление. Поэтому timeout будет работать только в вызове poll, но не recv (send).

poll вам возвращает признак есть ли в сокете данные для чтения (или готов ли он к записи). Если да - вызываете recv (send), если нет можно поделать что-то свое, потом снова вызвать poll.

Кроме того имейте ввиду, что recv может получить не полный буфер, и send отправить не весь буфер.

Всегда анализируйте возвращаемые значения системных функций, особенно когда дело касается ввода/вывода.

На сколько я знаю, в функциях WinAPI, которые работают с путями, допускается указание в путях задвоенных и затроенных (и т.д.) слешей. Причем как прямых так и обратных.
Если у вас не так, стоит привести пример кода, ошибку и путь который передается в программу.

DNS сервер у вас реально где расположен? Этот адрес и укажите на TS.

Укажите запуск программы с помощью которой вы хотите, что бы файл открылся.
www.script-coding.com/ContMenuExpl.html

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

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

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

https://www.boost.org/doc/libs/1_64_0/libs/math/do...
https://rsdn.org/forum/cpp/2640596.1
https://habr.com/ru/post/112953/
https://randomascii.wordpress.com/2012/02/25/compa...

На уровне стандартной библиотеки это не сделать, т.к. в std реализована определенная схема работы: ввод заканчивается нажатием Enter, до окончания ввода программа не контролирует входной поток, только затем все введенные символы передаются на обработку программе.
В простом варианте - читайте в строку, затем обрабатывайте каждый символ отдельно.

Но по уму вам нужно переводить терминал в "сырой" (raw) режим средствами ОС, в этом режиме появляется возможность обрабатывать каждую нажатую клавишу отдельно, не требуется подтверждение ввода Enterом и т.д. Но в работе в этом режиме std и ее стандартные объекты вам не помогут никак, нужно переходить на уровень ОС.
Можно поискать библиотеки, в которых реализован "сырой" ввод. Например в libuv это есть, но это кроме всего прочего еще и бибилотека ассинхронного ввода/вывода, что как бы добавляет сложностей.

Поставьте набор сторонних кодеков, например K-Lite Codec Pack.

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