ProcessMessages

[Itamar M. Lins Jr.]

Ola!
ProcessMes... tem até no Delphi.
Alias acredito não está relacionada com retro-compatibilidade com o clipper, é um recurso para ambiente multusuário.
Qualquer loop em qualuer linguagem travará o processador se não houver algo para devolver o processo ao "Kernel".
Até o linux tinha um furo, na época fazimos em "Bash" um programinha que mostrava como "pindurar" o sistema, matar a CPU, ficava lento pacas.


Saudações,
Itamar M. Lins Jr.

[Maligno]

Eu não entendi se você entendeu errado ou o que. Posso ter deixado meio confuso.

Então, pra deixar mais claro... Minha desconfiança quanto à retrocompatibilidade é aquilo que diz respeito às funções de manipulação do "idle cycle". Não me refiro ao ProcessMessage, que é um recurso utilizado em várias ferramentas e tem sua importância, como você frisou muito bem.

[mhackervix]

Não é bem isso. Mas quase. ProcessMessages (ou seja lá o nome que for) tem for função "desafogar" a fila de mensagens

Maligno,

O que eu estava tentando exemplificar era uma forma de aplicação real da função.
Quanto a utilização de funções tipo MilliSec() para dar retorno ao SO, a maioria das liguagens a possuem em virtude do não funcionamento perfeito de maquinas virtuais intrincicas a sistemas preemptivos ( lebrando que uma grande propaganda no lançamento do windows 95 era o SO Preemptivo X o SO Cooperativo do Win 3.1x), restando ao programador, ajudar o sistema quando na execução de loops "grandes".

Espero que possa ter ajudado.

PS: estou prescisando de ajuda no tópico DbApp() (presciso da sintax deste comando do xHabour)

att.

[Stanis Luksys]

Enfim,

Mas qualquer programa Windows não-GUI pode rodar em uma janela DOS (console) também

Mas no caso eu quis dizr que o xHarbour roda DE FATO em DOS, em 16 bits, por isso a existência de tal função não é apenas "por compatibilidade", mas sim direcionado aos usuários de tal plataforma. Duvido muito que existe algum.

Quanto as funções, acho que ficou claro a diferença entre elas, e "equivocado" ou não, mantenho minha resposta inicial lá pro alxsts, na qual digo que em modo console puro (ex: DOS, XTERM, NTVDM) você não precisará de uma função que realize o trabalho da processmessages, uma vez que o ambiente é monotarefa ou emulado para ser.

No caso emulado como NTVDM, o próprio SO gerencia isso sem essa ajudinha da função, até mesmo impondo limites de memória e processamento (teoricamente, porque no XP subia a 99). No caso dos 16 bits monotarefas não há nem necessidade, uma vez que se imagina que cada programa seja um único processo a ser executado de casa vez. E seu programa estando dentro uma VM, ele jamais teria como dizer ao SO fora da VM pra fazer a 'fila andar'.

Resumidamente, no caso do Windows XP talvez falte uma ProcessMessage no programa NTVDM, porque colocar isso no programa que está sendo emulado, faria ele disparar isso contra a VM e não surtiria nenhum efeito para o WIndows. Neste caso sim poderia se usar a MilliSec, o que desafogaria a VM e consequentemente o SO todo.

Abraços

[Maligno]

Quanto a utilização de funções tipo MilliSec() para dar retorno ao SO, a maioria das liguagens a possuem em virtude do não funcionamento perfeito de maquinas virtuais intrincicas a sistemas preemptivos

Eu já fiz coisas bem pesadas em C++ e nunca precisei usar essa função. Nunca li nada a respeito do que você acaba de dizer. A não ser em Clipper.
A única coisa necessária é uma eventual chamada à ProcessMessages(). Conforme eu disse antes, em razão da falta de oportunidade de executar as mensagens de processos do Windows. A fila enche e o sistema "trava". É preciso desafogar a fila. Se usar Millisec() (ou qualquer outra do tipo - tenho isso em C/C++), não adianta nada. A coisa fica do mesmo jeito; travado. Só mesmo com ProcessMessages().

[Maligno]

Mas no caso eu quis dizr que o xHarbour roda DE FATO em DOS, em 16 bits

Mas você não consegue gerar um programa 16 bits usando um compilador de 32 bits (BCC32). Existe algum compilador que gere programas 16 bits para o [x]Harbour? Aqui peço desculpas. Não conheço muito de [x]Harbour. Se existir, aí sim, o que você diz faz sentido. O que tínhamos em Clipper, tem-se também em [x]Harbour em 16 bits. Em 32bits, e aí entra a retrocompatibilidade, o programa seria o mesmo. Mas Millisec() teria que ter uma dupla função. Em 16 bits seria como era no Clipper. Em 32 bits teria de realizar o mesmo trabalho de ProcessMessages().

