Связывание статической библиотеки с dll

При программировании окон Если у вас есть статическая библиотека, которая предназначена для связи с библиотекой dll, где установлена dll/SUBSYSTEM: WINDOWS, то какой из следующих марков должен быть определен в статическом библиотека?Связывание статической библиотеки с dll

_LIB 
_WINDOWS

я путаю эти макросы, так как статические библиотеки это сам никогда не будет показывать свое собственное окно или консоль по себе, так что я не могу understatnd почему мы должны определить эти макросы для статического проекта библиотеки?

источник

2014-08-12 codekiddy

Я предполагаю, что '_LIB' - это значит, что вы создаете библиотеку, а' _WINDOWS' - потому, что вы находитесь на платформе * Windows *. Макросы, подобные этим, обычно используются для условной компиляции, поэтому вы можете иметь другой код на разных платформах, например. –

вы правы в _LIB, но _WINDOWS означает, что подсистема - это windows, _WIN32 (всегда определенная) указывает на платформу, но я не понимаю, почему нам нужно определить макрос _WINDOWS для статического lib, если у dll есть подсистема Windows? – codekiddy

Подсистема (CONSOLE ИЛИ WINDOWS) имеет смысл только для исполняемого файла. Он игнорируется для DLL. –

Только несколько моментов:

Это вполне возможно для функций в статической библиотеке создавать и манипулировать пользовательским интерфейсом, будь то окна User32 или консоль (я думаю, современный интерфейс также).
Если вы не предоставляете специальные функции для этой цели, приложение, использующее вашу библиотеку, не может определить, какие макросы использовались для компиляции библиотек.
заголовки Windows, иногда будет предоставлять по умолчанию, если вы не определили какой-либо из набора макросов (например WINVER)
Эти макросы только как магия, как ваш код делает их. Если вы их не тестируете, то определение их практически не будет иметь никакого эффекта.
Если ваша библиотека делает условно доступными функции пользовательского интерфейса, пропускать их во время компиляции с #if defined(_WINDOWS) имеет некоторые преимущества перед флажками включения времени выполнения.

В частности, если вызовы к функциям пользовательского интерфейса удаляются препроцессором, компоновщик не нужно будет добавлять библиотеки DLL пользовательского интерфейса в таблице импорта. Возможно, имеет значение, работает ли ваша библиотека на установках Windows Server Core. В то же время проверки времени выполнения хороши, потому что вам нужно только один раз собрать библиотеку и распространить одну версию.Использование флагов включения во время выполнения и установка компоновщика для использования задержки с задержкой могут дать лучшее из обоих миров.

источник

2014-08-12 16:56:28

после боя с Google для часов и различных форумов и официальных документов Я узнал, что все это значит при использовании визуальной студии!

статическая библиотека: не нужен/ENTRY или/Subsystem, так как код будет связан в другой код. поэтому библиотека не нужна консоль, windnow или точку входа

длл: /SUBSYSTEM должен быть установлен в WINDOWS и/ENTRY не должно быть установлено, почему? нет записи, потому что в visual studio linker automaticaly создается точка входа DllMain. подсистема библиотеки DLL должна быть установлена в WINDOWS link1 link2 другого нелогич- почему WINDOWS

ех: /SUBSYSTEM и/ENTRY должны быть заданы явно, если не установлено, то компоновщик будет снова автоматически установить подсистему и точку входа как отмечено в ссылке выше.

так, чтобы ответить на мой первоначальный вопрос, не должен быть определен ни один из вышеперечисленных «тупых» макросов :)

источник

2014-08-12 15:42:55 codekiddy

Связывание статической библиотеки с dll

ответ

Смежные вопросы