PC Toledo

Olá,

Ja está disponivel para download compilado com xHarbour. Não utilizei UPX nem nada deste tipo para não interferir no teste.

www.luksyssoft.com.br/teste.zip

Seria portanto importante que alguém pudesse compilar com o Clipper utilizando as funções que foram indicadas ao colega, vendo o efeito real que estas causariam neste teste.

Obs: Retirarei o qrquivo do servidor segunda feira pela manhã.

OK.

Realizei os testes com um milhão de regitros, com sete campos e indexando por tres campos, e realmente devo admitir que não ficou na casa dos 3 ou 4% conforme eu havia dito, chegando a atingir picos de até 93%, mantendo uma média de 37 a 50.

O que ficou muito evidanciado neste teste foi o tempo, o qual fiz questão de registrar. Aqui, testei num P4, e a rotina executada em xHarbour levou 18 segundos, já em clipper consideraveis 101 segundos (1 minuto e 41 segundos). Diferença total de 83 segundos, ou 560%, como preferir.

Bom, aí a coisa muda de figura. Apesar do seu programa dar uma boa ajuda ao algoritmo de ordenação, criando um DBF com registros já ordenados, num P4 considero normal que seja essa a média de consumo de CPU, com esses picos esporádicos. Numa experiência real, as taxas devem subir um pouco, pois os dados seriam reais. Em máquinas menores o consumo também deve subir, claro, o que é normal, pois o P4 é um processador com arquitetura bem otimizada.
E com relação ao Clipper, é também natural a diferença de performance. O acesso a disco pelo Windows é muito melhor do que pelo DOS, evidentemente. Some-se a isso o fato do XHarbour estar muito a frente do Clipper.

Obrigado pela sua presteza em responder a minha requisição.

Os 3% ao qual me referi, realmente não consegui alcançar, portanto posso aqui afirmar que errei quanto a este numero.

Nunca fiz esse teste. Mas afirmei que esse percentual era inviável apenas pela lógica. Algoritmo de ordenação não é uma peça de código banal. E esse código precisa ser processado. Assim, o processador, por mais otimizado que seja, não conseguiria manter 3% numa tarefa dessas.

Caso você se sinta a vontade pode também dizer aqui que neste simples caso foi muito relevante o uso do xHarbour, como ferramenta de migração para 32 bits, pois talvez seja importante a comunidade ouvir de uma pessoa experiente e com grandes conhecimentos técnicos como você algo neste sentido.

O XHarbour, como eu já disse antes, tem sua relevância no mundo da linguagem XBase, não só como uma simples ferramenta de migração de todo o software legado do Clipper, mas também por oferecer ao programador Clipper uma excelente oportunidade de entrar no mundo de 32 bits do Windows, podendo acessar todos os recursos a mais que este SO oferece. Assim como também abre uma porta para outros sistemas, como o Linux. O seu teste já demonstra, mesmo que de forma simples, que a vantagem, em relação a performance, é absolutamente real.
Mas é sempre importante conseguir perceber as reais limitações de cada produto. Assim como qualquer ferramenta de trabalho, o XHarbour nunca foi e nunca será perfeito. Mas mesmo com muitas deficiências, não é possível negar sua importância.
Entretanto, também é importante que o programador usuário de XHarbour saiba realmente como explorar todo seu potencial, senão ele nunca deixará de ser um simples "Clipper 32 bits". Certamente ele é muito mais do que isso.

Depois de vivenciarmos muitas experiências com programação, ao longo de muitos anos de trabalho, criamos certas expectativas com relação a ferramentas de trabalho. O XHarbour, para mim, não consegue corresponder a essas expectativas, por vários motivos. Sejam eles: deficiências como produto, incompletude, linguagem, etc. Assim, resolvi migrar para uma outra ferramenta. Não fosse isso, certamente o XHarbour seria uma boa escolha, como acredito que ele seja uma boa escolha para quem deseja manter não só o seu conjunto de software legado, mas também a afinidade que já possui com a linguagem XBase.

Aquelas threads, acerca de comparações entre o XHarbour e outros produtos, eram mais acirradas do que deveriam apenas pelo fato de que alguns teimam em colocá-lo em um pedestal que ferramenta nenhuma merece, dando a ele o mérito que ele não tem, usando para isso informações falsas e/ou propositadamente deturpadas. Cada ferramenta tem sua importância, tem seu lugar. E cada usuário deve saber identificar aquela que mais lhe convém. Opiniões são apenas opiniões (desde que justas e imparciais). Mas as decisões são de foro íntimo. E para decidir corretamente, é preciso ter informações verdadeiras.

Às vezes o melhor amigo não é aquele que lhe beija, mas aquele que lhe dá um tapa.

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

Legal,

A lição que a gente tira disso é que um programa vale mais que mil palavras... hehe.

Não adianta ficarmos aqui discutindo isso, ou que tal pesquisa de tal empresa aponta aquilo. Queremos mesmo é ver a prática.

A principio, dou minha participação no tópico por encerrada, e acredito que tenha sido até certo ponto esclarecedor para todos nós.

Quanto a questão inicial do amigo, é obvio que não seria nenhum pouco coerente eu chegar e dizer "use xharbour!", inclusive lendo mais pra cima poderá notar que não foi o que eu fiz.


Obrigado pela atenção.

Stanis,

ótimo exemplos, mas, ambos tem rezão, você e o Maligno e nao há discordias. Repare.


Todo o Windows 95/ME/98 foram consebidos em uma mesma plataforma e ambos compativeis com codigo de 16 e 32bits, sistema que nasceram debaixo da arquitetura NT são 32bits, NT/2K/XP, logo estes ultimos, codigo 32bits so mesmo emulado.

Porque os programas de DOS ficam mais lentos no XP?

R - Porque se o codigo de 16 bits é emulado, é necessário que, a instrução seja lida, entendida e reescrita (emulação) em um codigo de 32bits, correto!!!! Então o codigo de 16 bits tem um caminho mais longo para ser executados neste windows, e também tem a vantagem de medir o consumo de CPU com mais precisão do que os Windows mais antigos media, assim, quanto mais codigo, mais processamento, entao o codigo 16bits tem a obrigação de ser mais lento quando comparado com o mesmo codigo em Windows mais antigos, isso nao tem como negar, com maquinas identicas o programa de DOS fica muito mais lento quando é executado no Windows XP. Não ecxiste nem impressão de ficar melhor ou mais rapido no XP, existe ilusão, pois o processamento do console do Windows XP como todas as APIs da GDI são visualmente mais suaves, por isso programas em xHarbour modo console são ultra velozes quando comparados com os mesmos rodando em Windows 98.

