magellan
Modérâleur
Staff
Je te trouve tout à fait objectif au contraire. Windows a toujours souffert de cette "nécessité" de ne pas dérouter les utilisateurs et plus encore de maintenir une compatibilité entre toutes ses versions ou presque. N'oublions pas par exemple que tous les programmes "purs DOS" sont abandonnés depuis belle lurette. Quand la génération des OS de MS full NT, le DOS natif n'existe plus du tout, si ce n'est un shell vaguement compatible. C'est pour ça qu'a émergé DosBox d'ailleurs.Hello,
Désolé un sujet qui m'a fait bondir tellement de fois :
SergioVE a dit:
Et as-tu protesté quand Windows a arrêté le 32 bits, privant là aussi une bonne partie du parc d'évolution logicielle ?
PS. C'est du ressenti, pas une attaque perso !
J'ai commencé à bosser sur Unix tout début des années 2000 ( DecOSF ) et l'OS était déjà full 64 bits. Les processeurs x86 sur full 64 bits depuis 2003 et Windows a commencé à tourner le dos au 32bits début 2020.
Alors je veux bien mais faut vivre avec son temps, tu veux un soft de 30 piges et bah tu gardes ton TO7
Désolé c'est un sujet sur lequel je sais que je ne suis pas du tout objectif mais avec ce genre de raisonnement nos PC ressemblerait encore à des Casio.
Bisous <3
De toute manière, l'arbitrage est économique et pas philosophique. Quand tu es un particulier, sauf à avoir des logiciels très précis, tu parviens tôt ou tard à trouver une équivalence dans la nouvelle version de l'OS, et ce grâce au net. Dans le monde pro, c'est un sujet bien plus sensible. On ne fout pas à la poubelle un logiciel fait souvent sur mesure sans se poser la question du coût.
Dans le cadre des sites web obsolètes (format, technologie, version des librairies sensibles aux hacks...) c'est relativement plus "simple". En revanche, quand c'est de l'exécutable, c'est tout de suite délicat. Pour avoir eu comme projet la migration d'un programme en VB5 (de mémoire) pour le monter sur des PC sous 2000/XP, envisager de bricoler avec les DLL d'origine a vite été mise hors-sujet. On avait le source certes, mais cela voulait dire monter une machine avec un OS obsolète (98), tenter de remonter le tout dans un VB6 avec pertes et douleurs, puis chercher une manière de passer sous .NET. Et je ne parle même pas de la partie design, juste du fonctionnement interne du produit.
Note comme ça... j'ai vécu aussi le cas où le produit donnait satisfaction, mais était fermé sans disposition des sources. La société avait fermé depuis belle lurette, et le tout avait été acheté sur étagère... Donc la conséquence? Réécriture incomplète, buggée, avec toutes les conséquences qui vont avec. C'est aussi et surtout pour ça qu'on pousse partout l'open-source, même si ce raisonnement ne garantit en rien la faisabilité d'une maintenance interne. Avoir les sources ne veut pas dire avoir les gens capables de coder avec. J'ai commencé ma carrière (25 ans en arrière) sur du Clipper et du VBDOS 1.0. Allez trouver une ressource qui sait simplement monter l'environnement de compilation du premier...
Vous devez être connecté pour voir les liens.
Vous devez être connecté pour voir les liens.
(et encore là on a des projets maintenus en open source!)
