SendMessage

[kapak 0]

Olá pessoal, alguém saberia me informar pq a msg WM_CopyData não aceita ponteiros no lpData de CopyDataStruct ?Por ex, se quiser passar uma string de um .exe p/ outro .exe, tenho que colocar em lpData @s[1] e não @s(que é um ponteiro).Acredito que o Windows neste caso faça uma ponte de comunicação transmitindo os dados de um exe p/ outro; mas pq não é possível enviar ponteiros?

[Beppe 0]

Isto se deve ao fato que o Windows precisa copiar os seus dados para o espaço virtual do processo destinatário, e não tem como saber quando um ítem é um ponteiro ou não.Quando você usa @s, o Delphi manda um ponteiro para um outro ponteiro. @s[1] ou PChar(s) é uma referência(um ponteiro, é assim que são implementadas strings de tamanho dinâmico) para o primeiro caractere da string, assim o Windows copia tantos bytes quanto você indicar.Em suma, o Windows envia apenas inteiros, booleanos, etc, e ponteiros, mas não o conteúdo de ponteiros.

[kapak 0]

Pois é Beppe, até aí eu entendo que qdo você passa @s[1] c/ tamanho Length(s)+1(pq o #0 tem que ir junto), na verdade você está passando um array of char e o outro lado recebe da mesma forma e depois converte p/ string c/ StrPas.Mas a minha dúvida é que mesmo você passando um ponteiro, o outro lado não consegue enxergá-lo; e isso me faz acreditar que os endereços de memória de um .exe não são endereços globais e sim endereços locais de cada aplicativo.Bom se for isso, quer dizer que o Delphi não tem acesso a endereços reais de memória ?

[Beppe 0]

Mas a minha dúvida é que mesmo você passando um ponteiro, o outro lado não consegue enxergá-lo; e isso me faz acreditar que os endereços de memória de um .exe não são endereços globais e sim endereços locais de cada aplicativo.Bom se for isso, quer dizer que o Delphi não tem acesso a endereços reais de memória ?

Foi isto que eu quiz dizer com "...espaço virtual do processo...". Apenas o Windows pode lidar com a memória física. O que cada processo tem é um espaço virtual, no qual o Windows mapeia um endereço virtual pra um endereço físico na RAM. Isto se chama momória virtual, que o Windows implementa com paginação.Você pode perceber mais claramente, se notar que você pode em teoria acessar até 4GB de memória no processo, mas um PC tem geralmente de 32MB à 512MB de RAM. Também pode ver que no processo A, o inteiro no endereço, digamos $404040, provavelmente será diferente do inteiro no mesmo endereço do processo B. Eu digo "provavelmente", porque a página a qual ele pertence pode ser compartilhada, principalmente se for duas instâncias do mesmo .EXE.Espero não ter complicado as coisas.

[kapak 0]

Entendo, isto quer dizer que você também não pode fazer uma ponte de comunicação utilizando uma dll c/ ShareMem ?Por ex:p1.exe acessa comum.dll c/ ShareMem.p2.exe acessa comum.dll c/ ShareMem.p1.exe altera uma variável global da comum.dll através de uma função que ela exporta, mas quando p2.exe for ler esta variável ela não estará alterada.É isto, ou a memória da dll é global em todo o Windows ?

[Beppe 0]

Os dados(variáveis) em uma .dll são únicos para cada processo que a utiliza. O que é compartilhado é o código, isto é apenas por eficiência, porque código é somente-leitura.Na verdade, o Windows fornece um seção no executável para compartilhar dados entre processos, mas infelizmente o Delphi não expõe isto. Você ainda pode compartilhar dados com CreateFileMapping e MapViewOfFile.

[Beppe 0]

A questão de ShareMem é diferente. Ela serve para compartilhar o mesmo alocador de memória entre o processo e todas as .dll's que a utilizam. Assim, você pode alocar em um .dll e liberar em outra. Sem ela, os dados seriam acessíveis para leitura e escrita, mas cada .dll teria um estado interno para seu alocador de memória e um AV aconteceria se você tentasse liberar um bloco de memória com o alocador errado.

[kapak 0]

Ou seja, não se consegue passar por ex um TStringList de um .exe p/ outro; somente de .exe p/ .dll e vice-versa utilizando o mesmo alocador de memória.Bom, nunca utilizei o CreateFileMapping, vou dar uma estudada nessa função e aprender mais um pouco o Windows.Obrigado Beppe !

[Beppe 0]

Estude sim, e se quiser se aprofundar mais, estude os outros mecanismos de comunicação inter-processos(IPC), e veja para que servem. Mailslots, pipes, events, mutexes, critical sections, etc...PS: Estude também o método NewInstance da classe TObject. Se você implementá-lo diferente, pode alocar seus objetos Delphi numa área compartilhada, assim pode acessar uma TStringList de quantos processos você quiser.

[kapak 0]

Bem que eu queria me aprofundar no Windows mesmo, mas o que acontece é uma corrida contra o tempo; vão chegando os problemas e você tem que correr atrás da solução. Um típico caso é quando o Delphi não disponibiliza alguma função do Windows; daí você corre atrás das apis, estuda a função apropriada e a aplica. E o meu problema agora é passar um TList de objetos de um .exe p/ outro pq o cliente quer um espelhamento dos dois aplicativos. Cada uma que aparece, mas fazer o que ? ganhamos pra isso não é ?

[Beppe 0]

Bem que eu queria me aprofundar no Windows mesmo, mas o que acontece é uma corrida contra o tempo; vão chegando os problemas e você tem que correr atrás da solução. Um típico caso é quando o Delphi não disponibiliza alguma função do Windows; daí você corre atrás das apis, estuda a função apropriada e a aplica. E o meu problema agora é passar um TList de objetos de um .exe p/ outro pq o cliente quer um espelhamento dos dois aplicativos. Cada uma que aparece, mas fazer o que ? ganhamos pra isso não é ?

Eu também teria muita coisa que eu gostaria de fazer, mas sempre surge ene coisas quando você se dispõe à fazer.