Questão Por que o Windows de 64 bits precisa de uma pasta “Program Files (x86)” separada?


Eu sei que em uma versão de 64 bits do Windows a pasta "Arquivos de Programas" é para programas de 64 bits e a pasta "Arquivos de Programas (x86)" é para programas de 32 bits, mas Por que isso é necessário?

Por "necessário", não quero dizer "por que a Microsoft não tomou nenhuma outra decisão de design?" porque é claro que eles poderiam ter. Em vez disso, quero dizer, "por que, considerando o design atual do Windows de 64 bits, os programas de 32 bits devem ter uma pasta de nível superior separada dos programas de 64 bits?" Em outras palavras, "o que poderia dar errado se eu, de alguma forma, evitasse o mecanismo de redirecionamento e forçasse tudo a instalar na realidade?" C:\Program Files\"

Há muitas perguntas sobre o Superusuário e em outros lugares que afirmam "um é para programas de 32 bits, um é para programas de 64 bits", mas nenhum que eu possa encontrar dá o motivo. Pela minha experiência, isso não parece importa se um programa de 32 bits está instalado no local correto ou não.

O Windows de alguma forma se apresenta de forma diferente para um programa que está ficando sem "Arquivos de Programas (x86)"? Existe uma descrição que mostra exatamente o que é diferente para um programa instalado em "Arquivos de Programas (x86)" em vez de "Arquivos de Programas"? Acho improvável que a Microsoft introduzisse uma nova pasta sem um motivo técnico legítimo.


175


origem


Em vez de responder a sua pergunta, eu perguntaria - como você lidaria com arquivos de programas \ arquivos comuns? - sgmoore
Resposta de uma linha (e, portanto, um comentário): como você pode facilmente executar qualquer aplicativo de qualquer pasta sem conhecer sua arquitetura, não há claramente nenhuma obrigatório razão para esta separação. É uma questão de conveniência para suportar instalações duplas de aplicativos com ambas as arquiteturas. Em alguns casos, faz diferença, pois não são necessariamente recompilações simples. O principal problema é que os aplicativos de 32 bits não podem carregar dlls de 64 bits, portanto, normalmente não é possível instalar as duas versões no mesmo local. A outra alternativa é ter duas pastas "bin" para cada aplicativo. - Sklivvz
@Synetech Eu mesmo tive programas instalando sob (x86) apenas para ter binários x64 .. É horrível às vezes. - sinni800
Sempre me perguntei por que a Microsoft não colocou programas de 64 bits em "Arquivos de Programas (x64)" em vez de "mover" o diretório "Arquivos de Programas" herdados para Arquivos de Programas (x86) - LawrenceC
A verdadeira confusão sobre a diferenciação 64 / 32bit é que / Windows / System32 contém conteúdo de 64 bits, enquanto / Windows / SysWOW64 contém o material de 32 bits… - poke


Respostas:


Resposta curta: Para garantir que os aplicativos herdados de 32 bits continuem funcionando da mesma maneira que costumavam, sem impor regras desagradáveis ​​aos aplicativos de 64 bits, o que criaria uma confusão permanente.

Não é necessário. É apenas mais conveniente do que outras soluções possíveis, como exigir que cada aplicativo crie sua própria maneira de separar DLLs e executáveis ​​de 32 bits de DLLs e executáveis ​​de 64 bits.

O principal motivo é fazer com que aplicativos de 32 bits que nem sequer conhecem sistemas de 64 bits existam "apenas funcionem", mesmo que as DLLs de 64 bits estejam instaladas em locais que os aplicativos possam parecer. Um aplicativo de 32 bits não poderá carregar uma DLL de 64 bits, portanto, foi necessário um método para garantir que um aplicativo de 32 bits (que pode ser anterior a sistemas de 64 bits e, portanto, não tenha idéia dos arquivos de 64 bits) mesmo que existam) não encontraria uma DLL de 64 bits, tente carregá-la, falhar e gerar uma mensagem de erro.

A solução mais simples para isso é sempre diretórios separados. Realmente, a única alternativa é exigir que cada aplicativo de 64 bits "oculte" seus arquivos executáveis ​​em algum lugar que um aplicativo de 32 bits não tenha aparência, como bin64 diretório dentro desse aplicativo. Mas isso imporia a fealdade permanente aos sistemas de 64 bits apenas para suportar aplicativos herdados.


