Salut tout le monde, et bonne année !  
 
La boite qui m'emploie déploie des solutions sous Windows dans le domaine médical, et ces applications codées en WinDev discutent entre elles par le biais d'un socket CodeGear/Embarcadero codé en Delphi : scktsrvr.exe.  
 
Certains vieux postes clients intégrés à des machines ont des configurations matérielles d'un autre âge, et tournent encore pour certains sous Windows 2000. Installer Windows 10 dessus serait suicidaire, mais certaines versions de Linux conviendraient tout à fait.  
 
Le hic, c'est que l'entreprise n'a pas l'intention, ni le temps, ni les moyens de porter ses logiciels sous Linux, donc la seule solution serait d'utiliser Wine.  
 
J'ai testé, et les programmes eux-mêmes s'installent très bien. Les problèmes commencent à l'installation du socket, que Wine ne semble pas reconnaître, ou pas bien. Du coup, les applications métier d'un côté et le gestionnaire de base de données ADS de l'autre ne peuvent pas communiquer, et le programme est inutile.  
 
Est-ce que quelqu'un sait comment "raccorder" tout ce petit monde, notamment ce fameux socket ? J'ai essayé de bidouiller un socket en Python, sans effet, et je n'aimerais pas avoir à demander aux devs de sortir une version de l'application compatible spécialement pour moi ; ils ont déjà assez de boulot comme ça en ce moment.

A mon avis vous cherchez les emmerdes, vu que c'est un usage pro (et médical en plus). J'ai rien contre Wine, au contraire, mais pas convainqu que pour un usage pro ce soit la meilleure idée... Si on isole les postes W2000 du réseau (->VLAN) on pourrait les laisser en l'état.
 
Je ne peux pas te donner la solution magique, mais je pense à un truc: Sous Linux on peut utiliser la variable d'environnement LD_PRELOAD pour "remplacer" des fonctions de la libc ou autre. Peut-être(!!) il y a moyen de bricoler un truc pour "apprendre" à votre logiciel d'utiliser des sockets Linux ou des pipes ou ... Sauf que déjà c'est pas un truc facile et en plus comme il y a Wine dans l'histoire... Comme je disais, à mon avis vous cherchez les emmerdes.

Bonjour et merci d'avoir pris le temps de répondre.  
 
Le souci avec ces vieux postes, qui sont déjà sur des vLAN isolés pour des raisons évidentes de sécurité, c'est qu'ils commencent à sérieusement accuser leur âge.  
 
La maintenance est compliquée, tant au niveau matériel que logiciel : on ne peut pas les faire évoluer avec plus de RAM et un SSD, par exemple. On a souvent des BSOD et un redémarrage sous Windows 2000 sur un PC qui embarque royalement 512 Mo de RAM et un Pentium III cadencé à 2 GHz prend, disons, un certain temps... :-)  
 
L'idée d'installer un Linux léger dessus (genre Linux Lite, justement), c'est de continuer à les utiliser jusqu'à ce que le budget du client permette un remplacement complet de l'automate dans lequel le PC se trouve intégré.  
 
Qui plus est, il y a une vraie réflexion chez nous autour du passage d'une partie du parc client sur Linux, pour des raisons de licences Microsoft, bien sûr, mais aussi parce que souvent le service informatique du client opère depuis des serveurs et passerelles sous Linux, et possède donc quelques compétences dans ce domaine.  
 
Je vais voir en ce qui concerne la variable d'environnement à modifier, mais pour avoir déjà utilisé Wine il y a plusieurs années en association avec des applications métiers développées à l'époque pour Windows 7, je sais que ça peut fonctionner sans souci.  
 
