Как уже говорили другие, не существует единого стандарта для именования файлов в Windows.
Для нашей полной базы продуктов, которая охватывает 100-е годы exe, dll и static libs, мы успешно использовали следующее в течение многих лет, и это избавило от многих недоразумений. По сути, это сочетание нескольких методов, которые я видел в течение многих лет.
В двух словах: все наши файлы имеют префикс и суффикс (не считая самого расширения). Все они начинаются с «ом» (в зависимости от названия нашей компании), а затем имеют комбинацию из 1 или 2 символов, которая приблизительно идентифицирует область кода.
Суффикс объясняет, к какому типу встроенных файлов они относятся, и включает до трех букв, используемых в комбинации, в зависимости от сборки, которая включает Unicode, Static, Debug (сборки по умолчанию являются Dll и не имеют явного идентификатора суффикса). Когда мы запустили эту систему, Unicode не был таким распространенным, и нам приходилось поддерживать сборки Unicode и Non-Unicode (до Windows 2000 OS), теперь все построено исключительно на Unicode, но мы все еще используем одну и ту же номенклатуру.
Так что типичный "набор" файлов .lib может выглядеть как
omfThreadud.lib (Unicode/Debug/Dll)
omfThreadusd.lib (Unicode/Static/Debug)
omfThreadu.lib (Unicode/Release/Dll)
omfThreadus.lib (Unicode/static)
Все файлы встроены в общую папку bin, что устраняет многие проблемы dll-hell для разработчиков, а также упрощает настройку параметров компилятора / компоновщика - все они указывают на одно и то же местоположение с использованием относительных путей и никогда не требуется ручное (или автоматическое) копирование библиотек, в которых нуждается проект. Наличие этих суффиксов также устраняет любую путаницу в отношении того, какой тип файла у вас может быть, и гарантирует, что у вас не может быть смешанного сценария, когда вы записываете отладочную DLL в выпускной комплект или наоборот. Все exe-файлы также используют аналогичный суффикс (Unicode / Debug) и встраиваются в одну и ту же папку bin.
Существует также одна отдельная папка «include», каждая библиотека имеет один заголовочный файл в папке include, который соответствует имени библиотеки / dll (например, omfthread.h). Этот файл #include включает все остальные элементы, которые выставлено этой библиотекой. Это будет проще, если вы хотите использовать функциональность, которая есть в foo.dll, вы просто #include "foo.h"; наши библиотеки сильно сегментированы по областям функциональности - фактически у нас нет никаких dll «швейцарского армейского ножа», поэтому включение всех функций библиотеки имеет смысл. (Каждый из этих заголовков также включает другие обязательные заголовки, будь то наши внутренние библиотеки или SDK других поставщиков)
Каждый из этих включаемых файлов внутренне использует макросы, которые используют # pramga для добавления соответствующего имени библиотеки в строку компоновщика, так что отдельные проекты не должны быть связаны с этим. Большинство наших библиотек могут быть построены статически или в виде DLL, и #define OM_LINK_STATIC (если определено) используется для определения того, чего хочет отдельный проект (мы обычно используем DLL, но в некоторых случаях статические библиотеки, встроенные в .exe, делают больше смысла для развертывания или других причин)
#if defined(OM_LINK_STATIC)
#pragma comment (lib, OMLIBNAMESTATIC("OMFTHREAD"))
#else
#pragma comment (lib, OMLIBNAME("OMFTHREAD"))
#endif
Эти макросы (OMLIBNAMESTATIC & OMLIBNAME) используют _DEBUG, чтобы определить, какой это тип сборки, и сгенерировать правильное имя библиотеки для добавления в строку компоновщика.
Мы используем общее определение в статической и dll-версиях библиотеки для управления правильным экспортом класса / функций в сборках dll. Каждый класс или функция, экспортируемые из библиотеки, украшены этим макросом (имя которого совпадает с базовым именем библиотеки, хотя это в значительной степени неважно)
class OMUTHREAD_DECLARE CThread : public CThreadBase
В DLL-версии настроек проекта мы определяем OMFTHREAD_DECLARE = __declspec (dllexport), в статической версии библиотеки мы определяем OMFTHREAD_DECLARE как пусто .
В заголовочном файле библиотеки мы определяем его в зависимости от того, как клиент пытается с ним связаться
#if defined(OM_LINK_STATIC)
#define OMFTHREAD_DECLARE
#else
#define OMFTHREAD_DECLARE __declspec(dllimport)
#endif
Типичный проект, который хочет использовать одну из наших внутренних библиотек, просто добавил бы соответствующее включение в их stdafx.h (обычно), и это просто работает, если им нужно связать статическую версию, они просто добавляют OM_LINK_STATIC в свой компиляторнастройками (или определите его в stdafx.h), и он снова просто работает.