89



Eles não precisaram passar por esses controles para permitir programas de 32 e 16 bits no mesmo sistema. Eu não me lembro de ter visto um ProgramFiles (16) ou algo assim. Além disso, como exatamente um programa de 32 bits "encontraria uma DLL de 64 bits e tentaria carregá-la"? Que programas andam procurando por DLLs aleatórias em %programfiles%? Se for uma DLL compartilhada, ela será incluída no WinSxS; se não for compartilhada, cabe ao programador gerenciar suas próprias DLLs. A parte sobre isso é feita como uma conveniência para os programadores. - Synetech
IIRC Win3.1 não tinha um diretório de arquivos de programa (ou a maioria dos aplicativos o ignorava); Como resultado, não haveria nenhum aplicativo legacy win16 procurando por arquivos de programa para começar. Em vez disso, as bibliotecas compartilhadas do IIRC eram frequentemente colocadas em algum lugar na própria pasta do Windows. Win32 ter windows \ system e windows \ system32 é um artefato disso. - Dan Neely
Windows 3.1 não oferece suporte a nomes extensos de arquivos, por isso não poderia ter uma pasta 'arquivos de programa'. - Darth Egregious
@JarrodRoberson: Bem pelo contrário, é porque a Microsoft valoriza extremamente a compatibilidade retroativa. - David Schwartz
@Jarrod: Na verdade, como todos os desenvolvedores sabem, a Microsoft valoriza a compatibilidade com versões anteriores também altamente. Literalmente, todas as APIs deles têm métodos legados que eles se recusam a remover e grave bugs que eles se recusam a consertar, porque têm medo de quebrar programas antigos que foram escritos para essa API. O mesmo vale para a maioria das APIs, mas não para qualquer lugar próximo ao existente da Microsoft. - BlueRaja - Danny Pflughoeft


Ele permite que você instale a versão de 32 bits e 64 bits de um aplicativo sem sobrescrevê-lo.


Depois de olhar para esta resposta e comentar o tópico no dia seguinte, percebo uma possível grande supervisão em minha resposta. Eu assumi falsamente um histórico de programação e quando eu estava falando sobre você nos meus comentários, eu não quis dizer o usuário, mas o programador.

Eu não trabalho para a Microsoft e não tenho idéia do que o real raciocínio por trás dessas pastas é, mas acho que o motivo para ter essas pastas é tão óbvio que não tenho nenhum problema discutindo isso.

Então vamos acabar com isso!

  1. As pastas são incríveis!

    Vamos concordar em algo. As pastas são ótimas! Nós não precisamos deles, temos nomes de arquivos suficientes para colocar cada arquivo na raiz do seu disco rígido, então por que ter pastas?

    Bem, eles nos ajudam a pedir nossas coisas. E encomendar coisas é ótimo. Isso nos ajuda a processar as coisas com mais facilidade. Isso é especialmente útil ao trabalhar com uma máquina que requer estrutura.

  2. Separar dados e lógica é ótimo!

    Um paradigma freqüentemente encontrado em programação é separar dados da lógica. Você quer uma parte que sabe como fazer alguma coisa e você quer outra parte você pode fazer alguma coisa com


65



