Conversion du code Win16 C en Win32

Question

En général, que faut-il faire pour convertir un programme Windows 16 bits en Win32? Je suis sûr que je ne suis pas la seule personne à hériter d'une base de code et à être étonné de trouver du code 16 bits caché dans les coins.

Le code en question est C.

Answer 1

1. Les significations de wParam et lParam ont changé dans de nombreux endroits. Je vivement vous encourage à rester paranoïaque et à convertir autant que possible pour utiliser les message crackers . Ils vous éviteront des maux de tête sans fin. S'il n'y a qu'un seul conseil que je puisse vous donner, ce serait le bon.
2. Tant que vous utilisez des crackers de messages, activez également STRICT . Cela vous aidera à comprendre la base de code Win16 en utilisant int , où elle devrait utiliser HWND , HANDLE ou quelque chose d'autre. Leur conversion aidera beaucoup avec le numéro 9 de cette liste.
3. hPrevInstance est inutile. Assurez-vous qu'il n'est pas utilisé.
4. Assurez-vous que vous utilisez des appels conviviaux pour Unicode. Cela ne signifie pas que vous devez tout convertir en TCHAR , mais que vous devez remplacer OpenFile , _lopen et _lcreat <. / code> avec CreateFile , pour nommer l'évident
5. LibMain est maintenant DllMain , et le format de la bibliothèque et les conventions d'exportation sont différents
6. Win16 n'avait pas de VMM. GlobalAlloc , LocalAlloc , GlobalFree et LocalFree doivent être remplacés par des équivalents plus modernes. Une fois terminé, supprimez les appels à LocalLock , LocalUnlock et à vos amis; ils sont maintenant inutiles. Je ne peux pas imaginer que votre application fasse cela, mais assurez-vous de ne pas dépendre de WM_COMPACTING pendant que vous y êtes.
7. Win16 n’avait pas non plus de protection de la mémoire. Assurez-vous de ne pas utiliser SendMessage ou PostMessage pour envoyer des pointeurs vers des fenêtres hors processus. Vous devrez passer à un mécanisme IPC plus moderne, tel que des canaux ou des fichiers mappés en mémoire.
8. Win16 manquait également de multitâche préventif. Si vous vouliez une réponse rapide à partir d'une autre fenêtre, il était vraiment cool d'appeler SendMessage et d'attendre que le message soit traité. C'est peut-être une mauvaise idée maintenant. Déterminez si PostMessage n'est pas une meilleure option.
9. La taille des pointeurs et des entiers change. N'oubliez pas de vérifier avec soin où que vous soyez en train de lire ou d'écrire des données sur un disque, surtout s'il s'agit de structures Win16. Vous devrez les refaire manuellement pour gérer les valeurs les plus courtes. Encore une fois, le moyen le moins pénible de gérer ce problème consiste à utiliser des craqueurs de messages dans la mesure du possible. Sinon, vous devrez rechercher et convertir manuellement int en DWORD , etc., le cas échéant.
10. Enfin, lorsque vous avez compris ce qui était évident, envisagez d'activer les vérifications de compilation 64 bits. La plupart des problèmes rencontrés pour passer de 16 à 32 bits sont identiques à ceux de 32 à 64, et Visual C ++ est en fait assez intelligent. Non seulement vous attraperez des problèmes persistants; vous vous préparez également pour votre éventuelle migration Win64.

MODIFIER : comme le fait remarquer @ChrisN, le guide officiel pour le portage d'applications Win16 sur Win32 est toujours disponible. Les deux options sont détaillées et ajoutées aux points ci-dessus.

Answer 2

Outre la création correcte de votre environnement de construction, voici quelques détails à prendre en compte:

1. Les structures contenant des entiers devront passer de 16 à 32 bits ou être élargies. Si vous modifiez la taille de la structure et que celle-ci est chargée / enregistrée sur le disque, vous devrez écrire le code de mise à niveau du fichier de données.

2. Les données par fenêtre sont souvent stockées avec le handle de fenêtre à l'aide de GWL_USERDATA. Si vous élargissez certaines données à 32 bits, vos décalages changeront.

3. POINT & amp; Les structures SIZE sont 64 bits dans Win32. Dans Win16, ils étaient de 32 bits et pouvaient être renvoyés sous forme de fichier DWORD (le demandeur diviserait la valeur renvoyée en deux valeurs de 16 bits). Cela ne fonctionne plus sous Win32 (c’est-à-dire que Win32 ne renvoie pas de résultats 64 bits) et les fonctions ont été modifiées pour accepter un pointeur permettant de stocker les valeurs de retour. Vous devrez modifier tous ces éléments. Des API telles que GetTextExtent sont affectées par cela. Ce même problème s’applique également à certains messages Windows.

4. L'utilisation de fichiers INI est déconseillée dans Win32 au profit du registre. Bien que les fonctions de fichier INI fonctionnent toujours, vous devrez faire attention aux problèmes de Vista. Les programmes 16 bits stockaient souvent leur fichier INI dans le répertoire système Windows.

Ce ne sont là que quelques-uns des problèmes dont je me souviens. Cela fait plus de dix ans que j'ai effectué un portage Win32. Une fois que vous y entrez, c'est assez rapide. Chaque base de code aura son propre " feel " en ce qui concerne le portage auquel vous vous habituerez. Vous rencontrerez probablement quelques bugs en cours de route.

Answer 3

Il existe un guide complet dans l'article Portage 16 À 3 bits sous Windows sur MSDN.

Answer 4

Le sdk Win32 d'origine avait un outil qui analysait le code source et marquait les lignes à modifier, mais je ne me souviens plus du nom de l'outil.

Quand j’ai dû faire cela dans le passé, j’ai utilisé une technique de force brute - c’est-à-dire: 1 - mettez à jour les makefiles ou l’environnement de construction pour utiliser le compilateur et l’éditeur de liens 32 bits. Vous pouvez éventuellement créer un nouveau projet dans votre IDE (j'utilise Visual Studio) et ajouter les fichiers manuellement.

2 - construire

3 - Corrigez les erreurs

4 - répétez les étapes 2 et 3 jusqu'à ce que l'opération soit terminée

La douleur du processus dépend de l'application que vous migrez. J'ai converti 10 000 programmes en ligne en une heure et 75 000 programmes en moins d'une semaine. J'ai également eu quelques petits utilitaires que je venais d'abandonner et de réécrire (principalement) à partir de zéro.

Answer 5

Je suis d’accord avec Alan pour dire que les essais et les erreurs sont probablement la meilleure solution.

Voici quelques astuces . / p>

Answer 6

Convenu que le compilateur détectera probablement la plupart des erreurs. De même, si vous utilisez " à proximité de " et " far " pointeurs, vous pouvez supprimer ces désignations - un pointeur est simplement un pointeur dans Win32.