Quanto ao consumo elevado de CPU ele acontece com qualquer linguagem, basta fazer um WHILE em delphi, vb, c, clipper, xharbour ou qualquer linguagem e consumo de CPU vai pro topo, todos os manuseadores de tasks inclusives os do linux tem que ir executando parte do codigo de cada processo, quando parte deste processo chega em um WHILE ou algo parecido a tendencia é que pelo consumo alto de CPU o proprio programa que administra estes TASK demore a responder, você pode notar como o Windows em diversos momentos demora para redesenhar a tela ou algo assim.

Quando usamos a FREETSLICE ela dá um time na CPU o que folga e libera o emulador do DOS um pouco e o TASKMANAGER aproveita para administrar outros processos. só isto, mesmo assim quando o sistema em Clipper segue o processamento normal o consumo de CPU vai cotinuar alto da mesma forma. No xHarbour todos os pontos de paradas já foram aliviados (READ, PROMPT, INKEY, ETC) e por nao ser emulado o codigo tende a ser mais veloz, mesmo assim, se pegarmos a rotina do stanys, é possível fazer com que ela rode no xHarbour sempre com consumo de CPU de 0.03% (Coiso que com o Clipper nao é possivel fazer, as rotinas que tornam isto possivel deixam tudo muito lento, falo de algo que nao testei profundamente), ou seja quase zero, isto tem que ser adotado para um bom uso do emulador de terminal tanto do Windows quanto do Linux, vc tem que saber tambem distribuir o poder de processamento do seu sistema, assim eu sempre faço em Delphi (PROCESSMESSAGES) que tem rotinas para isto, em xHarbour, o PRWIN mesmo, não dá picos de uso de CPU ou nenhum programa que eu tenha migrado, pois sempre há uma rotina que alivia qualquer processamento.

Qual a consequencia?
R - O processo irá rodar um pouco mais lento, porém num ambiente onde a execução do sistema está centralizada, isto traz vantagens pois a CPU nao esquenta tanto e vc pode com um modesto micro P4 2.8 e 1 de ram segura mais de 100 terminais rodando o seu sistema sempre na mesma velocidade. Sem ter picos em um processo que pode fazer com que o restante rode mais lentamente.

Tudo que se executa tem que consumir CPU, mas se souber executar bem para nao ter picos, vc terá rotinas que nao serão tão velozes mas nao prejudicarão outros processos.

Isso é só para implementar a visão dos amigos.

Caros Amigos,

Tenho um sistema usado em diversas empresas com micros com WinXP. Inicialmente houve lentidão, mas com a utilização do Timeslic() este problema foi totalmente resolvido.

Ocorre que ultimamente tenho ouvido reclamações de algumas empresas que o sistema voltou a ficar lento após a migração para WinXP. E mesmo os micros com Win98 que executam em rede também ficam lentos (mesmo que o servidor não esteja usando o programa !)
Fazendo umas perguntas reparei que a lentidão ocorria um tempo depois na migração para o WinXP, e não na mesma hora. E em todos os casos era o WinXP Professional.

Por isto fico imaginando se não há alguma atualização feita (pelo Windows Update) que esteja deixando o acesso aos arquivos mais lento pelo ms-dos.

Será que mais alguem tem reparado nesses sintomas ? Ainda preciso estudar melhor este problema, provavelmente checando o log de atualizações feitas no windows destes micros.


Um abraço,
Flavio.

Flavio,

Venho acompanhando todas as atualizações do WIN-XP e até hj nunca vi fala nd que atrapalhase os arquivos pelo MS-DOS, porem jah passei por alguns casos desse tipo, na maioria das vesses era virus na maquina dos clientes, jah tive caso tb..de o cliente esta com um sistema meu aberto, mais AUTOCAD,PHOTOSHOP e etc... aberto e reclama que o sistema tava lento, outro caso é o aumento consideravel de registros em determinados DBF...dependendo da quantidade de registros e um sistema mal elaborado..isso com o tempo pode se tornar uma dor de cabeça...entaum resumindo na minha opnião o RUINDOWS ainda não leva a culpa..de uma analisada em algum de seus clientes que mais reclama...e veja se tem algum ANTI-VIRUS instalado...se a quantidade de registros nos DBF estaum muito grande tipo(100 mil registos), ou ainda se vc esta usando um RDD bom e rapido e seguro para os seus sistemas.

Abraços

flavioacm escreveu:Tenho um sistema usado em diversas empresas com micros com WinXP. Inicialmente houve lentidão, mas com a utilização do Timeslic() este problema foi totalmente resolvido.

Como eu comentei antes, não há motivo para os programas DOS ficarem mais lentos no XP, seja que versão for.

Ocorre que ultimamente tenho ouvido reclamações de algumas empresas que o sistema voltou a ficar lento após a migração para WinXP. E mesmo os micros com Win98 que executam em rede também ficam lentos (mesmo que o servidor não esteja usando o programa !)
Fazendo umas perguntas reparei que a lentidão ocorria um tempo depois na migração para o WinXP, e não na mesma hora. E em todos os casos era o WinXP Professional.

Estou passando por algo semelhante num cliente, que me reclamou que meu programa ficou lento de uma hora pra outra.
Tudo funcionava perfeitamente, sem qualquer problema de lentidão. De fato, a lentidão existe, mas só no que diz respeito a manipulação de arquivos. Talvez o problema que você tem seja semelhante ao meu. Veja: o Clipper trabalha com tabelas de acesso local. Os dados são manipulados localmente. Se você fizer uma indexação todo o arquivo trafegará pela rede, até sua máquina. Isso é fato. Assim, o grande gargalo do Clipper é esse. No meu caso, já tenho suspeito: a rede do cliente. Rede não é minha área. Nem gosto de tratar disso, mas vou investigar pra tentar encontrar uma luz. O sujeito da rede já foi acionado. Mas uma coisa é fato: se o programa funcionava, dentro do que se poderia esperar como sendo normal, e mudou de uma hora pra outra sem que você não fizesse nenhuma alteração de grande monta, o erro não está do seu lado. Ou é hardware (cabos, switches, etc) ou é software (SO ou rede). No meu caso é líquido e certo: alguém meteu o dedo onde não deveria.

