PC Toledo

Para carregar as impressoras com NET USE dentro do programa usei o RUN. Tive muitos problemas de memória devido a isto. Então criei um .BAT que carrega as impressoras antes de entrar no sistema. Mas agora, preciso colocar dentro do sistema. Li sobre o SwpRUNcmd() e disseram que é melhor.

Questão: Uso o BLINKER 7 e Clipper 52e. Não tenho muita experiencia com o BLINKER. O SwpRUNcmd() deve ser utilizado no protegido. Qual a diferença no BLINKER entre o modo protegido e o modo real ? Agradeço desde já a juda.

Uso a instrução: BLINKER EXECUTABLE EXTEND. Isto basta ?

Ola Eliane,

Eu estou usando dentro do sistema e não tenho tido problemas e me parece mais adequado porque é uma funçao do proprio sistema.

Quanto ao BLINKER EXECUTABE EXTEND eu tambem ainda não entendi o que é melhor, pelo que li, se deixar dessa forma ele reserva automaticamente 512kb.

Agora estou tendo uma problema semelhante ao que voce teve " .EXE continuar carregado" q voce relatou no forum e resolveu com a funçao FREETSLICE !
Sera q poderia me enviar esta funçao para mim qdo tiver um tempo, para meu email: cez_a@ubbi.com.br


Desde já agradeço.

Cezar escreveu:Agora estou tendo uma problema semelhante ao que voce teve " .EXE continuar carregado" q voce relatou no forum e resolveu com a funçao FREETSLICE !
Sera q poderia me enviar esta funçao para mim qdo tiver um tempo, para meu email: cez_a@ubbi.com.br

Você pode encontrar essa função na minha página. Está na tabela de cor salmão, sob o título "Liberação do tempo de CPU" , no endereço abaixo.

Mas é sempre bom lembrar que a função FreeTSlice() libera o tempo de CPU que seria utilizado pelo "garbage collector" do Clipper, que não funciona como deveria pelo modo tradicional: usar o tempo ocioso para desfragmentar a memória. Assim, você fica sem essa coleta de lixo. Você deve então, forçar seu programa a desfragmentar a memória, incluindo chamadas à função Memory(-1) antes de declarar matrizes e abrir bancos de dados (que internamente utilizam matrizes). Ou então depois de descartar esses dados, ao final da função ou no fechamento dos bandos. Aliás, uma curiosidade: não adianta procurar. O parâmetro -1 não é documentado na função Memory(). À primeira vista, é uma função informativa apenas. Mas,...

[]'s
Maligno
http://www.buzinello.com/prg

Eliane escreveu:Para carregar as impressoras com NET USE dentro do programa usei o RUN. Tive muitos problemas de memória devido a isto. Então criei um .BAT que carrega as impressoras antes de entrar no sistema. Mas agora, preciso colocar dentro do sistema. Li sobre o SwpRUNcmd() e disseram que é melhor.

Questão: Uso o BLINKER 7 e Clipper 52e. Não tenho muita experiencia com o BLINKER. O SwpRUNcmd() deve ser utilizado no protegido. Qual a diferença no BLINKER entre o modo protegido e o modo real? Agradeço desde já a juda.

Uso a instrução: BLINKER EXECUTABLE EXTEND. Isto basta ?

Uma correção: a função SwpRunCmd() não exige o uso do modo protegido. Funciona no modo real.

A diferença entre os modos real e protegido é simples: o modo real trata a memória de forma segmentada, em blocos de 64KB, limitando-se aos primeiros 640KB da máquina. É a forma mais antiga. Data da época em que o Bill Gates disse que "JAMAIS" alguém um dia precisaria de mais memória que isso. O modo protegido vê a memória num plano linear, sem a limitação de segmentos de quaisquer tamanhos. O programa usa a memória que você der a ele através da configuração da janela. Porém, existe um detalhe: muitos programas utilizam bibliotecas antigas que contém funções (sobretudo as que acessam a RAM de vídeo) que fazem endereçamento direto à outras regiões de memória. No modo protegido (como o nome diz) isso não é permitido. Para acessar uma região da memória que não lhe pertence, um programa deve alocar um seletor de memória através do sistema operacional. Por isso, alguns programadores sofrem um pouco quando adaptam seus programas a esse modo. É preciso trocar as LIBs de modo real para protegido. A CATools, por exemplo, tem duas versões, uma para cada modo.

