64 bits

[Gr@c@]

Os componentes do ACBr já estão aptos para serem usados em Delphi 64 bits?

[EMBarbosa]

Ei Gr@ç@,

não tivemos nenhum retorno sobre isso ainda. Eu acredito que se houverem os problemas sejam muito poucos.

A ideia seria alguém começar compilando os DEMOS e fazer testes neles. Não sei se alguém já fez isso.

[Gr@c@]

Obrigada Elton.

O Delphi Conference será dia 23/10 e seria bom se o pessoal que já tem o Delphi XE2 postasse aqui problemas ou mesmo dúvidas para levarmos no dia.

[Daniel Simoes]

Não vejo vantagens em compilar uma aplicação Desktop (automação comercial) em 64bits... isso apenas diminuiria o numero de máquinas onde a aplicação pudesse ser instalada.... E aplicações Desktop não fazem um uso intensivo de processamento...

No XE2, o Delphi usa o FreePascal para compilar em Mac e 64bits... será que continuará desta maneira ?

[Gr@c@]

A intenção aqui é fazer aplicativo para 32 e 64 bits, onde estaria incluso pelo menos NF-e, CT-e e SPED.

A maioria dos micros agora vem com Windows7 64bits e já tivemos problemas com o aplicativo ECF + dll do fabricante. Lembra como foi rápida a transição do 16bits para 32bits e como as pessoas torciam o nariz para aplicativos 16bits?

[EMBarbosa]

Obrigada Elton.

O Delphi Conference será dia 23/10 e seria bom se o pessoal que já tem o Delphi XE2 postasse aqui problemas ou mesmo dúvidas para levarmos no dia.

Pois é, se houver retorno ou dúvidas a gente pode investigar. Mas não estou lembrado de nada no momento.

Penso por alto, me vem duas coisas à mente que poderiam dar problemas:

1) A biblioteca Synapse, para acesso a porta paralela. Que não me lembro se estava bem testada para 64 bits.

2) Algum acesso/alocação/liberação à memória, arquivo ou algum protocolo que seja feito em bloco de bits.

Mas como disse, o melhor seira talvez compilar e executar todos os DEMOS e verificar se o retorno de todos é igual ao deles compilados para 32 bits. É trabalhoso, mas não precisa de muito conhecimento técnico dos componentes.

[Mark Apollo]

Se puder ajudar: Desenvolvo em BDS 2006 em windows 7 64bits, não compilo em 64bits, mas executo a aplicação sem problemas tanto em 32 quanto em 64 bits.

Utilizo NFe, CTe e SPED.

[EMBarbosa]

Se puder ajudar: Desenvolvo em BDS 2006 em windows 7 64bits, não compilo em 64bits, mas executo a aplicação sem problemas tanto em 32 quanto em 64 bits.

Utilizo NFe, CTe e SPED.

O maior problema não é ter um Windows 64 bits, mas compilar para 64 bits.

Você ou qualquer outrapessoa que possua o Lazarus ou Delphi que permita compilar para 64 bits pode ajudar da seguinte maneira:

1) Compilar os programas de exemplo para 64 Bits.

1.1) Reportar quaisquer erros de compilação, se possível com sua correção.

2) Executar os programas de exemplo no Sistema operacional de 64 bits e verificar seu funcionamento se está de acordo com a versão 32 bits.

2.1) Reportar quaisquer erros ou divergências no funcionamento, levando em conta o funcionamento da versão de 32 bits.

Assim, a pessoa pode testar todos os componentes ou projetos mesmo que não utilize o componente em questão.

[megaterra]

Pessoal tambem estou interessado nessa compilação para 64 bits com delphi xe2, tentei instalar pelos pacotes e pelo instalador

AcbrInstall e os mesmos me retornaram o erro em todos os pacotes:

ACBrNFeDanfeFRpkg.dpk(73) Fatal: E2202 Required package 'designide' not found

se alguem puder ajudar.

[MagoSchmidt]

Pessoal,

 

Estou usando somente o AcbrNFSe e tentando compilar em 64 bits. Não consegui terminar a compilaçao pois parece haver a necessidade de uma versão 64 bits da CAPICOM.DLL.

 

