Redistributable compilatore - DLL per MS Visual Studio

Question

Sto facendo un gioco di apprendimento di programmazione per il mio progetto senior e sto cercando un compilatore in grado di compilare una DLL che possono poi essere caricati in modo dinamico in un Visual Studio 2008 C ++ applicazione.

L'idea importante qui è che il compilatore è ridistribuibile. Se VS era ridistribuibile sarei utilizzando tale.

Finora ho avuto un certo successo con MinGW, ma che il successo è limitato. Attualmente sono solo in grado di ottenere una DLL caricata e di lavoro in un momento. Nel momento in cui provo a caricare un secondo le app si blocca VS C ++ con un errore di violazione di accesso.

Sono stato in grado di caricare due DLL compilate in VS per sé senza problemi in modo che mi porta a credere che si tratta di qualcosa di specifico per MinGW, è DLL, e il modo in cui interagiscono con LoadLibrary () e quant'altro.

Ho lavorato a questo problema per un bel po 'di tempo e sono Frusterated. Se qualcuno sa di un diverso compilatore che si conosce sarebbe lavorare invece di MinGW, o se avessi visto questo problema, forse si conosce il motivo per cui la seconda DLL si blocca. Sono sicuro che è correlata ad ogni DLL calpestare l'altro in qualche modo, ma non ho idea di che cosa sarebbe o come trovare fuori.

Potrebbe essere il modo in cui sto compilando la DLL o come sto caricarlo; Non ho idea.

Vorrei davvero apprezzare le valutazioni, grazie!

Modifica: Queste sono le semplici chiamate a g ++ e dlltool per creare il DLL http://pastebin.com/f675df4b0

Questa è la fonte da uno dei miei DLL. http://pastebin.com/f5c062611

Questo è il codice nel mio C ++ applicazione per caricare la DLL. http://pastebin.com/f52f94a18

-Michael

Answer 1

State ritornando 0 da DllMain. Secondo le specifiche si dovrebbe restituire TRUE a meno che qualcosa va storto. Tuttavia non riesco a vedere il motivo per cui questo dovrebbe dare un comportamento diverso su MSVC o MinGW. Si dice anche che LoadLibrary dovrebbe restituire 0 se DllMain restituisce FALSE quindi questo non può essere la spiegazione reale.

Fa DllMain effettivamente ottenere chiamato sia nel MSVC e la versione MinGW, non è successo qualcosa se si rimuove il commento sulla chiamata messagebox in esso?

Per maggiori informazioni su DllMain, controllare http: //msdn.microsoft.com/en-us/library/ms682583(VS.85).aspx

Un'altra cosa che ti potrebbero interessare se si chiama in realtà l'AiFunction dal primo dll prima di caricare il secondo. Se lo fai, si può provare a caricare entrambi dll senza chiamare qualsiasi funzione dll inbetween e vedere se funziona meglio?

Il mio sospetto è che MinGW e MSVC racchiude la struct Input o Output in modo diverso e che in qualche modo questa mancata corrispondenza dimensione fa sì che il po 'di memoria per essere danneggiato quando si chiama AiFunction. È possibile controllare questo sanity confrontando sizeof () risulta per l'uscita e di ingresso all'interno e all'esterno del dll e vedere se corrisponde. Questo non garantisce che sia corretto, ma se non corrisponde si può essere abbastanza sicuro che qualcosa sta per andare storto.

Alla fine mi sono preoccupato che il ritorno di uscita può potenzialmente essere un problema a lungo termine, se si avvia l'introduzione di chiamate virtuali e cose del genere dal momento che non può essere attuata in esattamente allo stesso modo all'interno MSVC e MinGW. Se si mantiene senza funzioni virtuali e cose del genere dovrebbe andare bene fino a quando le partite struttura di imballaggio.

Answer 2

sarebbe solo utilizzando Visual Studio Express essere abbastanza buono? Il compilatore è liberamente scaricabile e vi farà risparmiare un sacco di dolore cercando di ottenere le DLL per essere compatibile.

Non so come rigoroso le vostre esigenze sono, ma le probabilità sono che se si controlla l'informazioni di licenza su Visual Studio Express sarà sciolto abbastanza per il vostro progetto.