Para montar seu programa no modo protegido você só precisa de dois comandos do BLinker:

BLINKER EXECUTABLE EXTEND
LIBRARY BLXCLP52

Esta LIB é necessária para o BLinker embutir no EXE o código necessário para o gerenciador de memória que, evidentemente, é diferente do que se usa no modo real. A LIB depende da versão do Clipper. Como você disse que usa a versão 5.2e, é essa mesmo que citei no exemplo.

[]'s
Maligno
http://www.buzinello.com/prg

Maligno escreveu:. Você deve então, forçar seu programa a desfragmentar a memória, incluindo chamadas à função Memory(-1) antes de declarar matrizes e abrir bancos de dados (que internamente utilizam matrizes). Ou então depois de descartar esses dados, ao final da função ou no fechamento dos bandos.

Mestre Maligno,

Gostaria de saber se é REALMENTE necessário utilizar esse comando (Memory(-1)) para ganho de performance no sistema ou é algo DISPENSÁVEL??? Ou, em que situação é muito necessário???


Janio

janio escreveu:Gostaria de saber se é REALMENTE necessário utilizar esse comando (Memory(-1)) para ganho de performance no sistema ou é algo DISPENSÁVEL??? Ou, em que situação é muito necessário???

Veja que Memory(-1) não serve para "ganhar", mas para "manter" a performance. Na grande maioria dos casos, você pode viver sem isso tranquilamente. Mas em sistemas que consomem muitos recursos, pode ocorrer um processo contínuo de fragmentação de memória, a ponto de forçar o gerenciador de memória a fazer swaps em disco. Quando o sistema recebe um pedido de RAM por parte de um programa, ele entende que essa memória deve ser contígua, isto é, não pode ser espalhada. Deve ser um bloco só. Se chegar no ponto de não mais existir memória contígua para atender uma requisição, o gerenciador de memória, através de um sistema especial de paginamento, elege algumas páginas mais antigas (ele sabe quais são) para serem transferidas para um arquivo em disco. Eventualmente as páginas que residem em disco poderão ser transferidas de volta para a RAM, enquanto que outras páginas da RAM tomam seu lugar no disco. Daí a lentidão.

Inclusive, esse problema de fragmentação é mais notado em programas que ainda utilizam o modo real, já que a memória, nesses casos, é mais limitada. Mas o problema também pode aparecer em programas que rodem no modo protegido, mesmo com muita RAM. Tudo dependo da quantidade de recursos alocados (do tamanho) pelo programa.

Cito um caso acontecido comigo: um programa de controle de produção industrial (BLinker no modo protegido) estava consumindo recursos demais, depois que implementei um sistema de pedidos que me obrigava a criar listas com mais de 150 campos GET. Existem nesse programa algumas outras funções que também consomem muitos recursos. Mas no caso dessa função, a carga da lista GET já era problemática, devido ao tamanho (a função _GET() era a vilã - já citei isso noutra thread do fórum). Mas o problema maior era o entra-e-sai da lista. Um grande bloco de memória era alocado para manter as matrizes de trabalho. O usuário saía, utilizava outro recurso qualquer que aproveitava a memória que antes era utilizada pela função de inclusão de pedidos. Voltava para essa lista de pedidos, que fazia uma nova alocação de memória. Como já não havia memória RAM contígua para abrigar os recursos do GET, o gerenciador de memória mandava pro HD algumas páginas antigas de memória para conseguir um bloco contíguo que satisfizesse as necessidades da lista. Então o usuário saia de novo pra executar outra tarefa e o processo de repetia. Nisso a fragmentação aumentava e os swaps em disco ficavam cada vez mais freqüentes. Tudo ficava muito lento, até que culminava no aborto do programa. Inserir chamadas a Memory(-1) em pontos estratégicos fez o problema sumir como que num passe de mágica. Não precisei fazer mais nada. Depois disse, nunca mais tive qualquer problema com memória.