É essa a razão original, embora? Eu não poderia simplesmente instalar o aplicativo para C:\Program Files\App32 e C:\Program Files\App64? - Stephen Jennings
@StephenJennings: Mas isso exigiria que você tomasse a decisão manualmente. A maneira como funciona agora é que o processo é automático, porque o Windows sabe qual pasta deve ser fornecida quando um aplicativo chama SHGetSpecialFolderPath para determinar o local de instalação. - Der Hochstapler
@Synetech: Por que instalar %PROGRAMFILES% em primeiro lugar? Por que não colocar a versão de 32 bits na área de trabalho dos usuários e os 64 bits na Lixeira? Só porque isso pode ser feito, não significa que seja uma boa ideia. Desculpe, não sigo seu raciocínio. - Der Hochstapler
@Synetech: Sim, você deu um bom exemplo de como isso poderia ser feito. Outro exemplo perfeitamente bom de como isso pode ser feito é a maneira como é na verdade sendo feito agora. Simplesmente escrever um arquivo para% PROGRAMFILES% e ter certeza de que ele acabará na pasta correta é uma coisa. Verificar por si mesmo qual pasta é a corrigir um é outro. Se você realmente não enxerga o benefício da abordagem anterior, não poderei convencê-lo. A questão era por que existem 2 pastas. Eu acho que minha resposta é perfeitamente razoável a esse respeito. - Der Hochstapler
@ OliverSalzburg, não exatamente. A questão é por que duas pastas são requeridosnão por que estamos. Na verdade, ele até negrito: Por que isso é necessário? Você não explicou porque é necessário e o exemplo que eu dei (e até mesmo o seu próprio exemplo sarcástico) mostram que isso não ter para ser feito do jeito que é. - Synetech


TL; DR:

Para resumir, não, não é necessário; eles poderia usei uma única pasta e não, o Windows não se apresenta de maneira diferente para um programa sendo executado de um local ou outro.


Bem, todo mundo parece estar jogando em suas opiniões sobre isso, então eu vou jogar no meu 2 ¢. Outros já conjecturaram sobre as razões pelas quais porque A Microsoft optou por criar pastas de nível superior separadas para versões de 32 bits e 64 bits, portanto deixarei essa parte (a melhor razão foi a explicação de David de que é uma conveniência para os programadores). É claro que, mesmo assim, não resolve a questão direta Por que isso é necessário?, para o qual a resposta é presumivelmente: não é.

Em vez disso, vou abordar o corpo principal da questão

O Windows de alguma forma se apresenta de forma diferente para um programa que está ficando sem "Arquivos de Programas (x86)"?

Na verdade não, mas a localização do programa posso afeta o comportamento, mas não da maneira que você pensaria.

Quando você executa um programa, o Windows configura um ambiente no qual executá-lo (quero dizer, em termos de memória, endereçamento, etc., não apenas variáveis ​​de ambiente). Este ambiente depende do conteúdo do executável (programas de 32 bits e 64 bits diferem internamente). Quando você executa um programa de 32 bits em um sistema de 64 bits, ele é executado no subsistema de 32 bits, que emula um ambiente de 32 bits. É chamado WoW64 (WoW64 significa Windows no Windows de 64 bits) e é semelhante a como aplicativos de 16 bits seriam executados no XP usando o NTVDM.

Quando você executa um programa com ou sem privilégios de administrador, isso afeta como ele é executado, mas a localização devemos não afetá-lo (embora existam alguns exemplos de dependência de localização, como alguns drivers, por exemplo).

(Estou usando um computador diferente, por isso não posso confiar no histórico do meu navegador para voltar atrás em meus passos, mas no outro dia ao responder esta questão SU Acabei em esta questão SO o que me levou a Google PROCESSOR_ARCHITEW6432que levam a esta questão SO e esta postagem de blog da Microsoft.)

Em algum lugar ao longo do caminho, eu li uma postagem do StackOverflow sobre como a variável do ambiente %processor_architecutre%  fornece resultados diferentes dependendo de onde você executa o prompt de comando (Eu tentarei achar a citação exata).

A resposta acabou sendo devida se a versão de 32 bits ou 64 bits do prompt de comando foi executada (ou seja, de System32\ ou SysWoW64\). Em outras palavras, enquanto a localização parece que afetar o comportamento do programa, é só porque existem diferentes versões do programa, não porque o Windows trata a pasta de uma maneira especial.

Isso faz sentido porque o conteúdo do arquivo executável determina se ele é de 32 bits ou 64 bits, portanto, você pode colocar uma cópia de 32 bits e 64 bits do mesmo programa (por exemplo, foobar32.exe e foobar64.exe) na mesma pasta e quando você executá-los, eles serão carregados corretamente (a versão de 64 bits será executada nativamente e a de 32 bits será executada na camada de emulação do WoW64).

