Re: Threads vs Process

Le 23/08/2024 à 21:30, Francois LE COAT a écrit :

Salut,
 Arachide écrit :

Bien je préfère encore utiliser GEM/ATARI que MS/Windows. C'est sans
nul doute pas ton cas. Tu as un certain goût pour les usines à gaz :-)
Le GEM est simple et efficace. Windows est très lourd et vulnérable.

 Simple et efficace...
Si on reparlait des routines de redraw du GEM... C'est une horreur à implanter. Il faut déjà que ton logiciel se souvienne exactement de tout ce qui est écrit dans la fenêtre (ce qui peut être galère si c'est la fenêtre interactive d'un logiciel de programmation comme le FORTH avec des ordres écrits par l'utilisateur et des résultats affichés par un programme.)
Il ne faut pas qu'il écrive réellement sur sa fenêtre, mais qu'il attende un ordre "redraw" du GEM qu'il peut s'envoyer lui-même quand il se dit qu'il y a du changement.
Puis faut initier le redraw, puis parcourir la liste des rectangles à redessiner, clipper et refaire tous les appels VDI de tracés, de surfaces, de textes.... et ce pour chaque petit bout de rectangle.
 Guillaume.

 Il te serait sans doute impossible de programmer Windows, avec
l'équivalent des outils que tu utilises pour le GEM. Le GEM est
programmable à un niveau très proche du matériel, de façon simple.
Alors tu ne peux pas reprocher au GEM d'être complexe à gérer
Guillaume, étant donné la nature fruste des outils que tu utilises.
C'est ton choix. Plus personne ne travaille comme toi avec les
systèmes actuels. C'est ton savoir-faire sur ATARI qui est perdu.
Étant donné l'ampleur des projets actuels, ça n'est plus possible.
Le facteur de croissance de la complexité est de l'ordre du million !
 ATARIstiquement vôtre =)

Qu'est ce qu'il ne faut pas lire
Il est toujours possible de programmer en assembleur sous Window, même certains parties de logiciel sont encore écrit principalement en assembleur, c'est le cas par exemple pour le décodeur logiciel AV1 de VLC, c'est le premier à avoir réussi à utiliser cette nouvelle norme avant qu'il y ai des solutions hardware et quelque chose comme 80% du code est en assembleur.
https://code.videolan.org/videolan/dav1d/-/tree/master/src?ref_type=heads
Bien sur qu'il pourrait utiliser windows en assembleur mais où as tu vu le contraire? Un exemple:
https://github.com/bplaat/win32asm
C'est stupide tout fini par de l'assembleur! Par contre je pense que c'est plus dur de faire du code x86 que du 68K! Mais cela est une autre histoire qui n'a rien à voir avec les commentaires.
Est ce que c'est facile sans doute pas le plus simple mais pas si difficile que cela, l'api win32 est assez bien faite, c'est en fait bien plus simple à utiliser que GEM faut le reconnaitre. Guillaume à raison le GEM c'est compliqué et pas toujours efficace.
Tiens Guillaume a donné un très bon exemple avec les fenêtres c'est vraiment le truc nullissime du GEM, le soucis principal est la déconnexion entre l'affichage (VDI) et l'AES c'est un gros problème et un gouffre d'inefficacité, sous Win32 tu as ton handle graphique pour dessiner dans la fenêtre, tout ce que tu dessines est relatif à la fenêtre donc de mémoire (cela fait 25 ans que je n'y ai plus touché) la zone de travail le coin haut gauche est à la coordonnée 0,0, jamais besoin de savoir où est la fenêtre donc pas besoin de calcul, et pas d'histoire de rectangle tu dessines dedans point barre, le système n'a même pas besoin de te demander ce qu'il faut faire  si tu bouges une fenêtre par dessus la tienne. Pire admettons sous GEM que tu ai une boite de dialogue à dessiner dans ta fenêtre et si ta fenêtre est en arrière plan et mettons qu'il y ai 5 zones alors si tu dois redessiner la fenêtre tu vas appeler 5 fois objc_draw()! Donc tout le travail sera fait 5 fois! alors que sous windows au pire il sera fait une fois!
GEM a quelques avantages mais certainement pas celui de la simplicité de programmation.
OL