Se alguém já tiver passado por isto ou já tiver o TLB da CAPICOM.DLL de 64 bits dê alguma dica por favor

 

Abraços!

[MagoSchmidt]

Pessoal,

 

Passaram-se alguns meses e eu tive que retornar ao problema. O AcbrNFSe não compila para 64 bits pois dá o seguinte erro na ACBrNFSeWebServices_XML.pas: "E2197 Constant object cannot be passed as var parameter" nesta linha:

 

-------------------

procedure TWebServicesBase.OnBeforePost(const HTTPReqResp: THTTPReqResp;

  Data: Pointer);

var

 Cert         : ICertificate2;

 CertContext  : ICertContext;

 PCertContext : Pointer;

begin

 Cert        := FConfiguracoes.Certificados.GetCertificado;

 CertContext := Cert as ICertContext;

 CertContext.Get_CertContext(Integer(PCertContext));

                     ^^^^^^^^^^^^^^^^^^

--------------

 

Isto ocorre porque a Get_CertContext está declarada assim na ACBrCAPICOM_TLB.pas:

 

function Get_CertContext(out ppCertContext: Integer): HResult; stdcall;

 

Pelo que descobri, integer em 64 bits continua com 4 bytes, enquanto pointer agora é 8 bytes....esta é a origem do poblema...Alguem tem uma saída?

Editado 6 Março, 2013 por MagoSchmidt

[MagoSchmidt]

Esqueçam tudo. Acabei de descobrir que NÃO EXISTE CAPICOM 64 Bits. O máximo que pode ser feito é usar a CAPICOM de 32 bits rodando na plataforma 64 bits, mas nao era isto que eu queria....

 

Do MSDN:

 

"[CAPICOM is a 32-bit only component that is available for use in the

following operating systems: Windows Server 2008, Windows Vista, and

Windows XP.]"

Editado 6 Março, 2013 por MagoSchmidt

[Mark Apollo]

Mago, 

 

também tenho tido alguns problemas com o CAPICOM, o que me fez tomar uma decisão:  estou migrando os componentes que necessito para .NET.

 

Estou aos poucos fazendo isso no meu tempo vago, hoje tenho em produção somente a consulta de NFe's destinadas, mas, aos poucos quero migrar, primeiramente o ACBrNFe e, de acordo com minha necessidade, os outros também.

 

Assim que tiver com eles mais completos posso, caso achem interessante, disponibilizar na comunidade.

[Juliomar Marchetti]

markapollo

chegou a olhar o projeto ACBrFrameWork dos Rafaeis???

eles já estão a fazer isso e está disponível no SVN

[Mark Apollo]

markapollo

chegou a olhar o projeto ACBrFrameWork dos Rafaeis???

eles já estão a fazer isso e está disponível no SVN

Ei, Juliomar, sim, já olhei, só que eles não estão migrando o projeto, eles estão fazendo um interop, ou seja, continuamos presos ao 32 bits, se não for possível compilar os componentes em 64 bits.

 

 

O que eu estou fazendo é não utilizar a dll, não utilizar um código em delphi, somente em .NET.

 

Estou preparando algumas informações e, assim que tiver mais concreto, dou mais notícias.

 

Mesmo se a galera não se interessar, estou fazendo por mim, pois estou precisando muito e estou aproveitando muito do aprendizado e da estrutura dos componentes ACBr para o desenvolvimento, já que, ao meu ver, a suite ACBr é a mais estruturada do mercado, mesmo quando olhamos um único componente.

[MagoSchmidt]

Ei, Juliomar, sim, já olhei, só que eles não estão migrando o projeto, eles estão fazendo um interop, ou seja, continuamos presos ao 32 bits, se não for possível compilar os componentes em 64 bits.

 

 

O que eu estou fazendo é não utilizar a dll, não utilizar um código em delphi, somente em .NET.

 

Estou preparando algumas informações e, assim que tiver mais concreto, dou mais notícias.

 

