Bibliotecas: Mapeamento de Arquivo sem DLL

Novo comentário
 

Mapeamento de Arquivo sem DLL:

Classes (convertidas do C++ para MQL5) para trabalhar com arquivos de memória mapeada.

Autor: o_O

 

Alex, você pensou em passar um identificador de arquivo virtual para outra thread?

Não encontrei, se houver, por favor, me indique.

ZY Mas, em geral, isso é bom.

 
Urain:

Alex, você já pensou em passar o identificador de um arquivo virtual para outro thread?

Qual é o problema?
 
sergeev:
Qual é o problema?

Não há problema, eu encapsulei o identificador e o passei para outro objeto, tudo funciona.

Só estou procurando onde você forneceu essa transferência de acesso a arquivos.

 

na classe CMemMapApi, o identificador de memória deve ser armazenado pelo programa que o utiliza (esse objeto).

e em CMemMapFile - o identificador é armazenado em m_hmem público

 
sergeev:

Na classe CMemMapApi, o identificador de memória deve ser armazenado pelo programa que o utiliza (esse objeto).

e em CMemMapFile - o identificador é armazenado em m_hmem público .

Então não estou entendendo algo muito bem :)

especificar que, após fechar o arquivo, ele pode ser aberto em outro programa ou

ele é destruído após o fechamento?

E quando o arquivo é destruído e a memória é liberada?

 
Urain:

Então não estou entendendo algo muito bem :)

especificar que, após fechar um arquivo, ele pode ser aberto em outro programa ou

ele é destruído após o fechamento?

e quando o arquivo é destruído e a memória é liberada?

Aha, entendi, você não pode passar os handles, mas apenas fazer uma nova abertura em uma nova thread pelo nome do arquivo.
 
Urain:

Aha, descobri que não é possível passar os handles, mas apenas fazer uma nova abertura em uma nova thread pelo nome do arquivo.
Bem, Nikolay, por que eu fiz tudo isso? :) Claro, para que diferentes softwares possam gravar/ler simultaneamente em um arquivo comum.
 
sergeev:
Nikolay, por que fiz tudo isso? :) Claro, para que diferentes softwares pudessem gravar/ler em um arquivo comum ao mesmo tempo.
Alex, obrigado por seu trabalho. Ainda não tentei usá-lo, pois é um tópico novo para mim e preciso ler (artigos sugeridos por Rashid). Apenas uma pergunta no momento. No título do tópico, é enfatizado - sem DLL. Mas há um apelo ao kernel32.dll e ao msvcrt.dll. Então essa solução não é adequada para o mercado?
 
tol64:
Alex, obrigado por seu trabalho. Ainda não tentei usá-lo, pois ainda é um tópico novo para mim e preciso ler (artigos sugeridos pelo Rashid). Mas aqui vai uma pergunta para o momento. No título do tópico, é enfatizado - sem DLL. Mas há um apelo ao kernel32.dll e ao msvcrt.dll. Então essa solução não é adequada para o mercado?

Não é adequada para o mercado (embora ainda esteja em questão), mas Renat disse que pensaria em implementar essas coisas no padrão MQL5.

No título, eu quis dizer sem dlls escritas por você mesmo, afinal, as dlls padrão do Windows são mais seguras do que as escritas por você mesmo.

 
Urain:

O título significa sem dlls escritas por você mesmo, afinal, as dlls padrão do Windows são mais seguras do que as escritas por você mesmo.

Sim, eu quis dizer sem dlls escritas por você mesmo. E as padrão são seguras no sentido de que todos sabem o que elas fazem.
Para o mercado, essa solução (de acordo com as regras existentes) não é adequada.


Mas o mercado (eu realmente espero) aceitará minha variante proposta como básica - você pode publicar um Expert Advisor que chama funções da biblioteca ex5.

Ou seja, todas as chamadas de dll são feitas no ex5, que não está exposto no mercado, mas está na base de código ou no site do desenvolvedor.

123456789101112
Novo comentário