¿Por qué Windows de 64 bits necesita una carpeta separada "Archivos de programa (x86)"?


178

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.


13
En lugar de responder a su pregunta, le preguntaría: ¿cómo manejaría \ archivos de programa \ archivos comunes?
sgmoore

8
Respuesta única (y, por lo tanto, un comentario): dado que puede ejecutar fácilmente cualquier aplicación desde cualquier carpeta sin conocer su arquitectura, entonces claramente no hay una razón obligatoria para esta separación. Es una cuestión de conveniencia admitir instalaciones dobles de aplicaciones con ambas arquitecturas . En algunos casos hace la diferencia ya que no son necesariamente simples recompilaciones. El principal problema es que las aplicaciones de 32 bits no pueden cargar dlls de 64 bits, por lo que normalmente no puede instalar ambas versiones en el mismo lugar. La otra alternativa es tener dos carpetas "bin" para cada aplicación.
Sklivvz

1
@Synetech Incluso tuve programas de instalación bajo (x86) solo para tener binarios x64 ... A veces es horrible.
sinni800

10
Siempre me he preguntado por qué Microsoft no puso programas de 64 bits en un "Archivos de programa (x64)" en lugar de * mover "el directorio" heredado "de Archivos de programa a Archivos de programa (x86)
LawrenceC

30
El verdadero desastre sobre la diferenciación de 64/32 bits es que / Windows / System32 contiene contenido de 64 bits, mientras que / Windows / SysWOW64 contiene las cosas de 32 bits ...
toque

Respuestas:


92

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.


52
No tuvieron que saltar a través de estos aros para permitir programas de 32 bits y 16 bits en el mismo sistema. No recuerdo haber visto alguna vez 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.
Synetech

30
IIRC Win3.1 no tenía un directorio de archivos de programa (o la mayoría de las aplicaciones lo ignoraron); Como resultado, no habría ninguna aplicación win16 heredada que buscara cosas en los archivos de programa para empezar. En cambio, las bibliotecas compartidas del IIRC a menudo se ubicaron en algún lugar de la carpeta de Windows. Win32 tener windows \ system y windows \ system32 es un artefacto de eso.
Dan Neely

15
Windows 3.1 no admitía nombres de archivo largos, por lo que no habría podido tener una carpeta de 'archivos de programa'.
Darth Egregious

14
@JarrodRoberson: todo lo contrario, es porque Microsoft valora la compatibilidad con versiones anteriores extremadamente alta.
David Schwartz

24
@Jarrod: En realidad, como todos los desarrolladores saben, Microsoft valora demasiado la compatibilidad con versiones anteriores . Literalmente, cada API que tienen tiene métodos heredados que se niegan a eliminar y, a menudo, errores serios que se niegan a corregir, porque temen romper los programas más antiguos que se escribieron para esa API. Lo mismo es cierto para la mayoría de las API, pero no para cualquier lugar cercano al existente de Microsoft.
BlueRaja - Danny Pflughoeft

65

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!

  1. ¡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.

  2. ¡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?

  3. 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 con FOLDERID_ProgramFilespara recuperar la ruta correcta).
    Todo encuentra su lugar automáticamente y el patrón es idéntico con cada aplicación que instala .

  4. 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!

  • ¿Qué pasaría si pongo tanto el diesel y el gas en mi coche?
  • ¿Qué pasaría si trato de usar tanto corriente alterna y continua en la misma línea?
  • ¿Qué pasaría si sigo tanto mi gato y mi pescado en el mismo acuario?

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.


3
¿Es esa la razón original, sin embargo? ¿No podría simplemente instalar la aplicación en C:\Program Files\App32y C:\Program Files\App64?
Stephen Jennings

44
@StephenJennings: Pero eso requeriría que tomes la decisión manualmente. La forma en que ahora funciona es que el proceso es automático, porque Windows sabe qué carpeta proporcionar cuando una aplicación llama SHGetSpecialFolderPathpara determinar la ubicación de instalación.
Der Hochstapler

66
@Synetech: ¿Por qué instalar %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.
Der Hochstapler

