como descarregar a dll - página 2
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Não há UnloadLibrary() no WinAPI, há FreeLibrary().
Você está certo :-). Meu MSDN não foi carregado por alguma razão :-).
.
O SO descarrega qualquer dll somente no valor zero do contador de carga.
Neste caso, a única aplicação que carrega a dllku é o metatrader.
Neste caso, a única aplicação que carrega a dllku é Metatrader.
usando uma biblioteca externa via #import.
Quando eu descarrego o idnikator, o terminal ainda mantém a dll. como eu me livro dele?
Escreva uma dll sem erros. Normalmente os dlls são descarregados por eles mesmos, a menos que haja alguma contingência.
Além de qualquer método "hacker", esta é a única coisa possível.
Escreva a dll sem erros. Normalmente, a dll se descarregará sozinha, a menos que haja alguma contingência.
Bem, meu caro amigo.
Eu tenho o último Dll e decidi seriamente provar que você está errado :-).
Descobri que depois de sair do roteiro, assim como depois de sair do indicador
(fechando a janela ou apagando o indicador), o Dll é descarregado.
Quanto à "alfabetização"... DllMain sempre retorna estupidamente VERDADEIRO.
Mas lembro que há cerca de um ano tive que sair de Metatrader para substituir o Dll.
OS = WinXP SP3, MT = 225
Vocês são estranhos ou algo assim. Só tive tais problemas, que não foram descarregados, algumas vezes, e isso sempre foi devido a erros no código. Este é o primeiro. A segunda. Deixe-me lembrar que a Microsoft inventou este mecanismo de carga/descarga implícita especificamente para simplificar o manuseio do Dll.
De onde você tira estes estranhos problemas - eu me recuso a entender.
Sim, e isso, eu pessoalmente não uso o DllMain, diretamente.
Vocês são estranhos ou algo assim. Só tive tais problemas com algo não descarregado algumas vezes, e isso sempre foi devido a erros de código.
De onde você tira estes estranhos problemas - eu me recuso a entender.
E eu pessoalmente não uso o DllMain diretamente.
Aqui está uma citação da MSDN:
"Quando o sistema chama a função DllMain com qualquer valor diferente de DLL_PROCESS_ATTACH, o valor de retorno é ignorado".
Isto é, quando você descarrega um Dll-in, o sistema não se importa absolutamente com o que você pensa de si mesmo como programador lá.
Não pode ser escrito corretamente ou incorretamente - se você não estiver nele, ele simplesmente sai. Se possível.
.
Mas como você se acha um profissional, você provavelmente pode aconselhar os iniciantes em vez de ajustar...
Eu não vejo você escrevendo nada de substancial - remova a ligação dinâmica do projeto,
dependências em pacotes de tempo de execução, manuseie cuidadosamente os pacotes interligados - é provável que sejam usados lá, é claro.
são usados lá, é claro, e possivelmente trabalham com o subsistema COM, onde uma única chamada como a OleInitialize pode atender
dúzias de sistemas Dlls. Já que todas essas dependências são carregadas de uma só vez... é fácil com a colocação em funcionamento,
mas com a desinicialização - por exemplo, se tanto Dll como Metatrader conectarem as mesmas bibliotecas do sistema -
pode haver problemas - quem sabe o que está na parte de trás do sistema operacional.
.
Nós somos usuários de API que engancham todas as funções do Dll através de .h / .lib e o carregamento de bibliotecas,
O mais provável é que isso aconteça na inicialização da aplicação, não há *nada* que possamos fazer.
Ou carregaríamos todas as bibliotecas por nós mesmos e ligaríamos todas as funções dinamicamente à mão.
Por outro lado, tudo deve estar bem em matemática nua - ou em algumas funções API.
O Windows armazena qualquer DLL. É um cache muito forte.
Devido ao exposto acima, ele se revela bastante próximo da realidade. Isto é, se o dll-ine enganchar as dependências -
Então o sistema operacional não pode descarregá-lo sem o aplicativo de carregamento que carregou esta DLL.
Aqui está uma citação da MSDN:
"Quando o sistema chama a função DllMain com qualquer valor diferente de DLL_PROCESS_ATTACH, o valor de retorno é ignorado".
Isto é, quando você descarrega um Dll-in, o sistema não faz absolutamente nenhuma diferença o que você pensa de si mesmo como um programador lá.
Não pode ser escrito direito ou errado - se você não está nele, ele simplesmente sai. Se possível.
Mais uma vez, para os especialmente dotados - se a dll for escrita sem erros - tudo deve funcionar como deveria. Não há nenhum mecanismo especial para descarregar bibliotecas que são carregadas por ligação tardia. Está claro?! A MQL4 não oferece nenhum serviço relacionado explicitamente à carga/descarga de Dll via Load\FreeLibrary. Da mesma forma, não há acesso ao Terminar.
Mas como você se considera um profissional, você provavelmente pode aconselhar os iniciantes em vez de ajustar...
Eu não vejo você escrevendo nada de substancial - remova a ligação dinâmica do projeto,
dependências em pacotes de tempo de execução, manuseie cuidadosamente os pacotes interligados - é provável que sejam usados lá, é claro.
são usados lá, é claro, e possivelmente trabalham com o subsistema COM, onde uma única chamada como a OleInitialize pode atender
dúzias de sistemas Dlls. Já que todas essas dependências são carregadas de uma só vez... é fácil com a colocação em funcionamento,
mas com a desinicialização - por exemplo, se tanto Dll como Metatrader conectarem as mesmas bibliotecas do sistema -
pode haver problemas - quem sabe o que está na parte de trás do sistema operacional.
Leia Richter, eu o recomendo altamente. Torna-se claro que não há mágica em trabalhar com dlls, e as bibliotecas são sempre descarregadas assim que não são mais necessárias para o espaço de endereços do processo atual. Esta necessidade é determinada pelo balcão. Se o contador não for zerado até o momento da descarga do programa MQL, significa que em algum lugar houve um erro, e um erro grosseiro.
Assim, na verdade, somos usuários de APIs que executam todas as funções Dll - geralmente via .h / .lib e o carregamento de bibliotecas,
O mais provável é que aconteça na inicialização da aplicação, não há *nada* que possamos fazer.
Ou nós mesmos carregaríamos todas as bibliotecas e ligaríamos todas as funções de forma dinâmica à mão.
Por outro lado, tudo deve estar bem em matemática nua - ou em algumas funções API.
Devido ao exposto acima, ele se revela bastante próximo da realidade. Isto é, se a linha dll enganchar as dependências -
então o sistema operacional não pode mais descarregá-lo sem descarregar a aplicação que carregou este Dll.
Os desenvolvedores do MT4 estavam muito certos em não colocar o mecanismo Load\FreeLibrary nas mãos dos usuários. Muito bem. É tudo sobre o nível da cultura de programação dos comerciantes.
E por último, leia as próprias recomendações da Microsoft - é preto e branco afirmado lá que embora seja possível fazer complexas dependências dll entre si - tudo isso tem suas limitações.
O Windows irá armazenar em cache qualquer DLL. Ela se esconde muito.
Eu não chamaria o mecanismo de mapeamento de um dll para um espaço de endereços de processo de um mecanismo de cache. É um processo completamente separado.
Eu não chamaria o mecanismo de mapeamento dll para um espaço de endereços de processo de um mecanismo de cache. É um processo completamente separado.
Você é meio esquisito. Há até mesmo um diretório dllcache no diretório Windows\system32, todos os sysadmins do mundo descarregam todas as dlls usando regsvr32, e você está contando fábulas para as pessoas aqui. Com quem você está contando? Aqui não há idiotas.