Path: ...!2.eu.feeder.erje.net!feeder.erje.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!pasdenom.info!from-devjntp
Message-ID: <GUNojJNcSWSyRF_Iq2SsKlsEbxs@jntp>
JNTP-Route: news2.nemoweb.net
JNTP-DataType: Article
Subject: Re: Threads vs Process
References: <v71gat$aj8p$1@dont-email.me> <6yJYAaCkd3eL3M3zbAsI5cpaDcg@jntp> <va736k$42f$4@news.gegeweb.eu>
 <va7qqt$1a5fd$1@paganini.bofh.team> <0k-2a_D_rIkBRouPtDuvjh3fvxI@jntp> <vaabma$1j0cc$1@paganini.bofh.team>
 <uVP1nXEw_trV0YqJ346yQsAHx9I@jntp> <vaajdo$1jcnm$1@paganini.bofh.team> <vaalsm$jda5$1@news.usenet.ovh>
 <vaanvq$1jjcm$1@paganini.bofh.team>
Newsgroups: fr.comp.sys.atari
JNTP-HashClient: FSNckHYNFzA5sbslF-Z7gR7pCYU
JNTP-ThreadID: v71gat$aj8p$1@dont-email.me
JNTP-Uri: http://news2.nemoweb.net/?DataID=GUNojJNcSWSyRF_Iq2SsKlsEbxs@jntp
User-Agent: Nemo/0.999a
JNTP-OriginServer: news2.nemoweb.net
Date: Sat, 24 Aug 24 18:33:38 +0000
Organization: Nemoweb
JNTP-Browser: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0
Injection-Info: news2.nemoweb.net; posting-host="7c83a59c1183fed9b35854847a43d6ec4fc10fe2"; logging-data="2024-08-24T18:33:38Z/8999117"; posting-account="69@news2.nemoweb.net"; mail-complaints-to="julien.arlandis@gmail.com"
JNTP-ProtocolVersion: 0.21.1
JNTP-Server: PhpNemoServer/0.94.5
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-JNTP-JsonNewsGateway: 0.96
From: OL <ol.google@lutece.net>
Bytes: 5688
Lines: 78

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