/* Topic des codeurs [9] */

Dafyd · Le 16/01/2018, à 17:05

Le problème c'est qu'après des années à faire du Python, du Java (beurk) et du C++, j'ai un peu de mal à penser mon code autrement qu'en OO.

Dafyd · Le 17/01/2018, à 11:56

Salut à tous,

Quelqu’un connaîtrait une bonne ressource (livre ou net) sur le C++ moderne ? Du genre move semantic, raii, smart pointers, etc etc ? J’avoue nager un peu dans tout ca...

Merci

grim7reaper · Le 19/01/2018, à 09:22

Salut,

La plupart des bouquins de référence ont été mis à jour, donc tu peux utiliser :

Programming: Principles and Practice Using C++ (2e édition) de Bjarne Stroustrup
The C++ Programming Language (4e édition) de Bjarne Stroustrup (la bible)
C++ Primer (5e édition) de Lippman et al. a aussi été mis à jour pour le C++11

Pour des trucs plus orienté C++11/C++14 il y a :

A Tour of C++ de Bjarne Stroustrup
Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14 de Scott Meyers

Pour des sujets plus spécifique :

C++ Concurrency in Action: Practical Multithreading d’Anthony Williams (donc un gars très bien placé pour parler de ça)
The C++ Standard Library: A Tutorial and Reference (2e édition) de Nicolai M. Josuttis

Dafyd · Le 19/09/2018, à 22:04

Et ben... plus de codeurs sur ce forum ?

Elzen · Le 19/09/2018, à 23:04

J'peux continuer à poser des questions techniques autour de Touhy auxquelles personnes ne va répondre, si tu veux