O FreePascal permite que você instale as versões DOS e Windows e elas vão na mesma pasta: %programfiles%\FreePascal. Ele gerencia as diferentes arquiteturas mantendo arquivos executáveis ​​(.exe, .sys, .dll, .ovr, etc.) em pastas separadas e compartilhamento de arquivos de recursos, como imagens, arquivos de origem, etc.) Não há razão técnica para que isso também não possa ser feito para versões de 32 e 64 bits de um programa. Como David disse, é mais fácil para o programador se eles forem mantidos separados (isto é, usando variáveis ​​para fazer parecer que há apenas um conjunto de arquivos, etc.)


14



Vingança para baixo-votação! Muahahaha! suspiro - Synetech
Down-vote estranho: \. BTW bom explicar +1. - avirk


Outra razão é que a maioria dos programas usava variáveis ​​ambientais, como% PROGRAMFILES%, para indicar onde o programa estava instalado. Para programas de 64 bits, ele vai para o local normal. Para programas de 32 bits, ele será redirecionado para o novo Program Files (x86) pasta.

Embora, pelo menos com o novo material do .Net no Visual Studio, eles agora tenham a variável App.Local que elimina toda a necessidade disso.


11



Isso não explica isso. Quem exatamente está usando a variável de ambiente e por que se importa se um programa é de 32 bits ou 64 bits? - Synetech
@Synetech - O autor dos programas usa a variável de ambiente. Quanto ao motivo, isso seria devido a referências a dlls. Você não pode carregar uma dll de 32 bits em um processo de 64 bits e vice-versa. - Ramhound
E como %programfiles%, %programfiles(x86)%ou %programw6432% fazer diferença lá? Quaisquer DLLs compartilhadas vão para o único diretório WinSxS e quaisquer DLLs não compartilhadas estão ali mesmo com o executável. Isso só importa se por algum motivo você tiver versões de 32 bits e 64 bits do mesmo programa instalado e, mesmo assim, você manterá as DLLs de 32 bits com o executável de 32 bits e a DLL de 64 bits com o executável de 64 bits. Você pode fazer isso da seguinte maneira: %programfiles%\CoolApp\bin\32 e% programfiles% \ CoolApp \ bin \ 64`, por que as pastas de nível superior separadas? - Synetech
@Synetech Claro que sim; % programfiles% já existe há algum tempo. Se você instalar um programa de 32 bits em um computador de 64 bits, ter um local causaria problemas para esse aplicativo de 32 bits. WoW embora possa redirecionar% programfile% para a versão (x86) para aplicativos de 32 bits, e a versão não-x86 para 64. - Andy
Eu acho que as pessoas não ficariam tão confusas, se não houvesse redirecionamento implícito - kommradHomer


A solução da Microsoft para essa transição de 32 bits para 64 bits foi adicionar suporte legado para a maioria dos aplicativos de 32 bits. Em outras palavras, a maioria dos aplicativos de 32 bits funcionará no ambiente operacional de 64 bits. Tenha em mente que outros sistemas operacionais que operam em uma arquitetura de 64 bits não podem carregar ou executar aplicativos de 32 bits.

Para ajudar a facilitar a transição, a Microsoft determinou que todos os aplicativos de 32 bits devem, por padrão, ser carregados na pasta Arquivos de Programas (x86), em vez de serem mesclados com aplicativos verdadeiros de 64 bits na pasta Arquivos de Programas.

Fonte 

"o que poderia dar errado se de alguma forma eu evitar o mecanismo de redirecionamento e forçar tudo para instalar no C: \ Program Files real?" 

Nada. Os dois diretórios do programa são apenas para organização ou para manter programas com duas versões de 32 e 64 bits separadas, como o Internet Explorer. Mas você pode instalar um programa de 32 bits em "Arquivos de Programas" e um programa de 64 bits em "Arquivos de Programas x86" e nada acontecerá se o programa for executado da mesma forma.

Wiki diz:

Alguns instaladores de aplicativos rejeitam espaços dentro do local do caminho de instalação. Para sistemas de 32 bits, o nome abreviado da pasta Arquivos de Programas é Programa 1. Para sistemas de 64 bits, o nome abreviado da pasta Arquivos de Programas de 64 bits é o Progra ~ 1 (o mesmo que em sistemas de 32 bits); enquanto o nome abreviado da pasta Arquivos de Programas (x86) de 32 bits é agora Progra ~ 2.


8



Ele Ele. Artigo agradável. Os comentários para esse artigo soam exatamente como os que estão aqui. Pior, esse artigo foi publicado há mais de dois anos, o que mostra que essa questão não é nova e, se ainda assim não puder ser respondida com autoridade, acho que nunca será (a menos que alguém da equipe do Windows entre). Bem, suponho que todos devam parar de se preocupar e aprender a amar a bomba, quero dizer, viver com ela. +1 Por apontar o artigo e mostrar que essa questão existe há tanto tempo. - Synetech
@Synetech obrigado! Sim, a ideia por trás de colocar o link do artigo é a mesma que você tem. Esta é uma questão de tempo muito antiga, mas IDK porque as pessoas ainda não conseguiram. No entanto, o MS deve escrever um KB ou documentação para este problema :) - avirk
Sim, eles deveriam, especialmente porque não são apenas os desenvolvedores que perguntam, até mesmo os usuários normais se perguntam sobre isso. Infelizmente, a documentação da Microsoft nem sempre é boa demais. - Synetech
@Synetech yup! Documentação MS é uma droga na maioria das vezes. Mas sim, eles também escreveram bons artigos e eu tenho certeza que eles são contáveis;) - avirk


O motivo é tornar o upgrade de um programa para 64 bits mais fácil para os desenvolvedores. Eles não precisam escrever nenhum código personalizado para verificar o programa em um diretório ao compilar no modo de 32 bits e em outro diretório ao compilar no modo de 64 bits; eles apenas checam C:\Program Filese, quando executado em modo de 32 bits, isso é automaticamente alterado para C:\Program Files (x86) pelo Windows de 64 bits. Da mesma forma, as entradas do Registro são isoladas entre programas de 32 e 64 bits.

Isso evita conflitos de desenvolvedores desconhecidos que apenas mudam seu modo de compilação para 64 bits sem pensar muito sobre isso, e impede uma quantidade enorme de trabalho para desenvolvedores que desejam que os usuários possam instalar versões de 32 e 64 bits de suas versões. software em simultâneo.


Mas por que qualquer programa quer permitir que ambas as versões sejam instaladas simultaneamente? Um exemplo: o Photoshop e o IE possuem extensões que são nativas do .dll. Não é possível ter códigos de 32 e 64 bits misturados no mesmo processo, portanto, um complemento para a versão de 32 bits não pode ser usado com a versão de 64 bits e vice-versa. Assim, o Photoshop / IE ter para permitir que ambas as versões sejam instaladas, ou arriscar quebrar sua enorme base de addons existentes.


6



+1 Pelo menos você abordou a questão subjacente de por que usuários comuns teriam as duas versões. - Synetech


Programas que são executados em "Arquivos de Programas (x86)" usam o WOW64 subsistema (Windows de 32 bits no Windows de 64 bits é um conjunto de drivers e APIs com a intenção de executar aplicativos x32 em um sistema de arquitetura x64):

O subsistema WoW64 compreende uma camada de compatibilidade leve que   tem interfaces semelhantes em todas as versões de 64 bits do Windows. Destina-se a   criar um ambiente de 32 bits que forneça as interfaces necessárias para   executar aplicativos do Windows de 32 bits não modificados em um sistema de 64 bits.   Tecnicamente, o WoW64 é implementado usando três bibliotecas de link dinâmico   (DLLs):

  • Wow64.dll, a interface principal para o kernel do Windows NT que traduz entre chamadas de 32 e 64 bits, incluindo ponteiro e chamada   manipulações de pilha
  • Wow64win.dll, que fornece os pontos de entrada apropriados para aplicativos de 32 bits
  • Wow64cpu.dll, que cuida da comutação do processador do modo de 32 bits para o modo de 64 bits

O sistema de 64 bits precisa "emular" aplicativos de 32 bits, essa é a razão pela qual o Windows precisa "segregar" duas pastas de Arquivos de Programas.


5



Mas por que tem que colocar em pastas diferentes? O Windows já é totalmente capaz de determinar a arquitetura de um executável observando o cabeçalho PE. Por que não pode carregar o ambiente apropriado quando carrega o executável? - Synetech
Eu acho que é apenas uma escolha da Microsoft para mostrar facilmente aos usuários qual arquitetura eles querem da versão de dois programas ao abrir um programa. Quer dizer, se não houvesse essas duas pastas e se fosse transparente para os usuários (se mudasse automaticamente), eles não saberiam se estavam rodando um aplicativo de 32 ou 64 bits, mesmo que não soubessem qual programa abrir se rodando em 64 bits .. - Diogo
A versão de 64 bits do IE tem uma reputação de ser terrível. - Samuel Edwin Ward
A MS recomenda o uso do office32, a menos que você esteja trabalhando com conjuntos de dados grandes o suficiente para exceder as restrições de memória. Acredito na necessidade de recompilar os addons binários para trabalhar com o office64; combinado com não dar quaisquer benefícios em casos de uso normal está por trás da decisão. - Dan Neely
Acho que você verá que um programa de 64 bits explicitamente instalado na pasta Program Files (x86) funcionará perfeitamente normalmente (e, na maioria dos casos, vice-versa). O Windows não usa o local da pasta para determinar como tratar o executável. - Harry Johnston


É interessante que as respostas aqui e pela internet variem bastante. Encontrar uma resposta precisa para essa questão importante foi um desafio. Parece haver um pouco de informação falsa apresentada na Internet, levando a confusão.

Eu realizei uma quantidade significativa de pesquisa e tirei a seguinte conclusão, que acredito ser precisa:

  • Não faz diferença onde um aplicativo é armazenado. Em tempo de execução, o Windows determinará se o aplicativo é de 32 bits ou 64 bits e automaticamente usará a seção de registro e DLL apropriada.

Isso acontece automaticamente e é independente de onde o aplicativo está armazenado. Não há velocidade, confiabilidade ou outro benefício funcional em ter pastas separadas de 32 e 64 bits.

A única razão para a separação padrão em duas pastas ('Arquivos de Programas' e 'Arquivos de Programas (x86)') é que, se você tiver duas versões do mesmo programa (uma versão de 32 e 64 bits), maneira simples de manter os arquivos sobrepostos separados. Mesmo nesse caso, desde que todos os nomes de arquivos sejam únicos, eles poderiam existir na mesma pasta sem nenhuma conseqüência.

Há uma ressalva na conclusão acima, e essa é a das aplicações mal codificadas. Se um aplicativo tiver algum caminho codificado nele, ele só usará esse caminho. Como regra geral, os caminhos nunca devem ser codificados em um aplicativo, mas ocasionalmente um programador cometerá esse erro. Nesse caso, o programa usará o caminho codificado; o diretório no qual o aplicativo está instalado não afetará onde ele realmente procura por arquivos.


5





Ter que separar pastas torna possível manter os aplicativos nativos de 64 bits e os que exigem WoW64 apart.

Isso pode ser útil - como @OliverSalzburg já apontou - se você deseja instalar tanto ele de 64 bits e 32 bits de um navegador da web (por exemplo), uma vez que alguns plug-ins e add-ons só podem estar disponíveis para um dos dois.

Ter que separar pastas faz essa separação automático, usando técnicas como redirecionamento de registro.

Suponha que um instalador tente determinar a pasta de arquivos do programa lendo o registro usando, por exemplo, RegQueryValueEx.

Em qualquer caso, ele tenta ler a chave do registro

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion

que normalmente aponta para C:\Program Files.

No entanto, se o instalador for um aplicativo de 32 bits, o redirecionamento do registro fará com que a chave de registro

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion

para ser lido em vez disso, o que normalmente aponta para C:\Program Files (x86).

Por que estes especial Os nomes das pastas utilizados só podem ser respondidos pelas pessoas que fizeram esta escolha. Você pode sempre alterar os nomes das pastas padrão, se quiser.

O Windows de alguma forma se apresenta de forma diferente para um programa que está ficando sem "Arquivos de Programas (x86)"?

Eu duvido. A maioria dos instaladores permite que você escolha uma pasta de instalação personalizada, por isso não importa realmente Onde um programa é instalado.


3



Desculpe eu misturei "permitir" com "proibir" - Wernfried Domscheit