Mesmo se a galera não se interessar, estou fazendo por mim, pois estou precisando muito e estou aproveitando muito do aprendizado e da estrutura dos componentes ACBr para o desenvolvimento, já que, ao meu ver, a suite ACBr é a mais estruturada do mercado, mesmo quando olhamos um único componente.

 

markapollo, podemos trocar algumas idéias pelo msn/skype? Estou precisando urgente migrar meu sistema para plataforma 64 bits e a única parte que ainda está pegando é a da AcbrNFSE. Meu msn/skype é [email protected] se voce puder favor add.

 

obrigado

[Rafael Dias]

@markapollo

O ACBrFramework funciona sim em x64.

So não temos ainda todos os componentes implementados, mas ate o momento todos os teste que eu fiz em x64 foram bem sucedidos.

Muitas coisas é só trocar as dll, tipo o ACBrEAD você precisa das dlls do openssl compiladas em x64. o ACBrDIS também precisa de dll x64 eu adicionei ela mas não tive a oportunidade de testar pois não tenho um display para o mesmo.

Mas o ECF, EAD e AAC já testei e funcionam corretamente.

E outra pelo que eu vi no codigo do ACBr nao precisa de muitas modificações para o x64 apenas das dlls corretas.

Sobre o NFe eu ainda estou implementando, e estou tendo alguns erros na compilação x64, mas assim que tiver tempo devo corrigir.

[Mark Apollo]

Tenho acompanhado o processo do framework também, quando decidir reproduzir o ACBr para .NET ainda não existia ele, somente a dll, mesmo assim decidi por conta própria continuar.

 

Tenho um certo receio em algumas coisas, tais como o uso do CAPICOM, que já foi abandonado pela microsoft a anos, outra coisa que acabei percebendo foi que, ao menos na consulta de NFe's destinadas, as requisições ficaram muito mais rápidas, tipo: antes eu não conseguia realizar a consulta até o ultimo NSU de todos os CNPJ's que necessito, mesmo que deixasse rodando um dia inteiro, hoje, em cerca de 1 hora eu consegui recuperar todas as notas, mesmo iniciando do NSU 0, agora demoro 10 segundos para retornar todas as notas de um dia para 14 CNPJ's. Também tive menos erros de conexão, etc...

 

Estes são alguns dos motivos que têm me motivado a migrar o componente para .NET.

[Daniel Simoes]

Markopollo,

 

Você conhece .NET, conhece os fontes do ACBr e conhece a CAPICOM, então porque não juntar forças com a equipe do ACBrFramework para ajustar o código em pascal para remover a dependência da Capicom ?

 

Eu particularmente ainda prefiro a CAPICOM... instalar os inúmeros Frameworks do .NET nunca é tarefa fácil (ou rápida)... Na CAPICOM, basta registrar algumas DLLs e está feito...

 

Não creio que a simples troca da CAPICOM por .NET deixe a comunicação tão mais rápida dessa maneira... o gargalo provavelmente era outro... Mas em fim não fiz testes...

[Mark Apollo]

Markopollo,

 

Você conhece .NET, conhece os fontes do ACBr e conhece a CAPICOM, então porque não juntar forças com a equipe do ACBrFramework para ajustar o código em pascal para remover a dependência da Capicom ?

 

Eu particularmente ainda prefiro a CAPICOM... instalar os inúmeros Frameworks do .NET nunca é tarefa fácil (ou rápida)... Na CAPICOM, basta registrar algumas DLLs e está feito...

 

Não creio que a simples troca da CAPICOM por .NET deixe a comunicação tão mais rápida dessa maneira... o gargalo provavelmente era outro... Mas em fim não fiz testes...

 

 

 

[OFF Topic]

Tenho medo de falar sobre outras linguagens em fóruns por causa de retalhação, mas, sinceramente, aqui me sinto mais a vontade, mas, tomo muito cuidado em apresentar argumentos para que eu não acabe levando a conversa produtiva à discussões xiitas sobre linguagens, detesto isso...

[/OFF Topic]

 

Sim, tenho um conhecimento básico sobre os itens citados, sim, dentro da minha disponibilidade, poderia juntar forças com a galera.

 