(Blague à part, j'ai proposé une conf' à Capitole sur Touhy et quelques uns des choix de dev que j'ai fais dessus, je tâcherai p't'être de vous exposer ça un de ces jours)

grim7reaper · Le 20/09/2018, à 10:06

Si si, on est encore là.

Dafyd · Le 23/09/2018, à 01:32

Bah moi perso, après quelques projets jamais aboutis, dans différents langages, pour différentes raisons, j'ai décidé de réfléchir à quelque chose de plus sérieux avant de me mettre à coder sans but précis et donc ne rien produire j'ai quelques idées !

Pylades · Le 23/09/2018, à 06:57

Encore là, mais ça fait un moment que j'ai plus eu le temps de toucher à du code…

grim7reaper · Le 25/09/2018, à 18:32

Ha, Pylades!
L’un des pères fondateurs du TdC

Ça prend plus de temps de débugger des humains que du C hein

vv221 · Le 26/09/2018, à 12:14

Dafyd a écrit :

Et ben... plus de codeurs sur ce forum ?

Bah si, mais on code, ce qui laisse peu de temps pour bavarder

The Uploader · Le 30/09/2018, à 21:31

Dafyd a écrit :

Et ben... plus de codeurs sur ce forum ?

Si, si !

Un exemple en C89 (toolkit MSVC, Win32 x86, Pentium II ou ultérieur requis car j'aime prendre en charge aussi les vieux coucous sous Windows XP) (j'ai pas tout écrit, c'est un fork) :

Windows Multimedia CD Audio OGG player wrapper, un wrapper pour le sous-ensemble de l'API WinMM (API héritée de l'ère Windows 3.X/9.X pour le multimédia dans Windows) concernant la lecture des musiques CD à l'aide du périphérique MCI pour les CD audio.

Permet d'avoir les musiques CD sans le CD, et de corriger souvent l'usage de l'API WinMM (le jeu ne prévoyait pas la répétition des musiques, par exemple. Ou il mettait le volume du son à 0 donc pas de musique. Ou il ne détecte pas de CD à l'aide du vrai WinMM, et n'envoie pas de commandes pour lire la musique... Bon là je modifie le comportement de l'exe du jeu avec OllyDbg pour qu'il passe outre, et pas le wrapper).

Un des derniers développements fut la prise en charge de mciSendStringA (la version ANSI et basé sur des chaînes de caractères de mciSendCommand). Au menu : reconnaissance de tokens, parsing, le tout avec les version sécurisées de strtok et consorts. Bon c'est une adaptation/modification d'un patch existant, mais ça a permis de prendre en charge les rares jeux utilisant mciSendStringA, tel que le port PC de The House of the Dead.

Ça a l'air plus suivi que les autres développements (tous arrêtés ou presque) de Ogg-Winmm sur GitHub, et ça c'est cool.
* Une star (surveillance ? Je sais toujours pas trop ce que c'est !) par juanitogan, l'auteur de plein de fan-patchs super avancées sur des jeux Sierra (de la rétro-ingénierie de dingue)
* Un premier fork de mon fork il y a quelques jours (identique pour le moment)
* Une demande de support pour le jeu DOS/Windows (deux versions sur le CD, comme ça se faisait souvent à l'époque) Ignition reçue à l'instant par mail. On dirait un autre cas rare d'un jeu développé par des gens qui se haïssent (ils utilisent mciSendString plutôt que son équivalent "binaire" mciSendCommand)

Autre exemple en Delphi 1 (un fork là aussi) :

RUNEXITW

github a écrit :

Fork of RUNEXIT (http://www.shdon.com/software/tools) for games that use an executable file which launches another executable
Description : (from http://www.shdon.com/software/tools)
"A simple 16-bit Windows utility intended to run a single application and immediately closing down Windows after that application quits. For example, the command win c:\runexit\runexit.exe notepad would start Windows 3.1 with Notepad open and return to the DOS prompt when Notepad is closed."
How to modify it:
Get Windows 3.11 inside DOSBox : http://www.vogons.org/viewtopic.php?t=9405
Install Borland Delphi 1 : https://winworldpc.com/product/delphi
Clone source
??? profit!

Contexte :
Quand on automatise un jeu Windows 3 (qui peut être 16 bit, ou 32 bit à l'aide de Win32s), on veut pouvoir 1.le lancer, 2.Quitter Windows dès que jeu a fini (ce qui ferme DOSBox). Or, pas mal de jeux utilise un exécutable qui ne fait que lancer un autre exécutable avant de quitter. Il faut alors changer de stratégie : 1.Lancer l'exe, 2.Chercher une fenêtre, 3.Attendre que la fenêtre ne soit plus avant de quitter Windows.

Bon rien de super compliqué, à part se taper Delphi 1, l' "IDE" qui va avec, le tout dans DOSBox, et le peu de l'API Win16 auquel on a accès pour atteindre l'objectif (seule route : D'abord ShellExecute, ensuite WindowFromPoint, IsWIndow, ExitWindows, et puis c'est tout)

Dernier exemple (Win32s, C89, Microsoft VIsual C++ 4.1 de juin 1996) :

J'avais appelé ce projet "RUNCOLD". 30 lignes de code tout mouillé, mais chaque ligne n'est pas là sans raison. C'est intégré à la version automatique de Donald In Cold Shadow, apparue hier avec la fiche.
Adapté quelque peu plus tard pour la version automatique de The Amazon Trail

En gros :
- J'avais besoin que le jeu s'exécute dès le départ en plein-écran. Impossible de le modifier avec OllyDbg, car le jeu utilise une bibliothèque qui utilise des API non-documentées du kernel Windows 3.X/9.X (le jeu est compatible Windows 3.X et 95/98 et cible ces deux versions de Windows) pour remplacer entièrement GDI, chose qui d'ailleurs ne fonctionne pas sur d'autres Windows. Enfin, modifier le jeu pour le mettre en plein-écran via ce biais était pas impossible, mais ça plantait...
- On est en 32 bit car j'avais besoin d'utiliser PostMessageA, et même si sous Windows 3.X tout se passe dans le même espace d'adressage, ça ne permet pas d'aller poster un message sur la boucle des appels d'une fenêtre Win32 depuis une application Win16. Donc impossible d'adapter RUNEXITW. Apparemment, le thunking ça ne marche que dans un sens (code 32 bit vers code 16 bit), ou quelque chose comme ça. En tout cas, rien n'y faisait.
- On s'exécute là aussi dans DOSBox + Windows 3.11, mais on est 32 bit grâce à Win32s
- Microsoft Visual C++ 4.1 (même pas l'antédiluvien MSVC++ 6 !) est le dernier IDE de MS à prendre en charge Win32s. Fonctionne toujours parfaitement sous Windows 10 ! Pour la gestion des sources (perdues depuis), j'utilisais tout de même git.

- Processus du programme :
* CreateProcessA (avec chemin en dur, car dans l'environnement émulé, ce sera toujours C:\DISNEY\CLDSHADW\CLDSHADW.EXE le chemin. Gestion des strings en C évité. )
* WaitForInputIdle (on attend que la fenêtre existe, et soit prête à recevoir des messages)
* FindWindow (recherche de la fenêtre du jeu à l'aide de sa classe spécifique. Pas moyen d'avoir la mauvaise fenêtre, dans l'environnement émulé, à part le gestionnaire de programmes, seul le jeu a une fenêtre. Nom de la classe définie par le jeu découverte grâce à OllyDbg)
* SetForegroundWindow (on la met au premier plan)
* SetActiveWindow (pour pouvoir la rendre active)
* PostMessageA (pour pouvoir lui envoyer un message, simulant l'usage de l'entrée Fullscreen du menu Screen). Cet entrée porte un ID. Il est interne, mais a été découvert grâce à Resource Hacker, le dialogue décrivant les menus de la fenêtre étant une ressource de l'exécutable)
* On attend que la fenêtre n'existe plus avant de quitter (polling avec FindWindow + Sleep. Il est recommandé d’utiliser plutôt WaitForSingleObject, mais ça n'a jamais voulu fonctionner).

Pour déboguer ça, il faut lancer DOSBox, Windows 3.11, et lancer notre programme depuis DOSBox. C'est pas instantané, et la moindre erreur résulte en une General Protection Fault ou autre message inexploitable.

Alors y'a une modif de l'exe du jeu sur Old-Games.Ru pour qu'il utilise autrement WinDirect (la bibliothèque qui remplace GDI) et s'exécute nativement. Mais on perd le mode plein-écran, et le jeu s'exécute toujours par défaut dans une toute petite fenêtre en 320x200. Au mieux en 640x400 en allant dans le menu Screen. Sur un écran HD, c'est pas très lisible.

En gardant DOSBox, on garde la compatibilité avec les manettes modernes (important pour un jeu de plateformes), la possibilité d'utiliser des scalers (HQ2X, HQ3X, Super2xSAI ...), la pérennité de la solution quel que soit la variante de Windows, et le mode plein-écran. On peut aussi utiliser une variante de DOSBox pour Linux, OS/2, ou autre. Et WinDirect peut toujours remplacer GDI avec ses appels à des fonctions non-documentées du kernel Windows de l'ère 16 bit s'il veut.

Le jeu est maintenant en plein-écran dans l'émulateur, comme les versions SNES ou Megadrive, au lieu d'être dans une fenêtre en 320x200 dans la fenêtre par défaut en 640x480 de DOSBox. Non mais oh ! Et les commits sur le SVN de DOSBox évoque la prise en charge des écrans HiDPI...

Le mode plein-écran est aussi le seul mode du jeu où le scrolling est parfait (pas de déchirures lors des mouvements). Là encore, comme sur les versions console. Et au contraire des versions console, le port PC bénéficie de musiques CD.

Enfin, tout ça, c'est pour les versions automatiques d'Abandonware France, auxquelles je participe beaucoup depuis des années.

Rien de super compliqué (j'en suis pas encore à écrire mon propre wrapper DirectDraw/Glide/OpenGl/Direct3D - et heureusement pour mes cheveux ! -, pour ça je m'appuie sur ddrawCompat ou dgVoodoo2, voire l'Application Compatibility Toolkit qui permet d'activer des shims avancées du genre ForceDirectDrawEmulation), mais je m'amuse beaucoup.

Et sinon, DOSBox v0.75 va sortir ! (la v0.74 a 8 ans déjà !) \o/

Voilà, je retourne dans ma grotte.

Dernière modification par The Uploader (Le 01/10/2018, à 08:57)

grim7reaper · Le 02/10/2018, à 09:10

@The Uploader: toujours aussi fan de DOS apparemment

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#126 Le 16/01/2018, à 17:05

Re : /* Topic des codeurs [9] */

#127 Le 17/01/2018, à 11:56

Re : /* Topic des codeurs [9] */

#128 Le 19/01/2018, à 09:22

Re : /* Topic des codeurs [9] */

#129 Le 19/09/2018, à 22:04

Re : /* Topic des codeurs [9] */

#130 Le 19/09/2018, à 23:04

Re : /* Topic des codeurs [9] */

#131 Le 20/09/2018, à 10:06

Re : /* Topic des codeurs [9] */

#132 Le 23/09/2018, à 01:32

Re : /* Topic des codeurs [9] */

#133 Le 23/09/2018, à 06:57

Re : /* Topic des codeurs [9] */

#134 Le 25/09/2018, à 18:32

Re : /* Topic des codeurs [9] */

#135 Le 26/09/2018, à 12:14

Re : /* Topic des codeurs [9] */

#136 Le 30/09/2018, à 21:31

Re : /* Topic des codeurs [9] */

#137 Le 02/10/2018, à 09:10

Re : /* Topic des codeurs [9] */

Pied de page des forums