Génération d’un lanceur EXE pour Windows

Lors du packaging, il est possible de créer un lanceur natif Windows pour une application protégée. Il s’agit d’un fichier exécutable purement Win32 que l’on peut exécuter en double-cliquant, sans que l’utilisateur ait besoin d’installer Java ni de voir run.bat.

L’EXE est optionnel et n’est pas généré par défaut. Une fois activé, les fichiers run.sh / run.command / run.bat existants sont conservés dans le package généré. Les deux méthodes de lancement utilisent exactement les mêmes paramètres d’archivage, de classpath, de classe principale et de JVM.

1. Champ d’application

Il est nécessaire de sélectionner au moins une plateforme cible Windows. La sélection simultanée des plateformes Linux ou macOS n’entraîne pas d’échec de la tâche: les sous-pakets pour ces plateformes sont générés normalement, mais sans fichier EXE, en utilisant toujours le script de démarrage existant. Lorsque aucune plateforme cible n’est Windows, une erreur est affichée directement.

2. Opérations GUI

1. Sur la page de sélection du fichier d’entrée et de la plateforme cible, cochez Générer des fichiers EXE d’applications Windows (x64/x86/ARM64) et sélectionnez au moins une plateforme cible Windows.
2. Ce commutateur se trouve avant la séparation entre le mode simple et le mode avancé, permettant ainsi la génération de fichiers EXE dans les deux modes.
3. Lorsqu’il est coché, une page Lanceur EXE pour Windows supplémentaire apparaît pour saisir le nom du fichier, le mode d’initiateur, l’icône et les informations sur la version Windows. S’il n’est pas coché, on accède directement à la page de confirmation finale.
4. Une fois l’EXE activée, le champ de saisie Paramètres de démarrage de la JVM n’apparaît que sur cette page de lanceur, afin d’éviter deux entrées pour le même paramètre. Les paramètres saisis sont enregistrés à la fois dans l’EXE et dans le script de démarrage.
5. La page de confirmation finale liste les plateformes sur lesquelles l’EXE sera réellement générée, ainsi que les champs du lanceur remplis.

3. Exemple CLI

Forme simplifiée, il suffit de utiliser --windows-exe :

p4j --target-platform windows-x64 javaapp app.jar dist --windows-exe

Spécifier le nom du fichier et le mode de fenêtre:

p4j --target-platform windows-x64 javaapp app.jar dist \
  --windows-exe \
  --exe-name MyApp.exe \
  --exe-mode gui \
  --exe-icon assets/app.ico

Générer trois architectures Windows en même temps et remplir complètement les ressources de version:

p4j --target-platform windows-x64,windows-x86,windows-aarch64 \
  springboot app.jar dist \
  --windows-exe \
  --exe-name MyService \
  --exe-file-version 1.4.2.0 \
  --exe-product-version 1.4.2.0 \
  --exe-company 'Example Inc.' \
  --exe-product 'Example Service' \
  --exe-description 'Example background service' \
  --exe-copyright 'Copyright (C) 2026 Example Inc.'

Les paquets Tomcat sont également pris en charge; l’EXE générée lance Tomcat en arrière-plan.

p4j --target-platform windows-x64 tomcat app.war dist --context /demo --windows-exe

4. Description des paramètres

Lorsque l’une des options --exe-* est sélectionnée, la génération de l’EXE est activée automatiquement, il n’est donc pas nécessaire d’écrire manuellement --windows-exe.

Le nom de fichier ne doit être qu’un nom de fichier, sans inclusion de /, \ ou de parties relatives à des dossiers; si le suffixe .exe est absent, il est ajouté automatiquement.

Les règles pour les deux champs de version sont identiques: des chiffres séparés par des points décimaux, allant de 1 à 4 segments, chacun ayant une valeur comprise entre 0 et 65535, par exemple 1.0.0.1. Windows stocke chaque segment en tant qu’entier sans signe de 16 bits, ce qui explique pourquoi les formats contenant des lettres ou des espaces tels que v1.0 ou 1.0-beta ne sont pas acceptés. Une valeur vide indique 0.0.0.0. Ces deux champs sont vérifiés avant le début du processus de compression, de sorte qu’aucune erreur ne survient en cours de compression.

5. Structure de sortie

Prenons l’application Java comme exemple: l’EXE et le script de démarrage se trouvent tous deux dans le répertoire racine du package:

dist/
├── MyApp.exe             # Le lanceur Windows a été ajouté.
├── app.p4jx
├── vlxjre/
├── lib/
├── run.sh
├── run.command
├── run.bat
└── README.md

README.md, présent dans le package, affiche le nom du fichier EXE généré ainsi qu’un message indiquant la signature du code.

6. Comportement lors de l’exécution

Le répertoire contenant l’EXE correspond au répertoire racine de l’application. Le lanceur ne prend en charge que les dossiers de runtime, d’archivage, de classpath et de travail situés à l’intérieur du répertoire racine; les chemins pointant vers l’extérieur du package, ainsi que ceux remplacés par des liens symboliques ou des points de connexion, sont rejetés et le processus ne démarre pas. Cela signifie qu’il est possible de déplacer ou de renommer l’ensemble du package, mais il n’est pas possible de copier l’EXE séparément pour l’utiliser.

Les paramètres JVM de l’EXE sont fixés lors du packaging et signés avec le bloc de paramètres; leur vérification a lieu au moment de l’exécution, et ils ne peuvent pas être modifiés après le déploiement. APP_JAVA_OPTS n’est valide que pour run.bat, et l’EXE ne le lit pas. Si vous devez modifier les paramètres JVM de l’EXE, veuillez le re-packager.

Pour les mêmes raisons, il n’est pas permis d’écrire des paramètres de démarrage dans l’EXE avec -javaagent, -agentlib, -agentpath, -Xbootclasspath et --patch-module. Lorsque ces paramètres sont transmis via --jvm-option, le packaging échouera directement.

7. Signature du code

Protector4J n’ajoute pas de signature d’éditeur à l’EXE généré, ni ne traite aucune clé Authenticode. Toutes les modifications PE, telles que l’icône, les ressources de version et les paramètres de démarrage, sont effectuées durant la phase de packaging; par conséquent, l’étape de signature doit être effectuée en dernier.

1. Terminer le packaging et s’assurer que l’EXE peut démarrer correctement l’application.
2. Effectuer une signature Authenticode à l’aide de votre propre certificat, en y ajoutant un timestamp RFC3161.
3. Vérifier la signature à l’aide de la politique /pa de Windows.

Une fois la signature terminée, ne modifiez plus ce fichier PE: toute modification rendra la signature invalide. Si vous devez changer l’icône ou le numéro de version, veuillez repackager le fichier et le signer à nouveau.

8. Champs du fichier de tâche

Le p4j-task.yml exporté utilise la version 2; les champs suivants sont enregistrés lorsque l’EXE est activé. Les fichiers de tâche de version 1 peuvent toujours être lus normalement.

windowsExe: true
exeName: MyApp.exe
exeMode: console
exeIcon: assets/app.ico
exeFileVersion: 1.4.2.0
exeProductVersion: 1.4.2.0
exeCompany: Example Inc.
exeProduct: Example Service
exeDescription: Example background service
exeCopyright: Copyright (C) 2026 Example Inc.

9. Questions fréquentes

Pour une liste complète des options CLI, consultez Référence des paramètres CLI; pour le processus de guide GUI, consultez Guide d’utilisation de l’interface graphique.