Discussion :

[Toto ZEHERO]

Bonjour,
je suis développeur débutant, en stage pour apprendre le métier, et dans la perspective d'une très prochaine migration de XP (32) vers W7 (64), il m'est demandé de procéder au portage d'une application. Cependant, je n'ai encore jamais fait ça et ne sais pas comment m'y prendre :

• quels éléments dois-je exactement prendre en compte AVANT, PENDANT et APRES ?

• Quels sont les changement impliqués dans le code même de l'application (codée en C++) ?

• des conseils, des indications particulières ?

Je suis là pour apprendre et suis preneur de toute remarque que vous m'apporterez.

Merci beaucoup par avance !!

[Bousk]

Salut,

porter une application c'est souvent pas compliqué.
Tu prends ton projet, tu compiles, et tu résouds les erreurs jusqu'à ce que ça compile.
De Windows à Windows, à moins d'utiliser des trucs très bas niveau ou bien spécifiques, c'est fort simple.

[JolyLoic]

Tout va dépendre de la qualité du code initial. Là, tu as deux portages en 1 :
- 32 bits vers 64 bits
- XP vers 7

Je te suggère éventuellement d'en faire un troisième dans la foulé : Passer à une version plus récente du compilateur. En effet, quitte à devoir tout retester, autant ne le faire qu'une fois Et pour peu que ça te permette des nouveautés du langage comme auto, la partie portage 32/64 bits devrait être plus simple.


Pour le premier, si ça compile, ça devrait déjà être pas trop mal. Généralement, les soucis vont être avec les tailles de conteneurs stockées dans des entiers là où il aurait fallu des size_t (en 32 bits, les deux types sont équivalents, pas en 64 bits.

Pour le second, les plus gros problèmes que j'ai pu avoir son liés à l'UAC : Sous xp, il était autorisé qu'une application enregistre des choses dans son propre répertoire. Sous 7, le répertoire program files est protégé, tu ne peux pas écrire dedans. En fait, il te laisse croire que l'écriture au eu lieu, mais il met les données ailleurs, quand il ne lance pas tout simplement une erreur. Donc première chose à faire, c'est regarder si le programme essaye d'écrire là dedans (fichier de configuration, répertoire temporaire...).

[Médinoc]

Pour le second, les plus gros problèmes que j'ai pu avoir son liés à l'UAC : Sous xp, il était autorisé qu'une application enregistre des choses dans son propre répertoire. Sous 7, le répertoire program files est protégé, tu ne peux pas écrire dedans. En fait, il te laisse croire que l'écriture au eu lieu, mais il met les données ailleurs, quand il ne lance pas tout simplement une erreur. Donc première chose à faire, c'est regarder si le programme essaye d'écrire là dedans (fichier de configuration, répertoire temporaire...).

Inexact. C'est juste que sous XP, pratiquement tout le monde tournait en Admin, ce qui laissait les applications écrire dans leur propre répertoire même quand celui-ci était dans Program Files.
Sous Vista et supérieur, même les Admins tournent en non-Admin par défaut.

Les façons "horrible paresseux" de corriger ça casser le thermomètre, sont:

• Ne pas installer l'application dans Program Files (certaines comme Google Chrome s'installent individuellement pour chaque utilisateur, dans un répertoire lui appartenant).
• Indiquer dans le manifeste de l'application qu'elle doit toujours être exécutée en Admin, et que le commun des mortels n'a pas le droit de la lancer. Il existe certaines applications spécifiques pour lesquelles c'est justifié, mais elles sont rares.
• Donner au commun des mortels le droit d'écrire dans le sous-répertoire en question (comme le fait Steam). Attention, ne jamais donner de tels droits sur Program Files lui-même!

La vraie façon de corriger ça est:

• Utiliser le bon répertoire (ou plus précisément, le bon KNOWNFOLDERID avec SHGetKnownFolderPath()) pour chaque fichier créé par l'application.

À noter que le même problème se présente pour le Registre (HKEY_LOCAL_MACHINE contre HKEY_CURRENT_USER).

[chrtophe]

Attention aux chemins si ils sont en durs
Windows XP : Mes documents Vista/7 : Documents
All Users devenant quelque chose comme ProgramData
etc...

[Médinoc]

Ou plus exactement,

• Mes Documents devient FOLDERID_Documents
• All Users devient FOLDERID_Public
• All Users\Application data devient FOLDERID_ProgramData

Etc.

À noter aussi que SHGetKnownFolderPath() ne retourne que des paths en UTF-16: En 2014, on n'est plus vraiment censé utiliser des chemins de fichier en ASCII étendu. La classe CA2W (ou si tu n'as pas ATL/MFC, MultiByteToWideChar() dans un wrapper C++ de ton cru retournant une std::wstring) est ton amie.

[Toto ZEHERO]

Très bien, merci beaucoup à tous pour vos réponses, j'en prends note.
J'en suis encore à ma phase d'analyse pendant un petit moment je pense, le temps d'étudier correctement l'existant/ce qui a été fait, les versions utilisés etc, mais je reviendrai vers vous pendant l'écriture/la ré-écriture du code si j'ai loupé un truc...

Mais si vous avez d'autres suggestions/conseils, n'importe quoi, n'hésitez pas à m'en faire part !!

Merci à tous.