Por isto fico imaginando se não há alguma atualização feita (pelo Windows Update) que esteja deixando o acesso aos arquivos mais lento pelo ms-dos.

Não duvido, mas não acredito muito nesta hipótese. Ainda prefiro (no meu caso) a hipótese de erro na rede.

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

Wagner,

Discordo de quase tudo o que você escreveu. Infelizmente não dá pra ser resumido. Mas não vou quotar nada, pra economizar um pouco de espaço.

Por partes:

1) A emulação que você diz que é feita nos programas DOS rodando em kernel NT não tem nada a ver com "ler, entender e reescrever" as instruções de 16 bits. Você cismou que os programas DOS, rodando no XP, têm de ser muito mais lentos e agora cavou uma justificativa completamente fora da realidade.
Mas isso é fácil de contra-argumentar: todos os processadores X86 compatíveis tem o compromisso da retro-compatibilidade. Ou seja: todos as antigas instruções do 8088, por exemplo, são perfeitamente executáveis num Pentium 4 de última geração. Seria suicídio da indústria se não fosse assim. Portanto, e sendo assim, fica uma questão bem interessante: porque TRADUZIR instruções de 16 para 32 bits se todas as instruções 16 bits são perfeitamente executáveis nos processadores mais novos? Pode responder?
Nem precisa acreditar no que digo: vá direto à fonte. Procure o "Intel Literature Center" e baixe os manuais dos processadores que quiser e analise o conjunto de instruções e confirme que tanto em nível de registradores quanto de instruções, a compatibilidade é total. Portanto, essa necessidade de tradução é uma fantasia.
Outra fonte: pegue no Emule ou nos sites de engenharia reversa (hackers) os fontes do Windows NT, que vazaram na Net. São mais de 600MB. Zipado uns 200MB. Você não encontrará lá nenhum "TRADUTOR" de instruções de 16 para 32 bits.
Outra fonte: visite o MSDN ou o MS-TechNet e pesquise por VDM (Virtual DOS Machine) e entenda como funciona o processo de execução de um programa DOS num kernel NT.
Outro contra-argumento: se houvesse de fato emulação em nível de instruções, eu não poderia, por exemplo, bootar um P4 com um disquete do MS-DOS 5 e rodar minhas aplicações DOS. É um teste fácil, que qualquer um poderá fazer. Se a emulação, nesse nível, precisasse ser feita, um boot com MS-DOS seria impossível.
Veja bem: a emulação existe de fato, mas em nível de traps de hardware e gerenciamento de acesso à memória segmentada, já que em kernel NT a memória é de acesso linear. As interrupções existem da mesma forma que antes. Mas os serviços, anteriormente executados no núcleo do DOS ou na camada mais externa, passaram a ser executadas pela VDM por meio de simples "system calls". O mesmo ocorre com as interrupções de BIOS. Aliás, acho que emulação é até um termo pouco apropriado pra definir o que é feito. Isso causa confusão. Você próprio se confundiu e acabou "criando" uma dedução errada. Trata-se apenas de um recurso do NT que permite executar um programa MS-DOS. Só isso. E exatamente por isso, não há motivo algum para um programa DOS ter uma performance inferior.
OBS: é válido lembrar que um programa DOS rodando em modo janela terá uma ligeira (muitas vezes nem perceptível) queda de performance devido ao overhead criado pelo ambiente gráfico. Mas no modo tela cheia isso não ocorre, pois o vídeo é comutado para texto puro.

2) Não é ilusão minha quando digo que meus programas DOS, rodando em XP, são tão rápidos quanto nas versões não-NT do Windows. Isso é fato mais que comprovado. Acredite ou não, nunca vi um programa meu rodar mais lento num XP. No mínimo com a mesma velocidade.

3) O TASKMANAGER, como você diz, não "administra processos" da forma genérica como você acredita. O escalonamento de tarefas (esse é o termo correto) é feito pelo núcleo do sistema, rodando em anel 0. A função do TaskManager é aquilo que você vê: mostrar as tarefas em execução, mostrar o consumo de recursos, etc. Ou seja, tarefas de alto nível. Jamais se poderia fazer escalonamento de tarefas numa aplicação rodando em anel 1, como é o caso do TaskManager e de todas as aplicações de alto nível. Até porque, escalonamento de tarefas é uma operação altamente privilegiada, que só pode ser executada por código rodando em anel 0.
OBS: a partir do 80286 (se não me falha a memória) os processadores passaram a contar com opções de processamento em situações de privilégio diferenciado, chamados de anéis (ou rings). O anel mais privilegiado é 0, onde roda o núcleo do sistema que, entre outras coisas, faz a preempção (tira o controle de uma tarefa para entregar a outra) que é a base do escalonamento (controle de quem fica com quanto tempo de CPU). Essa arquitetura preemptiva, inclusive, é o que nos dá a ilusão de que muitas tarefas são executadas ao mesmo tempo (multi-tasking). As aplicações de nível mais alto rodam em anel 1, menos privilegiado e submisso ao anel 0. Outras tarefas (threads da aplicação) rodam em anel 2 e são vinculadas à aplicação que as criou. E, claro, são controladas pelo núcleo do SO (a preempção). Exatamente por isso, o Pentium HT (Hiper-Threading) se dá tão bem com aplicações multi-threaded. Ele tem um segundo núcleo dedicado às threads. Isso é visível no TaskManager que, para esses processadores, tem duas medidas de consumo de CPU. Para obter detalhes ou confirmar essas informações, consulte os manuais da Intel. Neles você tem isso tudo bem melhor explicado.

4) Um percentual de 0,03% de consumo de CPU é puro mandrakismo. Se isso fosse verdade, a Microsoft deveria adotar o XHarbour para fazer seu próximo sistema operacional, pois meu XP, em absoluto repouso, fica sempre na faixa dos 2%.

5) O que você quer dizer com "vc tem que saber tambem distribuir o poder de processamento do seu sistema"? Processamento é processamento. A ordem de como as coisas devem ser feitas é algo vinculado às necessidades do programa na realização de determinada tarefa. Não dá pra mudar isso como num passe de mágica. E nada disso fará o programa consumir menos CPU. A não ser, claro, que o programa tenha sido realmente muito mal feito. Mas aí o processo que faz a performance melhorar tem outro nome: otimização (ou refactoring).

