Compilador Redistribuível - DLLs para MS Visual Studio

Question

Estou fazendo um jogo de aprendizado de programação para o meu projeto sênior e estou procurando um compilador que possa compilar uma DLL que possa ser carregada dinamicamente em um aplicativo C ++ do Visual Studio 2008.

A idéia importante aqui é que o compilador é redistribuível. Se o VS fosse redistribuível, eu usaria isso.

Até agora, tenho algum sucesso usando Mingw, mas esse sucesso é limitado. Atualmente, só posso carregar uma DLL e trabalhar de cada vez. No momento em que tento carregar um segundo, o aplicativo VS C ++ trava com um erro de violação de acesso.

Consegui carregar duas DLLs compiladas no VS, sem problemas, por isso me leva a acreditar que é algo específico para Mingw, é DLL e como eles interagem com o Loadlibrary () e outros enfeites.

Trabalho nesse problema há algum tempo e estou frustrado. Se alguém souber de um compilador diferente que você sabe que funcionaria em vez de Mingw, ou se você viu esse problema, talvez saiba por que a segunda DLL trava. Tenho certeza de que está relacionado a cada DLL pisando na outra de alguma forma, mas não tenho idéia do que seria ou como descobrir.

Pode ser a maneira como estou compilando a DLL ou como estou carregando; Eu não faço ideia.

Eu realmente apreciaria o feedback, obrigado!

EDIT: Estas são as chamadas simples para G ++ e DLLtool para criar a DLLhttp://pastebin.com/f675df4b0

Esta é a fonte de uma das minhas DLLs.http://pastebin.com/f5c062611

Este é o código no meu aplicativo C ++ para carregar a DLL.http://pastebin.com/f52f94a18

-Michael

Answer 1

Você está retornando 0 da Dllmain. De acordo com as especificações, você deve retornar verdadeiro, a menos que algo dê errado. No entanto, não consigo ver por que isso deve dar um comportamento diferente no MSVC ou Mingw. Ele também diz que a biblioteca de carga deve retornar 0 se o dllmain retornar falso, para que essa possa não ser a explicação real.

O dllmain é realmente chamado na versão MSVC e Mingw, algo acontece se você remover o comentário na chamada da caixa de mensagem?

Para mais informações sobre Dllmain, confira http://msdn.microsoft.com/en-us/library/ms682583(vs.85).aspx

Outra coisa que pode ser interessante se você realmente chamar a AIFunction da primeira DLL antes de carregar o segundo. Se o fizer, você pode tentar carregar as duas DLLs sem chamar nenhuma função de DLL entre e ver se funciona melhor?

Minha suspeita é que o Mingw e o MSVC embalam as estruturas de entrada ou saída de maneira diferente e que, de alguma forma, esse tamanho incompatível faz com que a memória seja corrompida quando você chama a AIFunction. Você pode verificar a sanidade comparando os resultados sizeof () para saída e entrada dentro e fora da DLL e veja se ela corresponde. Isso não garante que esteja correto, mas se não corresponder, você pode ter certeza de que algo vai dar errado.

Finalmente, estou preocupado que o retorno da saída possa ser um problema a longo prazo se você começar a introduzir chamadas virtuais e essas coisas, pois isso pode não ser implementado exatamente da mesma maneira dentro do MSVC e Mingw. Se você mantê -lo sem funções virtuais e essas coisas, deve ficar bem, desde que a embalagem da estrutura corresponda.

Answer 2

O uso do Visual Studio Express seria bom o suficiente? O compilador é livremente download e economizará muita dor tentando fazer com que as DLLs sejam compatíveis.

Não sei o quão rigorosos são seus requisitos, mas é provável que, se você verificar as informações de licenciamento no Visual Studio Express, será solto o suficiente para o seu projeto.