logo
Contato | Sobre...        
rebarba rebarba

Rodrigo Strauss :: Blog


Disponível o OmniObjects versão 0.20

Arrumei um boa desculpa para minha falta de posts no blog: minha profunda dedicação ao projeto OmniObjects. :-)

Essa semana eu disponibilizei no site do projeto no SourceForge o OmniObjects versão 0.2, que agora tem toda a funcionalidade necessária para ser usável em algum projeto. Agora o proxy já faz o controle do contador de referência e libera o objeto remoto quando ele deixa de ser usado. Além disso, o suporte ao QueryInterface remoto também está funcionando perfeitamente. Qualquer componente com oleautomation pode ser usado com o OmniObjects, sem restrições.

Aos que estão estudando programação Win32 em C/C++, o código fonte é bem ilustrativo e comentado. Lá você pode ver alguns usos práticos de DLLs, COM, ATL, Winsock, threads e sincronização entre outros. Você pode somente ver os fontes do OmniObjects diretamente no seu browser ou baixá-los diretamente do servidor SubVersion do SourceForge. Os fontes também estão contidos no ZIP do release 0.2.


Em 14/10/2006 01:17, por Rodrigo Strauss


  
 
 
Comentários
Cesar Gimenes | em 20/10/2006 | #
Muito interessante! É bem o que estou precisando para meu projeto...
pena que ainda não tem porte para GNU/Linux :D
Rodrigo Strauss | website | em 20/10/2006 | #
AINDA não... Mas aceito voluntários para ajudar :-)
Cesar Gimenes | em 23/10/2006 | #
Já estou dando uma olhada nos fontes e estudando essa historia de objetos distribuídos.

Eu sou do tempo que se abria um socket e se usava muito sscanf para ler as requisições RPC. :D
Clebson Derivan | em 23/10/2006 | #
Cara vai dar trampo portar o projeto pro gcc o Strauss é muito viciado em VC++ :D vou dar umas dicas para quem tentar se aventurar:

OmniIdl\stdafx.h
1 - tirar os headers do windao (tchar.h, conio.h, direct.h, windows.h).
2 - para nao ter que mudar muito no codigo definir o tipo TCHAR:
typedef char TCHAR;
typedef char _TCHAR;
3 - tirar os "cosnt" select1st, select2nd o gcc nao deixa passar nem com reza.

OmniIdl\OmniIdl.cpp
1 - tirar os "_" das funcoes posix (_stat, _chdir, _mkdir[adicionar o parametro mode a funcao mkdir]
2 - comentar essa funcao find_all nao ta sendo usado em lugar nenhum :P

Exceptions:
1 - a classe std::exception nao possui construtor std::exception(const char *)
2 - declarar destrutor virtual:
eg: virtual ~ParseException() throw ()

Adicionar new line em alguns arquivo: (CodeEntities.h, MakeMarshal.cpp, MakeMarshal.h, etc...)

bom, nao tou com tempo de converter, mas acho que vai ser preciso mudar muita coisa!! tem parte que esta sendo chamando api (eg: CoCreateGuid, FindResource) :~~

mas seria uma otima um port pra linuxes, se alguem topa, ate ajudo.

[]'s
Clebson Derivan
Rodrigo Strauss | website | em 23/10/2006 | #
O OmniIdl foi preparado para ser portado facilmente, já que ele usa quase nada de API Win32 e usa só Boost e C++ ISO. O select1st e 2nd é só usar o do boost, esse acabou sobrando no código. As únicas dependências explícitas do Windows é sobre criação de GUID (fácil de portar, deve ter código BDS pronto) e os resources (que eu não sei como funciona no Linux). Mas quase tudo está isolado em funções e não espalhado pelo código.

Coloquei o _ antes das funções posix porque o Visual C++ 8 disse (warning) que o padrão ISO usa _ antes. Mas acho que também não é complicado.

Não é preciso usar TCHAR, já que eu fiz tudo em ANSI para ser mais fácil de portar.

Ah, o OmniIdl é o mais fácil de portar. O OmniObjects.dll usar Winsock, threads e eventos Windows :-)

Cesar Gimenes | em 24/10/2006 | #
O problema não é o código do Strauss, é a falta de tempo (como sempre) para brincar com isso. :(

De qualquer forma uma hora ou outra vou ter implementar alguma coisa um pouco mais robusta que o velho método de parsing de strings e sockets. :)

Ando procurando alternativas que me sirvam como XML-RPC (já tinha implementado algumas coisas com isso faz algum tempo), SOAP, e algumas outras implementações derivadas de CORBA e de DCOM... até o Remoting do .Net sobre Mono eu estou testando. :D

Estou meio inclinado a usar XML-RPC, alem de eu já ter alguma coisa implementada ele atende os requisitos das minhas aplicações sem falar que eu já tenho módulo desenvolvido para o Apache e seria simples servir XML-RPC por ele.

O legal com o OmniObjects é que sem duvida o código ficaria muito mais elegante.

Clebson Derivan | em 24/10/2006 | #
Cesar,

vc quer algo multiplataforma!? ja deu uma olhada no bom e velho Sun RPC ?

[]'s
Clebson
Cesar Gimenes | em 27/10/2006 | #
Clebson,

Tem que ser multiplataforma sim.
Não conheço o Sun RPC, vou dar uma olhada.

O que estou procurando é a forma mais transparente possível de chamar uma RPC e tanto passar parâmetros quanto receber retornos complexos como vetores, classes, listas, etc.
Encontrei o que eu queria com o Remoting do .Net mas não quero ficar preso ao .Net mesmo o sistema funcionando perfeitamente sobre o Mono.

Obrigado pela dica!
Renato Santos | em 09/11/2006 | #
Cara...

Descobri seu site hoje e deixei de trabalhar pra ficar lendo os posts hahaha

Meu chefe que não descubra

Vou acompanhar sempre de agora em diante!

Muito bom, adorei as dicas, principalmente aquela sobre o vector, não sabia que isso existia, simplesmente salvou minha vida! Precisava mesmo fazer um vetor ficar variando loucamente auhauhauha...

Sucesso!

Abraços
Rodrigo Pinho | em 14/11/2006 | #
Gostei do seu trabalho ... dei uma olhada por cima nos fontes, e gostei do que eu vi.

Demoro para vc colocar no codeproject.

Abraços
Rodrigo Strauss | website | em 14/11/2006 | #
Vou escrever um artigo pra lá assim que terminar mais uma versão. Estou terminando o suporte a passar objetos via parâmetros, e ainda preciso dar uma reorganizada nos fontes... :-)
rebarba rebarba
  ::::