[Stanis Luksys]

Olá Maligno,

Nesta página tem uma lista com os compiladores mais indicados para cada SO, muito embora seja possível utilizar outros que não estão na lista.

http://www.harbour-project.org/faq/harbour22.html#22

Abraços.

[Maligno]

Taí uma coisa que não sabia. Pode-se usar o BCC 3.1 pra gerar um programa 16 bits. Se bem que nos dias de hoje,... Ninguém (em sã consciência) vai querer um dinossauro desses.

[Stanis Luksys]

Pois é!

É o tipo de compatibilidade que não tem o menor nexo em ser mantida, pois veja, para que rodar um programa Harbour sobre DOS em 16 bits, se você tem o Clipper que lhe oferece uma infinidade de bibliotecas para realizar tal serviço com muito mais opções?

E é como eu disse agora há pouco, ainda tem gente neste mundo, por motivos diversos, optando por usar um SO que seja apenas modo texto, mas o DOS é a última opção a ser recomendada, e com certeza um sistema não Microsoft seria o utilizado.

Abraços.

[Maligno]

Mesmo não fazendo sentido, se o custo de manutenção da compatibilidade for zero, ou seja, se não atrapalhar em nada nos programas novos, não há porque se preocupar. Agora, se isso custar algo (código extra, limitações), não vale a pena. Melhor deixar o 16 bits no limbo. Ou criar um fork só pra isso. Mas aí o custo aumenta.

[Stanis Luksys]

Opa,

Eu penso assim, é importante pela questão da portabiliade, você faz seu programinha bem cru e fala, "ele pode rodar em qualquer SO". De fato, pode.

No entanto é sensível a diferença de quantiade bibliotecas para cada SO, e claro que nem haveroia de ser diferente, uma vez que um deles é realmente dominante. Seguindo esta lógica, se você quiser seu programa muito portável, terá de abrir mão de todos os recursos modernos que estas libs provêm.

Ou seja, para ter seu programa compatível com o DOS e Windows, ele terá de se limitar aos recursos do DOS. Sendo assim prefiro usar o Cliiper que fazia milagre no velho DOS.

UMa alternativa seria o uso de diretivas de compilação para adicionar e remover recursos extras a cada plataforma. Ah... Nem me passa pela cabeça manter compatibiliade com o DOS, pois embora eu leia aqui no Forum Às vezes "Tenho Cliente que ainda roda DOS", eu mesmo não conheço uma alma viva que use DOS. Quem nunca usou então, jamais aceitará usar.

[mhackervix]

Taí uma coisa que não sabia. Pode-se usar o BCC 3.1 pra gerar um programa 16 bits. Se bem que nos dias de hoje,... Ninguém (em sã consciência) vai querer um dinossauro desses.

embora eu leia aqui no Forum Às vezes "Tenho Cliente que ainda roda DOS", eu mesmo não conheço uma alma viva que use DOS. Quem nunca usou então, jamais aceitará usar.

Sobre o Uso do DOS como sistema, ainda existem empresa (geralmente grandes) que ainda o utilizam por confiança no conjunto da aplicação (Aplicativo/SO). O DOS ainda é muito utilizado em aplicações embarcadas como naqueles verificadores de preço que existem em Supermercado (o Segundo modelo mais vendido aqui no Brasil utiliza DOS como parte do seu FIrmWare). Porem em aplicações cotidianas vemos uma migração grande para sistemas com interface GUI (principalmente aqui no Brasil e nos paises do 3º Mundo e emergentes), embora vi muitos sistemas "vivos" (em desenvolvimento) rodando em DOS na Africa e Principalmente na Europa e Oeste Asiatico, o que não demostra nenhuma tendencia e sim uma migração um pouco mais lenta.

Nunca li nada a respeito do que você acaba de dizer.

Um bom livro é "Arquitetura de Computadores" do Andrew Tanenbaum. Li quando fiz Graduação no final da decada de '80 e inicio da de '90, mas acredito que exista edições mais novas. Embora o conteudo teorico pouco evoluiu (os produtos comerciais decolaram) de lá para cá. É um livro de fácio leitura e muito boa coesão teórica.

Eu já fiz coisas bem pesadas em C++ e nunca precisei usar essa função.

Depende muito do que se esta fazendo e qual o resultado esperado. Analisei recentemente um programa em Delphi que ao executar as operações de TEF-Discado (cartão de Crédito) cosumia muito a CPU em um loop que aguardava um arquivo de retorno, uma solução muito simples foi colocar dentro do Loop uma instrução equivalente a MilliSec() e a aplicação passou a se comportar "menos pesada".

Para terminar, gostaria de agradecer aos colegas, pois um topico bastante simples, gerou uma discução com boa tematica.

Obrigado a Todos.

att.