prog 32 bits installé en %ProgramFiles% sous Seven 64 bits

rm avait prétendu :

Salut,

Rien n'empèche à priori d'installer un programme 32 bits (un truc banal,
hein, pas un driver ou assimilé) dans le dossier normalement "réservé" aux
applications 64 bits sous Seven (surement idem sous Vista), soit
%ProgramFiles%

Cela présente-t-il un inconvénient, voire un risque de souci à plus ou
moins long terme ? Vaut-il mieux toujours les installer en
%ProgramFiles(x86)% et le cas échéant, pourquoi ?

Il me semble qu'en ce cas le code 32 bits et 64 bits est mêlé dans
l'installateur, qu'il reconnait à qui il a à faire et installe la
version 64 bits.

rm, le 11/6/2010 a écrit :

Salut,

Rien n'empèche à priori d'installer un programme 32 bits (un truc banal,
hein, pas un driver ou assimilé) dans le dossier normalement "réservé" aux
applications 64 bits sous Seven (surement idem sous Vista), soit
%ProgramFiles%

Cela présente-t-il un inconvénient, voire un risque de souci à plus ou
moins long terme ? Vaut-il mieux toujours les installer en
%ProgramFiles(x86)% et le cas échéant, pourquoi ?

Ce serait tendre le bâton pour se faire battre. Il est préférable de
laisser les choses se faire naturellement. Même si la plupart des
programmes peuvent s'installer /n'importe où/. Il y a des dizaines de
raisons pour que /ça plante/ et c'est particulièrement vrai des outils
de développement.
Juste un exemple, que vous pouvez compiler "pour voir" (testé avec
Visual Studio 2010 Express modifié pour du 64bits):
<CODE>
#include <stdio.h>
#include <stdlib.h>
#include "Shlobj.h"
#include <tchar.h>


int main(void){
TCHAR buf[1024];
SHGetSpecialFolderPath( 0,
buf,
CSIDL_PROGRAM_FILES,
FALSE );
printf("%lsn", buf);
wcscat(buf, L"\test\inits.dat");
printf("%lsn", buf);
/*
Suite du code, utiliser buf pour ouvrir en lecture inits.dat,
au même niveau que testxx.exe
*/
return EXIT_SUCCESS;
}
</CODE>

Vous générez un test32.exe et un test64.exe, vous les lancez tous les
deux de là où ils sont. Plus parlant encore, vous les copiez tous les
deux dans "C:Program Files (x86)test" et tous les deux également dans
"C:Program Filestest". Vous voyez bien dans quels cas il va se passer
des choses désagréables.


Pourquoi ces deux dossiers ? Je ne fais que des hypothèses mais je ne
dois pas être très loin de la vérité. Chez Microsoft fort logiquement
on a favorisé le mode de l'avenir. Le mode 32bits est dit "legacy",
"héritage", c'est un mode "dégradé", même s'il ne l'est pratiquement
pas en termes de performances. On ne veut pas trimbaler pour dix ans ou
plus des rustines sur le mode 64bits, il doit garder des noms naturels.
De plus si on reprend des sources 32bits pour les gonfler en 64bits,
garder le même arborescence peut être utile, on préserve l'acquit des
développeurs, etc. Donc ce sera "Program Files" pour les programmes et
"System32"[*] pour les DLLs système. Le mode 32bits quant à lui passe
par une grosse tuyauterie, on peut voir ça comme s'il était dans un
environnement virtualisé. Le système lui répondra "Program Files
(x86)", pire quand un programme parlera à quelque chose (DLL) dans
"..System32..", on le dirigera silencieusement vers "..SysWOW64..".
Bref, un truc bien fichu[**] qui donne satisfaction si on ne cherche
pas à le piéger en installant au mauvais endroit ;-)
Dernier point: si les programmes 32bits marchent "à priori" à partir de
"Program Files", pourquoi un "Program Files (x86)" ?[***] D'abord parce
que dans l'idée de la migration, on envisage des versions coexistantes.
C'est le cas pour IE8 et Photoshop CS5 par exemple. Bien entendu on
peut jouer sur les noms de dossiers, mais voir plus haut, ça signifie
trimbaler de la rustine. Et puis il y a les fichiers et chemins communs
aux deux versions. Imaginons une stucture:
..Program FilesCommun..Lib(fichiers)
Une méthode (vue sur Linux par exemple) serait de faire:
..Program FilesCommun..Lib64(fichiers)
Rustine, tout ça... Alorsz que la méthode choisie nous permet de faire
une modification en hat de l'arborescence de façon transparente pour
les applis 32bits:
..Program FilesCommun..Lib(fichiers)
..Program Files (x86)Commun..Lib(fichiers)

Voilà.

[*] Oui, ça peut paraître étrange. Ça prouve peut-être qu'on n'avait
pas fait les meilleurs choix au moment du passage aux 32bits.

[**] A part les DLLs 64bits dans System32 et les 32bits dans SysWOW64
qui fait un peu désordre en première approche, mais c'est logique.
C'est il y a ... 20 ans (?) que System32 aurait dû rester System.

