long - variable char c++
¿Pueden 32 y 64 bits trabajar juntos? (4)
En resumen: no puede vincular una aplicación de 32 bits a una biblioteca de 64 bits.
Puede ejecutar una aplicación de 32 bits, utilizando bibliotecas compartidas de 32 bits en un sistema operativo de 64 bits (al menos todos los procesadores populares de 32/64 bits como AMD, Intel y Sparc). Pero eso no implica ninguna biblioteca.
Respuesta más larga: participé (en las afueras) de algunos de los equipos que diseñaron el kernel de Linux de 64 bits para x86. Hubo brevemente (en comparación con todo el proyecto, las discusiones duraron unas cuantas horas) un poco de discusión sobre cómo técnicamente podría hacer que esto funcionara. El breve resumen de esto es que en 64 bits hay registros que no están disponibles en 32 bits. También existe el problema de las direcciones de memoria y los 32 bits adicionales en los registros. Todos estos PUEDEN resolverse suponiendo que la propia biblioteca "sabe" que es una biblioteca compatible de 32 bits. Pero básicamente tenemos una biblioteca de 64 bits que está escrita para ser una biblioteca de 32 bits, y hemos perdido el punto.
Es posible que los "más registros" no se apliquen a algunos procesadores, pero la mayor cantidad de registros / direcciones de bits se aplica definitivamente a TODOS los procesadores compatibles de 32 y 64 bits. Y no conozco ningún procesador único que permita un código de 32 bits que llame a una biblioteca compartida de 64 bits o biblioteca estática. Simplemente no funciona a menos que el código esté específicamente escrito para hacer frente a eso, lo que anula el propósito de tener una biblioteca genérica de 64 bits para admitir aplicaciones de 32 bits.
Editar:
Lo anterior trata sobre la vinculación de una unidad ejecutable, por ejemplo, un archivo ejecutable, una biblioteca compartida o una biblioteca estática. Eso tiene que ser todo "un bit", ya sea 32 o 64 - sin mezcla.
Cuando un proceso que habla con otro (por ejemplo, una aplicación GUI que muestra el estado de un proceso que no es GUI), siempre y cuando los dos procesos utilicen el mismo protocolo [y, por lo general, IPC no permite el paso de punteros de todos modos, por lo que La conversión de 32/64 bits no es un problema tan grande], puede tener un proceso que sea de 32 bits y otro que sea de 64 bits.
¿Puede funcionar la biblioteca de 64 bits en una aplicación de 32 bits? Por ejemplo, mi aplicación GUI utiliza 32 bit Qt. Y mi núcleo de negocios es una biblioteca de 64 bits. El sistema operativo es de 64 bits. ¿Pueden trabajar juntos y cómo? Gracias.
Estoy trabajando en una aplicación que hace exactamente esto. El núcleo de la aplicación es x64 (y usa Qt), pero tiene que comunicarse con algunos equipos, para los cuales solo tengo una biblioteca de 32 bits del fabricante. La forma en que lo implementé es tener dos aplicaciones de 64 bits para el núcleo y la GUI, y 32 bits que controla el equipo y se comunica con las aplicaciones principales mediante QSharedMemory. Ambas aplicaciones se basan en Qt (64 y 32 bits en consecuencia).
Sí, pero es una gran molestia.
Primero, un kernel es diferente de una biblioteca. Normalmente, una biblioteca se hace visible en el espacio de direcciones virtuales de su proceso; comparte el espacio de direcciones con tu propio código. Llamar a una rutina de biblioteca es simplemente una llamada de subrutina.
Por el contrario, para solicitar servicios del kernel, su proceso ejecuta una instrucción especial para generar una trampa. Esta captura hace que el procesador haga algunas cosas especiales que incluyen guardar los registros de su proceso y otros estados en la memoria (o en los registros especiales del procesador a los que normalmente no puede acceder), cambiando varios modos en el procesador para que sean adecuados para el núcleo, y cambiando el contador del programa para que apunte a instrucciones para el kernel. Entonces el kernel se está ejecutando. En este punto, el kernel podría estar ejecutándose en modo de 64 bits mientras su proceso se estaba ejecutando en modo de 32 bits. Sin embargo, el núcleo está diseñado para ser consciente de estas diferencias. Cuando su kernel inspecciona su proceso para ver lo que está solicitando, busca información y estructuras de datos a sabiendas de que su proceso se estaba ejecutando en un modo de 32 bits. Un kernel puede soportar procesos de 32 y 64 bits, simplemente trata cada tipo de proceso de manera diferente.
Esto supone, por supuesto, que el kernel de 64 bits que está utilizando admite procesos de 32 bits.
Normalmente, cuando llama a una biblioteca, quiere que sea el mismo modo que su código, porque una llamada de biblioteca normal es solo una llamada de subrutina; no genera una trampa y no cambia los modos del procesador. Si hubiera una necesidad crítica de llamar rutinas en una biblioteca de 64 bits desde un proceso de 32 bits, entonces podría crear un proceso de ayuda de 64 bits. Su proceso de 32 bits empaquetaría una solicitud de una llamada a la biblioteca y enviaría esa solicitud al proceso auxiliar de 64 bits mediante algún tipo de comunicación entre procesos. Ese proceso de ayuda llamaría a la rutina de la biblioteca y devolvería los resultados.
Naturalmente, esto agrega una sobrecarga significativa a cada llamada de la biblioteca, por lo que es algo que desea hacer solo si hay una gran necesidad y no hay una mejor alternativa.
Si ejecuta Windows, su aplicación compilada para 32b puede ejecutarse en un sistema host Windows 64b: observe el subsistema WOW64 integrado en Windows 64b.
Dicho esto, no puede mezclar código compilado para 32b con código compilado para 64b. Lo que significa que una biblioteca que fue construida para 32b no puede vincularse con el código de 64b, y viceversa. (Diferentes convenciones de llamadas, diseño de cuadros de pila, exceptuando el desenrollado, ...)