Может ли 64-битная библиотека работать в 32-битном приложении? Например, мой графический интерфейс приложения использует 32-битный Qt. И мое бизнес-ядро - это 64-битная библиотека. ОС - 64 бит. Могут ли они работать вместе и как? Благодарю.Может 32 бит и 64 бит работать вместе?
Вкратце: вы не можете связать 32-разрядное приложение с 64-разрядной библиотекой.
Вы можете запустить 32-разрядное приложение, используя 32-разрядные совместно используемые библиотеки в 64-разрядной ОС (по крайней мере, все популярные 32-/64-разрядные процессоры, такие как AMD, Intel и Sparc). Но это не касается каких-либо библиотек.
Более длинный ответ: Я был вовлечен (на окраинах) некоторых команд, которые разработали 64-битное ядро Linux для x86. Были кратко (по сравнению с целым проектом, дискуссии длились довольно много часов) некоторое обсуждение того, как вы могли технически выполнить эту работу. Краткое изложение этого заключается в том, что в 64-битных версиях есть регистры, которые недоступны в 32-разрядной версии. Также существует проблема адресов памяти и дополнительных 32-битных регистров. Все они могут быть решены, если предположить, что сама библиотека «знает», что это 32-разрядная совместимая библиотека. Но тогда у нас в основном есть 64-битная библиотека, которая написана как 32-битная библиотека, и мы как бы потеряли смысл.
«Больше регистров» может не применяться к некоторым процессорам, но больший адрес/бит-диапазон регистров определенно применимы ко всем 32- и 64-разрядным совместимым процессорам. И я не знаю ни одного процессора, который позволяет 32-битный код, вызывающий 64-разрядную общую библиотеку или статическую библиотеку. Он просто не работает, если код специально не написан, чтобы справиться с этим, что наносит ущерб тому, что общая 64-разрядная библиотека поддерживает 32-разрядные приложения.
Редактировать:
Приведенные выше обсуждаемые связывающие один исполняемый блок, например, исполняемый файл, общую библиотеку или статическую библиотеку. Это должно быть «одно битовое», либо 32, либо 64 - без смешивания.
Когда процесс, ведущий к другому процессу (например, приложение графического интерфейса пользователя, которое отображает статус из процесса, отличного от GUI), если оба процесса используют один и тот же протокол [и, как правило, IPC не разрешает в любом случае, так что 32-/64-битное преобразование не так уж и важно], у вас может быть один 32-разрядный процесс, а другой - 64-разрядный.
Было выполнено несколько смешанных двоичных кодов на системах Amiga, которые могли запускать полные файлы, содержащие 68k и PPC-код. Штыри были связаны с выполнением переключения контекста, когда выполнение выполнялось от одного процессора к другому. Однако, если я правильно помню, то оба работали в режиме 32b. – Jens
-1 «Короче говоря». это неверно.все 32-разрядные программы на 64-битной Windows в конечном итоге используют 64-разрядные службы, поскольку они работают в 64-разрядной ОС. для преодоления разрыва в 64-битной библиотеке вы можете использовать любое количество технологий, включая COM. –
@Alf: COM - это RPC. С помощью RPC вы можете преодолеть промежуток между 32 и 57 бит. Это не особо. По мере того, как библиотеки идут, 64-битная Windows по-прежнему поставляется с 32-разрядными версиями своих библиотек (DLL) в подсистеме WoW именно потому, что вы не можете смешивать битность в одном процессе. – MSalters
Если вы работаете в Windows, ваше приложение, скомпилированное для 32b, может работать в хост-системе Windows 64b: посмотрите подсистему WOW64, встроенную в Windows 64b.
Сказав это, вы можете не код смешения, скомпилированный для 32b с кодом, скомпилированным для 64b. Значение библиотеки, которая была построена для 32b, не может быть связана с кодом 64b и наоборот. (Различные соглашения о вызовах, компоновка фреймов стека, кроме разматывания, ...)
Да, но это не связывание с библиотекой, это интерфейс системного вызова, который вызывает системные вызовы из 32-разрядного кода в 64-битное ядро. Это совсем другое дело. (Написано до того, как был добавлен второй абзац, что объясняет мою точку зрения) –
@MatsPetersson: OP не требует «связывания с библиотекой», нет требования выполнять задачу X таким образом, чтобы это не сработало; напротив, ОП запрашивает способы, которые действительно работают –
«Может ли 64-битная библиотека работать в 32-битном приложении?» Значит что? –
Да, но это большая неприятность.
Во-первых, ядро отличается от библиотеки. Как правило, библиотека становится видимой в виртуальном адресном пространстве вашего процесса; он разделяет адресное пространство с вашим собственным кодом. Вызов подпрограммы библиотеки - это просто вызов подпрограммы.
Напротив, для запроса услуг из ядра ваш процесс выполняет специальную инструкцию для создания ловушки. Эта ловушка заставляет процессор выполнять некоторые специальные функции, которые включают сохранение регистров вашего процесса и другого состояния в памяти (или в специальных регистрах процессора, к которым вы обычно не можете обращаться), изменение различных режимов в процессоре, чтобы сделать их пригодными для ядра, и изменяя счетчик программ, указывая на инструкции для ядра. Затем ядро запускается.На этом этапе ядро может работать в 64-битном режиме, пока ваш процесс работает в 32-битном режиме. Однако ядро предназначено для понимания этих различий. Когда ваше ядро проверяет ваш процесс, чтобы узнать, что вы запрашиваете, он ищет информацию и структуры данных, зная, что ваш процесс работает в 32-битном режиме. Ядро может поддерживать как 32-разрядные, так и 64-битные процессы, оно просто обрабатывает каждый тип процесса по-разному.
Это предполагает, конечно, что 64-битное ядро, которое вы используете, поддерживает 32-битные процессы.
Обычно, когда вы вызываете библиотеку, вы хотите, чтобы это был тот же режим, что и ваш код, потому что обычный вызов библиотеки - это просто вызов подпрограммы; он не генерирует ловушку и не меняет режимы процессора. Если возникла критическая необходимость вызывать процедуры в 64-битной библиотеке из 32-битного процесса, вы могли бы создать вспомогательный 64-битный процесс. Ваш 32-битный процесс завершит запрос на вызов библиотеки и отправит этот запрос в 64-разрядный вспомогательный процесс с помощью некоторой формы межпроцессного взаимодействия. Этот вспомогательный процесс вызовет библиотечную процедуру и отправит результаты назад.
Естественно, это добавляет значительные накладные расходы для каждого вызова библиотеки, поэтому это то, что вы хотите сделать, только если есть большая потребность и нет лучшей альтернативы.
+1 Я уверен, что даже если описание того, как происходит вызов ядра, является слишком конкретным (это типичная, но ни в коем случае единственная возможность) –
Я работаю над приложением, которое делает именно это. Ядро приложения x64 (и использует Qt), но оно должно связываться с некоторым оборудованием, для которого у меня есть только 32-битная библиотека от производителя. Способ, которым я это реализовал, - это наличие двух приложений на 64 бита для ядра и графического интерфейса и 32 бита, которые управляют оборудованием и взаимодействуют с основными приложениями, используя QSharedMemory. Оба приложения основаны на Qt (соответственно 64 и 32 бита).
Ядро представляет собой ядро 32/64 бит. Ядро не является библиотекой. – MSalters
Почему вы все сразу думаете о ядрах Linux и ОС? В «ядре» он может означать собственную библиотеку, которая является своего рода ядром в его приложении (да, это действительно немного плохо сформированный способ назвать это, но некоторые люди). Для объединения он имеет 32-битное приложение, которое содержит только графический интерфейс и отдельную 64-битную библиотеку с некоторой логикой. –
См. ... Я был прав, он просто неправильно использовал термин ... ':)' –