6) A função "ProcessMessages", parte da VCL do Delphi (e BCB), não tem nada a ver com "alívio do processador". Por favor, antes de dizer uma coisa dessas, leia o Help!!!
Explicando pra quem ainda não conhece: praticamente tudo no Windows é baseado em eventos que são disparados por meio de mensagens. Essa é uma forma especial de comunicação que existe entre o SO e o programa e entre partes distintas de um mesmo programa. Um clique de mouse, por exemplo, gera um evento que é disparado por meio de uma mensagem enviada pelo SO. Outro exemplo: um comando de "shutDown" força o SO a emitir uma mensagem de encerramento que é replicada (broadcasting) para todas as aplicações.
Depois deste preâmbulo,...
Há situações em que um programa parece travar. A tela não é redesenhada e às vezes fica um quadro meio "desfigurado" ou simplesmente branco. Isso não quer dizer necessariamente que o programa travou. Normalmente isso ocorre porque houve um emperramento na fila de mensagens da aplicação e aquela mensagem que serve para comandar um "repaint" ficou parada nesta fila e não foi processada. Para evitar isso, o que se faz é inserir uma chamada à função ProcessMessages() em alguns trechos críticos do programa, para "desemperrar" o processador de mensagens da aplicação. Só então a mensagem de "repaint" é processada e o form da aplicação (e seus controles: botões, edits, etc) é redesenhado, voltando ao normal.
Ou seja: isso não tem nada a ver com "aliviar" a CPU. E o mais engraçado da coisa é que, na prática, ProcessMessages() faz exatamente o contrário: aumenta o consumo de CPU, já que permite o processamento das várias mensagens emperradas. )))
Agora me diga: quem é que está tendo ilusões???

Você parece não ser muito chegado em ler Help. É uma prática ruim. Tudo bem, é decisão sua. Mas se não quiser ler o help do Delphi pra confirmar o que eu disse, eis uma parte que peguei do help do BCB (eu não programo em Delphi), que tem o mesmo teor:

Call ProcessMessages to permit the application to process messages that are currently in the message queue. ProcessMessages cycles the Windows message loop until it is empty, and then returns control to the application.

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




PS1: Falando em Help,... Depois de um bom tempo, baixei o XHarbour completo. Tudo o que vi pela frente. Notei uma falta: help. Custava ter um ZIPão com todos os arquivos de Help que um programador normalmente precisa? Baixei o Turbo C++ Explorer da Borland (é grátis). Um produto realmente bem feito, que deveria servir de exemplo. Só de Help são uns 200MB. Isso é o que se deve esperar de um produto de boa qualidade. Deixo aí minha crítica ao time que desenvolve o XHarbour. Help pra programador é como sapato pra mulher. Tem que ter de monte. ))))
E aquele help on-Line é horrível. Primeiro que é on-Line. Poderiam, pelo menos, ter feito um ZIP dele, pra consulta off-Line. Segundo que é incompleto, pelo que vi em algumas funções.

PS2: Antes de discordar do que eu disse, por favor, pesquise os dados nos locais que comentei. Leia com atenção. Depois disso, aí sim, você pode me contradizer à vontade. Se achar que deve, claro.

Puts Maligno,

Você parece que tem um ódio de mim não sei porque.

Eu não usei os termos que você queria que eu usasse, alias aqui é um forum.

Os aplicativos executados em NTVDM tem que ficar mais lentos pois o caminho para acesso a perifericos não é o mesmo, alias na documentação da NTVDM parece que o acesso a tela e controles de teclados ficam mais rapidos, tirando isto, você já pode ver logo que se nao tirar os commits do programa, já vai ter problemas com a NTVDM, eu fiz comparações num micro antigo que tinha o Windows 98 e XP instalados e no XP o mesmo programa fica pouca coisa mais lento, não é nada que impessa o uso e que o usuario nem vai perceber.

Quanto ao processamento do xHarbour ficar em 0.3% eu fiz sim e tem um puta servidor em SP rodando um aplicativo que está sendo acessado por filiais no Brasil todo e inclusive uma filial na CHina, se vc deixar um WHILE correr direto vai ter um consumo de CPU na casa dos 95% mas se aliviar o processador fazendo com que existam pequenos "pauses" no processo, ele fica pouca coisa mais lento e o consumo de CPU não sai da casa dos 0.3 ou 0.5 %, vc que tem que acertar isto, o processmessages do Delphi faz exatamente isto, em um While que vai demorar muito vc pode usar ele para que o resto do sistema não pare esperando que ele seja executado, alias só assim vc consegue deixar um botãoziho para o usuario cancelar o processamento, de outra forma como a CPU vai ficar tentando resolver o WHILE seu programa fica para esperando que este termine, será que é mentira? A, quanto ao sleep que tem que ter no While, logicamente, no Delphi também é bom, mas isto so para ambiente de processamento centralizado, se for rodar sempre local, isto já nao importa muito. O consumo de CPU não vai gerar problemas sérios.

Quanto a anel 0, anel 1, anel de casamento, anel 3 que alias é onde o KDE roda e faz com que o linux nao precise ser reiniciado mesmo se ele der pau, acho que você fala muito bonito, mas não quero confundir mais ninguém, agora que o programa DOS fica mais lento no XP fica, principialmente em rede, quem não teve problemas com commits que não ocorriam em outras versões do Windows?

Alias, se o NTVDM não emulasse o codigo de 16bits porque seria chamado de:

MAQUINA VIRTUAL ou NT VIRTUAL "DOS" MACHINE?

Puts... eu sempre to errado...


Averigue os processamentos de seu sistema, dando alguns sleep em Whiles que você vai ver como ele vai rodar bem mais "suave" sem ter picos de processamentos e você tambem vai ver como em um ambiente de processamento remoto você vai ter um consumo muito baixo de recursos e o potencial de conexoes aumenta e muito.

Alias, o Windows com tudo o que tem, recursos gráficos, acesso a arquivos, etc, etc, etc... tem um consumo de CPU hyper, ultra, power, mega baixo... se o Windows que comando todos os processos faz isso, porque seu programa nao pode???? e o que impede o xHarbour de fazer isto??? o sistema tem periodos de ociosidade que não gastam ciclos de CPU, no momento que vc está consumindo muito, tem inumeras formas de prolongar o processo e fazer o consumo de CPU cair, isto tem que ser revisto quando se trabalha com emulação de terminal pois se não o que era para ser um grande sonho e uma grande vantagem pode se tornar um pesadelo.

