#126 Le 16/01/2018, à 17:05
- Dafyd
Re : /* Topic des codeurs [9] */
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.
Hors ligne
#127 Le 17/01/2018, à 11:56
- Dafyd
Re : /* Topic des codeurs [9] */
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
Hors ligne
#128 Le 19/01/2018, à 09:22
- grim7reaper
Re : /* Topic des codeurs [9] */
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
Hors ligne
#129 Le 19/09/2018, à 22:04
- Dafyd
Re : /* Topic des codeurs [9] */
Et ben... plus de codeurs sur ce forum ?
Hors ligne
#130 Le 19/09/2018, à 23:04
- Elzen
Re : /* Topic des codeurs [9] */
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)
Hors ligne
#131 Le 20/09/2018, à 10:06
- grim7reaper
Hors ligne
#132 Le 23/09/2018, à 01:32
- Dafyd
Re : /* Topic des codeurs [9] */
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 !
Hors ligne
#133 Le 23/09/2018, à 06:57
- Pylades
Re : /* Topic des codeurs [9] */
Encore là, mais ça fait un moment que j'ai plus eu le temps de toucher à du code…
“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
Linus Torvalds – 12 janvier 2003
Hors ligne
#134 Le 25/09/2018, à 18:32
- grim7reaper
Re : /* Topic des codeurs [9] */
Ha, Pylades!
L’un des pères fondateurs du TdC
Ça prend plus de temps de débugger des humains que du C hein
Hors ligne
#135 Le 26/09/2018, à 12:14
- vv221
Re : /* Topic des codeurs [9] */
Et ben... plus de codeurs sur ce forum ?
Bah si, mais on code, ce qui laisse peu de temps pour bavarder
Jouer sur Ubuntu ? Facile !
Hors ligne
#136 Le 30/09/2018, à 21:31
- The Uploader
Re : /* Topic des codeurs [9] */
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) :
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)
- Oldies PC : Intel Pentium 3 @ 800 Mhz sur CM ASUS P2B-F, GeForce 4 Ti4800 SE, Disque Dur Hitachi 160 Go, 512 Mo de RAM, 3DFX Voodoo 2, Sound Blaster AWE64, Windows 98 SE / XP)
- Desktop : Intel Core i7 6700K @ 4 GHz sur CM ASUS Z170-P, GeForce GTX 1070, SSD Samsung 850 EVO 1 To, 16 Go de RAM, Disque Dur Seagate Barracuda 3 To, Windows 10
Hors ligne
#137 Le 02/10/2018, à 09:10
- grim7reaper
Hors ligne