WAPI v1.05 - Funções da API do Windows

por **Maligno** » 21 Jan 2008 17:30

<APAGADO>
Lista de parâmetros do utilitário WAPI.EXE.
Veja a lista atualizada no informe do último realease.

por **Pablo César** » 24 Jan 2008 16:48

Para que sejam feita a impressão em forma seletiva, a opção -PRINT precisaria ser informada uma sequência de caracteres CHR(2)+CHR(11)+CHR(3) em cada salto de página, com respeito a isto pergunto:

1. É possível Maligno, você alterar essa sequência de caracteres CHR(2)+CHR(11)+CHR(3) no seu código para apenas CHR(12) ??. Estou solicitando isto, porque normalmente é o CHR(12) que constam nos meus arquivos de impressão. Os arquivos são sempre gerados, ora para serem visualizados em tela e/ou impressora e também re-exibidos ou re-impressos posteriormente também. Tendo em mente que durante a impressão, pudera ocorrer algum problema (papel entolado, problema qualquer na impressão), daí então poderia visualizar o relatório e enviar as páginas que estariam faltando. Só que normalmente não posso colocar essa sequência de caracteres CHR(2)+CHR(11)+CHR(3) porque iriam afetar o relatório originalmente, tanto para a visualização como na impressão "normal" (iriam aparecer esses caracteres).

2. Digamos que no arquivo de impressão possua apenas uma sequência de caracteres CHR(2)+CHR(11)+CHR(3) e falta no final do arquivo. E seja preciso re-imprimir a segunda página. Esta situação estaria prevista ?

3. Digamos que uma das páginas do relatório tenha sido gerada com o tamanho maior do que uma página pode comportar e precise imprimir em forma seletiva, o aplicativo irá imprimir as páginas de acordo gerado sem importar-se com o tamanho de linhas por folha ?.

4. Para impressão de página de forma seletiva, é possível fazer o seguinte intervalo: "1,2,5,10-12,16" ?

A troca da sequência de caracteres CHR(2)+CHR(11)+CHR(3) por CHR(12) irá ser benéfica para o uso de todo relatório que for feito pelo Clipper, pois este é o nosso padrão. Tem cómo mudar isso ? Acho importantíssimo que seja feito pelo CHR(12), caso contrário, irá representar numa mudaça muito grande para adaptar a utilização exclusiva com o WAPI.

Outra pergunta que eu tenho a fazer, é com respeito ao 1º parâmetro que aceitaria em vez do nome da impressora (conforme esteja instalada no Windows) como a PORTA, isto é, LPT1, LPT2, \\COMPUTADOR\IMPRESSORA... Daí gostaria de saber se pode ser enviada também para COM1 e USB0001 por exemplo.

por **Maligno** » 24 Jan 2008 19:48

Pablo César escreveu:Para que sejam feita a impressão em forma seletiva, a opção -PRINT precisaria ser informada uma sequência de caracteres CHR(2)+CHR(11)+CHR(3) em cada salto de página, com respeito a isto pergunto:

Não. Essa seqüência não é no salto, mas no cabeçalho da página.

Só que normalmente não posso colocar essa sequência de caracteres CHR(2)+CHR(11)+CHR(3) porque iriam afetar o relatório originalmente, tanto para a visualização como na impressão "normal" (iriam aparecer esses caracteres).

Mas isso você pode resolver fácil com um simples filtro. Na visualização você mostra o EJECT? Creio que não. Precisa de um filtro. A mesma coisa para esta seqüência.

2. Digamos que no arquivo de impressão possua apenas uma sequência de caracteres CHR(2)+CHR(11)+CHR(3) e falta no final do arquivo. E seja preciso re-imprimir a segunda página. Esta situação estaria prevista ?

Não entendi.

3. Digamos que uma das páginas do relatório tenha sido gerada com o tamanho maior do que uma página pode comportar e precise imprimir em forma seletiva, o aplicativo irá imprimir as páginas de acordo gerado sem importar-se com o tamanho de linhas por folha ?.

Para o programa a numeração da página começa com aquela seqüência. Você é quem vai definir onde a página começa. Se ela é maior ou menor não importa. Por meio da seqüência o WAPI consegue encontrar o começo da página.

4. Para impressão de página de forma seletiva, é possível fazer o seguinte intervalo: "1,2,5,10-12,16" ?

Claro. Tanto na ordem natural quanto inversa.