Também não creio que a questão do desempenho seja pela capicom, mas, por outras questões que, sinceramente, não saberei dizer, fato é que tive este ganho de desempenho,

 

Quero terminar o componente NFe para poder ter mais informações,  Tenho tentado fazer o máximo possível na estrutura do componente em delphi, aproveitando nomes de propriedades e eventos, acredito que, caso seja interessante, não será possível, por exemplo, substituir a parte referente a ele no ACBrFramework, por exemplo.

[Rafael Batiati]

Pessoal, só pra jogar mais lenha na fogu.... errr ... só pra esclarecer o negócio aí:

 

1. Estamos trabalhando para compilar e funcionar tanto o ACBr quanto o ACBrFramework em 64 bits.

 

Essa é uma necessidade que foi "adiada" por algum tempo.

Em Delphi e Lazarus é bem mais cômodo compilar e distribuir em 32bits. No .Net eu também não vejo tanta vantagem em distribuir em AnyCpu ou x64.

Inclusive é uma desvantagem enorme ter que depender de DLLs de terceiros em 64bits.

 

Mas em alguns casos, como no Java por exemplo, isso começou a ser um problema, pois a maioria das máquinas x64 rodam um JRE 64bits, e ter que ficar selecionando o JRE de 32bits pra executar é algo indesejável para um projeto que propõem a multiplataforma ... 

 

Isto posto, estamos procurando e testando as dlls 64 bits que o ACBr utiliza ... (veja a pasta DLL na raiz do projeto ACBr) A maioria delas já possui uma distribuição 64 bits... as outras que não possuem estamos buscando soluções equivalentes. Em breve vamos atualizar o SVN adicionando as versões 64bits de todas elas.

 

2. CAPICOM versus .Net

 

O CAPICOM, ou melhor, o finado CAPICOM, nada mais é que um ActiveX para manipular a Microsoft CriptoAPI. Essa CriptoAPI, também conhecida como "CAPI" é a base do Windows Cryptographic Service Provider, uma API em C/C++ padrão na plataforma Windows a partir do Windows 2000 ... a mesma API que o .Net usa em alguns algoritmos de criptografia dele.

 

Daí vem o nome do ActiveX: CAPI + COM = CAPICOM. E como todo ActiveX, ele não é compatível com 64bits, só 32bits mesmo.

 

Então temos a opção de continuar usando a CAPI diretamente, sem ActiveX, usando as declarações em Delphi (pesquisei por alto, mas vejam o link abaixo)

http://cc.embarcadero.com/item/17598

 

Ou temos a opção de buscar outros projetos que façam o serviço, como a openssl que o ACBr já usa para assinaturas e o openSC para manipulação de SmartCards e tokens.

https://www.opensc-project.org/opensc

 

(...)

 

Ou seja, ainda temos um bom trabalho pela frente até ter tudo definido. No momento nós estamos ainda "em pesquisa".

É possível colaborar das seguintes formas:

 

- Quem tiver disponibilidade para compilar e testar em x64 e depois reportar os bugs ... ECF, DISPLAY, EAD, NFe, etc... acho que todos os componentes sofrerão algum impacto em x64.

- Quem quiser se aventurar a usar o CAPI diretamente ou a openSC, podemos abrir um novo tópico aqui pra trocar uma idéia de como fazer as chamadas a partir do Delphi.

 

É isso aí, abraços!

[Mark Apollo]

Pergunto: qual a dificuldade/problema em reproduzir a biblioteca em .NET, Java, etc, vejo no ACBrFramework que boa parte das classes são reproduzidas, boa parte do código já é reproduzido e outros mais para possibilitar a interoperação.  Não tive muito trabalho em fazer alguns recursos do NFe funcionar, acredito que vou ter mais trabalho é na geração do DANFe.

 

Sei que a toda alteração teria que dar manutenção em vários códigos, mas, já é assim hoje, se, por exemplo, adicionarem mais um elemento no xml da NFe, tanto o componente delphi terá que ser alterado, quanto a framework, apesar de ser um excelente trabalho o que está sendo feito.

Editado 14 Março, 2013 por markapollo

