Дед Пахом писал(а): ↑12 Июль 2022, 11:09
Игорь Столяров писал(а): ↑12 Июль 2022, 10:11
Поэтому считается, что раз автор опубликовал проект - то он его проверил.
Если это камень в мой огород, то зря, я libcurl.dll v7.84.0 в проект не добавлял.
Кстати, curl.exe той же версии точно так же зависит от всех этих api-ms-win-xxx-11-1-0.dll, это к тезису "лучше использовать curl.exe, чем libcurl.dll".
По-хорошему надо бы баг репорт открыть на оф. сайте curl, а то они все следующие версии могут собирать с этими зависимостями.
Тезис, что лучше использовать curl.exe относится к тому, что приложение работает штатно и не падает при проблемах в curl. Ошибка вылезет только тогда, когда будет вызов. С учетом того, что curl реализует дополнительный функционал, вызывается не часто и не у всех, не возникает таких напрягов, как в ситуации, когда приложение вообще не запускается.
Несколько лучше будет ситуация при динамической подгрузке библиотеки, но тоже можно напороться на потенциальные проблемы. Например, недавно всплыла проблема с piritlib.dll, которая у меня подгружается динамически. После инициализации этой либы и последующем выходе из приложения, приложение остаётся висеть запущенным в процессах. Только на Windows 10. Пришлось искать обход, принудительно килять запущенный процесс.
Решение надо находить быстро, пользователю пофиг, кто рукова пришивал. Поэтому я и предпочитаю использовать exe вместо dll, оформляя запуск в виде процесса, чтобы контролировать работу. Если, конечно, такое возможно при использовании конкретной либы. С точки зрения кода приложения вообще разницы нет, так как обертывается в класс.
C6/C11, ШВС, tps/btrieve.