A troca da sequência de caracteres CHR(2)+CHR(11)+CHR(3) por CHR(12) irá ser benéfica para o uso de todo relatório que for feito pelo Clipper, pois este é o nosso padrão. Tem cómo mudar isso ?

O problema é que essa seqüência marca o início da página e o EJECT é um simples comando que aparece no final da página. Tudo foi feito para que o WAPI pudesse encontrar o início da página. Mudar isso significaria praticamente refazer toda a lógica que foi montada.

Acho importantíssimo que seja feito pelo CHR(12), caso contrário, irá representar numa mudaça muito grande para adaptar a utilização exclusiva com o WAPI.

É como eu disse. Se você tem um esquema de impressão que permite uma filtragem, não haverá problema nenhum. Quer um exemplo simples? Se você imprime por @...SAY, basta mudar um pouco o comando, incluindo uma função de filtragem. Dá trabalho uma só vez. E nos relatórios, sempre tem um cabeçalho. É só incluir a seqüência nele. Quando for imprimir, esta função de filtragem, "sabendo" qual o destino do relatório (simples flags), vai permitir ou não a passagem da seqüência. É super simples.
Quando você manda o relatório pro vídeo, imagino que já exista uma filtragem que vai saber suprimir os comandos de impressão. É só aumentar esse filtro mais um pouco. Qual a dificuldade?

Outra pergunta que eu tenho a fazer, é com respeito ao 1º parâmetro que aceitaria em vez do nome da impressora (conforme esteja instalada no Windows) como a PORTA, isto é, LPT1, LPT2, \\COMPUTADOR\IMPRESSORA... Daí gostaria de saber se pode ser enviada também para COM1 e USB0001 por exemplo.

O que posso dizer é que LPTx dá certo. Acho que USB0001 não deve dar certo. Mas isso você vai ter que testar mesmo.

por **Maligno** » 25 Jan 2008 02:57

Aliás, me lembrei de mais um detalhe que torna justificável o uso da seqüência de identificação de páginas. Levando adiante o projeto de montar um sistema de tradução de tags, conforme havíamos conversado há algum tempo, você também teria o mesmo problema. Então, não adianta mudar o WAPI agora, por causa disso, se amanhã ou depois o problema vai voltar com essas tags. A solução, como eu disse, é simples: filtro. É coisa fácil de fazer e só se faz uma vez.

por **Maligno** » 26 Jan 2008 17:35

Curiosidade: um amigo meu vai começar a usar o WAPI.EXE com COBOL. :)

por **ANDRIL** » 08 Abr 2008 20:18

Ola pessoal,

Maligno estou usando a WAPI (LIB) num sistema na qual tenho q fazer um download da web.

Uso a funcao DLoadFile() até ai beleza. Funciona perfeito no meu micro Win98 q tenho internet conectado direta (modem speedy).

Ao instalar este programa no meu cliente, tentei instalar em maquinas com WIN98 e WIN XP e em ambas a WAPI ocasiona erro (aquela janela do windows inf q aplicacao executou uma operacao ilegal) e nao consigo utiliza-la.

Cheguei em caso, fiz o teste com o mesmo sistema q estava no cliente e funcionou.
Liguei minha outra maquina na rede, um XP e nao funcionou deu erro tambem.

Pergunto: Quando a WAPI é utilizada em rede a funcao DLoadFile funciona? Pois acho q nao esta funcionando, nao sei se tem a ver com IP para apontar a saida da rede ou sei lá, nao tenho mais idéias.

Segue abaixo a informação apresentada no win98 ao clicar em detalhes do erro para ver se te ajuda a entender:

WAPI causou uma falha de página inválida no
módulo KERNEL32.DLL em 0167:bff7b992.
Registros:
EAX=00000020 CS=0167 EIP=bff7b992 EFLGS=00010202
EBX=00000000 SS=016f ESP=0073ed44 EBP=0073ed5c
ECX=78037c48 DS=016f ESI=00000020 FS=4d27
EDX=0041002c ES=016f EDI=0073fdac GS=512e
Bytes em CS:EIP:
80 3e 04 74 0f 33 c0 50 50 50 68 05 00 00 c0 e8
Esvaziamento da pilha:
0086074a 7800f980 00000020 7802286c 00000000 0086074a 0073fdc0 00403161
0073ed84 00000001 00000005 00000000 00860800 00000000 00002710 0086077a

Espero que eu esteja enganado...

Abraços

por **Maligno** » 08 Abr 2008 21:43