44
@Synetech: Sí, dio un buen ejemplo de cómo podría hacerse. Otro ejemplo perfectamente bueno de cómo se podría hacer es la forma en que se está haciendo en este momento. Simplemente escribir un archivo en% PROGRAMFILES% y estar seguro de que terminará en la carpeta correcta es una cosa. Comprobar por ti mismo qué carpeta es la correcta es otra. Si realmente no ve el beneficio del enfoque anterior, entonces no podré convencerlo. La pregunta era por qué hay 2 carpetas. Creo que mi respuesta es perfectamente razonable en ese sentido.
Der Hochstapler

3
@OliverSalzburg, no del todo. La pregunta es ¿por qué son dos carpetas requeridas , no hay por qué son . De hecho, incluso lo en negrita: ¿por qué es esto necesario? No explicaste por qué es necesario y el ejemplo que di (e incluso tu propio ejemplo sarcástico) solo muestra que no tiene que hacerse de la manera que es.
Synetech

14

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

¿Windows se presenta de alguna manera diferente a un programa que se está quedando sin "Archivos de programa (x86)"?

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\o SysWoW64\). 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.exey foobar64.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.)


¡Venganza por la votación negativa! Muahahaha! suspiro
Synetech

Down-vote extraño: \. Por cierto, explique +1.
avirk

11

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.


44
Eso no lo explica. ¿Quién está usando exactamente la variable de entorno y por qué le importaría si un programa es de 32 o 64 bits?
Synetech

44
@Synetech: el autor de los programas utiliza la variable de entorno. En cuanto a la razón por la que le importaría es por las referencias a dlls. No puede cargar una dll de 32 bits dentro de un proceso de 64 bits y viceversa.
Ramhound

1
Y cómo hacerlo %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?
Synetech

@Synetech Claro que sí; % programfiles% ha estado alrededor por un tiempo. Si instala un programa de 32 bits en una computadora de 64 bits, tener un lugar podría causar problemas para esa aplicación de 32 bits. Sin embargo, WoW puede redirigir% programfile% a la versión (x86) para aplicaciones de 32 bits, y la versión que no es x86 para 64.
Andy

Creo que la gente no estaría tan confundida si no hubiera una redirección implícita
kommradHomer

8

La solución de Microsoft para esta transición de 32 bits a 64 bits ha sido agregar soporte heredado para la mayoría de las aplicaciones de 32 bits. En otras palabras, la mayoría de las aplicaciones de 32 bits funcionarán en el entorno operativo de 64 bits. Tenga en cuenta que otros sistemas operativos que operan en una arquitectura de 64 bits no pueden cargar o ejecutar aplicaciones de 32 bits.

Para ayudar a facilitar la transición, Microsoft ha designado que todas las aplicaciones de 32 bits se carguen de manera predeterminada en la carpeta Archivos de programa (x86) en lugar de mezclarse con las aplicaciones verdaderas de 64 bits en la carpeta de Archivos de programa normal.

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:

Algunos instaladores de aplicaciones rechazan espacios dentro de la ubicación de la ruta de instalación. Para sistemas de 32 bits, el nombre corto para la carpeta Archivos de programa es Progra ~ 1 . Para sistemas de 64 bits, el nombre corto para la carpeta Archivos de programa de 64 bits es Progra ~ 1 (igual que en los sistemas de 32 bits); mientras que el nombre corto para la carpeta Archivos de programa de 32 bits (x86) ahora es Progra ~ 2 .


1
Jeje. Buen articulo. Los comentarios a ese artículo suenan exactamente como los de aquí. Peor aún, ese artículo fue de hace más de dos años, lo que demuestra que esta pregunta no es nueva y si aún no puede ser respondida con autoridad, entonces supongo que nunca lo hará (a menos que alguien del equipo de Windows intervenga). Bueno, supongo que todos deberíamos dejar de preocuparnos y aprender a amar la bomba, quiero decir, vivir con ella. +1 Por señalar el artículo y mostrar que esta pregunta había existido durante tanto tiempo.
Synetech

1
@Synetech gracias! Sí, la idea detrás de poner el enlace del artículo es la misma que tienes. Esta es una pregunta muy antigua pero IDK por la que la gente aún no puede obtenerla. Sin embargo, la MS debería escribir una KB o documentación para este problema :)
avirk

Sí, deberían hacerlo, especialmente porque no solo los desarrolladores preguntan, incluso los usuarios normales se preguntan. Lamentablemente, la documentación de Microsoft no suele ser demasiado buena.
Synetech

