mslomp
(usa Slackware)
Enviado em 19/09/2008 - 13:14h
particularmente não conheço esse py2exe, mas segundo experiências anteriores, ele deve funcionar segundo o mesmo esquema que era utilizado em versões antigas do VB, ou seja, gera-se um p-code (pseudo code), que tem lá suas semelhanças com o bytecode utilizado pelo java, por exemplo. no caso do VB, quem realizava a "conversão", ou seja, executava o código nativo era uma dll (vbrunXX e, mais recentemente msvbvmXX. atualmente o trabalho sujo é feito pelo framework .net), sendo que esta possuía centenas e centenas de funções que interagiam de fato com as apis win32 - tanto é que aqueles tais de "declare function blablabla lib kernel32..." etc simplesmente informavam a essa máquina virtual que ao encontrar uma chamada a tal função, deveria executá-la e retornar os valores correspondentes. a grosso modo, essa máquina virtual era um pombo-correio entre o p-code e os recursos do windows.
na época havia um programa que embutia essa máquina virtual no executável gerado pelo vb, de modo que não era necessário que as dependências estivessem instaladas para executá-lo. muito intrigado que fiquei, resolvi investigar como aquilo era possível, e após diversas teorias, cheguei a uma solução que me parecia viável. fiz uns testes e bingo! é algo do tipo "claro, como não pensei nisso antes!!!"
então, chega de blablabla e vamos à "revelação" passo a passo de como a mágica funciona:
1 - criei uma dll nativa com o masm
2 - criei um projeto exe no vb (4 ou 5, não lembro) e adicionei suporte a resources
3 - embuti a tal dll como um resource binário
4 - no código vb, através das apis win32 para manipulação de resources (e não as funções nativas do vb para isso), eu extraía a dll para a memória como código executável
5 - estando ela em memória, eu podia mapeá-la e carregá-la através de LoadLibrary e então chamar suas funções normalmente
então eis que descobri que, no caso do programinha aquele, simplesmente havia um stub em código nativo que fazia esse serviço, visto que o p-code do executável vb só poderia funcionar após a vm estar carregada, lógico. então ele embutia tanto a vm quanto o exe gerado pelo vb.
sendo assim, talvez seja esse também o método utilizado por esse tal py2exe. a desvantagem é que sua vm traz junto muita coisa desnecessária, tornando o executável maior do que o que seria razoável. porém, isso pode ser contornado através de compactadores de executáveis, como o upx por exemplo.
dá para fazer isso num linux? a resposta é: sim, porém é necessária outra abordagem, visto que o elf não possui essa propriedade de resources, e também, não estamos lidando com dlls, e sim com pic (position independent code), apesar de que isso torna as coisas mais fáceis do que com dlls. a idéia básica seria embutir a vm sob formato shared object na seção de dados do executável, e através de artifícios (em assembly), mapeá-lo como porção de código (text).
ps: eu ainda devo possuir aquele meu projetinho em vb que mencionei acima. vou vasculhar o fundo do baú, e caso eu o encontre avisarei os colegas por aqui, e posso com prazer compartilhá-lo com os interessados.