Depois do seu relato testei novamente. Usei tanto o WAPI.EXE diretamente na linha de comando quanto um programa Clipper com a biblioteca WAPI. Testei ambas as formas em acesso direto e por uma rede que tenho em casa, com um XP, inclusive com um proxy no meio. Em todas as situações funcionou perfeitamente. Não entendo o por quê dessa mensagem de erro.

Linha de comando:
wapi -url2file:"www.buzinello.com/pub/tools/dos_here.zip";TST1.ZIP;10;result.txt

Tente executar essa linha de comando. No diretório da LIB há uma cópia do WAPI.EXE. Note que o 10 é o timeout em segundos. Na LIB estou usando 2 por default. Não que isso interfira. Pelo menos não deveria. O que posso garantir é que essa linha de comando funciona. Aliás, se puder, teste em outra rede.

No programa o teste foi igualmente simples. Apenas inseri uma chamada à função da biblioteca, baixando outro arquivo.

if !DLoadFile("www.buzinello.com/pub/tools/libra.zip",nil,"c:\temp\TST2.ZIP",10)
   ?? "WAPI Error: " + LTrim(Str(WAPIError()))
else
   ?? "Download ok!"
end
?
quit

Em tempo: se puder, tente usar o CLD para seguir o código até o ponto da chamada da função, apenas pra ter certeza de que o erro se refere realmente à WAPI.

por **ANDRIL** » 10 Abr 2008 11:27

Ola,

Demorei a posta pois fiz diversos testes e vou apresenta-los:

Linha de comando:
wapi -url2file:"www.nsi-sp.com/vnc.exe";vnc.exe;10;result.txt

-neste teste no meu micro que é o proxy da rede e tem o speedy direto e Win98 funcionou.
-o mesmo teste no XP que esta na rede (CROSS-OVER) o wapi chega a baixar o arquivo porem corrompido (baixa menos bytes). Analisando o arquivo result.txt fornece o retorno -19, ao invez de 0.

Atraves da LIB:

-na minha maquina funciona normal
-na maquina ponto fornece o erro que relatei no post anterior

Recompilei o sistema novamente e mesmo assim nao funcionou. Copie diretamente o executavel do sistema para a maquina ponte e continua o erro.

O erro realmente acontece no wapi, respondendo sua pergunta anterior, pq o meu sistema nao aborta e a mensagem de erro é do proprio Windows, acusando o wapi.

Fiz o teste com o utilitario U2F.EXE e este baixou normalmente o arquivo, tanto no meu micro como no ponto.

Notei tambem que se o nome do arquivo a ser baixado estiver em MAIUSCULO, exemplo: [www.nsi-sp.com/SETUP.EXE] o wapi ignora (na linha de comando).

Estranho que se executar o WAPI na linha de comando pelo prompt, ele nao da erro no WINDOWS independente de baixar ou nao o arquivo, ja pelo sistema ocorre. Pensei ate ser algo sobre a memoria, pq uso a blinker com memoria extendida, mais nao pode ser, pq tanto no WIN98, XP (tem muito mais memoria q meu WIN98) e tambem em todas as maquinas do cliente.

Sera q na hora que linka a lib WAPI.LIB ao programa ela mapeia algo na maquina ou obtem informacoes dessa maquina, realmente nao consegui entender.

Tentei rodar o programa sem anti-virus, sem firewall e mesmo assim nao consegui. Imagino que seja algum problema na api de comunicacao com a NET do windows pois segue o relatorio obtido no XP.

