Lier une ancienne DLL

Bonjour à tous,

Dans le cadre de la refonte d'un poste de Windows XP vers Windows Seven, je suis amené à intégrer une ancienne DLL dans un nouveau projet Visual Studio C++.

J'ai essayé d'inclure la DLL dans les références afin d'utiliser les fonctions sans succès.

La commande dumpbin me donne le retour suivant

Citation:

---

dumpbin /export MYDLL.DLL

Microsoft (R) COFF/PE Dumper Version 11.00.61030.0
Copyright (C) Microsoft Corporation. All rights reserved.


Dump of file MYDLL.DLL
LINK : warning LNK4094: 'MYDLL.DLL' est un exécutable MS-DOS*; utilisez EXEHDR pour en faire un dump

Summary

---

Quand je tente de charger la DLL via la méthode

Code:

---

HINSTANCE hGetProcIDDLL = LoadLibraryA("MYDLL.DLL");

---

A l'exécution, j'obtiens une pop-up d'erreur avec le message suivant :

Citation:

---

MYDLL.DLL n'est pas conçu pour s'exécuter sous Windows ou il contient une erreur. Installez à nouveau le programme à l'aide du support d'installation d'origine, ou bien contactez votre administrateur système ou le fournisseur du logiciel pour obtenir du support.

---

Mon problème est que je n'ai pas les sources ayant permis de générer la dll.

Any idea ?

NB : La dll a été compilée en Fortran

Une Dll 16-bits ???
Pour le confirmer, faudrait aller dans un musée pour récupérer les outils de cette époque.

http://gaming.stackexchange.com/ques...64-bit-windows

J'ai fait un petit coup de commande file sous linux et j'obtiens le résultat suivant :
>file MYDLL.DLL
MYDLL.DLL: MS-DOS executable, NE for MS Windows 3.x (driver)

Donc 16-bit? Très probablement...

Existe-t-il un moyen de conversion? d'appel ?

OK un NE file:
http://wiki.osdev.org/NE
C'est donc du bon vieux Win16.

Une Dll 16 bit pense qu'elle est encore dans les années 80 et qu'elle a accès à tous et n'importe quoi dans le système et c'est clairement plus le cas.
Le VDM dont il est question dans l'article en lien dans ce post est une émulation d'un environnement 16 bit dans du 32 bits.

Dans mon précédent post, il est mention d'un certain nombre de hack pour essayer de faire fonctionner des jeux avec des Dll 16bits sur des machines 64.

Mais franchement, un code qui a plus de 20ans et qui n'est pas maintenu, il y a forcément mieux maintenant.

Je pense qu'il serait plus rentable de prendre du temps pour trouver une bibliothèque de remplacement plus à jour que de prendre un temps fou pour une migration extrêmement hypothétique.

Well ...

Disons que la problématique est un peu plus complexe que cela.

C'est une dll fournissant des méthodes mathématiques afin d'établir des consignes de pilotage pour une machine (datant de la même période).

Ce modèle mathématique est bien sûr propriétaire, donc pas de source disponible ... Et l'élaboration d'un nouveau modèle s'avère long et coûteux sachant que la machine n'est pas modifiée (donc pas d'intérêt économique...)

Et comme la machine vieillit beaucoup mieux que les systèmes informatiques la pilotant ...

Je suis donc prêt à me risquer sur une migration si il existe un espoir de faisabilité ...

Dans ce cas tu as peut-être intérêt à gérer cela dans un environnement virtualisé contenant un système 32 bits voire 16 bits.

Effectivement l'utilisation d'une VM peut palier temporairement à mon problème, le temps qu'un groupe d'étude se penche sur la réalisation d'une nouvelle librairie mathématique pour le pilotage de cette machine.

Durant mes différentes recherches je suis notamment tombé sur cet article abordant la notion de thunk :
https://support.microsoft.com/en-us/kb/155763

Cela semble permettre d'utiliser une dll 16bit dans une application 32bit.

Quelqu'un a déjà eu une expérience dans ce domaine?

Si oui, est-il possible, une fois l'application obtenue en 32bit, de la faire fonctionner sur un Win7 ?

oui, le soucis est qu'en mode 64 bits, il n'est plus possible d’exécuter de taches 16 bits : limitation CPU. Exécuter des taches 32 bits en 64 bits ne pose pas de problème.

La Virtual DOS Machine native de Windows ne peut pas, mais un truc qui fait carrément de l'émulation devrait en être capable.