Amélioration des installations automatiques

[Wisblade]

Plop les gens.

Bon, l'installation automatique, c'est cool.

Mais ce qui suit, ce n'est pas vraiment dédié aux joueurs à qui la ligne de commande fait peur, ou qui s'évanouissent à la vue d'un compilateur. Ou d'un pavé de texte.


Donc, c'est cool. Ce qui l'est moins, c'est que si l'on est un gros geek collectionneur, ça plombe le disque car DOSBox est installé à chaque fois : 2000 jeux à 5 Mo la copie de DOSBox, ça pèse 10 Go au total.
Alors OK, le prix du giga de disque est ridicule, mais à force, c'est pénible tout de même... Car le jour où on veut upgrader DOSBox vers la nouvelle version "dlamorkitu", c'est même plus du masochisme, c'est "50 nuances d'abrutissement total".

De plus, ce qui est encore moins cool, et beaucoup d'entre vous ne peuvent même pas s'en rendre compte, c'est que créer les setups "à la main", même en copiant/collant comme un fou, c'est là encore un boulot parfaitement ingrat et absolument pas amusant à faire.

Or, de mon côté, j'ai la "chance" (hum....) de devoir me taper des créations de script d'installation "pros", du genre à faire blêmir tout débutant sous InnoSetup. Mais du coup, je sais ce qu'il est possible de faire, quand je n'ai pas déjà des librairies toutes prêtes sous le coude !
J'ai également pas mal d'expérience avec AutoIt, qui permet de finir l'automatisation lorsqu'elle s'avère impossible à faire en ligne de commande.

J'ai commencé à packager des jeux pour des potes, depuis mon propre disque virtuel DOS, et j'ai commencé à réaliser le travail (et les problèmes...) que ça engendre. Avec "seulement" 16 jeux, on dépasse déjà les capacité d'InnoSetup à faire un setup unique, je vais donc réfléchir à un mode totalement incrémentiel type dépôt pour gérer ça, car je gère en même temps que l'installation de DOSBox et du jeu l'intégration de ce dernier au front-end que j'utilise (DOS Panel, pas top, mais en attendant, ça fera le job).

Du coup, je propose les points suivants :

1. Lors de l'installation automatique, on peut installer le jeu en mode "autonome" (DOSBox intégré, mode actuel), ou en mode "incrémental" (un seul DOSBox partagé, les jeux à côté). Ceci est l'amélioration principale des setups existants. Pas de conversion "à la volée" d'un mode à l'autre, faudra désinstaller et réinstaller si on veut changer.
2. Perso, j'ai commencé à méchamment customiser mon disque virtuel pour simplifier non pas l'installation des jeux, mais leur utilisation : un seul batch de lancement général (gros machin de plus de 100 lignes...), on tape "~run <nom du répertoire>" et ça se lance tout seul, ça ferme DOSBox au besoin. Pas de commande "CD" à faire, pas besoin de faire un "DIR" pour se rappeler le nom de l'exécutable, montage des ISO automatiquement sans devoir jongler avec le front-end ou la configuration DOSBox, recherche de l'exécutable automatique avec ordre de priorité, possibilité de monter plusieurs CD, gros splash d'affichage rappelant les touches pour swapper les CD, etc.
   Du coup, l'intégration dans un front-end devient extrêmement simple : le nom du répertoire est nécessaire et suffisant pour créer l'entrée complète. Des fichiers de noms fixés (".INI", ".ICO", ".PDF", ".BAT", etc.) servent de pilote d'intégration pour chaque jeu. La configuration DOSBox est unique pour l'instant pour tous les jeux, à l'exception d'un fichier de map clavier (faudrait vraiment que je travaille sur un .MAP complet pour clavier AZERTY...)