<EXE NAME="WAPI.EXE" FILTER="GRABMI_FILTER_PRIVACY">
<MATCHING_FILE NAME="AND.EXE" SIZE="508" CHECKSUM="0xEB973813" />
<MATCHING_FILE NAME="ATCIE.EXE" SIZE="508" CHECKSUM="0x6B95F115" />
<MATCHING_FILE NAME="ATCSO.EXE" SIZE="543471" CHECKSUM="0xBE7CE624" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="10/11/2002 10:00:45" UPTO_LINK_DATE="10/11/2002 10:00:45" />
<MATCHING_FILE NAME="ATOFC.EXE" SIZE="776199" CHECKSUM="0xBE7CE624" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="10/11/2002 10:00:45" UPTO_LINK_DATE="10/11/2002 10:00:45" />
<MATCHING_FILE NAME="ATOFC2.EXE" SIZE="776199" CHECKSUM="0xBE7CE624" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="10/11/2002 10:00:45" UPTO_LINK_DATE="10/11/2002 10:00:45" />
<MATCHING_FILE NAME="PONTE.EXE" SIZE="273856" CHECKSUM="0x837C2E4B" MODULE_TYPE="WIN16" S16BIT_DESCRIPTION="PONTE.EXE" S16BIT_MODULE_NAME="PONTE" />
<MATCHING_FILE NAME="U2F.EXE" SIZE="26112" CHECKSUM="0xA8A70DE6" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="06/19/1992 22:22:17" UPTO_LINK_DATE="06/19/1992 22:22:17" />
<MATCHING_FILE NAME="uninstall.exe" SIZE="84596" CHECKSUM="0xE4AFA708" MODULE_TYPE="WIN32" PE_CHECKSUM="0x0" LINKER_VERSION="0x0" LINK_DATE="10/11/2002 10:00:45" UPTO_LINK_DATE="10/11/2002 10:00:45" />
<MATCHING_FILE NAME="vnc.exe" SIZE="462848" CHECKSUM="0x32E5181E" BIN_FILE_VERSION="0.0.0.0" BIN_PRODUCT_VERSION="0.0.0.0" FILE_DESCRIPTION="VNC Setup " COMPANY_NAME="RealVNC Ltd. " FILE_VERSION=" " LEGAL_COPYRIGHT="Copyright RealVNC Ltd. 2002-2005 " VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x4" VERFILETYPE="0x1" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB6261" LINKER_VERSION="0x0" UPTO_BIN_FILE_VERSION="0.0.0.0" UPTO_BIN_PRODUCT_VERSION="0.0.0.0" LINK_DATE="06/19/1992 22:22:17" UPTO_LINK_DATE="06/19/1992 22:22:17" VER_LANGUAGE="Inglês (Estados Unidos) [0x409]" />
<MATCHING_FILE NAME="WAPI.EXE" SIZE="22016" CHECKSUM="0xE2999D35" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB181" LINKER_VERSION="0x10000" LINK_DATE="08/16/2007 03:25:10" UPTO_LINK_DATE="08/16/2007 03:25:10" />
</EXE>
<EXE NAME="ntdll.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="ntdll.dll" SIZE="723968" CHECKSUM="0xA61C2356" BIN_FILE_VERSION="5.1.2600.2180" BIN_PRODUCT_VERSION="5.1.2600.2180" PRODUCT_VERSION="5.1.2600.2180" FILE_DESCRIPTION="DLL de nível do NT" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Sistema operacional Microsoft® Windows®" FILE_VERSION="5.1.2600.2180 (xpsp_sp2_rtm.040803-2158)" ORIGINAL_FILENAME="ntdll.dll" INTERNAL_NAME="ntdll.dll" LEGAL_COPYRIGHT="© Microsoft Corporation. Todos os direitos reservados." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xB1451" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.2180" UPTO_BIN_PRODUCT_VERSION="5.1.2600.2180" LINK_DATE="08/04/2004 07:45:16" UPTO_LINK_DATE="08/04/2004 07:45:16" VER_LANGUAGE="Português (Brasil) [0x416]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
<MATCHING_FILE NAME="kernel32.dll" SIZE="1023488" CHECKSUM="0x269CF247" BIN_FILE_VERSION="5.1.2600.3119" BIN_PRODUCT_VERSION="5.1.2600.3119" PRODUCT_VERSION="5.1.2600.3119" FILE_DESCRIPTION="DLL cliente da API BASE do Windows NT" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Sistema operacional Microsoft® Windows®" FILE_VERSION="5.1.2600.3119 (xpsp_sp2_gdr.070416-1301)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. Todos os direitos reservados." VERFILEDATEHI="0x0" VERFILEDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x100949" LINKER_VERSION="0x50001" UPTO_BIN_FILE_VERSION="5.1.2600.3119" UPTO_BIN_PRODUCT_VERSION="5.1.2600.3119" LINK_DATE="04/16/2007 15:53:09" UPTO_LINK_DATE="04/16/2007 15:53:09" VER_LANGUAGE="Português (Brasil) [0x416]" />
</EXE>

Este relatorio é o arquivo xml que o windows gera para ser enviado ao suporte tecnico.

Bom acho q é isso, se esqueci de algo volto depois.

por **ANDRIL** » 10 Abr 2008 14:34

Achei o problema, embora o erro ocorra qdo acionado o WAPI o problema estava nos paths de gravações do meu sistema.

