Primeiramente quero me desculpar pela extensão da resposta, mas não dá pra ser sucinto demais nesse tipo de assunto.
Eolo escreveu:a) vc disse "...hoje em dia com tanta memória a disposição e que não é aproveitada da melhor forma...". Bem, talvez algum colega possa esclarecer isso melhor, mas pelo que eu vi até agora quem manda na coisa são os 640k, tudo fica pendurado neles. Você pode ter 2Gb de RAM, mas se esgotar os 640k, ferrou...
Não necessariamente. Isso só acontece se você utilizar o modo real. No modo protegido, todo o código é executado na memória extendida, acima do primeiro MegaByte. Então, o limite de uso de memória do sistema passa a ser muito maior. Os 640KB são solenemente desprezados, e nem fazem falta, haja vista que hoje em dia não fazem muita diferença. Talvez você se pergunte porque desprezar 640KB de memória. A resposta está no gerenciador de memória. No modo protegido toda a RAM é protegida (óbvio). Isso significa que qualquer acesso à memória deve, primeiro, passar pelo processo de requisição de um seletor de memória. E quem autoriza ou não é o sistema operacional. Para obter o controle da memória, ela precisa ser mapeada dentro do gerenciador do SO. E esse mapeamento exclui o primeiro megabyte. Assim, só a memória extendida poderá ser utilizada. Aliás, esse controle de requisição de seletor é o que explica o porquê de algumas bibliotecas dispararem GPFs quando o programa executa. Elas tentam acessar a memória diretamente, sem pedir "licença" pro SO. Aí é GPF sem dó nem piedade. Isso acontece principalmente naquelas bibliotecas que têm funções com acesso direto à RAM de vídeo.
Esse assunto de memória é muito extenso, mas pra quem programa em Clipper sob Windows NT (estou excluindo os Win9x de propósito), ele começa justamente na máquina virtual NT, como é a tradução de NTVM. O Windows, quando monta uma máquina virtual com orientação a texto, vulgarmente conhecido como DOS emulado (termo errado - veja o meu PS abaixo), ele reserva parte da memória física para essa máquina. Na configuração do atalho você pode observar que existe um listBox pra selecionar o montante de memória que será dedicada à essa máquina DOS. Se você selecionar, por exemplo, 4MB, a máquina terá disponíveis apenas esses 4MB de memória física. Nenhum outro programa Windows terá acesso à essa área reservada. Mas é sempre bom lembrar que uma máquina virtual é um programa Windows como outro qualquer e está sujeito ao swap pelo gerenciador de memória do Windows, no caso dele precisar de mais memória física. A estratégia de apropriação de memória do Windows passa por muita coisa. O Task Manager do XP mostra bem qual o estado dos totais de memória física e virtual, embora ele não mostre a memória consumida pela aplicação individualmente. Mas se, na eventualidade de acontecer da memória da máquina virtual se mostrar insuficiente, o BLinker (não o Windows) entra em ação. Por meio de uma tabela interna ele descobre quais páginas de memória tem mais teia de aranha, ou seja, as mais antigas. Ele as envia pro disco e libera essa memória física para o procedimento que a requisitou. Se alguma página residente em disco for necessária novamente, esse procedimento é repetido, havendo portanto, uma troca (ou swap). Estou falando apenas do modo protegido.
No modo real, a memória convencional também é utilizada e, se tiver sido definida uma área de overlay, o programa, se muito extenso, pode trabalhar de maneira mais folgada. Essas seções de overlay podem, inclusive, ser jogadas para a memória extendida; aquela acima de 1MB, e a troca pode ser feita em RAM mesmo, o que incrementa a performance do programa, já que não será mais necessário acessar a disco.
Quando ao comentário do Pablo, que disse que overlay é um recurso ultrapassado, sou obrigado a concordar. Pense bem: uma vez que o modo protegido oferece mais flexibilidade pra trabalhar com memória, não faz muito sentido usar overlay, mesmo com seções internas em RAM ou externas em disco. Aliás, com seu programa rodando em modo protegido ele pode ser do tamanho que for que dificilmente haverá problema de falta de memória, desde que você dê a máquina virtual o montante de memória que ela necessita. É claro que alguns procedimentos adicionais devem ser adotados, como a desfragmentação pontual (após o descarte de matrizes e fechamento de bancos de dados). Na minha opinião, a fragmentação é a maior vilã dos programas Clipper, uma vez que o desfragmentador nativo é muito problemático. Eu próprio já tive problemas com isso, mesmo com o programa rodando em modo protegido.
Eolo escreveu:b) quanto ao Rtlink, a resposta é sim. A diferença é o Blinker linka em modo protegido e o Rtlink não (acho que só em modo real). Tente migrar para o Blinker, que é mais atual.
Sim, o BLinker é atualmente a melhor opção de linker, pelo menos na opinião da maioria. E com relação ao modo protegido em conjunto com overlay, que é a forma com que você trabalha, atente para esta frase, extraída do help do BLinker 7:
If BLINKER EXECUTABLE EXTENDED is specified then ALL link script commands to do with overlaying are ignored, and a non-overlaid program is always created.
Acho que a frase dispensa comentários.
[]'s
Maligno
http://www.buzinello.com/prg
PS: O termo DOS emulado é errado e é usado há muito tempo não só por ignorância dos que desconhecem os esquemas de emulação e virtualização, como por vício de linguagem, que é bem o meu caso. Peço desculpas por isso. Sempre prezo o uso correto dos termos e acabei viciado no termo emulação.
Há uma diferença brutal entre emulação e virtualização, embora ambos os processos tenham finalidades semelhantes: tornar possível executar sistemas e/ou hardwares em máquinas que podem não ser as nativas.
Emular, em informática, significa transformar ou traduzir o código original de forma que ele se torne compreensível e executável em um hardware diferente. Exemplos em que a emulação é necessária: Basic do Z80 rodando no PC, calculadora HP48X rodando no Mac, MSX rodando num IBM3090, etc.
No processo de emulação, a máquina local invariavelmente possui um hardware diferente do da máquina emulada. Por conta disso, todo o processamento dessa máquina tem de passar antes por um processo de tradução do código da máquina original para o hardware da máquina local. Se estivermos rodando um DOS num SparcStation Sun com processador DEC Alpha, a emulação é o único caminho pra ter o DOS rodando código X86. Issó é lógico: um DEC Alpha é RISC, enquanto que um X86 é CISC. São processadores totalmente diferentes.
Por outro lado, a virtualização só é possível quando os hardwares envolvidos são compatíveis. Voltando ao DOS: no PC com Windows NT o processador local é o mesmo do processador da máquina virtual: o X86 compatível. Mesmo que estejamos falando de processadores multinucleares de 64 bits, a retrocompatibilidade, que é compromisso da Intel (e de outras fábricas), garante a existência das instruções X86 antigas. Inclusive os registradores do processador são criados de forma a serem divisíveis em partes pequenas. E a menor parte é idêntica ao registrador do já saudoso 8088. Incluindo aí, claro, sua nomenclatura. Portanto,
nenhuma tradução será necessária, apesar de
certas pessoas ignorantes e turronas teimarem em dizer o contrário, mesmo depois de eu ter provado que o processo ocorre dessa forma.
Aliás, é exatamente o processo de virtualização que deixou muitos usuários Mac contentes com a Apple, que trocou seus PowerPC pelos chips Intel. Hoje pode-se rodar um XP dentro do MacOS praticamente na mesma velocidade do sistema operacional. É óbvio que existe uma pequena perda de performance. Antigamente, ainda com os PowerPC, o XP rodava normalmente, mas só através de emulação, já que o PowerPC é RISC, incompatível com os X86. Isso, logicamente, matava a velocidade da máquina emulada.
Pra encerrar o assunto, que já se extendeu mais do que deveria: uma dica para os colegas que querem testar seus programas em diferentes versões do Windows. Eu uso o VMware, que é um excelente programa para virtualizar máquinas. Tudo roda absolutamente igual, como se meu PC tivesse sido carregado com essa versão do Windows. E é muito rápido. A perda de performance é quase imperceptível, dependendo do hardware (eu uso um Dual Core 2.8GHz com 1GB de RAM). Justamente porque o Windows virtualizado não necessita da tradução que ocorre no processo de emulação.
