Может 32 бит и 64 бит работать вместе?

Ответ 1

Вкратце: вы не можете связать 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-разрядные приложения.

Edit:

В приведенном выше обсуждении связывается одна исполняемая единица, например. исполняемый файл, общую библиотеку или статическую библиотеку. Это должно быть "одно битовое", либо 32, либо 64 - без смешивания.

Когда процесс, который ведет переговоры с другим процессом (например, графическое приложение, которое отображает статус из процесса, отличного от GUI), если два процесса используют один и тот же протокол [и, как правило, IPC не разрешает передачу указателей во всяком случае, поэтому 32-/64-битное преобразование не так уж и важно], у вас может быть один 32-разрядный процесс, а другой - 64-разрядный.

Ответ 2

Да, но это большая неприятность.

Во-первых, ядро ​​отличается от библиотеки. Как правило, библиотека становится видимой в вашем виртуальном адресном пространстве процесса; он разделяет адресное пространство с вашим собственным кодом. Вызов подпрограммы библиотеки - это просто вызов подпрограммы.

В отличие от этого, чтобы запрашивать службы из ядра, ваш процесс выполняет специальную инструкцию для создания ловушки. Эта ловушка заставляет процессор выполнять некоторые специальные функции, которые включают сохранение регистров процесса и другого состояния в памяти (или в специальных регистрах процессора, к которым вы обычно не можете обращаться), изменение различных режимов в процессоре, чтобы сделать их пригодными для ядра, и изменение счетчик программ указывает на инструкции для ядра. Затем ядро ​​запускается. На этом этапе ядро ​​может работать в 64-битном режиме, пока ваш процесс работает в 32-битном режиме. Однако ядро ​​предназначено для понимания этих различий. Когда ваше ядро ​​проверяет ваш процесс, чтобы узнать, что вы запрашиваете, он ищет информацию и структуры данных, зная, что ваш процесс работает в 32-битном режиме. Ядро может поддерживать как 32-разрядные, так и 64-битные процессы, оно просто обрабатывает каждый тип процесса по-разному.

Это предполагает, конечно, что используемое 64-битное ядро ​​поддерживает 32-битные процессы.

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

Естественно, это добавляет значительные накладные расходы для каждого вызова библиотеки, поэтому это то, что вы хотите сделать, только если есть большая потребность и нет лучшей альтернативы.

Ответ 3

Если вы запустите Windows, ваше приложение, скомпилированное для 32b, может работать в хост-системе Windows 64b: посмотрите под WOW64 который встроен в 64b Windows.

Сказав это, вы не можете смешивать код, скомпилированный для 32b, с кодом, скомпилированным для 64b. Значение библиотеки, которая была построена для 32b, не может быть связана с кодом 64b и наоборот. (Различные соглашения о вызовах, компоновка фреймов стека, кроме разматывания,...)

Ответ 4

Я работаю над приложением, которое делает именно это. Ядро приложения x64 (и использует Qt), но оно должно связываться с некоторым оборудованием, для которого у меня есть только 32-битная библиотека от производителя. Способ, которым я это реализовал, - это наличие двух приложений на 64 бита для ядра и графического интерфейса и 32 бита, которые управляют оборудованием и взаимодействуют с основными приложениями, используя QSharedMemory. Оба приложения основаны на Qt (соответственно 64 и 32 бита).