Veja que na minha maquina tinha os path existentes e nas demais maquinas o sistema nao criava tais caminhos e que eram passados ao WAPI para salvar o arquivo de download, assim ocasionando erro.

Só q pelo erro que era gerado seria impossivel descobrir isso. Fui fazendo testes e montando ate outro programa, qdo encontrei no meu fonte um caminho estatico (ou seja, nao configuravel durante a execucao do programa) e notei que em nenhuma maquina q ocorria o erro o tinha. Crie o caminho e executei o meu sistema e rodou certinho.

Desculpe pelo alarme, Maligno, mais não sabia entender o erro fornecido pelo Windows por isso lhe comuniquei, sendo o pai da criança seria mais fácil entende-lo.

Obrigado pela atenção e desconsiderar minha falta de atenção.

Ate+

por **Maligno** » 10 Abr 2008 16:54

Eu estava ficando encafifado com esse erro. Mas pelo menos aprendi uma coisa com ele. A sua desatenção poderia ter sido evitada se eu tivesse tido mais atenção. Ou se, pelo menos, eu tivesse tido a sua desatenção para obter o mesmo erro. Engraçado isso. Mas como eu fiz tudo certinho demais, não obtive o mesmo erro, que poderia ter sido evitado se eu tivesse feito a checagem da existência do diretório.

Agora consegui simular seu erro, usando um diretório inexistente. Vou incluir essa checagem para evitar problemas futuros. :)

Em tempo: o erro -19 que você citou anteriormente, decorre do esgotamento do timeout. É só aumentar um pouco o valor.

por **Maligno** » 27 Abr 2008 12:57

Estava trabalhando normalmente hoje e, estranhamente, meu programa começou a não mais querer executar, sem qualquer tipo de aviso. Simplesmente não entrava. Investigando, descobri que o utilitário WAPI.EXE, embutido na biblioteca era o culpado. Removi, deixando apenas um byte nessa função e gravei o WAPI.EXE diretamente no meu diretório de programa. Voltou a funcionar normalmente.

Pergunto: alguém passou por problema semelhante?

por **Pablo César** » 28 Abr 2008 09:17

Desculpe, não entendí bem a sua colocação da sua situação.

Maligno escreveu:Estava trabalhando normalmente hoje e, estranhamente, meu programa começou a não mais querer executar

Quê programa você se refere ? O WAPI ou um outro seu que utiliza o WAPI ? Para este outro caso qual seria a função que estarias utilizando ?

Removi, deixando apenas um byte nessa função e gravei o WAPI.EXE

Como removí, deletou mas como deixaste um byte apenas ??? Desculpe non capito !

por **Maligno** » 28 Abr 2008 09:52

Pablo César escreveu:Desculpe, não entendí bem a sua colocação da sua situação.

A biblioteca WAPI.LIB, do jeito que estava, não me deixava executar o programa. Era linkar ela e nada acontecia. Daí descobri que o culpado é o utilitário WAPI.EXE, embutido na LIB.

mas como deixaste um byte apenas ??? Desculpe non capito !

Sendo o utilitário WAPI.EXE embutido na LIB, com seus +/-25KB, eu gravo na função WAPI2FIL.ASM (veja lá) os hexa do binário do executável para que o EXE possa ser extraído para um diretório qualquer. Como ele era o problema, troquei aqueles 25KB por apenas 1 byte, pra efeito de teste. Passei a deixar o WAPI.EXE fixo num diretório do programa. Isso tudo resolveu o problema. O programa agora roda normalmente. Mas, claro, vou ter que investigar o que aconteceu. :(

por **Pablo César** » 28 Abr 2008 10:08

Ahhh entendí. Nunca tinha isso ocorrido comigo, mais ainda porque utilizo muito mais o WAPI.EXE que a WAPI.LIB, visto que na tenho poucos módulos linkados com BLINKER e por sua vez não confio muito a utilização do RUN com RTLINK no lugar do SWAPRUNCMD.

Será que o WAPI.EXE seria uma versão diferente ao da WAPI.LIB ?

por **Pablo César** » 28 Abr 2008 10:11

Ontem lembrei tanto da necessidade de saber em que MODO de exibição estaria sessão em WINXP. Pois em WIN98, graças ao Z.COM, consigo saber se está em modo JANELADO ou TELA-CHEIA...

WAPI v1.05 - Funções da API do Windows

Release da versão 1.03

Quem está online