Abraços e evite começar discussões, você está conquistando minha antipatia infelizmente, não tenho aversão a ninguém aqui e não quero ter nunca, sou Evangelico e sirvo a Deus e não preciso criticar os outros para ganhar a vida pois Ele me basta.

Acho que você fala bonito, mas acho que isto não resolve, entender é entender, eu não tenho diploma de nada, nem de datilografia, o que aprendi foi fazendo e não sei falar bonito, mas se for preciso eu faço o que me pedirem, alias por isso não paro mais em casa, só na estrada, programo em C, Delphi, Clipper, xHarbour, Foxpro, Vb, Processadores ARM, 6502, Palm, Linux, Procolos proprios, ASM, já programei tudo quanto é tipo de perifericos para Windows e Linux, já programei servidores seriais para Linux, libs, CGIs com clipper e com xHarbour e recursos para o mesmo, libs graficas, Descompiladores para diversas linguagens, ja ajudei em diversos projetos, ACBR, xHarbour, já programei POS de tudo quanto é tipo, eu conheço na pratica, por isso não sei termos técnicos, porém eu sei o que estou falando e vivo isto todo o dia.

vagucs escreveu:Você parece que tem um ódio de mim não sei porque.

De todas, essa foi a dedução mais errada que você já teve. Me dá a impressão de que você simplesmente não aceita ser contestado. Mas fique tranqüilo. Não tenho ódio de ninguém.

Eu não usei os termos que você queria que eu usasse, alias aqui é um forum.

Não entendi o que tem a ver uma coisa com a outra. Mas tudo bem. De qualquer forma, o que eu quero é o que menos importa.

Os aplicativos executados em NTVDM tem que ficar mais lentos pois o caminho para acesso a perifericos não é o mesmo, alias na documentação da NTVDM parece que o acesso a tela e controles de teclados ficam mais rapidos, tirando isto, você já pode ver logo que se nao tirar os commits do programa, já vai ter problemas com a NTVDM

Uai! Mas o que aconteceu com aquela história de "tradução" de código de 16 pra 32 bits? Desistiu de ir por esse caminho e agora quer tentar ir por outro?
Agora a explicação para a lentidão é que o acesso a periféricos não é feito da mesma forma que antes?
É evidente que os COMMITS, em qualquer situação, se mal usados, vão trazer lentidão pro programa. Seja DOS puro, XP, etc.

com maquinas identicas o programa de DOS fica muito mais lento quando é executado no Windows XP

eu fiz comparações num micro antigo que tinha o Windows 98 e XP instalados e no XP o mesmo programa fica pouca coisa mais lento, não é nada que impessa o uso e que o usuario nem vai perceber.

No primeiro quote, sua frase num post anterior. E agora você diz que fica pouca coisa mais lento. Decida-se, Wagner. Você quer que fique mais lento ou só um pouquinho lento? )))
Seja consistente com suas alegações.

Quanto ao processamento do xHarbour ficar em 0.3% eu fiz sim

Aí você vai me desculpar, mas nem tem como conversar. Minha máquina e meu XP não dão menos de 2 ou 3% em repouso absoluto, mesmo eliminando todos os programas. Sem deixar rodar nada. Absolutamente parado. Mas, funcionando, sua máquina consegue 0,3% de consumo? Não dá. É melhor esquecer isso.

o consumo de CPU não sai da casa dos 0.3 ou 0.5 %, vc que tem que acertar isto, o processmessages do Delphi faz exatamente isto

Poxa! Eu passo pra você o help desta função e ainda assim você teima em vincular essa função com alívio de processador? Leia o help, meu caro. Se você se der a esse trabalho verá que ProcessMessages não faz outra coisa senão forçar o desemperramento das mensagens na fila de mensagens da aplicação.

em um While que vai demorar muito vc pode usar ele para que o resto do sistema não pare esperando que ele seja executado, alias só assim vc consegue deixar um botãoziho para o usuario cancelar o processamento, de outra forma como a CPU vai ficar tentando resolver o WHILE seu programa fica para esperando que este termine, será que é mentira?

Não disse que é mentira. Disse que você está deduzindo errado. Mas tudo bem. É melhor deixar esse ponto pra lá. Se nem o help você quer ler, não há mais o que dizer disso.

Quanto a anel 0, anel 1, anel de casamento, anel 3 que alias é onde o KDE roda e faz com que o linux nao precise ser reiniciado mesmo se ele der pau, acho que você fala muito bonito, mas não quero confundir mais ninguém, agora que o programa DOS fica mais lento no XP fica, principialmente em rede, quem não teve problemas com commits que não ocorriam em outras versões do Windows?

Provavelmente o Linux roda em anel 0, assim como o Windows. Foi o que eu disse no meu post anterior.
Falar bonito? Você não tem argumentação melhor que essa?

Alias, se o NTVDM não emulasse o codigo de 16bits porque seria chamado de:
MAQUINA VIRTUAL ou NT VIRTUAL "DOS" MACHINE?

Pergunte a Microsoft porque ela criou esse nome. ))))))
Seria pedir demais você consultar um dicionário pra saber o significado da palavra emulação?
Porque você não pára com essa teimosia infantil e simplesmente não vai pesquisar pra saber o que é a VDM? Esquece o nome VDM. Isso é só um nome. O que interessa é o que ela faz. Ao invés de perder tempo com essas suas deduções erradas, faça um favor a si mesmo: pesquisa na Net e adquira gratuitamente esse conhecimento. Não precisa ficar discutindo. É só ter boa vontade. É tão difícil de entender isso?
Ou então, faça o inverso. Me prove o que você diz.

Puts... eu sempre to errado...

O seu problema é que você deduziu algumas coisas de forma errada sem se preocupar em ir atrás da literatura técnica para embasar suas deduções. Eu próprio aprendi muita coisa na base da dedução, mas tive o cuidado de checar. Muitas vezes vi que tinha deduzido errado e corrigi meus conceitos. Isso se chama "humildade pra reconhecer os próprios erros".

Averigue os processamentos de seu sistema, dando alguns sleep em Whiles que você vai ver como ele vai rodar bem mais "suave" sem ter picos de processamentos e você tambem vai ver como em um ambiente de processamento remoto você vai ter um consumo muito baixo de recursos e o potencial de conexoes aumenta e muito.