[***] J'avoue que je ne m'étais pas posé la question, tant je trouve
bien pratique d'avoir immédiatement l'information 32 ou 64.

--
Pierre Maurette

Le samedi 6 novembre 2010 à 23:08, Williamhoustra a écrit :

rm avait prétendu :

Salut,

Rien n'empèche à priori d'installer un programme 32 bits (un truc banal,
hein, pas un driver ou assimilé) dans le dossier normalement "réservé" aux
applications 64 bits sous Seven (surement idem sous Vista), soit
%ProgramFiles%

Cela présente-t-il un inconvénient, voire un risque de souci à plus ou
moins long terme ? Vaut-il mieux toujours les installer en
%ProgramFiles(x86)% et le cas échéant, pourquoi ?

Il me semble qu'en ce cas le code 32 bits et 64 bits est mêlé dans
l'installateur, qu'il reconnait à qui il a à faire et installe la
version 64 bits.

Non, non... J'ai testé avec un programme qui n'est pas encore compilé pour
du 64 bits ;)

@+
--
rm

Salut,
Le dimanche 7 novembre 2010 à 13:45, Pierre Maurette a écrit :

Je ne fais que des hypothèses mais je ne
dois pas être très loin de la vérité.

Ok.

On ne veut pas trimbaler pour dix ans ou
plus des rustines sur le mode 64bits, il doit garder des noms naturels.
De plus si on reprend des sources 32bits pour les gonfler en 64bits,
garder le même arborescence peut être utile, on préserve l'acquit des
développeurs, etc. Donc ce sera "Program Files" pour les programmes et
"System32"[*] pour les DLLs système. Le mode 32bits quant à lui passe
par une grosse tuyauterie, on peut voir ça comme s'il était dans un
environnement virtualisé. Le système lui répondra "Program Files
(x86)",

Ce n'est donc qu'une convention pour "ranger" les programmes par défaut.
Rien de plus restrictif au niveau du système ?
On peut donc installer une version 32 bits d'un programme dans un dossier
comme %ProgramFiles%Mon_Prog(32bits) et lorsqu'une version 64 bits sera
disponible, il suffira de l'installer en %ProgramFiles%Mon_Prog(64bits)
C'est une autre convention d'écriture possible, toute aussi claire...
Et pourquoi pas, si on ne veut pas faire cohabiter du 32 et du 64, tout
mettre en %ProgramFiles%Mon_Prog, en écrasant une 32 bits par une 64 tout
simplement ?

A part les DLLs 64bits dans System32 et les 32bits dans SysWOW64
qui fait un peu désordre en première approche

Si on mélange toutes les dll (32 et 64 bits) dans le même dossier System32,
tu penses que cela posera un gros problème à Windows ?

@+
--
rm - http://opera-fr.com

rm, le 11/7/2010 a écrit :

Salut,
Le dimanche 7 novembre 2010 à 13:45, Pierre Maurette a écrit :

Je ne fais que des hypothèses mais je ne
dois pas être très loin de la vérité.

Ok.

On ne veut pas trimbaler pour dix ans ou
plus des rustines sur le mode 64bits, il doit garder des noms naturels.
De plus si on reprend des sources 32bits pour les gonfler en 64bits,
garder le même arborescence peut être utile, on préserve l'acquit des
développeurs, etc. Donc ce sera "Program Files" pour les programmes et
"System32"[*] pour les DLLs système. Le mode 32bits quant à lui passe
par une grosse tuyauterie, on peut voir ça comme s'il était dans un
environnement virtualisé. Le système lui répondra "Program Files
(x86)",

Ce n'est donc qu'une convention pour "ranger" les programmes par défaut.
Rien de plus restrictif au niveau du système ?
On peut donc installer une version 32 bits d'un programme dans un dossier
comme %ProgramFiles%Mon_Prog(32bits) et lorsqu'une version 64 bits sera
disponible, il suffira de l'installer en %ProgramFiles%Mon_Prog(64bits)
C'est une autre convention d'écriture possible, toute aussi claire...
Et pourquoi pas, si on ne veut pas faire cohabiter du 32 et du 64, tout
mettre en %ProgramFiles%Mon_Prog, en écrasant une 32 bits par une 64 tout
simplement ?

A part les DLLs 64bits dans System32 et les 32bits dans SysWOW64
qui fait un peu désordre en première approche

Si on mélange toutes les dll (32 et 64 bits) dans le même dossier System32,
tu penses que cela posera un gros problème à Windows ?

Certainement. Ce n'est d'ailleurs pas cette question qu'il faut poser,
puisque les DLLs ont les mêmes noms dans la même arboresence dans
System32 et SysWOW64.

Pour le reste il me semble que vous attendez une réponse précise qui
n'est pas celle que je vous ai donné. Ma réponse était sans doute
longue et confuse, mais je ne peux que vous y renvoyer.

--
Pierre Maurette