Convertir le code C de Win16 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 stupéfaite de trouver du code 16 bits caché dans les coins.

Le code en question est C.

Answer 1

1. Les significations de wParam y lParam ont changé à de nombreux endroits. I fortement vous encourage à être paranoïaque et à vous convertir autant que possible pour utiliser craquements de messages . Ils vous épargneront bien des maux de tête. S'il n'y avait qu'un seul conseil à vous donner, ce serait celui-là.
2. Tant que vous utilisez des crackers à messages, permettez aussi STRICT . Il vous aidera à attraper la base du code Win16 en utilisant int où il devrait être en utilisant HWND , HANDLE ou autre chose. La conversion de ces derniers aidera grandement 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 compatibles avec Unicode. Cela ne signifie pas que vous devez tout convertir en langage TCHAR mais signifie que vous devez remplacer OpenFile , _lopen y _lcreat con CreateFile pour ne citer que les plus évidentes
5. LibMain est maintenant DllMain Le format de la bibliothèque et les conventions d'exportation sont différents.
6. Win16 n'avait pas de VMM. GlobalAlloc , LocalAlloc , GlobalFree y LocalFree devraient être remplacés par des équivalents plus modernes. Une fois fait, nettoyez les appels à LocalLock , LocalUnlock et amis ; ils sont maintenant inutiles. Non pas que je puisse imaginer que votre application fasse cela, mais assurez-vous que vous ne dépendez pas de WM_COMPACTING pendant que vous êtes là.
7. Win16 n'avait pas non plus de protection de la mémoire. Assurez-vous que vous n'utilisez pas SendMessage o PostMessage pour envoyer des pointeurs vers des fenêtres hors-processus. Vous devrez passer à un mécanisme IPC plus moderne, comme les pipes ou les fichiers mappés en mémoire.
8. Win16 n'avait pas non plus de multitâche préemptif. Si vous vouliez une réponse rapide d'une autre fenêtre, il était tout à fait cool d'appeler SendMessage et attendez que le message soit traité. C'est peut-être une mauvaise idée maintenant. Demandez-vous si PostMessage n'est pas une meilleure option.
9. Les tailles des pointeurs et des entiers changent. N'oubliez pas de vérifier attentivement tout ce que vous lisez ou écrivez sur le disque, surtout s'il s'agit de structures Win16. Vous devrez les refaire manuellement pour gérer les valeurs plus courtes. Encore une fois, la façon la moins douloureuse de gérer cela sera d'utiliser des craqueurs de messages lorsque cela est possible. Sinon, vous devrez rechercher et convertir manuellement les fichiers int a DWORD et ainsi de suite, le cas échéant.
10. Enfin, si vous avez bien compris, pensez à activer les contrôles de compilation 64 bits. Une grande partie des problèmes rencontrés lors du passage de 16 à 32 bits sont les mêmes que lors du passage de 32 à 64, et Visual C++ est en fait assez intelligent de nos jours. Non seulement vous attraperez certains problèmes persistants, mais vous vous préparerez également pour votre éventuelle migration vers Win64.

---

EDIT : Comme le souligne @ChrisN, le guide officiel pour le portage des applications Win16 vers Win32 est disponible en archive, et étoffe et complète mes points ci-dessus.

Answer 2

En dehors de la mise en place d'un environnement de construction adéquat, voici quelques points spécifiques que vous devrez aborder :

1. Les structs contenant des ints devront être changés en short ou passer de 16 à 32 bits. Si vous modifiez la taille de la structure et que celle-ci est chargée/sauvegardée sur le disque, vous devrez écrire un code de mise à niveau du fichier de données.

2. Les données par fenêtre sont souvent stockées avec le handle de la fenêtre en utilisant GWL_USERDATA. Si vous élargissez certaines de ces données à 32 bits, vos décalages vont changer.

3. Les structures POINT & SIZE sont de 64 bits dans Win32. Dans Win16, elles étaient de 32 bits et pouvaient être renvoyées sous forme de DWORD (l'appelant divisait la valeur de retour en deux valeurs de 16 bits). Cela ne fonctionne plus dans Win32 (c'est-à-dire que Win32 ne renvoie pas de résultats de 64 bits) et les fonctions ont été modifiées pour accepter un pointeur pour stocker les valeurs de retour. Vous devrez modifier toutes ces fonctions. Des API comme GetTextExtent sont concernées par ce problème. 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 des fichiers 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 de Windows.

Ce ne sont là que quelques-uns des problèmes dont je me souviens. Cela fait plus de dix ans que je n'ai pas fait de portage Win32. Une fois que vous vous y mettez, c'est assez rapide. Chaque base de code aura sa propre "sensation" en matière de portage, à laquelle vous vous habituerez. Vous trouverez probablement même quelques bogues en cours de route.

Answer 3

Il y avait un guide définitif dans l'article Portage du code 16 bits sur Windows 32 bits sur MSDN.

Answer 4

Le sdk win32 original avait un outil qui scannait le code source et signalait les lignes qui devaient être modifiées, mais je ne me souviens plus du nom de cet outil.

Lorsque j'ai eu à le faire dans le passé, j'ai utilisé une technique de force brute - c'est-à-dire : 1 - mettre à jour les makefiles ou l'environnement de construction pour utiliser un compilateur et un linker 32 bits. En option, il suffit de créer un nouveau projet dans votre IDE (j'utilise Visual Studio), et d'ajouter les fichiers manuellement.

2 - construire

3 - réparer les erreurs

4 - répétez 2 et 3 jusqu'à ce que vous ayez terminé

La difficulté 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 ligne en moins d'une semaine. J'ai également eu quelques petits utilitaires que j'ai simplement abandonnés et réécrits (pour la plupart) à partir de zéro.

Answer 5

Je suis d'accord avec Alan pour dire que les essais et les erreurs sont probablement le meilleur moyen.

Voici quelques bonnes conseils .