Já disse: meus programas rodam normalmente em qualquer DOS.
Inserir um Sleep no meio de um processamento pode reduzir o consumo de CPU, claro. Mas fará com que o programa rode mais lentamente. Afinal de contas, "sleep" significa "dormir". Enquanto "dorme" o programa não faz nada. ))))))))

Alias, o Windows com tudo o que tem, recursos gráficos, acesso a arquivos, etc, etc, etc... tem um consumo de CPU hyper, ultra, power, mega baixo...

Pra mim e em alguns clientes (eu fui atrás pra ver), o consumo de CPU, em repouso absoluto e total, não cai. Fica sempre na faixa dos 2%. Não adianta. É melhor deixar essa história pra lá.

se o Windows que comando todos os processos faz isso, porque seu programa nao pode???? e o que impede o xHarbour de fazer isto???

Eu só uso o XP. Nele, há sempre algum código sendo processado. É só ver a lista imensa de serviços que ficam pendurados. O consumo de CPU é realmente pequeno, mas sempre existe algum consumo, ainda assim. Se com você fica em 0,3%, então você é um sortudo. Nem discuto mais.

Abraços e evite começar discussões, você está conquistando minha antipatia infelizmente, não tenho aversão a ninguém aqui e não quero ter nunca, sou Evangelico e sirvo a Deus e não preciso criticar os outros para ganhar a vida pois Ele me basta.

Não use o nome de Deus em vão. Isso é uma coisa horrível de se fazer.
Começar discussões não. Isso aqui é um fórum, como você mesmo lembrou. Estamos aqui pra discutir. Se eu vejo alguém dizendo algo errado, que pode influenciar negativamente um novato, me considero na obrigação de discordar e apresentar meus argumentos. De forma embasada em documentação, claro.
Não ganho a vida criticando, meu caro. Se você está me tomando como antipático, é problema seu. Mas a recíproca não é verdadeira, felizmente.
Não sou agnóstico mas não sigo qualquer religião. Mas sei muito bem a diferença entre fazer o bem e fazer o mal. Não digo que você esteja fazendo o mal propositadamente. Não me entenda errado. Mas é óbvio que suas deduções erradas mais fazem mal do que bem. Essa é a minha opinião. Acho que você deveria tomar mais cuidado com essas deduções. Acredito que você é um sujeito inteligente, mas que ainda peca nesse ponto.

Acho que você fala bonito, mas acho que isto não resolve, entender é entender, eu não tenho diploma de nada, nem de datilografia, o que aprendi foi fazendo e não sei falar bonito

Porque você vincula o "falar bonito" com diploma? Acho que eu sou formado em universidade? Você só me faz rir. )))))))))))
Eu só tenho o terceiro colegial, que hoje chamam de ensino médio. Aprendi tudo sozinho, assim como você. Mas cultura independe de diploma, meu caro. Você deveria saber disso.
Se eu sei "falar bonito", é porque eu tenho alguma cultura, que não me caiu do céu. Eu fui atrás, estudei, batalhei. Coisa que qualquer um pode fazer. Não se esconda atrás do fato de você não ter muito estudo ou diplomas de universidade. Isso não é desculpa pra nada.

mas se for preciso eu faço o que me pedirem, alias por isso não paro mais em casa, só na estrada, programo em C, Delphi, Clipper, xHarbour, Foxpro, Vb, Processadores ARM, 6502, Palm, Linux, Procolos proprios, ASM, já programei tudo quanto é tipo de perifericos para Windows e Linux, já programei servidores seriais para Linux, libs, CGIs com clipper e com xHarbour e recursos para o mesmo, libs graficas, Descompiladores para diversas linguagens, ja ajudei em diversos projetos, ACBR, xHarbour, já programei POS de tudo quanto é tipo, eu conheço na pratica

Belo exemplo de humildade.
Não vou dizer que é o seu caso, mas conheço um sujeito que tem um currículo muito maior que o seu, mas ainda assim, é burro como uma porta. O que eu quero dizer com isso é que listar o seu currículo não acrescentou nada à discussão.

por isso não sei termos técnicos, porém eu sei o que estou falando e vivo isto todo o dia.

Não. Você realmente não tem uma perfeita idéia do que falou nessa thread. Aliás, o fato de ter aprendido sozinho não lhe garante saber o que faz. Já vi vários casos assim. Seja mais humilde.

Ademais, também aprendi tudo sozinho. Ainda assim, conheço os termos técnicos perfeitamente. Posso conversar de igual pra igual com qualquer engenheiro de software. E já conversei. Entendi e me fiz entender muito bem. Isso é muito importante. Principalmente por que eu ganho com isso mais experiência. Mas não me prendo ao meu conhecimento, que eu sei que é incompleto. Sempre será. Sou um eterno aprendiz, igual a todo mundo.

Agora, se sua intenção na vida é apenas ganhar dinheiro com programação, nem se preocupe muito com isso. Apenas tome mais cuidado com suas deduções, conforme eu disse antes. Não por você. Mas porque você, como pessoa que é estimada nesse fórum, pode estar servindo de modêlo, referência para os iniciantes. Se você deduz errado, ensina errado. E isso é mal. Não deveria acontecer. Mas se acontecer, e eu puder evitar, pode contar que, enquanto eu ainda participar desse fórum, estarei lá para discordar do que vir errado. Seja vindo de você ou qualquer outra pessoa. Mas por favor, não pense que sou um chato. Na área de programação eu sou MUITO chato. E há pessoas que me agradecem por ter sido chato com elas no momento em que foi necessário. )

Finalizando: provei meus argumentos, mas você não foi atrás pra confirmar. Preferiu teimar nas suas deduções erradas, sem provar nada. Paciência. Pelo menos cumpri meu papel de plantar a semente da dúvida. Espero que quem tiver lido tudo isso, pelo menos fique curioso, e se dê ao trabalho de ir atrás das matérias que citei. É informação pública, gratuita e fácil de encontrar. Taí o Google pra ajudar.

Como essa thread já descambou para o lado não-técnico, contando até com uma citação religiosa (aliás, em vão), não há porque continuar. Páro por aqui.

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

Pois é maligno, você sabe ofender as pessoas com certa facilidade.

