Как мне назвать нативную DLL, распространяемую как в 32-битной, так и в 64-битной форме?

У меня есть коммерческий продукт, представляющий собой DLL (собственный 32-разрядный код), и теперь пришло время создать его 64-разрядную версию. Таким образом, при установке в 64-битной Windows 32-битная версия помещается в Windows\SysWOW64, а 64-битная версия — в... Windows\System32! (Здесь я прикусываю язык...) Или DLL (и) могут быть установлены вместе с клиентским приложением.

Как мне назвать 64-битную DLL?

То же имя, что и 32-битный: два файла, которые делают одно и то же, имеют одно и то же имя, но совершенно невзаимозаменяемы. Разве это не путь к путанице и проблемам с поддержкой?

Различные имена (например, product.dll и product64.dll): теперь клиентские приложения должны знать, работают ли они в 32-разрядной или 64-разрядной версии, чтобы ссылаться на мою DLL, и есть языки, для которых это неизвестно до запуска. время - .NET является лишь одним из примеров. И теперь все статически скомпилированные клиенты должны обусловить объявления импорта: IF target=WIN64 THEN import Blah from "product64.dll" ELSE import Blah from "product.dll" ENDIF

Продукт содержит огромное количество кода C и большой кусок C++ — перенос его на C# невозможен.

Совет? Предложения?


dll native-code win64
person Spike0xff    schedule 05.03.2010    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Клиентские приложения не обязаны "знать", являются ли они 32-разрядными или 64-разрядными. ОС автоматически загружает библиотеки DLL из соответствующего расположения, поскольку невозможно загрузить 32-разрядную библиотеку DLL в 64-разрядный процесс и невозможно загрузить 64-разрядную библиотеку DLL в 32-разрядный процесс.

Если 32-битное приложение пытается загрузить что-то из system32, ОС автоматически перенаправит его в каталог SysWow64, принудительно загрузив 32-битную версию.

Имея разные имена, вы побеждаете весь этот механизм. Механизм, созданный специально для того, чтобы вы могли использовать одно и то же имя.

person doug65536    schedule 07.11.2015
comment
В вашем ответе предполагается, что мои библиотеки DLL всегда будут устанавливаться в общие системные папки, что абсолютно неверно. Многие (большинство?) моих клиентов предпочитают устанавливать вспомогательные библиотеки DLL для своих приложений вместе с приложением. Тем не мение! Я согласен (как вы можете видеть в моем ответе самому себе), что лучше не бороться с мэрией, поэтому у меня есть две абсолютно невзаимозаменяемые DLL с одинаковыми именами, и Windows не предлагает встроенного способа определить, что есть что. - person Spike0xff; 10.11.2015
comment
@ Spike0xff Хранение копий библиотек вместе с исполняемым файлом противоречит цели общих библиотек. Вы, вероятно, должны быть статическими ссылками. Если вы собираетесь хранить копию всей библиотеки, вы можете встроить ее в исполняемый файл. По крайней мере, тогда он отбрасывает неиспользованные порции. - person doug65536; 10.11.2015

arrow_upward
1
arrow_downward

Почему бы не поставить перед dll знак подчеркивания... например, product_32.dll и product_64.dll? ИЛИ указать это с помощью префикса платформы - product_x86_32.dll и product_x86_64.dll? По крайней мере, это устранит путаницу в именовании DLL... Что вы думаете?

person t0mm13b    schedule 05.03.2010

arrow_upward
0
arrow_downward

Я решил последовать примеру Microsoft, которая сохранила те же имена для DLL в System32, когда они перешли на 64-битную версию. В Win7/64 System32\avicap32.dll является 64-битной DLL!

Существует некоторая потенциальная путаница для меня и моих клиентов из-за наличия 32-битных и 64-битных библиотек DLL с одинаковыми именами. Однако я думаю, что было бы хуже, если бы все мои клиенты должны были сделать свои кодовые слова чувствительными к ширине. Особенно разработчики .NET, которые часто могут оставить для своей целевой платформы значение AnyCPU.

person Spike0xff    schedule 28.04.2010