D'ailleurs, c'est le cas, à ceci près que sans socket fonctionnel, les différents programmes ne communiquent pas... :-(

Attention: Cette variable d'environnement veut un fichier objet, donc du code compilé qu'il faudra développer. C'est pas un simple texte "remplace X par Y"... C'était juste une idée qui me passait par la tête.
 
Oui, j'imagine que maintenir en vie des vieilles machines ce n'est pas la joie...

Non, en effet, c'est compliqué, d'autant qu'elles sont sollicitées H24 sur certains sites.  
 
Pour le reste, nous étudions le portage de nos applis sur Linux, en code natif, donc, mais c'est du travail de longue haleine.  
 
J'ai tenté de virtualiser l'appli complète avec EnigmaVB, qui fonctionne très bien dans la plupart des cas, mais pas ici. Ce fichu socket... :-(

Il y a pas moyen de venir virtualiser complètement les machines sous Windows 2000 incluant la solution, et de maximiser les ressources allouées dans la limite du support de l'OS ? (4Go et dual-core pour Windows 2000 il me semble)

Ah oui, très bonne idée. Avec KVM/Qemu on peut émuler(?) un autre processeur, donc ça devrait le faire. J'ai fait tourner W98 sur du Ryzen 5 + Debian 10 avec cette méthode. Faudra juste voir pour les "passtrough" USB ou autres pour interfacer le hardware spécifique.

Ce fut une piste à un moment donné, en effet, mais je crois que ça a été abandonné parce que même virtualisé sur un hôte costaud, Windows 2000 reste Windows 2000, avec ses limites : 32-bit, une gestion de la RAM catastrophique selon les standards actuels, plus il y a aussi la gestion du hardware médical à prévoir.  
 
Ces PC sont arrivés au bout de leur vie, mais nous devons encore les maintenir jusqu'à ce qu'ils rejoignent le paradis des PC... Ou alors nous y installons un Linux léger et nous essayons de faire tourner nos solutions dessus.  
 
J'ai encore testé tout à l'heure, et avec l'injection d'un regsvr32.exe à jour, j'arrive à aller jusqu'au bout de l'installation sans souci. La base de données s'installe aussi sans problème.  
 
Ne me reste qu'à faire fonctionner ce lutin de socket... :-D

Il me semble pas que tu aies besoin d'émuler du hardware x86 sur un x64. Il doit avoir une rétro compatibilité des instructions (à vérifier)

Tu prends un mauvais point de comparaison en prenant les standards d'aujourd'hui : il faut re contextualiser les choses. Je m'explique : cette application a été développée dans son temps, dans les années 2000 en tenant compte des limitations liées au hardware et au SE. En maximisant le hardware dans la limite supporté via une VM, tu t'affranchis de la question des perfs, tout en assurant une sécurité vu que le serveur aurait une redondance au niveau des disques.  

Rassure moi, vous avez une stratégie de migration au cas où ses machines rendent l'âme du jour au lendemain ?!?

Je pense que tu fais fausse piste avec Wine. C'est la fausse bonne idée

Tu te rappelles des conséquences de l’incendie d’OVH et de tous ces messages de panique sur Twitter ?

– Notre serveur a brûlé, on a perdu toutes nos données ! On fait comment, maintenant ?
– Bah, mettez en place votre PRA (Plan de Reprise d’Activité). Et récupérez vos sauvegardes.
– Un quoi ? Et des quoi ? On avait tout sur ce serveur, nous ! On croyait qu’OVH s’occupait de tout ça !
– Le contrat de location de ces serveurs dit explicitement qu’OVH ne fait pas de sauvegardes et que c’était à vous de vous en occuper. Vous aviez pas lu les petites lignes, avant de souscrire ?
– … Oh, regarde : un singe à cinq têtes ! (Fuit)

(Il y en a eu des dizaines, des comme ça… Donc, sans être la réponse à ta question, ça peut quand même donner un bon indice)

Mais voilà : à force d’accumuler de la dette technique (ne pas avoir renouvelé les machines depuis plus de 20 ans !!!), vient le moment où le matériel arrive au bout de sa vie, et qu’on commence à payer chèrement cette négligence totale… Je dis pas ça pour toi, Ugly.

Bon, déjà, question sauvegardes, on est pourvus, je vous rassure !
 
(Bon, j'avais pondu une longue tirade d'explication, mais le site m'en a mangé la moitié, et je suis fatigué, donc je ne vais pas la refaire. Sachez que j'apprécie vos idées à leur juste valeur, et que toutes les options sont sur la table, hormis le remplacement pur et simple de ces postes, qui sont "embedded" dans la hardware médical, avec des connexions de style RS232 ou WLBus.)

Oui et ? C'est pas parce que OVH, une grande entreprise d'hébergement, se permet de faire ça que les petites doivent faire la même chose...

Je n'appelle pas ça de la dette technique : OVH n'est pas resté bloqué sur des versions anciennes de logiciels / distributions (par ex. Debian 6 en 2022 à cause d'un kernel custom) bien qu'ils traînent la patte pour proposer les dernières versions.
Il y a plus une défaillance au niveau de l'environnement des serveurs (buse à incendie, plancher en bois toussa )

Tu aurais dit ça depuis le début, je ne pense pas que je t'aurais proposé la virtualisation.
Une idée qui vient de me passer par la tête : tu peux essayer de voir les dépendance de ce fameux « scktsrvr.exe » avec un « dependency walker » et voir si les DLLs sont aussi présente avec Wine. Cependant, je ne pense pas que le gain de perfs' récupéré avec Wine en vaut la chandelle sur le long terme.

Tu misses le point : le problème n’était pas le fait qu’OVH ne faisait pas de sauvegarde, c’était le fait que les entreprises qui s’hébergeaient chez eux ne le faisaient pas non plus de leur côté.
 
Bon, c’est pas le cas chez Ugly, puisqu’il a dit que c’était bon pour ça. C’est juste les machines qui sont tellement anciennes que si l’une d’elles pète (et ça peut arriver à tout moment, là), sa boîte va être vraiment très embêtée car elle ne pourra sûrement pas se permettre de la remplacer, ni ne pourra probablement exploiter ses données avec de nouvelles machines.

Effectivement, je comprends mieux maintenant ce que tu veux dire et je suis aussi d'accord avec toi  

Pas directement sans portage/mise à niveau du backend. Mais les données (brutes) seront toujours la vu qu'il y a une présence d'une BDD.

J'ai lu toutes vos réponses, et un consensus semble se dégager : je suis dans la merde...!

... et le site n'aime pas quand on insère les emojis de Windows 10 dans les réponses... Je note, je note...  
 
Plus sérieusement, on bute en effet sur une question simple : que faire quand ces machines vont passer l'arme à gauche ? Doit-on attendre que cela se produise et accepter les piètres performances qu'elles proposent sous Windows 2000 ou XP, ou essayer quand même de faire tourner nos logiciels sous un Linux allégé ?  
 
Nous pourrions aussi engager des devs dédiés à l'adaptation de nos softs à Linux, mais bon, les temps sont durs.  
 
Je reste ouvert à toutes vos suggestions, notez bien.

non, il faut modernisé le soft, mettre au pied du mur "l'investisseur" (les N+1 quoi).
Qd tes machines vont passer l'arme à gauche, il se passera que certains collaborateurs seront au chomage technique et ça en général, c'est l'argument imparable : "vous voulez qu'un jour payer 10collaborateurs à rien foutre pendant 3semaines, pendant qu'en urgence on développe un soft (bancal/buggué... puisque dans l'urgence)?"
 
Les temps sont peut être durs, mais tu n'en sais rien

Non c'est sûr, mais les budgets dans les hôpitaux sont ce qu'ils sont. L'idée, c'est aussi de préparer l'avenir, sur d'autres plateformes que Windows, mais ça, c'est pour après-après-demain... :-)

Rester sur Windows. La machine a été certifiée comme ça. Tu ne peux pas changer d'OS comme tu le ferrais à la maison.

Arrête alors d'étaler les forces du pole dev dans plusieurs directions si tu dis que les temps sont durs : concentres-toi sur un OS (Win IoT) et demande le portage sur cet  OS de ton logiciel. Si les autres machines sous 200 meutent, tant pis, mais au moins vous aurez une nouvelle version au catalogue à proposer.  

+1
Plus tu attends, plus la dette technique va être grande, et plus ça va coûter bonbon. On peut aller jusqu'à la réécriture du logiciel depuis 0.
Alors autant aller secouer le cocotier de ton N+1 tout de suite.  

Nous ghostons déjà des postes sous Windows IoT (postes clients) et franchement, c'est pas la panacée.  
 
Quand je parle d'embedded pour nos postes actuels sous 2000, le terme est à prendre avec des pincettes : à l'époque, nous avons juste inséré un vrai PC dans la coque qui entoure ces automates d'analyse.  
 
Le fait est que ces postes ont été mis en place dans la 1ère moitié des années 2000 et qu'ils ont fait leur temps, mais installer IoT Core dessus reviendrait à se tirer une plus grosse balle dans le pied : le multi-tâche n'est pas à la hauteur, surtout avec de nombreux processus assez exigeants en termes d'I/O, et je ne suis pas sûr qu'on y gagnerait en termes de longévité sur ces machines qui, je le rappelle, ont un HDD et ne sont pas faciles à décortiquer.  
 
Sur des NUC récents, ça fait l'affaire, avec un SSD et 2 petits Go de RAM, on peut y faire tourner une suite logicielle basique (poste client), mais les postes adossés à nos automates ont une fonction serveur aussi (certaines applications sont déportées dessus), et la base de données ADS à elle seule les mettrait à genou.  
 
On a testé, on a pas aimé... Nos clients non plus... :-)

Ah oui, très bon point, les certifications sur du matos médical ça doit pas être simple...

ah, j'avais pas capté  
 
il faudrait donc partir sur de la virtualization et des simples stations?

Pour ce qui est de la certification, détrompez-vous : les fabricants ont tout loisir de changer d'OS s'ils l'estiment nécessaire, sans avoir à repasser par un processus de certification, car cette dernière est établie sur la base du "service rendu" par l'automate.  
 
Pour le reste, en effet, on pourrait transformer ces postes en clients légers et faire en sorte que les processus lourds s'exécutent côté serveur, mais on en revient à ma question de départ : comment faire tourner ce fichu socket sur un Linux afin de ne plus être tributaire d'un OS vieux de plus de 20 ans...?

Perso je pense que dans l'immédiat la solution de la virtualisation de W2000 proposée par frenchieisverige est encore la plus viable. Comme ça on peut remplacer le matos hard par du neuf (donc fiable etc) avec un Linux et faire tourner un W2000 en virtualisé. A long terme il faudra voir pour passer l'appli en natif Linux.

Donc l'idée serait d'installer un Linux léger sur ce poste, d'y faire tourner VirtualBox ou Qemu, et d'installer Windows 2000 en VM dessus ?  
 
Déjà, pas sûr qu'on ait encore des ISO ghosts de Windows 2000 sous la main, et quand bien même, on parle d'une machine qui a 512 Mo de RAM et un Pentium III d'avant la Guerre du Golfe, donc question performances, on va être au ras des pâquerettes.  
 
Faire tourner un Linux et y installer le soft me semblerait préférable. Je vais continuer avec mes sockets Python pour voir, mais c'est pas gagné.  
 
Bonne nuit à tout le monde !

Non, bien sûr la virtualisation ça serait sur du matos neuf! C'est juste que virtualiser tout un OS vous avez plus de chances de faire fonctionner votre soft qu'avec Wine je pense.
 
Si tu veux continuer sur la piste Wine, il existe(ait?) des logiciels genre Process Monitor de chez MS qui permettent de voir assez bien ce que fous un soft, mais attention c'est des tonnes et des tonnes d'infos à trier. Peut-être ça peut aider.

non sur du neuf ou ce que vous avez de plus récent et disponible.
il suffit de sortir le disque et de faire un DD pour en faire une image.

Oui mais le hic, c'est que c'est très compliqué d'aller dedans. Le matériel n'est pas évolutif du tout. Il a été conçu comme ça il y a des années, et on doit faire avec les limitations qu'il nous impose.  
 
Ajouter de la RAM, changer le HDD contre un SSD, tout ça, c'est impossible là-dessus.  
 
En plus, on doit aussi composer avec la connectique présente, et penser aux connections en RS232 et consort.

Bah après y a pas de solution magique, il faudra bien toucher au hardware un jour, au plus tard quand il tombera en panne.  
 
Pour les RS232 il y des adaptateurs USB et ça fonctionne très bien, même si il faudrait vérifier la situation au niveau pilotes pour W2000...

bah l'idée c'est qd meme d'avoir une sauvegarde de la machine avant qu'une tuile vous tombe dessus.
Ensuite ya des convertisseurs usb/RS232 et ça coute presque rien.

Comme je l'ai dit, les sauvegardes ne sont pas un problème. Le souci, c'est un hardware vieillissant et non-évolutif, associé à une version antédiluvienne de Windows.  
 
Si on pouvait installer un OS moderne dessus, sans avoir à retoucher le matériel, et faire tourner notre soft tranquillement, on pourrait attendre les prochains budgets et moderniser tout ça.  
 
On parle d'automates à 80 000 euros...

non mais là je ne te parle de sauvegarde des données, mais une sauvegarde de la machine et qui pourrait tourner facile sur une qemu en cas de tuile hardware...
niveau hard faut le faire evoluer demain. en plus c'est du 32bits. En attendant c'est quand meme sage d'avoir une image de la machine que tu peux faire booter sur une autre machine recente.

Puisqu'il dit que les sauvegardes c'est gérer
 
Sinon, pour les idées évoquées:
- p2v: pas sûr du tout que ca se passe bien
- dongle rs/usb: à choisir méticuleusement. Les pilotes à cette époque c'était pas la panacée, potentiellement, encore moins en intégré.  
 
Autre idée pour la migration:
- y aller crescendo. Faire le teste sur un OS de la version/génération d'après, et voir ce qui coince (j'ai suivi de loin la discussion, pas tout relu aujourd'hui)

On a songé à migrer la machine sur W7, on a même testé sur des automates qu'on garde (essntiellement pour les pièces), et ça fonctionnouille, sans plus. Pas de gros plantage, mais des lenteurs, et comme les processus qui tournent dessus sont gourmands en I/O, l'optimisation s'annoncerait compliquée.  
 
J'ai relu les specs de cette génération de produit ce matin, et on est bien sur 512 Mo de RAM, un Pentium III à 1,4 GHz (j'ai dû fantasmer quand je parlais de 2 GHz...) et un HDD de 60 Go, suffisant pour stocker l'OS et servir de tampon pour les les images prises par l'automate avant upload vers le serveur.  
 
Paradoxalement, la partie automate pure est plus évolutive, mais pour le PC, c'est la préhistoire... :-(

ecoute j'ai des softs (diag automobile serialisés) qui tournaient sur win2000 et que je fais tourner aujourd'hui en qemu maintenant.
Je ne comprends pas trop la difficulté    sauf le budget.  
 
Vire ce pc antédiluvien et virtualise le avec plus de ram et dédie un core de xeon sur un hyper-V. ça va te prendre 2h

J'aimerais que ce soit aussi simple. Il faut un PC pour faire fonctionner l'automate qui y est associé. Avec quelques (beaucoup...) aménagements, on pourrait extraire le PC du chassis dans lequel il se trouve, et là on aurait l'embarras du choix, mais c'est un peu plus compliqué que de simplement le virtualiser.