Ayant longtemps travaillé sur MS-DOS, Windows 3.x, 9x et Me, j'avais des codes comme le tien qui ont cessé de fonctionner sur NT/2000/XP. Pareil pour certains logiciels. Ce problème est d'ailleurs très connu. En fait, un système d'exploitation multitâche moderne ne doit jamais laisser une application accéder directement à un port matériel. Imagine deux applications qui accèdent en même temps à une imprimante branchée sur le port parallèle. Conséquence: conflit d'accès au port. C'est pour cette raison qu'on doit passer par un pilote sous les systèmes NT/2000/XP. Ce pilote organise l'accès au port voulu pour les applications qui le demandent. On peut utiliser les APIs de Windows ou certaines librairies comme la fameuse inpout32.dll. Cette dernière installe justement un pilote fonctionnant en kernel mode pour gérer l'accès aux ports.
DosBox est un émulateur conçu pour permettre de faire tourner les vieux programmes MS-DOS sur les systèmes récents. Il n'est pas du tout fait pour encourager les programmeurs à continuer à utiliser les vieilles techniques pour les faire tourner sur les systèmes modernes. Essaie plutôt de voir toutes les belles choses que ces systèmes récents nous offrent en tant que programmeurs.
Tu peux mettre un zip contenant le projet complet avec un exécutable en démo. Tout le monde pourra ainsi tester.

Salut,
Ce genre de code ne peut marcher que sur MS-DOS, Windows 3.x, 9x et Me. Sur Windows NT/2000/XP/Vista/Seven l'accès direct aux ports est interdit car il faudra passer par un pilote.

@SHORZY tu peux regarder parmi mes codes source suivants:
http://www.cppfrance.com/codes/AFFICHAGE-SUR-ECRAN-OSD-WIN32_38898.aspx
http://www.cppfrance.com/codes/CONTROLE-VOLUME-OSD-WIN32_38949.aspx
http://www.cppfrance.com/codes/CHRONOMETRE-OSD-WIN32_48929.aspx
Désolé, je ne fais que du Win32 API jamais de QT.

Franchement, je ne me suis jamais penché sur le sujet mais je pense que si on a vraiment besoin de contrer ces techniques, on a la possibilité de faire un hook API en kernel mode. On pourra intercepter et détourner pour notre processus LdrLoadDll() ou même CreateRemoteThread(). Ce n'est qu'une piste et il y en aura sûrement d'autres.

Microsoft a prévu toutes ces fonctions juste pour les besoins de débogage. C'est précisé par MSDN. La technique du CreateRemoteThread() est une idée de Jeffrey Richter qui l'a bien détaillée dans son livre "Programming Applications for Microsoft Windows" publié à la fin des années 90 par Microsoft. Il y a également parlé du sous-classement de fenêtre d'un autre processus mais sans fournir d'exemple de code.
Il est toujours très utile de comprendre comment les choses fonctionnent. Ainsi, si on a besoin de contrer ces techniques dans nos applications, on sait au moins ce qu'on doit faire.

Je viens de faire une petite investigation et, effectivement, la fenêtre du visualistaur appartient bien au process explorer.exe. C'est lui qui la crée. Elle n'a donc pas son propre process. Ceci explique pourquoi la dll ne s'injecte que la première fois. Les tentatives suivantes
échouent car la dll est déjà chargée dans le process explorer.exe. Puisque le sous-classement se fait dès le chargement dans DllMain(), cette dernière ne sera plus appelée et donc la fenêtre cible ne sera pas sous-classée. Il vaut donc mieux éviter ce genre de fenêtre et ne faire des tests qu'avec celles ayant leurs propres processus. Une fois fermées, leurs processus seront terminés et notre dll se trouvera libérée.

