Sé que en una versión de Windows de 64 bits, la carpeta "Archivos de programa" es para programas de 64 bits y la carpeta "Archivos de programa (x86)" es para programas de 32 bits, pero ¿por qué es esto necesario?
Por "necesario", no quiero decir "¿por qué Microsoft no pudo haber tomado ninguna otra decisión de diseño?" porque por supuesto que podrían haberlo hecho. Más bien, quiero decir, "¿por qué, dado el diseño actual de Windows de 64 bits, los programas de 32 bits deben tener una carpeta de nivel superior separada de los programas de 64 bits?" Dicho de otra manera, "¿qué saldría mal si de alguna manera evitara el mecanismo de redireccionamiento y obligara a todo a instalarse en la realidad C:\Program Files\?
Hay muchas preguntas sobre Superusuario y en otros lugares que afirman que "una es para programas de 32 bits, otra para programas de 64 bits", pero ninguna que pueda encontrar da la razón. Desde mi experiencia, no parece importar si un programa de 32 bits está instalado en el lugar correcto o no.
¿Windows se presenta de alguna manera diferente a un programa que se está quedando sin "Archivos de programa (x86)"? ¿Existe una descripción que muestre exactamente qué es diferente para un programa instalado en "Archivos de programa (x86)" en lugar de "Archivos de programa"? Creo que es poco probable que Microsoft introduzca una nueva carpeta sin una razón técnica legítima.
Respuestas:
Respuesta corta: para garantizar que las aplicaciones heredadas de 32 bits continúen funcionando de la misma manera que antes, sin imponer reglas feas en las aplicaciones de 64 bits que crearían un desastre permanente.
No es necesario. Es más conveniente que otras soluciones posibles, como requerir que cada aplicación cree su propia forma de separar las DLL y los ejecutables de 32 bits de las DLL y los ejecutables de 64 bits.
La razón principal es hacer que las aplicaciones de 32 bits que ni siquiera saben que los sistemas de 64 bits existan "simplemente funcionen", incluso si las DLL de 64 bits están instaladas en lugares donde las aplicaciones podrían verse. Una aplicación de 32 bits no podrá cargar una DLL de 64 bits, por lo que se necesitaba un método para garantizar que una aplicación de 32 bits (que podría ser anterior a los sistemas de 64 bits y, por lo tanto, no tenga idea de archivos de 64 bits incluso existe) no encontraría una DLL de 64 bits, intentaría cargarla, fallaría y luego generaría un mensaje de error.
La solución más simple para esto es consistentemente separar directorios. Realmente, la única alternativa es requerir que cada aplicación de 64 bits "oculte" sus archivos ejecutables en algún lugar donde una aplicación de 32 bits no se vería, como un
bin64directorio dentro de esa aplicación. Pero eso impondría una fealdad permanente en los sistemas de 64 bits solo para admitir aplicaciones heredadas.fuente
ProgramFiles (16)algo así. Además, ¿cómo exactamente un programa de 32 bits "encontraría un archivo DLL de 64 bits e intentaría cargarlo"? ¿En qué programas se busca la búsqueda de archivos DLL aleatorios%programfiles%? Si es una DLL compartida, entonces va en WinSxS; si no se comparte, entonces depende del programador administrar sus propios archivos DLL. Sin embargo, la parte de que se haga como una conveniencia para los programadores es razonable.Le permite instalar tanto la versión de 32 bits como la de 64 bits de una aplicación sin sobrescribirla.
Después de mirar esta respuesta y el hilo de comentarios al día siguiente, me doy cuenta de un posible descuido importante en mi respuesta. Asumí falsamente un fondo de programación y cuando estaba hablando de ti en mis comentarios, no me refería al usuario, sino al programador.
No trabajo para Microsoft y no tengo idea de cuál es el verdadero razonamiento detrás de estas carpetas, pero creo que la razón para tener estas carpetas es tan obvia que no tengo problemas para discutirlo.
¡Así que vamos a desglosarlo!
¡Las carpetas son increíbles!
Acordemos algo. ¡Las carpetas son geniales! No los necesitamos, tenemos suficientes nombres de archivo posibles para colocar cada archivo en la raíz de su disco duro, entonces, ¿por qué tener carpetas?
Bueno, nos ayudan a ordenar nuestras cosas. Y ordenar cosas es genial. Nos ayuda a procesar las cosas más fácilmente. Esto es especialmente útil cuando se trabaja con una máquina que requiere estructura.
¡Separar datos y lógica es genial!
Un paradigma que a menudo se encuentra en la programación es separar los datos de la lógica. ¿Quieres una parte que sabe cómo hacer algo y quiere otra parte que se puede hacer algo con el .
Esto también se encuentra en el sistema de archivos.
Tenemos carpetas para la aplicación (lógica) y carpetas para nuestros objetos de valor (datos):
Lógica
%WINDIR%%PROGRAMFILES%%PROGRAMFILES(x86)%Datos
%PROGRAMDATA%%HOMEDRIVE%%HOMEPATH%Entonces, parece que las carpetas son increíbles y tiene sentido poner programas en su propia carpeta. ¿Pero por qué tener 2? ¿Por qué no dejar que el instalador maneje eso y ponga todo en una
Programscarpeta?Los instaladores no son mágicos
Hoy, a menudo utilizamos pequeños programas para instalar nuestros programas más grandes. Llamamos a estos pequeños programas instaladores .
Los instaladores no son mágicos. Deben ser escritos por programadores y son aplicaciones (con posibles errores) como cualquier otra aplicación existente. Así que veamos la situación que un programador imaginario tendría que enfrentar con y sin el sistema actual:
1 carpeta de archivos de programa
El desarrollador mantiene 2 instaladores. Uno para la versión de 32 bits y otro para la versión de 64 bits de su aplicación. El instalador de 32 bits escribirá
C:\Program Files\App\y el instalador de 64 bits escribiráC:\Program Files\App\sixtyfour\.2 carpetas de archivos de programa
El desarrollador mantiene 1 instalador. El instalador siempre escribirá
%PROGRAMFILES%y dependerá del sistema operativo para expandir la ruta en consecuencia (en realidad no usa variables de entorno para estos casos, usaría SHGetKnownFolderPath conFOLDERID_ProgramFilespara recuperar la ruta correcta).Todo encuentra su lugar automáticamente y el patrón es idéntico con cada aplicación que instala .
La consistencia tiene sentido
Cuando aprendes algo, eso generalmente implica que un comportamiento observado fue consistente. De lo contrario, realmente no hay nada que observar y aprender.
Lo mismo es cierto para nuestro pequeño sistema de archivos. Tiene sentido poner siempre las mismas cosas en las mismas carpetas. De esa manera, sabremos dónde buscar cuando busquemos algo.
El sistema para la distinción de aplicación 32/64 promueve este objetivo. Las aplicaciones se separan en 2 ubicaciones para evitar conflictos en los nombres, el comportamiento de carga binaria y la seguridad (en cierta medida).
Aún no lo entiendo. Esto parece inútil.
Nunca debes olvidar una cosa. La gente es increíblemente estúpida. Esto incluye usuarios, superusuarios y especialmente programadores.
Es por eso que necesitamos cosas como la redirección del sistema de archivos para incluso hacer que nuestros sistemas sean utilizables.
Los programadores simplemente irán allí e intentarán cargar
C:\Windows\system32\awesome.dlly no les importará si se ejecutan en un sistema de 32 o 64 bits. Intentarían cargar la DLL de 64 bits y simplemente fallarían. Algunos programadores quieren usar alguna DLL de Office, no hay problema, ¡saben dónde encontrarla!C:\Program Files\Microsoft\Office\14.0\wizards.dll... y otro choque!Todas estas solicitudes de la aplicación de 32 bits se redirigen a las contrapartes de 32 bits para evitar bloqueos de la aplicación.
Necesitamos algunos nombres de carpetas fijos para construir dicho sistema. Si no hay una estructura de carpetas que admita esta redirección, ¿cómo va a hacer que funcione?
Bien, ahora lo entiendo. ¿Pero por qué no usar
C:\Program Files\x86\entonces?Ahora nos estamos volviendo filosóficos ...
¿Qué saldría mal si de alguna manera evitara el mecanismo de redireccionamiento y obligara a todo a instalarse en la realidad
C:\Program Files\?Lo más probable es que nada (siempre y cuando otras aplicaciones no dependan de una ubicación fija para esa aplicación).
El mecanismo WOW64 se conecta
CreateProcessy realizará comprobaciones más sofisticadas (más sofisticadas que verificar el nombre de la carpeta del ejecutable) en la imagen ejecutable para determinar si es de 32 o 64 bits.Sí, pero quiero decir, ¡TODAS las aplicaciones!
Algunas preguntas no requieren respuestas. No está destinado a hacerse, no lo hagas. No hay nada que ganar aquí. La cantidad de problemas que tal cambio podría causar siempre superará cualquier beneficio posible que alguien pueda ver en esto.
fuente
C:\Program Files\App32yC:\Program Files\App64?SHGetSpecialFolderPathpara determinar la ubicación de instalación.%PROGRAMFILES%en primer lugar? ¿Por qué no poner la versión de 32 bits en el escritorio del usuario y la de 64 bits en la Papelera de reciclaje? El hecho de que se pueda hacer no significa que sea una buena idea. Lo siento, no sigo tu razonamiento.TL; DR:
Para resumir, no, no es necesario ; que podrían haber utilizado una sola carpeta, y no, de Windows no se presenta de manera diferente a un programa que se ejecute de un lugar u otro.
Bueno, todo el mundo parece estar dando sus opiniones sobre esto, así que arrojaré mis 2 ¢. Otros ya han conjeturado sobre las razones por las cuales Microsoft eligió crear carpetas de nivel superior separadas para las versiones de programas de 32 bits y 64 bits, por lo que dejaré esa parte (la mejor razón fue la explicación de David de que es como un conveniencia para programadores). Por supuesto, incluso entonces, no aborda la pregunta directa ¿ por qué es esto necesario? , a lo que la respuesta es presumiblemente: no lo es .
En cambio, abordaré el cuerpo principal de la pregunta
En realidad no, pero la ubicación del programa puede afectar el comportamiento, pero no en la forma en que pensarías.
Cuando ejecuta un programa, Windows configura un entorno en el que ejecutarlo (es decir, en términos de memoria, direccionamiento, etc., no solo variables de entorno). Este entorno depende del contenido del ejecutable (los programas de 32 y 64 bits difieren internamente). Cuando ejecuta un programa de 32 bits en un sistema de 64 bits, se ejecuta en el subsistema de 32 bits que emula un entorno de 32 bits. Se llama WoW64 (WoW64 significa Windows en Windows de 64 bits ) y es similar a cómo se ejecutarían las aplicaciones de 16 bits en XP utilizando el NTVDM .
Cuando ejecuta un programa con o sin privilegios de administrador, afecta cómo se ejecuta, pero la ubicación no debería afectarlo (aunque hay algunos ejemplos de dependencia de la ubicación, como algunos controladores, por ejemplo).
(Estoy usando una computadora diferente, por lo que no puedo confiar en el historial de mi navegador para dar marcha atrás a mis pasos, pero el otro día, mientras respondía esta pregunta SU , terminé en esta pregunta SO que me llevó a Google PROCESSOR_ARCHITEW6432 que me llevó a esta pregunta SO y esta publicación de blog de Microsoft ).
En algún momento, leí una publicación de StackOverflow sobre cómo la variable de entorno
%processor_architecutre%da resultados diferentes dependiendo de dónde ejecute el símbolo del sistema (intentaré encontrar la cita exacta).La respuesta se debió a si se ejecutó la versión de 32 bits o de 64 bits del símbolo del sistema (es decir, desde
System32\oSysWoW64\). En otras palabras, aunque la ubicación parece afectar el comportamiento del programa, es solo porque hay diferentes versiones del programa, no porque Windows trata la carpeta de una manera especial.Esto tiene sentido porque el contenido del archivo ejecutable dicta si es de 32 bits o de 64 bits, por lo que puede colocar una copia de 32 bits y de 64 bits del mismo programa (por ejemplo,
foobar32.exeyfoobar64.exe) en la misma carpeta y cuando ejecútelos, se cargarán correctamente (la versión de 64 bits se ejecutará de forma nativa y la de 32 bits se ejecutará en la capa de emulación WoW64).FreePascal le permite instalar las versiones DOS y Windows y van en la misma carpeta:
%programfiles%\FreePascal. Gestiona los diferentes arquitecturas, manteniendo los archivos ejecutables (.exe,.sys,.dll,.ovr, etc.) en carpetas separadas y compartir archivos de recursos como imágenes, archivos de código-, etc.) No hay razón técnica que esto no podría también ser hecho por 32 y Versiones de 64 bits de un programa. Como dijo David, es más fácil para el programador si se mantienen separados (es decir, utilizando variables para que parezca que solo hay un conjunto de archivos, etc.)fuente
Otra razón es que la mayoría de los programas solían usar variables ambientales como% PROGRAMFILES% para señalar dónde se instaló su programa. Para programas de 64 bits, va al lugar normal. Para programas de 32 bits, redirigirá eso a la nueva
Program Files (x86)carpeta.Aunque, al menos con las nuevas cosas .Net en Visual Studio, ahora tienen la variable App.Local que elimina toda la necesidad de esto.
fuente
%programfiles%,%programfiles(x86)%o%programw6432%hacer una diferencia allí? Todas las DLL compartidas van al directorio único de WinSxS, y cualquier DLL no compartida está ahí con el ejecutable. Esto solo importaría si por alguna razón tiene instaladas las versiones de 32 bits y 64 bits del mismo programa, e incluso entonces, mantendría las DLL de 32 bits con el ejecutable de 32 bits y la DLL de 64 bits con El ejecutable de 64 bits. Puede hacer esto así:%programfiles%\CoolApp\bin\32y% programfiles% \ CoolApp \ bin \ 64`, ¿por qué las carpetas separadas de nivel superior?Fuente
"¿Qué saldría mal si de alguna manera evitara el mecanismo de redireccionamiento y obligara a todo a instalarse en el verdadero C: \ Archivos de programa \?"
Nada. Los dos directorios de programas son solo para la organización o para mantener separados los programas que tienen dos versiones, una versión de 32 bits y una de 64 bits, como Internet Explorer. Pero puede instalar un programa de 32 bits en "Archivos de programa" y un programa de 64 bits en "Archivos de programa x86" y no pasará nada, el programa se ejecutará igual.
Wiki dice:
fuente
La razón es hacer que la actualización de un programa a 64 bits sea más fácil para los desarrolladores. No tienen que escribir ningún código personalizado para verificar el programa en un directorio cuando compilan en modo de 32 bits y en otro directorio cuando compilan en modo de 64 bits; simplemente verifican
C:\Program Files, y cuando se ejecuta en modo de 32 bits,C:\Program Files (x86)Windows cambia automáticamente a 64 bits. Del mismo modo, las entradas del registro están aisladas entre los programas de 32 bits y 64 bits.Esto evita conflictos de desarrolladores desconocidos que simplemente cambian su modo de compilación a 64 bits sin pensarlo demasiado, y evita una enorme cantidad de trabajo para los desarrolladores que desean que los usuarios puedan instalar versiones de 32 y 64 bits de sus software al mismo tiempo.
Pero, ¿por qué algún programa querría permitir que ambas versiones se instalen simultáneamente? Un ejemplo: Photoshop e IE tienen extensiones que son .dll nativas. No puede tener código de 32 y 64 bits mezclado en el mismo proceso, por lo que un complemento para la versión de 32 bits no se puede usar con la versión de 64 bits, y viceversa. De este modo, Photoshop / IE tiene para permitir que las dos versiones que se instalarán, o el riesgo de romper su enorme base de complementos existentes.
fuente
Los programas que se ejecutan en "Archivos de programa (x86)" usan el subsistema WOW64 (Windows de 32 bits en Windows de 64 bits es un conjunto de controladores y API destinados a ejecutar aplicaciones x32 en un sistema de arquitectura x64):
El sistema de 64 bits necesita "emular" aplicaciones de 32 bits, esa es la razón por la cual Windows necesita "segregar" dos carpetas de archivos de programa.
fuente
Es interesante que las respuestas aquí y en Internet varíen bastante. Encontrar una respuesta precisa a esta importante pregunta ha sido un desafío. Parece que hay bastante información falsa presentada en Internet, lo que genera confusión.
He realizado una gran cantidad de investigación y he llegado a la siguiente conclusión, que creo que es precisa:
Esto sucede automáticamente y es independiente del lugar donde se almacena la aplicación. No hay velocidad, confiabilidad u otro beneficio funcional al tener carpetas separadas de 32 bits y 64 bits.
La única razón para la separación predeterminada en dos carpetas ('Archivos de programa' y 'Archivos de programa (x86)') es que si tiene dos versiones del mismo programa (una versión de 32 bits y una de 64 bits), proporciona un Una forma sencilla de mantener separados los archivos superpuestos. Incluso en este caso, siempre que todos los nombres de archivo sean únicos, podrían existir en la misma carpeta sin ninguna consecuencia.
Hay una advertencia a la conclusión anterior, y esa es la de aplicaciones mal codificadas. Si una aplicación tiene alguna ruta codificada, solo la usará. Como regla general, las rutas nunca deben codificarse en una aplicación, pero ocasionalmente un programador cometerá este error. En este caso, el programa usará la ruta codificada; el directorio en el que está instalada la aplicación no afectará dónde realmente busca archivos.
fuente
Tener que separar carpetas hace posible mantener separadas las aplicaciones nativas de 64 bits y las que requieren el WoW64 .
Esto puede ser útil, como ya señaló @OliverSalzburg , si desea instalar tanto el navegador web de 64 bits como el de 32 bits (por ejemplo), ya que algunos complementos y complementos solo pueden estar disponibles para uno de los dos.
Tener que separar las carpetas hace que esta separación sea automática , utilizando técnicas como la redirección del registro .
Suponga que un instalador intenta determinar la carpeta de archivos del programa leyendo el registro utilizando, por ejemplo, RegQueryValueEx .
En cualquier caso, intenta leer la clave de registro
que normalmente apunta a
C:\Program Files.Sin embargo, si el instalador es una aplicación de 32 bits, la redirección del registro provocará la clave de registro
para ser leído en su lugar, que normalmente apunta a
C:\Program Files (x86).Las personas que tomaron esta decisión solo pueden responder por qué se han utilizado estos nombres de carpetas particulares . Siempre puede cambiar los nombres de las carpetas predeterminadas si lo desea.
Lo dudo. La mayoría de los instaladores le permiten elegir una carpeta de instalación personalizada, por lo que realmente no importa dónde se instale un programa.
fuente
No puedo creer la confusión aquí ... en primer lugar, soy un desarrollador a tiempo completo.
MS hizo esto para resolver el caso en el que las aplicaciones antiguas de 32 bits y las nuevas aplicaciones de 64 bits usan una DLL. No se pudo cambiar el método anterior (System32, Archivos de programa, etc.) porque eso rompería los programas más antiguos que no se pueden volver a compilar.
Por lo tanto, MS creó una carpeta para almacenar programas, ensamblajes y bibliotecas específicos de 64 bits para que los nuevos programas pudieran vincularse a las bibliotecas adecuadas, y los programas más antiguos continuarían funcionando normalmente.
Tal como está, las DLL .Net pueden coexistir con otras versiones en la misma máquina. Por ejemplo, puede tener Library.1.0.1, Library.1.0.2, Library 1.1.0, etc. Y esto es solo para un tamaño de bit específico (32 o 64). Si no se utilizan carpetas separadas, cada ensamblaje debe tener una versión de 32 y 64 bits. Esto abarrotaría severamente un directorio que ya contiene múltiples versiones del mismo ensamblado.
Todo esto es para desarrolladores. Como usuario, solo tengo que lidiar con eso cuando estoy trabajando con un programa de 32 bits en Windows 7 64. Y prefiero tener la capacidad de ejecutar una versión de 32 bits y la misma aplicación también en 64 bits. Cuando estoy trabajando en una aplicación de 32 bits que necesito compilar en 64 bits, todo lo que hago es decirle al compilador que lo haga. Los nombres de dll y todo lo demás permanece igual.
La razón por la que esto no existía con Windows 95/98 es que esos sistemas simularon un tiempo de ejecución de 32 bits; No era un sistema operativo genuino de 32 bits. Fingió la ejecución de 32 bits con algo llamado "thunking".
Aquí hay una buena definición: http://searchwinit.techtarget.com/definition/thunk
fuente
ProgramFiles(x86)` avoid clutter? There are still both 32- and 64-bit versions of files, so avoiding clutter doesn't make sense. There is no difference between putting them in\ 32 \ blah` o\blah\32; De cualquier manera, están separados. En todo caso, la forma actual separa los componentes de la aplicación (y también los duplica innecesariamente, ya que pocas aplicaciones usan losCommonFilesrecursos y demás). Además, hace que parezca que las aplicaciones están volcando sus archivos DLL en un cubo común. Es bastante fácil mantener una aplicación. DLL de 32 bits con sus ex de 32 bits y sus DLL de 64 bits con susNo es necesario en absoluto. Por ejemplo, en mi computadora en funcionamiento, instalo cada aplicación en una carpeta
C:\MyPrograms\para separarlas de las aplicaciones instaladas por nuestro departamento de TI.Por supuesto, esto me impide instalar ambas versiones (32 y 64 bits) de una aplicación, pero esto no es un problema en mi caso.
Cada vez que inicia un programa, siempre
C:\Windows\System32\ntdll.dllse ejecuta la primera DLL . Esta DLL determina si su programa es una aplicación de 32 o 64 bits. Dependiendo de eso, se lo redirige a loWoW64que ya se menciona en varias respuestas.fuente