Por que o Windows 7 instala aplicativos de 64 bits na pasta Arquivos de Programas (x86)? Posso mudar o comportamento?


12

Eu tenho usado a versão de 64 bits do Windows 7 desde o CTP e tenho tido alguns problemas com aplicativos que são instalados no C:\Program Files (x86) pasta. Qual é o propósito de ter dois diretórios separados de Arquivos de Programas?

Todo programa que eu instalei entrou no C:\Program Files (x86) pasta. Não parece importar se o aplicativo é de 32 ou 64 bits. Por que os aplicativos de 64 bits não são colocados em C:\Program Files?

Existe uma maneira de alterar o padrão para ser C:\Program Files em vez de? Seria bagunça tudo se eu colocar tudo em C:\Program Files?

Se de fato existe algum benefício em ter uma pasta separada para aplicativos de 64 bits, parece que o padrão mais sensato seria usar C:\Program Files para aplicativos x86 e criar um novo C:\Program Files (x64) pasta para os novos aplicativos de 64 bits. Isso ajudaria a manter a compatibilidade com versões anteriores. Eu trabalho como desenvolvedor de software e alguns dos meus projetos contêm referências de caminho para bibliotecas sob C:\Program Files. Agora essas referências estão quebradas na máquina Windows 7 que as colocou C:\Program Files (x86). Eu até tentei mudar o local de destino no instalador para ser C:\Program Files, mas isso foi ignorado e o aplicativo entrou em C:\Program Files (x86) de qualquer forma.

Isso é muito frustrante porque preciso compartilhar o código-fonte entre máquinas de 32 e 64 bits e não quero ter que mexer com algum arquivo de configuração que defina o caminho para essas bibliotecas de maneira diferente em máquinas diferentes.

Edite as variáveis ​​de ambiente: (Utilizando apenas valores padrão ingleses de variáveis ​​para simplificar.) Em uma máquina de 64 bits %ProgramFiles% será C:\Program Files enquanto a nova variável %ProgramFiles(x86)% será C:\Program Files (x86). Portanto, se você tiver um programa de 32 bits que precise encontrar o caminho da pasta em que ele será instalado, será necessário verificar se ele estava sendo executado em uma versão de 32 bits ou de 64 bits do Windows para para saber qual variável de ambiente usar. Quaisquer aplicativos de 32 bits que foram gravados sem essa consideração precisariam ser atualizados para funcionar corretamente em uma máquina de 64 bits. Portanto, mesmo usando variáveis ​​de ambiente, a compatibilidade com versões anteriores é interrompida.

Além disso, %ProgramFiles(x86)% não existe em versões de 32 bits do Windows. Em caso afirmativo, os aplicativos de 32 bits poderiam sempre usar essa variável de ambiente e não precisariam de lógica condicional com base no sistema operacional em que estão sendo executados.


5
Você tem certeza de que esses aplicativos são de fato de 64 bits? Na maioria dos casos, você encontrará programas que são compatíveis apenas com 64 bits, mas na verdade são aplicativos de 32 bits.
John T

Eu me pergunto se usando o %ProgramFiles% variável de ambiente teria resolvido isso. Não tenho certeza de como ele lida com a diferença de x86 / 64 bits.
ceejayoz

Respostas:


7

A razão para isso é simplesmente muitos instaladores mais antigos, ou não entendem a nova estrutura de arquivos e plonk tudo no diretório de arquivos de programas padrão ou você está olhando para um programa inteligente que tem alguns componentes de 32 bits que estão sendo copiados lá.

Sua melhor aposta é baixar um novo programa - como Winrar x64 e veja onde ele é instalado para descartar um problema com a sua máquina.

Quanto a bagunçar coisas - pode, mas realmente depende do programa, não há uma resposta única para todos ... alguns programas menores e compactos com apenas alguns arquivos não devem ter nenhum problema, onde, se você falar sobre o Office , Adobe ou qualquer outro "conjunto" ou programa grande, ele provavelmente falhará, pois possui muitos componentes compartilhados que são de arquitetura cruzada.


Então, por que a Microsoft não criou o "C: \ Arquivos de Programas" como o local para aplicativos de 32 bits, para que os instaladores antigos não causassem problemas. Além disso, eu realmente não entendo por que precisa haver uma separação. Por que eles não podem simplesmente entrar em "C: \ Program Files"?
CoderDennis

A razão pela qual ambos não podem é que alguns aplicativos (especialmente aqueles com componentes compartilhados) têm arquivos com o mesmo nome em 32 bits como 64 bits. Quanto ao porquê é assim - eu não tenho idéia, alguém provavelmente tinha uma razão muito boa na época e simplesmente ficou preso como "a coisa a fazer".
William Hilsum

4

Se você usar algo diferente de %ProgramFiles% (ou CSIDL_PROGRAM_FILESou sob o .NET Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles) ) de qualquer forma, você está com problemas, já que as instalações personalizadas podem ter programas instalados em outros volumes (D: por exemplo) e instalações internacionais geralmente têm outras pastas por padrão.

  • Janelas espanholas: C:\Archivos de Programa,
  • Janelas francesas: C:\Programmes,
  • Janelas alemãs: C:\Programme,
  • Janelas Suecas: C:\Program

etc.


Não mencionei variáveis ​​de ambiente na minha pergunta original para simplificar. Acabei de adicionar uma edição que aponta como usar %ProgramFiles% é exatamente o que causa o problema.
CoderDennis

3

Observe que nas versões de 64 bits do Windows 7 (isso também pode se aplicar a outras versões mais recentes do SO, mas só posso confirmar isso para o Win 7 de 64 bits), há uma diferença entre o local aparente do% ProgramFiles% no explorer e no DOS.

No windows 7, a localização real da pasta física de% ProgramFiles% (e a variável associada% ProgramFiles (x86)% environemnt) é fixado de acordo com a versão em inglês ; ou seja, "C: \ Arquivos de Programas" e "C: \ Arquivos de Programas (x86)" respectivamente, mas é mostrado no explorador localizado como apropriado.

Para fornecer um exemplo específico; em uma instalação sueca do Windows 7 de 64 bits, se você abrir o Explorer e procurar na unidade do sistema (normalmente C :) você verá " Programa "e" Programa (x86) "pastas. Digitando% ProgramFiles% na barra de endereços move você em" C: \ Program ".

No entanto, se você abrir uma caixa do DOS e digitar SET, verá que o valor real de% ProgramFiles% é "C: \ Program Files", e não o explorador da pasta "C: \ Program". Mais explorando com CD e DIR você pode ver fisicamente é "C: \ Program Files"

A moral é se você usar as variáveis ​​de ambiente ou programa através da API, tudo ainda funcionará, mas esteja ciente dessa mudança sutil ao explorar o sistema de arquivos!


Na versão polaca, “Program Files (x86)” é “Pliki programow (x86)”, enquanto “Program Files” é, bem… “Program Files”. Polonês tem gramática estranha. Além disso, por favor, não chame de caixa DOS. Não há DOS lá.
kinokijuf
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.