Como disse eu sei o que vivo, rapaz, preciso documentas a questão do sleep, que vc mesmo concordou no que eu já havia falado, ele prolonga a tarefa de forma que o processador nao tenha gargalos, tudo é uma questão de você saber usar para que nao tenha consumos exagerado de CPU, o projeto da metaltex em SP só foi possivel fazend isto para que não existisse uso exagerado de CPU e fosse possivel ligar tanta gente em SP sem problemas com processamento.

Como disse em post anterior, o processmesage realmente faz com que outros eventos do aplicativo sejam processados e o uso do SLEEP em AMBIENTE DE PROCESSAMENTO REMOTO é quase inevitável pois se vc tiver um grande numero de maquinas terá sim que prolongar os processos para não ter tanto consumo de CPU, pois infelizmente parece que se você nao fizer isto, nem o linux consegue gerenciar este consumo naturalmente.


Quanto a EMULAÇÃO eu nunca vou discordar, procure qualquer pessoa que ja tenha trabalhado com emulacao de qualquer coisa, o principio basico é

LER INSTRUCAO
ENTENDER INSTRUCAO
TRADUZIR INSTRUCAO (OU GRAVAR ELA) PARA EXECUTAR COMO SE QUER

Isso é básico.

Agora se o DOS é emulado ou não, problema da microsoft, já nao tenho mais aplicativos em DOS, mas que ele é um emulador ele é, independente de rodar parte do codigo nativamente ou nao.

Ele roda os aplicativos mais lentamente, isso tudo depende de maquina tambem, um aplicativo DOS em um K6 500 de um cliente que antes rodava Win98 e depois ele colocou o XP, ficou muito mas muito mais lento, já em maquinas mais rapida melhor um pouco, mas fica mais lento, quando eu falo de muito mais lento, nao falo que um processo de 10 segundos passou a ser feito com 10 minutos, mas sim de 10 para 15 segundos é algo inaceitável aqui na CONAB, os engenheiros de software já analisaram isso e consultores também, e alias, o consumo de CPU para todos os estados acessando daqui já foi relacionado diversas vezes e mostrei toda a estrutura que foi criado para esta empresa de SP, mostrei tudo aqui de brasilia, o consumo, acesso externo, e o projeto por ter conseguido em pontos de muito gargalo chegar a picos de CPU de 7%, a CONAB está agora usando xHarbour, até final do ano todos os estados começarão a estar centralizados aqui e já fizemos os testes, se nao por um sleep para dar um time mesmo que de milisegundos, algo que nao prejudica o processamento a CPU fica com consumo alto em diversos monentos, como nunca podemos prever o que o usuario está fazendo o uso disto para fazer a tarefa "dormir" para que outros processos tambem recebam "atencao" é inevitável, até no delphi é.

Quanto a usar o nome de Deus em vão, eu nao usei o nome dele em vão, alias é pelo nome dele que tenho obtido muitas vitórias na minha vida e pelo nome dele que ao invés de criticar eu tento ajudar, alias vejam algum post meu que eu tenha criticado a resposta de alguem?

Alias tudo começa assim.

LEVANTA UMA QUESTAO
EU RESPONDO
AI VC VAI E VEM QUERER DISCUTIR MOSTRANDO QUE TODOS ESTAO ERRADOS
MAS APENAS DÊ SUA OPNIAO NA QUESTAO LEVANTADA

Acho que assim como 99% dos amigos nao fazem isso, vc nao precisa fazer tambem, se estou errado, me deixe errado, no erro estou sendo bem sucedido, alias se fosse errado acho que estaria no interior.

Isto gera muitos posts desnecessários.

Pois é maligno, você sabe ofender as pessoas com certa facilidade.

Já me disseram isso antes. Mas sempre confudem sinceridade e honestidade com ofensa.

Eu não ia voltar na thread, mas...

Quanto a EMULAÇÃO eu nunca vou discordar, procure qualquer pessoa que ja tenha trabalhado com emulacao de qualquer coisa, o principio basico é

LER INSTRUCAO
ENTENDER INSTRUCAO
TRADUZIR INSTRUCAO (OU GRAVAR ELA) PARA EXECUTAR COMO SE QUER

Só entrei de novo nessa thread por causa desse parágrafo. Ele me chamou a atenção para um detalhe. Ele demonstra que eu pensei certo sobre você. Você está apenas deduzindo que é assim, mas sem querer saber se é verdade ou não. Isso é achismo. Não é informação técnica. Só peço uma coisa: PROVE o que diz.

Mais uma vez (eu disse que sou chato): nem sempre a emulação de um sistema operacional necessita da tradução de instruções. Tenho um amigo, físico em Campinas, que trabalhava com máquinas SPARC e conseguia rodar programas DOS normalmente. Ele usava um emulador que sim, precisava emular instruções X86, já que os processadores SPARC são RISC. Totalmente diferentes dos X86. Aí seu argumento se justificaria.
Entretanto, no caso do Windows rodando em microprocessadores X86 isso NÃO É NECESSÁRIO, por causa da compatilibidade em nível de instruções. Já falei sobre isso.

Você quer tanto estar certo que não quer ir atrás da documentação que comentei. Fique assim então. Não me importo com sua teimosia. Mas me importo com o fato dos colegas aprenderem algo errado. Nem vou dizer que estou certo. Como disse antes: eu quis plantar a sementinha da dúvida sobre o que você disse. Aos colegas que se interessarem pelo assunto, resta ir atrás. Ou ficar na ignorância.

Falando então em princípio básico, posso dizer com certeza, e sem medo de errar: a NECESSIDADE é o princípio básico da emulação (e outras coisas mais, claro). Ou seja: se precisar traduzir, traduza. Se não precisar, como no caso da VDM em X86, não traduza.

Quanto a usar o nome de Deus em vão, eu nao usei o nome dele em vão

Usou sim. Mas não vou explicar porque. Mas deixa esse assunto pra lá.

alias é pelo nome dele que tenho obtido muitas vitórias na minha vida e pelo nome dele que ao invés de criticar eu tento ajudar, alias vejam algum post meu que eu tenha criticado a resposta de alguem?

Como evangélico que diz que é, você deveria saber que criticar é uma maravilhosa forma de ajudar. É uma forma de demonstrar apreço por alguém. É o mesmo que doar aos outros o que de melhor você tem. Amizade e companheirismo não pressupõem apenas palavras afáveis. Pressupõem também críticas, quando necessárias.
Por isso, critique (de forma construtiva) sempre que achar que deve. Seu silêncio só ajudará a propagar o erro.

