Convertir DLL en EXE

Un lanceur, un système de déploiement ou un périphérique peut n’accepter qu’un programme Windows même lorsque le composant disponible est une DLL. La solution pratique consiste généralement à créer un hôte EXE qui appelle la DLL, plutôt qu’à renommer ou convertir mécaniquement le fichier.

Qu’est-ce que le format DLL ?

Une DLL (Dynamic Link Library) est un fichier Windows Portable Executable (PE) contenant du code compilé, des données ou des ressources qu’un autre processus charge. Les applications utilisent les DLL pour les fonctions partagées, les plug-ins, les codecs, les fournisseurs de bases de données, les pilotes, les composants COM et les assemblies .NET.

Visual Studio, le .NET SDK, MinGW, Delphi et d’autres toolchains créent des DLL. Une DLL normale est conçue pour être chargée par un autre programme et expose des fonctions ou des classes managées ; elle ne fournit normalement pas le point d’entrée du processus, l’interface utilisateur et le comportement de démarrage attendus d’un EXE.

Qu’est-ce que le format EXE ?

Un EXE est un fichier PE destiné à démarrer en tant que processus Windows. Son en-tête identifie un sous-système exécutable et un point d’entrée ; il peut contenir un programme console, une application graphique, un installateur ou un service. Un EXE peut toujours dépendre de la DLL d’origine et d’autres fichiers runtime ; il n’est donc pas automatiquement autonome.

Comment créer un hôte exécutable

Lorsque le code source est disponible

1. Déterminez si la bibliothèque est du C++ natif, du .NET managé ou une autre sortie de compilateur ; l’hôte doit utiliser une interface et une architecture compatibles.
2. Dans Visual Studio, créez une Console App ou une Windows App via File → New → Project.
3. Ajoutez le projet de bibliothèque via Project → Add Project Reference. Pour un binaire managé sans son projet, ajoutez l’assembly comme référence et configurez son chemin de fichier dans le projet.
4. Implémentez le point d’entrée de l’hôte : main ou WinMain pour le C++ natif, ou Program.cs et Main pour une application .NET. Analysez les arguments, initialisez les paramètres requis, appelez l’API publique de la bibliothèque et retournez un code de sortie approprié.
5. Compilez avec Build → Build Solution. Visual Studio écrit normalement l’EXE dans un répertoire de configuration tel que bin\Release.

Pour une bibliothèque managée, la .NET CLI peut créer et publier l’hôte :

dotnet new console -n DllHost
dotnet add DllHost reference ..\Library\Library.csproj
dotnet publish DllHost -c Release -r win-x64 --self-contained true

Les fichiers publiés apparaissent sous DllHost\bin\Release\<target-framework>\win-x64\publish. Remplacez le target framework et le runtime identifier selon vos besoins. --self-contained true inclut le runtime .NET, mais ne garantit pas un fichier physique unique et ne supprime pas les dépendances natives.

Lorsqu’une DLL .NET managée est la seule ressource disponible

Utilisez ILSpy pour inspecter l’assembly, ses types publics, les assemblies référencés, le target framework et les méthodes appelables. Créez un hôte C# qui référence la DLL et appelle une méthode publique documentée. ILSpy peut décompiler le code à des fins d’analyse, mais l’obfuscation, les dépendances manquantes, le code unsafe et les restrictions de licence peuvent empêcher une reconstruction fonctionnelle ; n’utilisez le code que si vous en avez l’autorisation.

Pour produire un déploiement .NET à fichier unique, définissez PublishSingleFile sur true et publiez pour un runtime spécifique tel que win-x64. Les dépendances natives peuvent tout de même être extraites au runtime, et ce processus ne convertit pas une DLL native en code managé.

Lorsqu’une DLL native est la seule ressource disponible

Créez un hôte C++ dans Visual Studio ou une autre toolchain compatible. Effectuez un link vers la bibliothèque d’importation de la DLL, ou chargez-la au runtime avec LoadLibrary et obtenez les fonctions avec GetProcAddress. Vous devez connaître le nom de chaque fonction exportée, les types de paramètres, la disposition des structures, la convention d’appel, les règles de propriété et la séquence d’initialisation requise. Les méthodes de classes C++ ne constituent généralement pas une interface DLL stable, sauf si la bibliothèque documente un ABI compatible ; une API exportée de style C est plus facile à appeler.

rundll32.exe example.dll,ExportedFunction n’est pas un convertisseur. Il ne fonctionne qu’avec des exports correspondant à la signature de callback restreinte attendue par rundll32, et ne convient pas aux fonctions arbitraires, aux méthodes C++ ou aux bibliothèques nécessitant des arguments ou une initialisation personnalisés.

Limites de compatibilité et de conversion

• Renommer library.dll en program.exe ne modifie que l’extension du nom de fichier. Cela n’ajoute pas de point d’entrée exécutable et ne modifie pas les métadonnées PE.
• Une DLL peut être un plug-in destiné à un hôte particulier, n’exposer aucune API publique utilisable, nécessiter une configuration ou un état du registre, ou dépendre de DLL supplémentaires, de pilotes, d’un enregistrement COM ou des runtimes Visual C++/.NET. Un wrapper ne peut pas remplacer ces exigences.
• Faites correspondre l’architecture du processus et de la bibliothèque : un hôte x86 nécessite une DLL x86, tandis qu’un hôte x64 nécessite une DLL x64. Un processus 32 bits ne peut pas charger une DLL 64 bits.
• Les assemblies .NET managées et les DLL natives nécessitent des outils différents. ILSpy est destiné aux assemblies managées ; les binaires natifs nécessitent généralement le code source, un SDK, la documentation des exports, des headers compatibles et un compilateur correspondant. Des outils tels que dumpbin /exports de Visual Studio peuvent inspecter les exports natifs, mais ne peuvent pas déduire leurs types de paramètres.
• Il n’existe pas de convertisseur en ligne généraliste réputé capable de transformer une DLL arbitraire en EXE fonctionnel. Les services de conversion de fichiers en ligne ne peuvent pas inventer un point d’entrée ou un wrapper et peuvent exposer des binaires propriétaires ou dangereux ; effectuez le travail localement avec Visual Studio, le .NET SDK ou ILSpy.