Вы попали на самый неудачный вариант для создания графического приложения - с использованием чистого WinAPI. Как уже было сказано - это мучительно и неудобно, а главное надо хорошо понимать что вы делаете, т.к. это нижний уровень GUI, а у вас с этим проблемы.
На самом деле, вам стоит подумать - а нужно ли вам в принципе приложение с граф.интерфейсом, т.к. задача у вас примитивная, если не надо рисовать графики, то все остальное прекрасно делается в консольном приложении. А кроме того это гораздо проще.
Если же сильно хочется GUI, рекомендую использовать Qt. И может быть даже не MSVS, а QtCreator.
Ruslan, да и провайдер далеко не факт что в принципе сможет это сделать, т.к. возможно маршрут изменен где-то на промежуточном этапе, который не зависит от твоего провайдера.
Может на вашем компе появился какой-нить процесс который: занимает канал связи, занимает процессорное время, отжирает память.
Может нагрузка на облаке выросла или DDOSят его. Может в прошлый раз облако было ближе к вам, а сейчас переехало на край света.
Причин увеличения задержки и помимо провайдера может быть очень много.
Читайте внимательно мой первый пост.
Бесполезно выполнять эти команды на ВПН сервере - он и так имеет доступ к гугловским ДНСам.
Причину не работы, я описал в этом же посте. На вопросы вы не ответили.
Сергей, Начните с того, что покажите конфиг ВПН сервера. Используете ли в нем опцию: push "redirect-gateway def1 bypass-dhcp"
Именно она прописывает на клиенте ВПН сервер как шлюз по умолчанию.
Я первый способ пробовал
Вы где выполняли эти команды?
как фаервол может работать в качестве маршрутизатора
Правилами фаервола можно перенаправлять пакеты на другой интерфейс и т.п., а это прямое управление маршрутизацией. В т.ч. можно отправить пакеты на NAT, например.
Сергей, Как ВПН сервер сам попадает в интернет? Что является шлюзом в интернет для него?
Дело в том, что шлюз вашего ВПН сервера ничего не знает о ВПН сети. Поэтому он не знает куда слать полученные ответы и он их отбрасывает (или пересылает на свой шлюз по умолчанию).
Есть 2 варианта решения проблемы:
1. простой, но не всегда применимый: настроить на шлюзе статический маршрут до ВПН сети через ваш ВПН сервер.
2. чуть более сложный: поднять на ВПН сервере NAT на интерфейсе в сторону шлюза в интернет, отправлять на NAT все пакеты от ВПН клиентов в интернет с помощью правил фаервола. В этом случае пакеты от ВПН клиентов в интернет будут попадать на шлюз с адресом ВПН сервера, а не ВПН клиентов.
Не занимаюсь геймдевом.
Язык программирования - это только инструмент. Все ООП ЯПы плюс-минус похожи. Изучите один, следующий пойдет как по маслу. Самый сложный ООП ЯП это, наверное, С++.
Купите толстую книжку учебник по выбранному ЯПу, читайте и делайте примеры из нее. По С++ - Лафоре подойдет.
Дальше нужна еще книга по алгоритмам и структурам данных. Именно тут зарыта суть программирования, а вовсе не в ЯПе. Книжка Кормена, говорят, норм.
Сложные темы из программирования, которые используются вообще во всех сферах программирования - сетевое программирование (передача данных) и параллельное программирование. На это стоит заострить внимание. В геймдеве это все то же активно используется. Но в обычных учебниках про это пишут совсем чуть чуть. Нужно что-то более специализированное.
Из математики в геймдеве нужна линейная алгебра и тригонгометрия, на сколько я знаю.
В самом программировании мат.анализ нафиг не нужен. Он нужен в каких-то предметных областях, где он используется. Возможно, немного дискретной математики.
Ну а дальше берете понравившийся движок и начинаете его изучать и делать свой проект. Это можно начинать уже после освоения первого учебника по выбранному ЯПу, параллельно со всем остальным. За одно, свой проект, начнет добавлять вам вопросов для дальнейшего изучения.
Подтверждаю. Надо просто выбрать toolset с суффиксом xp в свойтсвах проекта. Он идет вместе со стандартным. Версия toolset для xp такая же, как и дефолтного. Другое дело, что сам MSVS может не встать на XP.
Но тут можно поставить MS Build Tools, а в качестве IDE использовать QtCreator.
В параметрах компилятору, надо будет вручную указывать нужный toolset. Как это делать написано тут: https://stackoverflow.com/questions/46325589/compi... https://stackoverflow.com/questions/52152135/how-t... https://social.msdn.microsoft.com/Forums/azure/en-...
Если у вас будет (наверняка) другая версия toolsetа, то просто проведите эксперимент - в MSVC создать простейший проект собрать его со стандартным toolsetом и с xp вариантом и сравнить параметры командной строки, которые выдаются для запуска cl и link.
Дмитрий Королев, Ты в курсе, что такое static переменные? Что будет, когда она определена так как у тебя в заголовочном файле? Уверен, что тебе именно такое поведение требуется?
На мой взгляд, если есть потребность в static переменной, то такой переменной самое место в *.c файле.
Можешь оставить в заголовке определение структуры, а определение переменной перенести в *.c.
Допускаю, что возможен какой-то вариант использования статической переменной, определенной в заголовке, но это что-то довольно экзотическое.
Дмитрий Королев, Ну и делайте документацию в заголовке. Если планирует распространять в виде библиотеки, то вместе с бинарником библиотеки необходимо передавать и заголовок, так что документации там самое место.
Не понял, что такое "статическая структура". Все определения переменных должны быть в *.c файле. Если какие-то переменные должны быть доступны не только библиотеке, то в заголовочнике объявите их как extern.
Дмитрий Королев, Да, вытаскивайте реализацию. Не нужно навязывать собственное видение процесса компилятору, он вас не поймет.
чем скрыть детали реализации от потребителя
1. Зачем это делать? Сейчас вы не пытаетесь скрывать детали реализации, с чего вдруг возник этот вопрос.
2. Потребители обычно имеют дело с исполняемым файлом - им ваши исходники не нужны.
Дмитрий Королев, В Си можно использовать динамические библиотеки, так же как и статические. Нет проблем.
Проблема использования одного заголовочного файла в нескольких файлах исходного кода в проекте решается с помощью include guards.
Но у вас не эта проблема - у вас проблема двух (или больше) функций с одним и тем же именем. Из-за того, что вы реализуете функции в заголовке. И эту проблему линковщик сам решить не способен.
Дмитрий Королев, __mi_ManagerInitialize - это видимо функция. И вы ее реализацию написали в заголовочном файле?
Отсюда и ошибка.
Смысл в том, что теперь эта функция у вас присутствует 2 раза и когда линкер пытается собрать исполняемый файл и находит такую двойную функцию, он не знает какой экземпляр выбрать. Логично.
В общем случае определение (реализацию) функций не нужно пихать в заголовок. Они должны быть в своих *.c файлах.
Исключением могут быть inline функции, но вы должны понимать к чему это приведет. Обычно inline функции очень короткие и компилятор не выделяет их в отдельные функции а сразу встраивает в код, т.е. нет вызова функции.
Так же можно объявлять функции в заголовке как static - но это плохая идея. Такие функции так же будут присутствовать в каждом объектном файле и будут включены в исполняемый файл несколько раз. Но область видимости такой функции будет распространятся только на текущий файл, поэтому подобной ошибки быть не должно.
Дмитрий Королев, Все верно. Имя макроса можно было придумать получше.
У тебя один заголовочный файл?
Текст ошибок в студию. Если их много однотипных, то давайте одну из них.
На самом деле, вам стоит подумать - а нужно ли вам в принципе приложение с граф.интерфейсом, т.к. задача у вас примитивная, если не надо рисовать графики, то все остальное прекрасно делается в консольном приложении. А кроме того это гораздо проще.
Если же сильно хочется GUI, рекомендую использовать Qt. И может быть даже не MSVS, а QtCreator.