News

Suite aux commentaires de Deksor concernant mon 486, j'ai passé deux disques durs IDE en bench.
Voici les résultats entre le Conner d'origine (240Mo) et un autre Seagate plus récent (850Mo) que j'ai sous la main.

	PC 486 (Winbond W83757F)	PC Pentium MMX (Intel 82371SB)
Conner CP30254
Seagate ST3850A

Que peut-on en conclure ?

Spécifications : Hormis la capacité qui diffère, déjà que le Conner ne possède que 32Ko de cache par rapport au Seagate qui lui en possède 120Ko. De plus le Seagate est en mode PIO4 et gère le DMA 2(0) alors que le Conner est limité au mode PIO3.

Temps d'accès : Le Conner passe les tests avec un graphe en forme de "deux montagnes" : première fois que je vois cela. On dirait un problème dans la gestion d'utilisation des plateaux et des faces. Pour le Seagate : alors que le graphe semble normal (linéaire) coté 486, on observe une sorte d’écrêtage dans le southbrigde du PC Intel.

Débits : Sans surprise, c'est globalement mieux du coté Pentium pour les deux HDD puisque le contrôleur IDE est plus récent.

Conclusion : Remplacer le disque Conner par le Seagate serait gagnant. Par contre la limitation du BIOS à 1024 cylindres le bridera à 504Mo utilisables sur ses 850Mo.

Je me suis penché sur le problème qu'avait mon PC mini-tour 486 d'époque. Je ne comprenais pas pourquoi le logiciel cachechk me disait que l'accès vers la RAM était lent et que visiblement le cache L2 n'était pas exploité à fond. J'avais donc décidé de remplacer le cache L2 et le passant de 64Ko à 256Ko par la même occasion (ayant récupéré des puces). Mais malheureusement sans solutionner le problème même si cela apportait un plus.

Cet après-midi j'ai donc fait des tests et j'ai bien vérifié l'ensemble des cavaliers de la carte mère PKM-5031Y par rapport à la documentation disponible. RAS tout est bon. J'en ai profité pour y installer le 486DX2-66Mhz d'AMD. Et là, comme par magie, plus de problème :

Le débit de la RAM est augmenté et le CPU est bien "reconnu" :

Le valeurs sont cohérentes avec le tableau indiqué sur cette page pour une configuration identique. Duke Nukem 3D s'en retrouve plus jouable même si pas tout à fait fluide.

Par contre le CPU chauffe pas mal, mais je pense que l'ancien devait arriver au même point. Impossible de laisser le doigt dessus. Je pense y mettre un ventirad.

Et je n'ai rien fait d'autre que de déplacer le cavalier pour la version DX2 (ouvrir J11) comme indiqué dans la documentation. Je ne m'explique pas pourquoi l'ancien processeur Intel DX-33 faisait dérailler l'accès L2/RAM alors que l'AMD ne pose aucun problème, j'ai interverti 2 fois les CPU et c'est systématique. Dès que l'Intel est en place, cachechk gueule. Le tout avec la même RAM. J'en viens donc à douter de l'Intel 486DX-33 d'origine. Pourtant je ne pense pas que ce soit un CPU fake pour autant.

Voilà une chose de réglée même si j'ignore vraiment pourquoi.

Quelques images de bench :


Les pics vers le bas c'est quand on joue avec le bouton Turbo :

Sans turbo (indice 7.02) et avec turbo (24.85) :

Un visiteur du site m'a contacté pour avoir mon avis concernant une vidéo :



Concernant les malwares, j'avais déjà fait une analyse plus poussée en juillet 2016 d'un autre truc mais qui était réel cette fois. Pour cette vidéo-ci : hélas ce n'est pas le seul à faire des blagues. C'est ce qui participe en partie à l'érosion du métier de développeur et des bonnes pratiques, les particuliers s'approprient ces outils professionnels pour faire n'importe quoi avec. Je n'ai pas vu de lien vers le code source, il propose 3 packages dans la description de la vidéo, j'ignore pourquoi s'éparpiller autant. Il ne livre que les .exe compilés. Après on pourrait aller plus en profondeur mais pas l'envie de décompiler. De ce que j'ai vu "WindowsApplication1" = cela semble être fait avec Visual Studio soit en C#, soit en VB.NET. Le type ne capte pas que son setup plante avec un message "read error" parce qu'il est sandboxé dans AVAST le temps de l'analyse heuristique. Bon soit.

Je rappelle qu'il est NORMAL que l'antivirus ne détecte rien puisque le programme lancé ne contient aucune signature de virus connue de la base de données de l'AV. L'analyse heuristique passe crème car comme il est planté son programme setup ne fait plus rien, donc AVAST situe le programme comme inoffensif car pas agressif dans des tentatives d'accès multiples pour pourrir le système. Les AV ont leurs limites, après le problème se situe entre le clavier et la chaise (Cf Ransomwares). Stop avec "Ohlalala AVAST c'est de la merde il a rien détecté". Les autres AV auraient certainement fait pareil.

Pour son application, rien de bien sorcier :

• un enchaînement de fonctions MSGBOX (= MeSsaGeBOX), il existe ce genre de fonctions toutes prêtes dans tous les langages. En Pascal, en Java.
• des formulaires (Forms = fenêtres) personnalisées avec quelques contrôles dessus.
  

En 20 minutes je te fais la même chose sans transpirer comme beaucoup d'autres, puisque quasiment n'importe qui qui débute avec Visual Studio passe par cela en général dans les tutoriels (voir sur Internet).

Le pire étant les commentaires des gamins parmi les viewers : "t'es trop fort, waouh". Je ferais un parallèle avec les vulgarisateurs comme Micode, ça épate les quidams, c'est joli, ça rend bien, mais au final les vrais savent qu'il n'y a rien de magique derrière tout cela (Kon-boot). Voir les commentaires sous la vidéo d'ailleurs. Le vrai génie n'est pas celui qui s'en sert mais celui qui l'a créé. Même si cela à l'avantage d'éveiller un peu les utilisateurs sur les questions de sécurité. Le risque avec ces bêtises c'est qu'à force de "troller ses potes", certains ne fassent plus attention (Cf Le garçon qui criait au loup) Voilà, bonne journée à tous.