Valdecir Luciano Carvalho

Então, o problema era que a utilidade do GetModuleHandle é de retornar o handle da dll supostamente ja em memoria pela referencia estática das externals. No entanto, com o "delayed" a carga não aconteceu ainda no momento da chamada desse procedimento pq não existiu até o momento nenhuma chamada que fizesse a aplicação carrega-la (por demanda). O que fiz ali foi só garantir que existe pelo menos uma chamada simples de uma função da dll pra assegurar que existe o carregamento da antes de tentar pegar o handle. Não esta doido, isso ai é um resultado esperado de uma resolução de conflito no svn. Sugiro vc fazer um svn "revert" desse arquivo, assim vc vai ter ele limpo como esta no servidor. Aí só depois vc aplica suas edições se achar necessário.

Régys estou usando o delphi XE7 e esta ocorrendo o mesmo erro, por exemplo o demo ECFTeste1 copila , mas na hora que executa a função : hLibeayDLL := GetModuleHandle(LIBEAY_DLL_NAME); na linha 1318, retorna "0" e é executado a exceção programada, utilizo o acbr com o delphi xe8 no windows 7 64 bits. Tente colocar os arquivos libeay32.dll, ssleay32.ddl no mesmo diretório do executável e tente novamente. Se ainda tiver com o erro baixe o arquivo dependency walker ( http://www.dependencywalker.com/ ) e verifique cada uma das dlls se não falta alguma dependencia. Apesar de não ser muito óbvio, uma dll pode carregar outras dlls as quais ela pode depender que exista na maquina, visível pelo path de execução,e ainda, no escopo de acesso do usuário que esta executando o aplicativo / dll. E pior, é importante que as dependencias sejam de versões compatíveis pois senão qualquer problema de versionamento pode quebrar a assinatura de métodos ou mesmo a funcionalidade esperada. Por exemplo, a versão 1.0.2d (1.0.2.4) do OpenSSL (libeay32 e ssleay32) depende da msvcr120.dll (12.0.21005.1) que não necessariamente vem no windows. Experimentem fazer essa pequena modificação no código e vejam se resolve o problema: procedure OpenSSL_add_all_algorithms; var hLibeayDLL: THandle; Add_all_algorithms_procedure: TOpenSSL_InitFunction; LibPointer : Pointer; {$IFNDEF FPC}sTmp :string;{$ENDIF} begin {$IFDEF FPC} hLibeayDLL := dynlibs.LoadLibrary(LIBEAY_DLL_NAME) ; {$ELSE} sTmp := String(SSLeay_version( 0 )); hLibeayDLL := GetModuleHandle(LIBEAY_DLL_NAME); {$ENDIF} ....

Régys estou usando o delphi XE7 e esta ocorrendo o mesmo erro, por exemplo o demo ECFTeste1 copila , mas na hora que executa a função : hLibeayDLL := GetModuleHandle(LIBEAY_DLL_NAME); na linha 1318, retorna "0" e é executado a exceção programada, utilizo o acbr com o delphi xe8 no windows 7 64 bits. Tente colocar os arquivos libeay32.dll, ssleay32.ddl no mesmo diretório do executável e tente novamente. Se ainda tiver com o erro baixe o arquivo dependency walker ( http://www.dependencywalker.com/ ) e verifique cada uma das dlls se não falta alguma dependencia. Apesar de não ser muito óbvio, uma dll pode carregar outras dlls as quais ela pode depender que exista na maquina, visível pelo path de execução,e ainda, no escopo de acesso do usuário que esta executando o aplicativo / dll. E pior, é importante que as dependencias sejam de versões compatíveis pois senão qualquer problema de versionamento pode quebrar a assinatura de métodos ou mesmo a funcionalidade esperada. Por exemplo, a versão 1.0.2d (1.0.2.4) do OpenSSL (libeay32 e ssleay32) depende da msvcr120.dll (12.0.21005.1) que não necessariamente vem no windows.

@Breno007 Qual versão de Delphi esta utilizando ? O problema que esta tendo é na compilação ou execução do aplicativo compilado com o novo source ? Se possível tire uma foto ou copie o log de compilação (se for o caso) e poste aqui.

Continua funcionando como ja estava funcionando antes. Só que infelizmente não carregando por demanda como no caso de ser compilada em Delphi 2010 pra cima. Ou seja, não ha quebra de compatibilidade e sim melhoria. Veja que a existe um check de versão por diretiva de compilação no código que só utiliza a feature se for num compilador com suporte, caso contrario compila como estava anteriormente sem nenhuma modificação a mais. Só trocar o .pas e reinstalar (recompilando) a acbr.

Boa tarde. Devido a uma necessidade em particular de uma aplicação, foi necessário fazer uma modificação na libeay32.pas que carrega as dlls do OpenSSL para evitar as mesmas fossem carregadas em memória logo no inicio da aplicação e sim quando forem realmente necessárias. Problema: A aplicação que usa a AcBr é quem extrai todos os arquivos necessários para execução. Mas como o carregamento das dlls openssl (libeay32.dll, ssleay32.dll, e por tabela msvcr100.dll/120.dll dependendo da versão do open ssl) é executada antes da execução dos unit initializers* o executável nunca viria a carregar pela, ainda ,inexistencia da dlls fisicamente no diretório. * codigo "initialization" de uma unit, que é onde , no caso, se extrai os arquivos. Solução: Utilizando de uma feature ("delayed") que foi inserida no Delphi 2010 que faz o carregamento atrasado das dependências externas. Segue em anexo a unit com a modificação sugerida. libeay32.pas