3. De même, à la création du setup, je balance le préprocesseur ISPP sur le coup pour extraire, depuis les ".INI", toutes les informations adéquates pour générer automatiquement le script ISS et m'éviter de me taper douze mille lignes manuelles dans l'ISS, avec les inévitables erreurs que ça engendre.
   J'aurais pu faire ça avec un batch, mais en ISPP, c'est classe.
   Le script ISS package le jeu, filtre les éléments indésirables (les sauvegardes de jeu notamment, et les fichiers de contrôle propres au système de packaging), et génère automatiquement les entrées "[Components]" et "[Files]" adéquates.
   A l'exécution du setup, je reconstruis le fichier de configuration du front-end à la volée en fonction des jeux installés (ça peut se faire sous forme de DLL embarquée dans le setup pour gérer plusieurs front-ends), et je patche les fichiers nécessaires (ex : Warcraft II, il faut remettre le flag "intro" à "1" dans "WAR2.INI" pour que l'intro soit visible au premier démarrage).
   Le tout est bien entendu compilable depuis la ligne de commande.

Le "truc" ultime, ce serait donc d'avoir tous les jeux installés sur une machine, de pouvoir les tester correctement, et une fois ceci fait, on lance un batch et le packaging se fait tout seul sans intervention. J'ai commencé à mettre au point un système pour éviter de repackager un jeu qui n'a pas bougé, histoire d'éviter de faire chauffer le CPU et le disque pour rien.

Perso, je suis parti sur un setup générique normal, et un sous-dossier contenant des sous-setups spéciaux, un par jeu : chaque sous-setup est prévu pour n'être lancé QUE depuis le setup principal (il n'est aucunement autonome), en mode automatique - seule la barre de progression s'affiche.
Ainsi, je pourrais distribuer à mes potes les jeux qu'ils veulent sans les polluer avec ceux qui ne les intéressent pas.

Pour ici, le même système peut être appliqué bien sûr, mais devoir télécharger deux trucs pour chaque jeu risque de rebuter les débutants. Un mode du setup permettra donc de créer un setup 100% autonome à partir des setups existants (en fait, un setup-cadre "muet" qui incorpore les deux sous-éléments en une seule archive pour éviter un double packaging).