Mas é como eu disse: você até pode passar o resto da vida sem ter esse tipo de problema. Vai depender do tipo de projeto que você desenvolver.

[]'s
Maligno
http://www.buzinello.com/prg

Porém, existe um detalhe: muitos programas utilizam bibliotecas antigas que contém funções (sobretudo as que acessam a RAM de vídeo) que fazem endereçamento direto à outras regiões de memória.

Porventura isso seria um motivo pelo qual só estou conseguindo rodar imagens BMP com 16 cores?

Garanto que isso não tem qualquer relação com seu problema.

Assino em baixo as colocações do Maligno a respeito do Memory(-1)
Implementei a função no meu sistema que roda em modo grafico, que antes tinha problemas com os savescreen e restscreen de telas. Fiz um teste bobo salvando e restaurando telas sem a função: o sistema sai do ar sem aviso nenhum
com a função o problema acabou.

Maligno!

Eu deveria colocar Memory(-1) sempre que for incluir um registro, ou seja, quando estou numa rotina de inclusão de registros o sistema volta ao início, ai incluo novamente outro, outro e outros..., isso consome também a memória, Já que uso muito savescre().

Bom, eu coloco o memory() no início do arquivo .prg, depois do read, onde posso colocá-lo para um melhor aproveitamento da função?

Memory(-1), com esse argumento negativo, serve para invocar o garbage collector e assim, desfragmentar a memória ocupada pelo programa. Essa função deve ser executada antes da alocação ou depois do descarte de blocos de memória de certo tamanho. Ou seja, variáveis strings grandes e matrizes, principalmente. Eu costumo usar imediatamente antes de sair de funções que manipularam grandes matrizes. Isso resolveu os problemas que tive no passado. Hoje em dia não tenho mais qualquer problema. Só não use demais, senão você acabará gerando um overhead no programa, que acabará ficando lento, já que a desfragmentação de memória envolve o uso de um algoritmo que não é lá muito econômico em termos de consumo de CPU.

Como faço para chamar um segundo programa (rotina) dentro do programa atual sem que essa rotina tire a atenção do programa principal, ou seja, rode em segundo plano sem abrir tela alguma, nem atrapalhando a execução do primeiro.
É pelo comando RUN que consigo fazer isso? E se houver erro, na execução da rotina, como irá se comportar, vai parar o programa principal? Vai chamar a tela e exibir o número do erro, etc...? Tenho que finalizar essa execução da rotina referente ao comando RUN dentro do programa principal ou ela será executada e facha automaticamente?
Quem poder me ajudar, obrigado!

Como faço para executar o Word a partir de uma aplicação em Clipper 5.3b que é executada em tela inteira ?

Ao sair do Word, como fazer com que a aplicação em Clipper não retorne minimizada ?

Já testei com o comando RUN executando a aplicação Clipper de forma janelada e funciona.

Veja só, certa vez tive problemas parecidos com o uso do Blat, usando modo gráfico.
A solução foi a seguinte:

1º salvar a tela // Save scren....
2º limpar a tela // sem limpar não dava certo ! // Cls
3º alternar para modo texto; // gmode(3)
4º executar o comando externo; // run ou swpruncmd()
depois,
alternar para modo gráfico; gmode(18)
restaurar a tela // rest scre...

Também tem outra solução que é tira e queda no WINXP, embora para o WIN98 também exista outra solução combinada que funciona também. A solução que me refiro é o uso da função WINDOW2TOP da WAPI do Maligno junto com Z.COM (para verificar se a janela em WIN98 está em modo janelado).

Se tiverem interesse sobre esta indicação, dê uma olhada em: https://pctoledo.org/forum/viewto ... 6178#36178