Question

Je fais un jeu d'apprentissage de la programmation pour mon projet senior et je suis à la recherche d'un compilateur qui peut compiler une DLL qui peut ensuite être chargé dynamiquement dans un Visual Studio 2008 application C ++.

L'idée importante ici est que le compilateur est redistribuable. Si VS était redistribuable je serais en utilisant cela.

Jusqu'à présent, je suis connu un certain succès en utilisant MinGW, mais que le succès est limité. À l'heure actuelle, je ne suis en mesure d'obtenir une DLL chargée et travailler à la fois. Le moment que j'essaie de charger une seconde les app se bloque VS C ++ avec une erreur de violation d'accès.

Je suis en mesure de charger deux DLL compilées dans VS lui-même sans problème il me porte à croire que c'est quelque chose de spécifique à MinGW, il est DLL, et comment ils interagissent avec LoadLibrary () et ainsi de suite.

Je travaille à ce problème depuis un certain temps et je suis frusterated. Si quelqu'un connaît un autre compilateur que vous savez fonctionnerait au lieu de MinGW, ou si vous aviez vu ce problème peut-être vous savez pourquoi la deuxième plante DLL il. Je suis sûr que c'est lié à chaque DLL marcher sur l'autre, en quelque sorte, mais je ne sais pas ce qui serait ou comment trouver.

Il pourrait être la façon dont je compiler la DLL ou la façon dont je suis le charger; Je ne sais pas.

Je voudrais vraiment apprécier les commentaires, merci!

Edit: Ce sont les simples appels à g ++ et dlltool pour créer la DLL http://pastebin.com/f675df4b0

Ceci est la source d'un de mes DLL. http://pastebin.com/f5c062611

Ceci est le code dans mon application C ++ pour charger la DLL. http://pastebin.com/f52f94a18

-Michael

Était-ce utile?

La solution

Vous retournerez 0 de DllMain. Selon les spécifications, vous devez retourner TRUE à moins que quelque chose ne va pas. Cependant, je ne vois pas pourquoi cela devrait donner un comportement différent sur MSVC ou MinGW. Il dit aussi que LoadLibrary devrait retourner 0 si DllMain retourne FALSE si ce ne peut pas être l'explication réelle.

Est-ce que DllMain effectivement s'appelle à la fois la MSVC et la version MinGW, ne se produit quelque chose si vous supprimez le commentaire sur l'appel messagebox en elle?

Pour plus d'informations sur DllMain, consultez http: //msdn.microsoft.com/en-us/library/ms682583(VS.85).aspx

Une autre chose qui peut être intéressant si vous appelez en fait le AiFunction de la première dll avant de charger la seconde. Si vous le faites, vous pouvez essayer de charger les dll sans faire appel à une fonction dll inbetween et voir si cela fonctionne mieux?

Je soupçonne que MinGW et MSVC emballe les struct d'entrée ou de sortie différente et que d'une certaine manière cette différence de taille provoque la partie de la mémoire à être endommagée lorsque vous appelez AiFunction. Vous pouvez le vérifier en santé mentale comparant sizeof () résultats pour la sortie et l'entrée à l'intérieur et à l'extérieur de la dll et voir si elle correspond. Cela ne garantit pas qu'il est correct, mais si elle ne vous pouvez être sûr correspond pas à quelque chose va mal tourner.

Enfin, je suis inquiet que le retour de sortie peut potentiellement être un problème à long terme si vous commencez à introduire des appels virtuels et des choses depuis que ne peuvent pas être mises en œuvre exactement de la même manière à l'intérieur MSVC et MinGW. Si vous conservez sans fonctions virtuelles et de telles choses, il devrait être bien aussi longtemps que les matchs d'emballage de la structure.

Autres conseils

Est-ce que juste en utilisant Visual Studio Express être assez bon? Le compilateur est librement téléchargeable et il vous fera économiser beaucoup de douleur en essayant d'obtenir les DLL compatibles.

Je ne sais pas comment stricte vos exigences, mais les chances sont que si vous vérifiez les informations de licence sur le Visual Studio Express, il sera assez lâche pour votre projet.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top