En gros, le principe d'intégration d'un jeu est le suivant (chaque extension "0:3" utilise le même nom de fichier "8:0", chez moi c'est "~LAK" par exemple) :

• On installe le jeu sur la machine virtuelle DOSBox normalement, dans son répertoire "8:0" (pas de gestion du "8:3" car l'interpréteur de commande de DOSBox est trop limité).
• On configure le jeu proprement, on repasse sous Windows.
• On crée un ".INI" permettant de saisir les informations requises pour packager le jeu.
• On met un ".ICO" pour faire joli.
• On renomme l'ISO du jeu pour qu'elle aie le même nom "8:0" que le répertoire du jeu, je réfléchis à un système pour pouvoir les numéroter mais j'avoue que les extensions du batch sous Windows me manquent...
• On prends un snapshot du répertoire "tout frais installé" (PAR2 des fichiers, MD5, copie binaire, OSEF).
• On vérifie que le jeu se lance correctement depuis le batch générique de lancement.
• On avance dans le jeu suffisamment pour pouvoir sauver une partie (idéalement, plus d'une).
• On rajoute dans le ".INI" les correctifs de déploiement : fichiers à ignorer, fichiers à patcher, etc.
• On ajoute les manuels du jeu (j'essaie de voir pour automatiser la connexion du PDF principal).
• Optionnel : ajout dans un front-end, le setup ramassera les fichiers de configuration des front-ends que l'on a décidé de gérer afin de s'en servir de modèle pour patcher celui de la machine où on installera le(s) jeu(x).
• Optionnel : identification du fichier de configuration du jeu afin de permettre un RAZ des paramètres du jeu, pour ceux qui ont une copie foirée.

Prêt à packager, pas une seule ligne d'ISS à modifier pour préparer le(s) setup(s). Au niveau boulot, ça veut dire aussi qu'un jeu simple peut être packagé grâce à deux fichiers, un ".INI" de description (<1 ko) plus un ".ICO" qui est de loin le plus gros fichier (100 à 300 ko en général pour une icône complète), et éventuellement un un batch de lancement (<1 ko aussi, je m'en sers par exemple pour forcer des jeux à se lancer dans certaines langues). Le batch le plus "lourd" que j'ai réalisé est celui de Worms, pour éviter d'avoir les vidéos qui se lancent à chaque démarrage et d'avoir des questions (559 octets...).

Heu, et si je propose ça, bien sûr, c'est que je peux aider à le faire, hein, c'est pas juste pour dire "ouais, les mecs, faites ça vite et bien et surtout, qu'on soit pas emmerdés par vos conneries techniques". Non. Je file un coup de main sur les points qui vous posent souci, ou si vous attendez un peu, je vous file le système que je mets au point et vous l'adaptez à votre goût.

Bon, tout ceci est un peu "en vrac", mais il se fait tard, j'ai faim et c'est juste pour donner l'idée générale de toute façon. Quel que soit le résultat de cette proposition, il va probablement y avoir quelques pages de topic avant d'arriver à un truc valable pour tous !

[reggio52]

Bienvenue à toi sur le forum, et dans l'équipe, puisque j'ai eu l'occasion d'échanger avec toi par mail. (enfin, je me suis occupé de réceptionner ton partage de manuel).

[Wisblade]

OK, je fais le lien maintenant (j'avais ton nom réel, pas ton pseudo ! ). Plus facile avec Wokie, les deux sont identiques sur mail et forum !

Bon, comme tu vois, j'ai mis un gros pâté, va falloir en discuter... Avec tout ça, j'ai pas encore bouffé, il est 1h15, ma femme et mon gosse dorment, je crois que je vais repartir au stand pour ce soir... Et laisser le reste de l'équipe digérer le pavé !

[The Uploader]

Salut

J'ai longtemps hésité de répondre face à ce pavé, et pour être honnête je ne suis pas sûr d'avoir tout compris. ^^

Dans l'état actuel des choses :
- On a essentiellement deux personnes qui s'occupent des abandonwares faciles sur leur temps libre (et y'a à faire ! Des jeux DOS à cracker, des jeux Windows à réparer, etc...)
- On a plein de jeux qui sont demandés en version abandonware faciles ou qu'on aimerait faire (exemple : Empereur, La Bataille pour Dune, sur lequel je suis bloqué depuis pfiou... 2 ans déjà ?)
- Les abandonwares-faciles c'est pas que ceux qui sont visibles sur le site, y'en a aussi plein qui sont faits régulièrement sur des fiches en préparation ou qui vont arriver (soit pour aider à la rédaction / test du jeu, soit pour ajouter une plus-value à la fiche)
- Pas mal de jeux nécessitent une version spécifique de DOSBox (exemple : DOSBox SVN pour certains jeux Windows 3.11, DOSBox Daum pour certains jeu Glide sous DOS. DOSBox ECE pour une meilleure émulation OPL3, etc. ...) et ne fonctionneront pas avec d'autres
- De plus en plus sont aussi des jeux n'utilisant pas DOSBox (mais ScummVM, ou PCem, ou des wrappers, ou autre). Soit parce que l'autre solution était meilleure (exemple : Urban Runner utilise ScummVM), soit parce que ce sont des jeux Windows à part entière.

Dans ces conditions, revisiter des abandonwares faciles pour les mettre à jour est difficile techniquement (parce qu'il faut être sûr que le jeu ne plante pas ou n'a pas un comportement anormal), et (plus subjectivement) moralement (si on refait les même, ou peut avoir l'impression de tourner en rond et on na pas l'impression d'avancer et d'apporter du neuf).

Mais les mises à jours, ça a déjà été fait. Liste non-exhaustive :
- King Quest's VII : Le jeu plantait au chapitre 3, corrigé avec une nouvelle ISO d'une réédition française (le jeu était alors à un "niveau de patch" différent)
- Dungeon Keeper qui a été mis à jour car on a appris à enlever la console de DOSBox, à faire disparaître l'invite de commandes avec START, et changé le dossier d'installation par défaut
- Blade Runner : usage de dgVoodoo2 pour que le jeu soit compatible avec les OS modernes de nouveau (et oui les versions automatiques commencent à avoir des problèmes de compatibilité avec le temps...), et amélioration du NOCD pour que le jeu se lance même si on a pas le moindre lecteur optique (un point que le crackeur d'origine n'avait pas anticipé).
- Dune pour lequel on a eu à la fois un magnifique patch VF, et l'usage de DOSBox ECE pour une meilleure émulation OPL3 et une meilleure prise en charge des écrans HD et un rendu des graphismes meilleur.
- Phantasmagoria : Correction de la VF et des vidéos, et meilleur paramètrage de DOSBox, unification des fichiers de données pour éviter le changement de CDs, et plein d'autres choses (merci Asylum et Threepwang pour ce travail de fourmi !).

(j'en prévois d'ailleurs une autre prochainement. Bon j'avoue, c'est sur un jeu que j'adore, mais y'a de vrais raisons techniques derrière aussi. )

Pour en revenir au système, je vois bien que DOSBox stagne depuis 10 ans (et même si on prend DOSBox SVN, le support de l'accélération graphique défaillant est toujours là, et le patch NukedOPL n'est toujours pas intégré, le rendu sur les écrans HD/4K en mode fenêtré est toujours ridiculement petit, et y'a pas de rendu graphique pixel-perfect), et que DOSBox ECE apporte plein de nouveautés cruciales pour le confort de jeu et/ou la compatibilité (OPL3 bien plus fidèle ce qui compte pour beaucoup de jeux, support des écrans HD/4K meilleur en mode fenêtre, support de l'accélération graphique amélioré, etc. ...). Mais dans les faits ça peut planter (notamment avec les jeux sous Windows 3.11), malheureusement.

Cependant, je pense que pas mal de jeux DOS (énormément d'abandonwares faciles sont des jeux DOS utilisant DOSBox 0.74 et 'juste' quelques paramétrages spécifiques) pourrait tous passer à DOSBox ECE. On les valide, et on les mets tous à jour. Dans le même temps, on pourrait les remettre à niveau avec le reste (chemin d'installation qui a évolué avec le temps, usage de -noconsole et de START, ...).
Tout ça pour dire que ton système pourrait nous enlever des problèmes de fidélité d'émulation et de compatibilité avec les OS modernes

Maintenant, on prévoit aussi un mode online sur le site pour jouer aux jeux DOS directement, ce qui pourrait rendre ces efforts caduques... ou pas :
- JSDOS n'est pas forcément aussi bien que DOSBox ou DOSBox ECE au niveau des performances (perfs 3D, mode Glide absent, ...) et de la fiabilité de l'émulation (le patch NukedOPL est uniquement dans DOSBox ECE)
- C'est encore uniquement dans les cartons
- Ça va utiliser le navigateur pour jouer, donc peut-être des cookies (et LocalStorage pour les sauvegardes semble-t-il : donc les sauvegardes faites en jeu sont dans le cache du navigateur en gros) ce qui peut ne pas plaire.

Pour les icônes, pas mal d'abandonwares faciles proposent des icônes refaits, mais j'avoue qu'on est pas des graphistes.
On aime ou pas, ça dépend si on a réussi à faire un bel icône (pas toujours facile).

Enfin, pas mal de sources de setups ont été perdues. On a toujours le résultat sur le site, mais pour pas mal d'entre eux si on veut les refaire, il faut récupérer les sources à partir du résultat à l'aide de InnoUnp.

Il ne récupère pas les sections Code, Registry, et d'autres, donc ensuite c'est à réparer.
La plupart de ces sections "perdues" ne sont pas utilisées quand on utilise un émulateur cependant.

Enfin, dans l'immédiat :
Pourrais tu partager ce système ?
Je suis curieux de le voir en détail. ^^

[Wisblade]

Plop.

J'ai longtemps hésité de répondre face à ce pavé, et pour être honnête je ne suis pas sûr d'avoir tout compris. ^^

Ben on va tenter d'éclaircir... J'ai un peu jeté les idées en vrac, aussi, donc c'est peut-être moi qui me suis mal exprimé.
Je vais tenter de répondre point par point aux éléments qui appellent une réponse/précision.

- On a essentiellement deux personnes qui s'occupent des abandonwares faciles sur leur temps libre (et y'a à faire ! Des jeux DOS à cracker, des jeux Windows à réparer, etc...)

Ben c'est aussi pour ça que je me propose... Par rapport à ce qui a sur le site, j'ai donc déjà réparé "Macadam Bumper", et j'ai exhumé de mes propres archives un "Lemmings", avec son data disk, qui n'affiche pas le pâté de couleur en début de niveau, et avec un trainer si besoin. Faut que je prenne mon courage à deux mains pour aller retrouver mes "fameux" CD tout dorés de l'époque au milieu des deux mètres cubes d'archives informatiques qui sont dans mon garage.

- On a plein de jeux qui sont demandés en version abandonware faciles ou qu'on aimerait faire (exemple : Empereur, La Bataille pour Dune, sur lequel je suis bloqué depuis pfiou... 2 ans déjà ?)

En fait, ce que je propose, c'est de se débarrasser de la partie pénible, à savoir fabriquer le setup - et je suis bien placé pour savoir que les copier/coller, c'est un nid à emm.... bien velu en plus d'être parfaitement rébarbatif à faire.
En gros : on "fige" plus ou moins la structure des jeux au niveau de la machine de développement / test. Une fois le jeu porté correctement et fonctionnel, en utilisant des éléments d'aide pour accélérer ce point sur les cas triviaux, on balance le script automatique et il va fabriquer le setup tout seul. Le test du setup produit est réduit au strict minimum : une énorme partie est faite à la création du setup, l'autre au niveau des tests génériques du système.
Cerise sur le gâteau, j'ai pu tester (avec succès) l'installation en mode non-administrateur.
Le but est aussi de capitaliser au maximum les éléments qui peuvent l'être : par exemple, j'aime bien le scaler "hq3x", je n'ai pas envie de patcher 2k fichiers de conf si jamais je veux passer dans un autre mode : je veux le faire à un seul endroit. D'où la centralisation d'un seul DOSBox gérant un nombre non-négligeable de jeux sans requérir de version particulière.

- Les abandonwares-faciles c'est pas que ceux qui sont visibles sur le site, y'en a aussi plein qui sont faits régulièrement sur des fiches en préparation ou qui vont arriver (soit pour aider à la rédaction / test du jeu, soit pour ajouter une plus-value à la fiche)

Justement, ça sert aussi à accélérer ce processus et à le simplifier.

- Pas mal de jeux nécessitent une version spécifique de DOSBox (exemple : DOSBox SVN pour certains jeux Windows 3.11, DOSBox Daum pour certains jeu Glide sous DOS. DOSBox ECE pour une meilleure émulation OPL3, etc. ...) et ne fonctionneront pas avec d'autres

Je n'ai pas prévu ça pour l'instant, car je n'ai pas encore eu le cas de figure, mais ce sera facile à intégrer.
Le principe est celui d'un déploiement modulaire usuel, que tu as forcément déjà rencontré (c'est ce que proposent des logiciels comme Visual Studio, Office, et j'en passe) :

• Un "kit de base" est déployé, avec peu ou pas d'options d'installation à part le répertoire (et encore...). Dans la version préliminaire que j'ai écrite, il y a DOSBox et Dos Panel, le front-end, plus l'équivalent du répertoire système tournant sur DOSBox (les outils d'automatisation servant à lancer le jeu facilement, donc). Tes versions custom de DOSBox s'installeront dans ce kit.
• Les jeux s'ajoutent à ce système, avec la dépendance adéquate (treeview InnoSetup usuel du panel [Components]).
• Parmi les tâches post-install possibles, tu as l'intégration au front-end des jeux installés, la remise à zéro des confs, la création des icônes, la langue, etc.
• En tâche déjà existante, il y a le patch de fichier de configuration à la volée (ex : remettre "intro=1" dans "Warcraft II" après l'installation), la gestion du déplacement des jeux (du répertoire de packaging "en dur" dans les fichiers de conf vers le répertoire final d'installation), et l'intégration dans Dos Panel.
• En tâche préliminaire, il y a l'analyse des jeux installés, la création des sections [Components] et [Files] adéquates, et la génération automatique des patchs correspondants.
• En terme d'éléments hybrides, il y le

Le principe est aussi de pouvoir soit installer un mode "collection", c'est à dire un setup unique (et petit...) pilotant un (gros) ensemble de sous-setups, un par jeu, et d'installer tranquillement ce que l'on veut. Pour l'utilisateur final : il charge le setup maître, chaque sous-setup qu'il souhaite - comme il chargerait une archive 7z donc - et il peut ensuite tout installer d'un coup sans se peler le noyau.
Un autre mode est de fusionner le setup maître et un sous-setup pour créer un setup autonome, unique, installant uniquement le jeu lui-même. Ce mode peut même servir de base à une installation portable standardisée, qui évite donc carrément de devoir déployer le jeu "pour de vrai".
Bien entendu, l'apport majeur, c'est la possibilité d'installer les jeux en mode non-administrateur, ce qui permet d'éviter de trop polluer la machine et/ou de pouvoir nettoyer facilement l'installation sans devoir désinstaller à la main des centaines de jeux.

- De plus en plus sont aussi des jeux n'utilisant pas DOSBox (mais ScummVM, ou PCem, ou des wrappers, ou autre). Soit parce que l'autre solution était meilleure (exemple : Urban Runner utilise ScummVM), soit parce que ce sont des jeux Windows à part entière.

Je n'ai pas regardé encore ScummVM, je dois dire, mais j'avoue que je ne vois pas la différence (en terme de setup bien sûr) entre installer une version custom de DOSBox et un tout autre émulateur.

Dans ces conditions, revisiter des abandonwares faciles pour les mettre à jour est difficile techniquement (parce qu'il faut être sûr que le jeu ne plante pas ou n'a pas un comportement anormal), et (plus subjectivement) moralement (si on refait les même, ou peut avoir l'impression de tourner en rond et on na pas l'impression d'avancer et d'apporter du neuf).

La remise à jour est plus simple qu'on ne le croit. En gros, sur un jeu qui tourne, je passe une minute à préparer le packaging et deux heures à trouver une icône (il est bien entendu tout à fait acceptable de coller une icône générique ou basse résolution lorsque l'on n'a pas trouvé "la" bonne et jolie qui va bien).
Après, tu lances la compilation, et si ça prend une nuit complète, on s'en fout : on n'est pas devant à faire des clics...

Mais les mises à jours, ça a déjà été fait. Liste non-exhaustive :

Peu importe la RAISON de la mise à jour. Vous n'êtes pas débiles : si vous faites une MAJ, c'est que c'est nécessaire et/ou que ça améliore le confort du jeu. Le sujet n'est pas là.
Le truc, c'est de pouvoir packager ça facilement ensuite. Ce n'est pas parcequ'on cause le Turbo Debugger dans le texte qu'on est un dieu d'InnoSetup, et réciproquement. Le but, c'est qu'en deux coups de cuillère à pot, n'importe qui peut installer le système de packaging sur sa machine et créer le(s) setup(s) de ses travaux d'adaptation en lançant un simple batch, sans se poser la question de "comment".
J'ai rendu automatique des compilations multi-plateforme, impliquant des VM et plusieurs langages distincts, avec un déploiement distribué, je sais que c'est possible à faire. Mais encore faut-il savoir que ça l'est, et avoir les billes pour le réaliser. C'est là que j'apporte mon aide. Cracker des jeux en mode complexe, j'ai arrêté il y a 20 ans. Les trads, j'aime bien les utiliser, mais pas les faire (la dernière que j'ai faite était la trad française d'InnoSetup, la maintenir me gonflait). Tout ça, je le laisse à des gens qui s'en occuperont bien mieux que moi. Par contre, l'automatisation et l'industrialisation, c'est parmi mes domaines de compétences les plus avancés, là je peux aider utilement.

Cependant, je pense que pas mal de jeux DOS (énormément d'abandonwares faciles sont des jeux DOS utilisant DOSBox 0.74 et 'juste' quelques paramétrages spécifiques) pourrait tous passer à DOSBox ECE. On les valide, et on les mets tous à jour. Dans le même temps, on pourrait les remettre à niveau avec le reste (chemin d'installation qui a évolué avec le temps, usage de -noconsole et de START, ...).

Et ça te prendrais dix minutes avec mon système, tu peux même proposer au choix l'un ou l'autre dans le setup. Cool, non ?
Si DOSBox ECE est si avancé que ça, je peux démarrer mes tests avec plutôt que de sticker sur DOSBox 0.74...

Tout ça pour dire que ton système pourrait nous enlever des problèmes de fidélité d'émulation et de compatibilité avec les OS modernes

Yep. Et surtout, le fait de pouvoir tout distribuer facilement. Même l'upload serveur pourrait être automatisé, voire la MAJ de la fiche suivant comment c'est gaulé en BDD.
Faudrait aussi voir, mais il devrait être possible d'utiliser le serveur pour remplir une grosse partie des .INI que je me tape à la main : l'ID BDD du jeu à la place du bouzin, et on va récupérer les infos directement sur serveur via un CGI-like (REST ?) pour remplir la description, le type / la catégorie du jeu, etc.

Maintenant, on prévoit aussi un mode online sur le site pour jouer aux jeux DOS directement, ce qui pourrait rendre ces efforts caduques... ou pas :

Joker à ce niveau. Je ne connais pas cette partie, faudra adapter vous-même ou me filer des specs très détaillées.
En tant que collectionneur, par contre, c'est un principe que je n'aime pas. J'aime avoir le jeu "chez moi".

Pour les icônes, pas mal d'abandonwares faciles proposent des icônes refaits, mais j'avoue qu'on est pas des graphistes.

Moi non plus, je ne suis pas graphiste, mais transformer un PNG en .ICO multi-résolution, ça va, donc je fais la plupart des miennes ainsi.
Faudra aussi que je regarde côté front-end : pour l'instant, aucun ne me convient totalement... Dos Panel est le moins pire, mais il ne propose pas plusieurs manuels par jeu et les icônes sont seulement en 32x32, ce que je trouve dommage, et son système de configuration est une vraie bouse.

Enfin, pas mal de sources de setups ont été perdues. On a toujours le résultat sur le site, mais pour pas mal d'entre eux si on veut les refaire, il faut récupérer les sources à partir du résultat à l'aide de InnoUnp.

Caduque, là. En passant au nouveau système, tu n'as plus besoin de les "refaire", ils se referont quasiment tout seuls.

Pourrais tu partager ce système ?

Non, je suis juste venu ici pour faire rêver et me barrer...
Pour l'instant, ce que j'ai en stock, c'est le prototype : un setup "monolithique" (mais 100% fonctionnel), écrit à l'origine pour distribuer des jeux à mes amis qui sont des quiches en configuration système, mais qui étaient - et sont toujours ! - de gros joueurs. Notamment, proto oblige, ça manque cruellement de commentaires.

Ce mode n'est pas viable pour le site, car je vois mal tenter de distribuer un setup qui risque fort de friser le TERAOCTET... Je confesse être un bourrin, mais là, même moi ça me choque !

Toutefois, ça te permettra de voir un peu ce que je propose. Par contre, en attache forum, ça va le faire moyen, et je n'ai pas envie non plus de publier "publiquement" un truc qui est plus un concept de faisabilité qu'un truc viable.
Je fais un checkout de la dernière version stable (je suis en train de développer le système permettant de réduire le coût de compilation des setups, en évitant de devoir repackager un jeu qui n'a pas bougé). C'est relativement long et complexe, car je suis aussi en train de prévoir que des quiches en InnoSetup puissent l'utiliser, donc je blinde un max.

Je t'envoie ça en MP dans un petit moment.

J'espère que c'est un peu plus clair.