[Rafael Batiati]

Pergunto: qual a dificuldade/problema em reproduzir a biblioteca em .NET, Java, etc, vejo no ACBrFramework que boa parte das classes são reproduzidas, boa parte do código já é reproduzido e outros mais para possibilitar a interoperação.  Não tive muito trabalho em fazer alguns recursos do NFe funcionar, acredito que vou ter mais trabalho é na geração do DANFe.

 

Sei que a toda alteração teria que dar manutenção em vários códigos, mas, já é assim hoje, se, por exemplo, adicionarem mais um elemento no xml da NFe, tanto o componente delphi terá que ser alterado, quanto a framework, apesar de ser um excelente trabalho o que está sendo feito.

 

No ACBrFramework.Net ou no jACBrFramework nada é reescrito, apenas as chamadas de Interop são feitas num modelo de classes semelhante ao do ACBr em Delphi. Não há uma única linha de código referente a regra de negócio dos componentes ...

 

Poderíamos fazer muita coisa diretamente em .Net ou em Java, mas nosso objetivo principal é fazer o Interop do ACBr garantindo o mesmo comportamento e resultado do componente original.

 

No meu ponto de vista, o ACBr já tem muitos anos de estrada, e deveríamos aproveitar essa  experiência. Implementar a mesma coisa em plataformas diferentes, mesmo que seja mais fácil a princípio, pode nos levar a resultados diferentes e debug mais custoso. 

Hoje um bug detectado por um usuário é corrigido de forma ampla em todas as plataformas.

 

Dessa forma, as funções precisam ser implementadas a partir do Delphi/Lazarus, para que todo o ACBr possa se beneficiar disso. Fazer pontos isolados em .Net ou Java só vai fragmentar o projeto em diversas soluções isoladas.

 

Abs!

[Mark Apollo]

Dan

 

No ACBrFramework.Net ou no jACBrFramework nada é reescrito, apenas as chamadas de Interop são feitas num modelo de classes semelhante ao do ACBr em Delphi. Não há uma única linha de código referente a regra de negócio dos componentes ...

 

Poderíamos fazer muita coisa diretamente em .Net ou em Java, mas nosso objetivo principal é fazer o Interop do ACBr garantindo o mesmo comportamento e resultado do componente original.

 

No meu ponto de vista, o ACBr já tem muitos anos de estrada, e deveríamos aproveitar essa  experiência. Implementar a mesma coisa em plataformas diferentes, mesmo que seja mais fácil a princípio, pode nos levar a resultados diferentes e debug mais custoso. 

Hoje um bug detectado por um usuário é corrigido de forma ampla em todas as plataformas.

 

Dessa forma, as funções precisam ser implementadas a partir do Delphi/Lazarus, para que todo o ACBr possa se beneficiar disso. Fazer pontos isolados em .Net ou Java só vai fragmentar o projeto em diversas soluções isoladas.

 

Abs!

 

Daniel, me desculpe, mas, a estrutura toda de classes e enums são reescritas, inclusive todos os registros dos SPED's, NFe, ou qualquer outro projeto,

 

Sim, concordo que centralizar a regra de negocio em um único lugar facilita, também concordo com a experiência do ACBr, não é atoa que estou aqui, colaboro e tento discutir, não para gerar confusão, mas, ao contrário, para ajudar o ACBr a melhorar ainda mais o quanto for possível.

 

Mas, só estou tentando passar a experiência que estou tendo, com melhor desempenho, por exemplo, que posso comprovar que foi "gritante", ao menos para consultar notas destinadas.

 

 

Mas, como falei, caso seja de interesse geral, eu disponibilizo o código, sem problemas nenhum, caso contrário, continuarei o desenvolvimento para uso próprio, aproveitando a experiencia do ACBr.  Mas, só disponibilizarei em consenso com os administradores do ACBr, justamente para não criar projetos fragmentados/paralelos.

 

Abraços.

[Rafael Dias]

A estrutura é duplicada não reescritar. Afinal não mudamos nada na estrutura.

E o importante não é isso e sim o fato da regra de negocio se manter e o codigo ficar centralizado.