@Synetech sí! La documentación de MS es una mierda la mayor parte del tiempo. Pero sí, también han escrito algunos buenos artículos y estoy bastante seguro de que son contables;)
avirk

6

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.


2
+1 Al menos abordó la pregunta subyacente de por qué los usuarios promedio tendrían ambas versiones.
Synetech

5

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 subsistema WoW64 comprende una capa de compatibilidad ligera que tiene interfaces similares en todas las versiones de Windows de 64 bits. Su objetivo es crear un entorno de 32 bits que proporcione las interfaces necesarias para ejecutar aplicaciones de Windows de 32 bits no modificadas en un sistema de 64 bits. Técnicamente, WoW64 se implementa utilizando tres bibliotecas de enlaces dinámicos (DLL):

  • Wow64.dll, la interfaz principal del núcleo de Windows NT que se traduce entre llamadas de 32 bits y 64 bits, incluidas las manipulaciones de puntero y pila de llamadas
  • Wow64win.dll, que proporciona los puntos de entrada apropiados para aplicaciones de 32 bits
  • Wow64cpu.dll, que se encarga de cambiar el procesador del modo de 32 bits al modo de 64 bits

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.


77
Pero, ¿por qué tiene que ponerlo en diferentes carpetas? Windows ya es totalmente capaz de determinar la arquitectura de un ejecutable mirando el encabezado PE. ¿Por qué no puede cargar el entorno apropiado cuando carga el ejecutable?
Synetech

1
Creo que es solo una elección de Microsoft mostrar fácilmente a los usuarios qué arquitectura desean de la versión de dos programas al abrir un programa. Quiero decir, si no hubiera estas dos carpetas y si fuera transparente para los usuarios (si cambiara automáticamente), no sabrían si ejecutan una aplicación de 32 o 64 bits, incluso, no sabrían qué programa abrir si se ejecuta en 64 bits ..
Diogo

1
La versión de 64 bits de IE tiene fama de ser terrible.
Samuel Edwin Ward

1
MS recomienda usar office32 a menos que esté trabajando con conjuntos de datos lo suficientemente grandes como para exceder las restricciones de memoria. Creo la necesidad de recompilar complementos binarios para trabajar con office64; combinado con no dar ningún beneficio en casos de uso normal está detrás de la decisión.
Dan Neely

1
Creo que encontrará que un programa de 64 bits instalado explícitamente en la carpeta Archivos de programa (x86) funcionará perfectamente normalmente (y, en la mayoría de los casos, viceversa). Windows no usa la ubicación de la carpeta para determinar cómo tratar el ejecutable.
Harry Johnston

5

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:

  • No importa dónde se almacena una aplicación. En tiempo de ejecución, Windows determinará si la aplicación es de 32 o 64 bits y usará automáticamente las DLL y la sección de registro correspondientes.

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.


3

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

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

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

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

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.

¿Windows se presenta de alguna manera diferente a un programa que se está quedando sin "Archivos de programa (x86)"?

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.


Lo siento, mezclé "permiso" con "prohibir"
Wernfried Domscheit

3

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


1
¿Cómo funciona 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 los CommonFilesrecursos 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 sus
ex

Ah, y en cuanto a 95/98, ¿quién dijo algo al respecto? Incluso XP tenía un subsistema de 16 bits (el NTVDM).
Synetech

Pensé que querías una explicación. ¿Pocas aplicaciones usan CommonFiles? Tengo 35 aplicaciones diferentes que tienen entradas allí. Es un lugar más seguro para almacenar componentes compartidos que el directorio System32. Su afirmación de que pocas aplicaciones usan esto es discutible. Citando: "No tuvieron que saltar a través de estos aros para permitir programas de 32 bits y 16 bits en el mismo sistema. No recuerdo haber visto nunca un ProgramFiles (16) o algo así [...] Sin embargo, la parte de que se haga como una conveniencia para los programadores es razonable ". Bueno, sí ... los programadores lo hacen. Escribimos las aplicaciones después de todo.
Jason Locke

Eh?
Synetech

Solo vuelva a leer esto ... lo dijo mejor en sus respuestas: superuser.com/a/442253/142951 . Si no eres desarrollador, es posible que no veas el propósito.
Jason Locke

0

No 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 lo WoW64que ya se menciona en varias respuestas.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.