Je n'avais pas faits de tests avec le visualisateur d'images de Windows car j'utilise un autre programme. Je viens de faire un test et c'est vrai ça ne marche que la première fois avec la visionneuse de Windows et la dll n'est effectivement pas libérée. Ca ne vient pas de mon code car normalement le système devrait forcer la libération de la dll une fois le processus de la visionneuse terminé. En essayant de supprimer la dll, le message d'erreur dit : "Cette action ne peut pas être réalisée car le fichier est ouvert dans COM surrogate". Je vais ce soir creuser un peu pour y voir un peu plus clair.
Pour ta fenêtre sans focus, dans le code de la dll, colle les lignes suivantes dans la procédure de sous-classement:
case WM_MOVING:
case WM_SIZING:
{
    RECT *pRect=(RECT*)lParam;
    SetWindowPos(hwnd, 0, pRect->left, pRect->top, pRect->right-pRect->left, pRect->bottom-pRect->top, 0);
    return TRUE;
}

Tu dois voir du coté de la dll. Comme précisé dans la présentation, le code de la dll est en pur C. Il ne suffit donc pas de le coller dans un nouveau projet C++. La seule modification à apporter est d'ajouter extern "C" devant la fonction DllMain:
extern "C" int APIENTRY DllMain(...
Le programme Injecteur n'utilise la dll que pour l'injecter dans le processus cible. Elle se trouve donc chargée par ce dernier et tant que ce processus n'est pas fermé la dll ne sera pas libérée donc impossible de la supprimer ou la modifier. C'est tout à fait normal. Tu n'as qu'à fermer toutes les fenêtres que tu as sous-classées pour libérer la dll. L'injecteur n'est pas responsable de sa libération. J'avais pensé ajouter un autre bouton qui appelle une autre fonction qui forcera le processus, ou tous les processus, cible à libérer la dll mais cela comporte le risque de les faire planter. Faute de temps, je ne l'ai finalement pas jugé nécessaire. Je vais revoir cette option plus tard.
Même après fermeture de l'injecteur, les fenêtres déjà choisies restent sous-classées et ont donc encore besoin de la dll. Quand tu relances l'injecteur puis tentes de re-sous-classer l'une de ces fenêtres, un message d'erreur te dira que cette fenêtre a déjà été sous-classée. C'est encore tout à fait normal. D'après les tests que j'ai faits je n'ai remarqué aucune anomalie.
J'espère que les choses sont plus claires maintenant.

Belleney >> C'est bien, d'ailleurs pour "néophyte" je ne parlais pas de toi. Mais j'espère que tu n'as pas loupé la série Windows NT à partir de 1993 ( NT 3.1, NT 3.51, NT 4, Win 2000) qui permettait de voir Windows autrement. On comparait souvent, à tort, Linux à Windows 3.xx, 9x et Me. Ces derniers étaient sur le point d'être abandonnés au profit de la technologie NT reprise dans XP, Vista et Seven. Pareil pour toutes les versions Win serveur. D'ailleurs, j'aime beaucoup les versions Linux serveur. Mais en tant que programmeur, je trouve plus intéressant et plus profitable de travailler sur un système utilisé par 90% que sur un autre utilisé par seulement 1%. Les acquis théoriques, mis en pratique, permettent, en plus du gain de temps, de chasser certains préjugés ou les fausses impressions et de voir les choses telles qu'elles sont. C'est vrai que, même si Windows est abondamment documenté il reste quand même certains points sombres que Microsoft ne peut ou ne veut mettre en lumière. C'est justement le but de ce genre de code source proposant de petites trouvailles qui divulguent certaines fonctionnalités pas assez documentées.

Belleney >> Il parait que tu ne connais pas assez Windows. En tant qu'administrateur, on peut tout faire que ce soit sur Windows ou autre. La plus grande faille de sécurité, qui concerne tous les systèmes sans exception, est de laisser un PC en mode administrateur entre les mains d'un néophyte. Seul un administrateur devrait avoir le droit d'installer ce genre de chose. Un utilisateur ayant un compte avec droits restreints ne pourra rien faire d'autre que ce que l'administrateur lui a préalablement installé.