LEVANTA UMA QUESTAO
EU RESPONDO
AI VC VAI E VEM QUERER DISCUTIR MOSTRANDO QUE TODOS ESTAO ERRADOS
MAS APENAS DÊ SUA OPNIAO NA QUESTAO LEVANTADA

Foi o que tentei fazer. Você que entrou na thread depois e discordou do que eu disse. O que é justo, aliás. Mas junto com a crítica, você lançou um monte de conceitos distorcidos. Tentei ajudar você a encontrar o caminho da luz. Afirmei que as provas estão fáceis de buscar. Mas você se recusa a ir atrás. E só pra não dar o braço a torcer. Seu ego...! Paciência. Quem perde é você. O que me importa é que fiz a minha parte.

Acho que assim como 99% dos amigos nao fazem isso, vc nao precisa fazer tambem, se estou errado, me deixe errado, no erro estou sendo bem sucedido, alias se fosse errado acho que estaria no interior.

Negativo, meu caro. Não deixaria você mantendo conceitos errados apenas por teimosia. Se posso ajudá-lo a mudar seus conceitos para melhor, considero minha obrigação. Ou você quer dizer que sempre está certo? Você nunca erra? Eu erro. E aceito críticas naturalmente. Mas tem que me provar. Não aceito que me empurrem qualquer coisa, como você tentou fazer.

Finalizando: para o caso de alguma palavra mais ríspida, peço que me desculpe. Realmente não tive a intenção de ofender.

Mas lembre-se: se eu ver informação que precise ser contestada, vinda de você ou de quem quer que seja, assim que possível, lá estarei, contestando e plantando outra sementinha de dúvida. Se 99% não faz, alguém tem que fazer.

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

Para finalizar Maligno, nao sei o que te fiz para vc ficar falando assim, sempre tento ajudar a todos aqui e participo da vida de muitos amigos e comemoro as conquista de cada um.


Bom quando a você achar isto é achismo, eu já montei um emulador de 6502 e de Z80 coisa basica e mais para entender o processo de emulação, o clipper é uma maquiina virtual e como montei o DClip eu tiver que entender como funcionava esta "EMULAÇÃO", entao o que eu disse abaixo nao é e nunca foi mentira.

Esta regra básica é que o emulador tem que cumprir para emular alguma coisa.
Quanto ao nome de Deus em vão, acho que você está muito equivocado, pois levar o nome dele em vão pelo que a biblia explica é outra coisa (jurar em nome de Deus, abençoar ou amaldiçoar em nome dele).

Quanto ao processmessage eu disse que era necessario a chamada e é, mas realmente nao é função dele aliviar o processamento, mas como disse antes, até no delphi um SLEEP é necessário isto para o caso de processamento centralizado, nao falo para usuario que roda o programa localmente, isto eu tive que fazer com o xHarbour pois com muitas conexões se vc nao souber aliviar o processamento em dados momentos o servidor fica muito lento e até pode parar de responder.

Acho que foi onde chegou toda questão.


Quanto a achismo, a NTVDM é um emulador de DOS que independente do set de instruções ser compativel, ainda parte deste codigo, digo interrupções no caso de hardware e acesso a memoria tem que ser emulados na mesma forma que qualquer emulador (LER, ENTENDER, INTERPRETAR) se ler a documentação do NTVDM vai ver que é assim, o que pode dependendo do tipo de hardware usado gerar lentidão.

Agora se quiser continuar com sua novela de falar que to levando o nome de Deus em vão, que eu nao sei o que falo, que emular não é isso, que aliviar processamento nao é isso, que NTVDM é tão rapido quanto o aplicativo em Win 98, acho que não vamos chegar a nada, guarde seus conceitos certos que fico com os meus errados, estou me dando certo com eles.

Abraços

Boa noite

Li atentamente este tópico, pois era um problema q eu vinha a muito tempo tentando resolver com win XP, e cheguei a uma conclusão q o melhor seria mudar de linguagem, optei o Delphi (a uns meses atras), porque? Digo:

O Clipper foi muito bom mas na sua época, optando pelo Delphi ganhei uma imensidão de banco de dados (dbf, access, sql, oracle, firebird,etc), tem muitos componentes, relatorio tanto em USB, LPT, sem ficar usando programas externos para fazer "pontes", entre outros.

Tive dificuldades com a arquitetura NT com o clipper, sendo q os dois amigos do forum tanto o Maligno quanto o Vagner tem suas razões, pois se vc não tirar os commits da vida no sistema para rodar no XP fica uma carroça, porém para indexar arquivos, exibir relatórios ficou muito melhor (pra mim), só o que mais se usa em um sistema é lançar nota de saída, notas de entrada, etc... onde se tem q usar os commits para o sistema não se perder, gravar os dados de acordo (e a gente ficar de cabeça fria).

Porque não usei xHarbour, simplesmente documentação, help, literatura, onde o Maligno tem toda razão, e alem disso uma interface no meu modo de ver q ainda fica a desejar, muitos libs clipper não funciona com o xHarbour, então pra q quebar a cabeça, estamos no mundo da informática, temos q sempre aprender e evoluir, e estou evoluindo com o Delphi.

Daí vcs vão falar: "mas o delphi não roda em Linux", tudo bem, mas eu só faço sistema para win mesmo, então eu entro em contradição quando falo em evoluir, tb não pois tem o Kylix, Lazarus pra Linux (se não me engano), pois a maioria dos comercios pequenos e médios usa o Windows.Quando for preciso eu terei com certeza.

Bom acho q deixei minha opinião sobre o que foi melhor pra mim e pra alguns colegas analisarem o q for melhor pra cada.

Até mais e bom fim de semana a todos

Amiguinhos

Todos estão colocando a culpa do excesso de consumo de CPU neste ou naquele aplicativo, na emulação ou não, e que deve ser feito este ou aquele ajuste nos mesmos.

Acontece que é possivel modificar os parametros de consumo no próprio Prompt do MSDOS em relação a ociosidade.

Não me lembro se aumentando ou diminuindo o tempo de ociosidade da sessão DOS o Windows ficava mais leve, mas muitas vezes foi isto que tive de fazer no meu aplicativo DOS.

Lógico que o que digo deixa irrelevante o fato de tudo que aqui foi discutido, mas não devemos atirar a pedra no culpado sem antes julga-lo.

@braços :?)