Помимо «битности», есть DLL-файлы, специфичные для типа машины/процессора, в некотором роде?

Question

Я работаю над разработкой приложения Java, которое загружает файлы собственных библиотек для выполнения некоторых вычислений. Приложение использует JNI для загрузки библиотек. Это приложение должно работать в средах Windows и Linux (как на 32-битных, так и на 64-битных).

В процессе компиляции мы скомпилируем код C в файлы библиотеки (32-разрядные и 64-разрядные библиотеки для Windows и 32-разрядные и 64-разрядные .so-файлы для Linux-сред). Эти файлы .dll и .so включены в файл распространения и упоминаются при вызове Java с использованием параметра -Djava.library.path.

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

Я думал, что проблема может быть связана с различием в типе процессора между машинами (то есть, что dlls были скомпилированы для одного типа процессора и других типов процессоров, они не могут их использовать).

Однако, он работает на одной машине, и не работает на другом компьютере, который имеет тот же процессор:

Он работает на ноутбуке HP под управлением Windows 7 64-бит, с этим процессором:

PROCESSOR_ARCHITECTURE=AMD64 
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 37 Stepping 5, GenuineIntel 

это не работает на ноутбуке Lenovo работает Windows 7 64-бит, с этим процессором:

PROCESSOR_ARCHITECTURE=AMD64 
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 58 Stepping 9, GenuineIntel 

Мой вопрос: помимо разрядности являются библиотек .dll машина/процессор Тип спецификации по-другому? (Я знаю, что файлы .dll должны соответствовать битности машины и что JVM также должен соответствовать битте .dll-файлов)

Или теоретически, если .dll 64-бит, если он запустить на КАЖДОЙ 64-разрядной машине, использующей 64-битную JVM?

Answer 1

отдельно от bitness .dlls машина/тип процессора конкретный каким-то другим способом?

Очень понравилось. Любой скомпилированный двоичный файл , предназначенный для работы под операционной системой, является как процессором, так и операционной системой, а иногда и конкретными версиями каждого.

Различные процессоры - даже в одном и том же семействе, такие как «x86» - могут предлагать различные наборы инструкций и возможности. См. https://en.wikipedia.org/wiki/X86_instruction_listings для перечисления различных вариантов только наборов инструкций и возможностей x86. Если скомпилированный двоичный файл использует определенную инструкцию, он не будет работать на процессоре, который не выполняет эту инструкцию. Например, если бинарный файл скомпилирован для использования инструкций SSE3, он не будет работать на процессорах, которые не реализуют SSE3.

И это не только аппаратное обеспечение. Специфические особенности операционной системы также важны для начинающих, потому что операционная система запускает процесс. Таким образом, двоичный файл должен работать в условиях и в среде операционной системы, которая его запускала. Бинарный код, предназначенный для работы в операционной системе, также должен будет звонить в эту операционную систему для взаимодействия с данными, устройствами или другими процессами.Различные операционные системы предоставляют эти возможности совершенно по-разному, вплоть до того, что разные версии одной и той же базовой операционной системы делают это несовместимо.

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

Или в теории, если .dll является 64-разрядной она должна работать на КАЖДОЙ 64-битной машины, с помощью 64-разрядной JVM?

Должно быть ясно, что ответ «Даже не близко».