Что должен знать опытный программист Unix об использовании Microsoft Tools?

Question

Я из мира UNIX, я хорошо знаком с Linux, Solaris, Cygwin и разработка MinGW. Недавно я портировал один из моих большие проекты ( cppcms ) для поддержки MSVC, включая создание статических и динамических библиотек с помощью CMake.

И у меня все время возникают совершенно странные проблемы:

1. У меня было Проблемы со сборкой CMake из-за программирования Windows отсутствует соглашение об именах для импорта и статических библиотек.

2. Теперь я обнаружил, что должен использовать разные версии ICU (сборки отладки / выпуска) в соответствии с фактическая сборка, которую я делаю (Debug / RelWithDebInfo - следует использовать Debug ICU, Release release ICU), и поэтому я должен изменить фактические соглашения для поиска библиотек в соответствии с режимом отладки / выпуска только в MSVC. В противном случае приложение просто не начнет выдавать ошибку об отсутствующей DLL.

   У меня нет таких проблем с Mingw или Cygwin с GCC, Open Solaris с Sun Studio или Linux с компиляторами gcc или intel.

3. И у меня все еще есть многочисленные проблемы с проводной связью и проводные ошибки и очень странное поведение - даже некоторые тривиальные вещи не работают под сборками MSVC, когда все работает абсолютно нормально под Solaris / Linux / Cygwin / Mingw с использованием GCC от 3.4 до 4.4, Компиляторы Sun Studio и Intel). Но не под MSVC.

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

Я знаю, что вопрос не очень хорошо определен. Я думаю, что я довольно опытный разработчик, и я знаю, как писать переносимый и хороший код C ++. Но с использованием Microsoft native инструменты сводят меня с ума из-за проблем, которые я просто не знаю, как решить.

Вопрос: Что должен опытный Программист Unix с неплохой базой в Win32 API должен знать, когда это начинает использовать Подлинные инструменты Microsoft?

P.S .: Может кто-нибудь объяснить, почему для «Release with Debug Info» требуется отладочная версия среды выполнения MSVC? И почему вообще существует две версии runtime ?

P.P.S.: Обратите внимание, у меня нет проблем с Win32 API, фактически сборка Windows GCC работает абсолютно нормально.

Разъяснения:

Я ищу подводные камни, в которые может попасть программист из мира Unix.

Например, при переходе с Linux на Solaris: убедитесь, что вы скомпилировали код с -mt или -pthreads при использовании многопоточных программ связывание с -lpthread недостаточно.

Answer 1

П.С .: Может кто-нибудь объяснить, почему "релиз" С информацией об отладке "требует отладки версия среды выполнения MSVC?

Это не так.

А почему там вообще существуют две версии среды выполнения?

Поскольку отладочная версия выполняет дополнительную проверку ошибок.

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

* What am I doing wrong?

Не сообщая нам, что " проблемы с проводной связью и ошибки в проводной сети и очень странное поведение " вы получаете.

* Where should I start?

Сообщая нам о конкретных ошибках и проблемах, с которыми вы сталкиваетесь.

* What do I miss?

Чтение документации и изучение инструментов.

Если ваш вопрос "Что я читаю, чтобы стать хорошим программистом Windows?" тогда мой ответ таков: все из Джефф Рихтер , как начало.

Answer 2

Нет волшебной палочки, которая автоматически сделает вас опытным разработчиком Windows. Windows - это совсем другая земля по сравнению с Unix. Есть много причуд, странного поведения и тому подобных вещей, которые просто отличаются . Единственный способ избавиться от невредимости - это решить одну небольшую проблему за раз. Сконцентрируйтесь на конкретной проблеме и попытайтесь понять проблему. Не просто «заставить его работать», а действительно поймите, что происходит. Хорошая книга о программировании для Windows поможет.

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

Answer 3

Я думаю, что вам нужно попытаться понять новый набор инструментов, а не просто попытаться использовать его в своем нынешнем понимании существующих инструментов. Для этого лучшим способом, IMHO, является попытка начать использовать Visual Studio в соответствии с намерениями Microsoft, а затем, когда вы сможете создать простой проект в IDE, вы можете перейти к его созданию с использованием предпочитаемой системы make, но сделайте это с помощью понимание того, как IDE использует свою систему make для настройки объектов для этой сборки (которая будет работать).

Так, например, для первой части вашего вопроса вы хотите создать простой проект статической библиотеки и простой проект dll и посмотреть вкладки параметров компоновщика. Перейдите к представлению «Командная строка», и вы увидите, что DLL использует параметр компоновщика / OUT, чтобы задать имя и местоположение файла dll, и параметр компоновщика / LIB, чтобы задать имя и местоположение библиотеки импорта. В статической библиотеке используется только параметр / OUT, который указывает имя статической библиотеки. Это правда, что если вы собираете статическую библиотеку и библиотеку DLL из одного и того же источника, и для обеих библиотек / LIB для dll установлено значение MyCrossPlatformCode.lib, а для параметра / OUT - MyCrossPlatformCode.dll, у вас могут возникнуть проблемы, если вы также собираете статическая библиотека с переключателем / OUT MyCrossPlatformCode.lib ... просто не делайте этого; либо создайте статические библиотеки в другой выходной каталог (что и делает OpenSSL), или, что лучше (IMHO), несколько искажите имена, чтобы у вас были MyCrossPlatformCode.lib / .dll и MyCrossPlatformCode_static.lib (что делает STLPort) .

Обратите внимание, что вы также можете изменить (или учитывать) сборку с различными версиями цепочки инструментов Microsoft (так что, возможно, вы получите stlport_vc8_x64d_static.5.1, возможно).

Альтернативный подход, если вы действительно не можете подумать о понимании своего набора инструментов, состоит в том, что вы могли бы взглянуть на некоторые из популярных систем с открытым исходным кодом, которые прекрасно работают на системах Windows и Unix; OpenSSL и STLPort для начала, пожалуй.

Answer 4

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

В случае ваших проблем с именами вы можете захотеть иметь разные каталоги, в которые вы помещаете ваши статические / dll. Вы можете сделать это в Visual Studio с помощью менеджера конфигурации, не зная, как это работает в экспресс-версии.