sexta-feira, dezembro 08, 2006

TechEd 2006 - Dia 3

Seguem as impressões sobre as apresentações que eu assisti no terceiro e último dia (30/11/2006) do TechEd 2006.

Smart Client - Composite UI Application Block

Outra palestra bem distante do que eu faço no dia a dia, mas muito boa. O Composite UI Application Block é um dos design patterns implementados pela Microsoft e pode ser baixado gratuitamente daqui. Tirando um pouco do glamour, podemos dizer que é um conjunto de classes para facilitar o desenvolvimento de aplicações de desktop nas quais a janela principal é composta de várias partes relativamente independentes. As classes permitem dinamicamente acrescentar as partes e atualizar o menu e o toolbar. É algo apropriado principalmente para grandes projetos desenvolvidos por times.

A chuva complicou a chegada de muita gente e até um pouco antes da hora prevista só estavam na sala eu e o apresentador (Marcelo Hideaki Azuma). A palestra foi começada com apenas três ouvintes, mas foi rapidamente enchendo (para ajudar uma das palestras ao lado foi cancelada porque o apresentador não chegou a tempo).

Windows Mobile e SQL Mobile - Aumentando a Performance da sua aplicação

Esta foi a palestra que eu menos gostei. Começou com o mal sinal, com o Marcio Boaro desdenhando outras plataformas, e foi morro abaixo. Parecia existir uma divergência entre o que estava escrito no PowerPoint e o que o apresentador tinha entendido. Para tornar um pouco mais divertida a apresentação, estava na platéia o Renato Haddad e pudemos assistir algumas discussões não conclusivas.

Windows Communication Foundation: Integrando aplicações

Uma palestra razoável, mas sem grandes novidades. Uma das poucas em que estourou o tempo.

Segundo o guia do evento, esta palestra ia falar também sobre como usar a solução "pear-to-pear", mas o tempo foi insuficiente. Será que estavam se referindo a isto?

Windows Communication Foundation: Segurança e Gerenciamento com WCF

Uma palestra muito boa, mas sobre a qual estranhamento lembro pouco. Devo confessar que estava meio sonolento... O apresentador foi o Mauro Santana, cuja voz é bem conhecida de quem fez os treinamentos do Programa Cinco Estrelas do MSDN.

Compatibilidade de Aplicações com o Windows Vista

Francamente, não esperava muito desta palestra, mas foi a que mais me marcou.

É inegável que a Microsoft faz um grande esforço para manter compatibilidade entre as versões do Windows, fazendo uma grande quantidade de testes e criando uma série de "adptações técnicas" para contornar programas mal comportados. Por outro lado, algumas decisões, notadamente as relativas a segurança, criam problemas tanto para programas como para usuários.

Uma das novidades do Windows Vista é deixar acessível ao administrador a base de dados de "adaptações técnicas". Este base de dados contém dezenas (centenas?) de aplicações (identificadas por nome do executável e/ou hashes e/ou outras coisas). Para cada aplicação pode ser indicada quais "adaptações técnicas" devem ser aplicadas.

A mais simples destas adaptações é mentir a versão. O Windows Vista é o Windows 6.0; o Windows 2000 é o 5.0 e o Windows XP é o 5.1. Algumas aplicações podem se atrapalhar com isto, seja por paranóia ("Versão de Windows Desconhecida!") ou por erro de programação ("se a versão é 5.1 é XP senão é Windows 2000...").

Uma mudança radical no Windows Vista é o tratamento dado ao Administrador. Na minha opinião, a encrenca toda é consequência da origem do Windows. O Windows surgiu no PC - Personal Computer. Normalmente, quem opera o Windows se considera (com razão ou não) o dono da máquina e espera poder fazer operações que em outros ambientes são de uso restrito, como instalar programas, mudar configurações, etc. O resultado é que quando foram introduzidas proteções, os usuários passaram a trabalhar sempre como administradores. A proliferação dos virus e a retomada do controle da TI sobre os computadores nas empresas grandes e médias criou uma grande encrenca.

A solução proposta pelo Windows Vista é o User Account Control. Basicamente ele tende a rodar as aplicações sob um usuário comum, mesmo se você estiver logado como Administrador. Para rodar uma aplicação realmente como Administrador com o UAC ligado, você precisa clicar com o botão direito e escolher "Run As Administrator". Se você não fizer isto, Coisas Inesperadas poderão acontecer quanto a aplicação tentar fazer uma operação que requer direito de administrador. O Windows poderá pedir uma confirmação, recusar com erro, recusar sem erro ou fazer uma "virtualização". A "virtualização" transforma uma ação que seria global (como escrever em determinados locais do Registry ou salvar uma configuração no Windows.ini) em uma ação restrita ao usuário. É de se esperar muita encrenca e choradeira por conta disto.

Uma coisa ainda mais radical é o Windows Resource Protection. A Microsoft resolveu restringir a atualização dos "recursos protegidos do sistema operacional" (praticamente tudo que está sob o diretório Windows) aos instaladores oficiais (marcados com o certificado digital da Microsoft). Não é mais permitido a um operador ou instalador substituir, modificar ou remover um módulo do sistema. É esperado que isto quebre um monte de instaladores.

Detalhes sobre a compatibilidade de aplicações com o Windows Vista podem ser encontrados aqui.

Concluindo

Valeu a pena? Eu diria que sim, não pelo conteúdo em si (que alguma hora vai estar disponível para download), mas por obrigar a parar por dois dias e meio e olhar outras coisas (ou coisas antigas de forma diferente).

quarta-feira, dezembro 06, 2006

TechEd 2006 - Dia 2

O segundo dia do TechEd 2006 (29/11/2006) começou com uma falha imperdoável que se repetiu no dia seguinte: não foi servido café antes da primeira palestra! O coffee break entre as palestras foi muito bom (principalmente entre a primeira e a segunda do terceiro dia), mas faltou um café para dar ânimo no início do dia (principalmente para quem ainda estava de ressaca do show do dia anterior).

Nesta edição do TechEd existia um número imenso de palestras. No processo de inscrição on-line você selecionava as que pretendia ver. Embora as recepcionistas na porta das salas tivessem um computador de mão (nada menos que o meu amigo SPT-1500, que não usa sistema Windows), ele era usado apenas para registrar as presenças. O controle da inscrição era feito visualmente, conferindo a lista impressa no verso do crachá. Uma vez começada a palestra e sobrando espaço na sala, a entrada ficava livre.

Seguem as minhas impressões sobre as palestras que vi neste dia.

Windows Vista para Desenvolvedores

Apresentou uma visão geral daquilo que um dia foi chamado de WinFx e acabou batizado com o infeliz nome .NET Framework 3.0 (o que merece um comentário mais longo o dia em que eu entender direito).

Desconfio que o marketeiro que definiu o nome dos "pilares" do .NET Framework 3.0 trabalhava antes fazendo press-releases para a Bill & Melinda Gates Foundation, já que todos tem o nome Windows * Foundation, exceto pelo Windows Cardspace, escalado às pressas para substituir o WinFS que não conseguiu ser feito.

Uma palestra boa mas não notável.

Soluções para os mais comuns desafios do Desenvolvimento de Windows Forms

Um segredo não muito oculto é que a Microsoft entregou aos apresentadores as palestras prontas (título, descrição, PowerPoint, exemplos, etc) do evento internacional. Fica difícil quem viu esta palesta do Alfred Myers acreditar isto, já que ele fez um trabalho excelente de adaptação. Cada parte da apresentação era precedida por um post falso do fórum MSDN, que imitava perfeitamente os posts reais (dos nicks estranhos ao estilo do texto).

A palestra em si girou em como contornar alguns "desafios" (bugs e limitações) do Windows Forms. Embora "mais comuns" seja discutível, várias pessoas (inclusive o próprio Alfred) já os tinham enfrentado na vida real. As "soluções" variaram entre derivar uma classe do .NET Framework e substiuir pequenos detalhes a fazer um complexo hook de mensagens para conseguir descobrir quando a visibilidade de um controle muda.

Windows Presentation Foundation: Construindo aplicações ricas e conectadas

O WPF (antigo Avalon) é a parte mais visível do Windows Vista. Esta palestra pode ser resumida ao Times Reader, que é um client para apresentar offline, via WPF, conteúdo do New York Times.

Uma coisa que ficou clara nesta palestra e na próxima, é a dificuldade de integração do WPF ao que já existe (Visual Studio, Windows Forms e mesmo ao SideBar do Vista). Algo que também merece um post mais longo quando eu entender!

Windows Presentation Foundation: Como fazer gráficos 3D na minha aplicação

O Fábio Galuppo seguiu um caminho diferente do Alfred: usou o PowerPoint original, em inglês. O resultado também foi bom, principalmente com a enfase sendo dado ao código.

Quem quiser ter uma idéia de como se programa em 3D com o WPF pode dar uma olhada neste capítulo extra do livro do Petzold sobre WPF.

Melhores Práticas para Criar Web Sites Escaláveis e com Amplo Acesso a Dados

Até hoje fiz muito pouca programação para Web e certamente nada que precisasse atender a número de grande de usuários, mas o título da palestra me interessou. Eurico Brás apresentou uma palestra muito boa sobre os fatores principais para criar sites escaláveis.

Uma curiosidade foi ver a importância prática de algo que mencionei quando falei do gerenciamento de memória no Windows 32 bits. O Windows cria um espaço virtual de 4GBytes para cada processo (o máximo que pode ser endereçado com 32 bits). Deste espaço, normalmente 2G são reservados para o sistema operacional, restando 2G para a aplicação. Normalmente as várias instâncias de um site rodam dentro de um único processo. Uma forma de melhorar o desempenho e eliminar alguns gargálos é usar chaches, o que aumenta o consumo de memória. Devido ao limite de 2GBytes, normalmente não adiante colocar mais que 3GBytes de Ram em um servidor web. No Windows Server 2003 existe uma opção para reduzir o espaço reservado ao sistema para 1GByte, neste caso faz sentido aumentar a memória do servidor até 4GBytes. Mais provavelmente não vai adiantar, pelo menos enquanto não tivermos a infraestrutura ampliada para 64bits (como já foi feito no SQL Server e no Exchange).

terça-feira, dezembro 05, 2006

TechEd 2006 - Dia 1

Segundo a versão oficial, este foi o maior TechEd até agora e incluiu o lançamento da década: Microsoft Windows Vista, 2007 Microsoft Office System e Microsoft Exchange Server 2007.

O processo de inscrição não foi muito suave, como mostram os comentários abaixo:

http://forums.microsoft.com/MSDN-BR/ShowPost.aspx?PostID=722381&SiteID=21
http://forums.microsoft.com/MSDN-BR/ShowPost.aspx?PostID=767777&SiteID=21

O primeiro dia do evento (28/11/2006) foi dedicado às sessões gerais (com algo entre 1700 e 3000 pessoas, dependendo da fonte). Todas estas pessoas ficaram amontoadas no pequeno espaço fora da sala, já que ela só foi aberta no horário de início (ao som de Beautiful Day do U2 repetida seguidamente umas cinco vezes).

Assim que todos se acomodaram, teve o longo lançamento dos três produtos, com Gabriel o Pensador como mestre de cerimônias e um grupo de músicos/dançarinos fazendo performances entre as apresentações. Como parece ser regra nestes casos, o evento estava atrasado uma hora quando veio o coffee-break (que eu não vi, quando eu saí da sala parecia que uma nuvem de gafanhotos tinha passado por ali).

Depois teve uma mais curta (e mais enfadonha) apresentação sobre as comunidades MSDN e TechNet.

Por último, uma apresentação de Hans Donner do seu gadget para o SideBar do Vista, desenvolvido em conjunto com o Fábio Galuppo.

Depois foi só curtir o cocktail do lnçamento e o show do Skank.

segunda-feira, dezembro 04, 2006

Adventure - Parte II

Ao final da primeira parte, o estado-da-arte eram as aventuras ilustradas. Em 1983, a Sierra lançou o que ela chamava de "3-D Animated Adventures".

A tela ao lado mostra o primeiro jogo lançado, o King Quest, em todo o esplendor da CGA com monitor RGB.

Olhando com atenção, é possível ver o nosso personagem, que pode ser movimentado através do teclado. Para realçar o aspecto 3D, o personagem pode passar tanto na frente como atrás de alguns elementos do cenário (como a árvore à esquerda). Os cenários possuiam algumas pequenas animações (como as bandeiras do castelo) .

Os comandos para interagir com o cenário continuavam sendo digitados, porém o parser era mais simples que o usado pela Infocom, a enfase claramente era na parte gráfica.

Estas aventuras tiveram grande sucesso e acabaram criando várias séries, como King Quest, Space Quest e Leisure Suit Larry. Para quem quiser ver como era um jogo da época, existe um jogo da série Space Quest feito por um fã: The Lost Chapter. Os primeiros jogos da série King Quest foram refeitos por fãs, com gráficos e sons atuais: King Quest I, King Quest II e King Quest III.

Como as demais aventuras, estas se baseavam em um interpretador, o AGI. Posteriormente a Sierra criou um aegundo interpretador, o SCI. À medida em que a resolução e o número de cores ia aumentando, a interface foi se afastando da digitação de texto e se limitando ao point-and-click. Nos links acima existem tanto interpretadores como editores de jogos.

Um Ano de Vida

Sábado passado (2/dez) este blog completou um ano de vida! Foram 75 posts, uma quantidade bem razoável. Idéias e rascunhos de novos posts não faltam, o que tem faltado é tempo!

Segundo o StatCounter, um número razoável de pessoas esbarram neste blog, alguns até intencionalmente. Espero que tenham encontrado algo de útil!

terça-feira, novembro 21, 2006

Resultado improvável no Google

Uma das informações curiosas fornecidas pelo StatCounter é o "Come From" que mostra a página anterior. Tipicamente é uma consulta ao Google, o divertido é ver o que foi procurado e qual o ranking da minha página nos resultados.

Um fato surpreendente foi ver que apareci no topo* para a busca de testes dos setes erros que aparecem diabos . Não é tão bacana quanto ser o especialista em placenta baixa, mas deu para dar algumas risadas.

* Como tudo na Web, isto é temporário. Provavelmente esta página vai mudar o resultado.


quinta-feira, novembro 16, 2006

O Longo Adeus ao Symbol Palm Terminal

Já esperada há alguns anos, saiu finalmente a notícia do encerramento da fabricação e venda da família SPT. Ainda tenho as pastas que eu montei em 1998, quando foi anunciado o SPT-1500 e tomei contato com a plataforma Palm. De lá até uns dois anos atrás, muito do meu trabalho envolvia esta plataforma. Aliás, foi só eu começar a escrever este post para vendermos mais umas cópias de um software feito para o SPT.

A Família SPT

A Symbol é um dos principais fabricantes de leitores de código de barras (scanners) e coletores portáteis de dados. Em 98 ela teve a idéia de criar um coletor baseado no recem lançado Palm III, que estava finalmente criando a categoria de Personal Digital Assistent (PDA), após alguns fracassos notáveis como o Newton da Apple.

O SPT-1500 consistia no hardware do Palm III (a mesma placa) acrescentado de um leitor de código de barras. Embora as características de hardware pareçam modestas nos dias de hoje (processador de 16 bits operando a 8MHz, 2MBytes de Ram, baterias não recarregáveis) o SPT-1500 possuia desempenho suficiente e um bom leitor de código de barras para aplicações de coletas de dados em um formato pequeno e leve e por um preço baixo (para o mercado de coletores de dados). A principal restrição do SPT-1500 era a baixa robustez; a solução da Symbol foi uma capa de borracha especial. O SPT-1500 era atraente principalmente para os mercados mais sensíveis a preço, como o brasileiro.

No ano seguinte foi lançado o SPT-1700, que era um reprojeto do hardware para obter a robustez esperada de um coletor (resistência a quedas de até 1,2m e operação de -20 a 50 graus C). Além disso, a linha SPT-17xx incluia modelos com rádio padrão 802.11 e CDPD.

Alguns anos mais tarde o SPT-1500 e os SPT-17xx foram substituídos pelos SPT-1550 e SPT-18xx, que utilizam processadores um pouco mais rápidos e uma versão mais recente do PalmOS

A Ascenção e Queda da Plataforma Palm

Após uma tentativa mal-sucedida em conjunto com a Casio, a Palm Computing lançou em 96 os primeiros modelos, chamados de Pilot 500 e Pilot 1000. No ano seguinte foram lançados o PalmPilot Personal e o PalmPilot Professional (que dispunha de um stack TCP/IP para uso com modem). Em 98 foi lançado o Palm III (as mudanças no nome se devem a um processo da empresa Pilot que fabrica canetas).

O Palm III acrescentou uma interface infra-vermelha e foi um grande sucesso. Os motivos principais foram o formato, a resposta rápida, uma grande facilidade de operação, um reconhecimento de escrita confiável, um esquema de sincronismo com PC quase que transparente, uma imensa autonomia com baterias palito e um imensa quantidade de softwares.

A plataforma Palm usa o seu próprio sistema operacional, o PalmOS. O objetivo original era ter um sistema compacto e eficiente. Por exemplo, a função de leitura de arquivos (databases na terminologia da Palm) retorna um ponteiro para a posição da Ram onde o registro está e o código dos programas era executado diretamente na posição onde estava armazenado. A parte da memória onde ficam os databases é protegida pelo hardware, evitando que um ponteiro perdido os danifique. Aliás, o PalmOS era extremamente robusto e mensagens de erro e reset era raro para quem usava apenas as aplicações pré-instaladas (para quem desenvolvia era um pouco diferente, mas acho que nunca me ocorreu de perder um database). A maior parte das funções do PalmOS eram de manipulação da interface com o usuário. O núcleo em si do sistema foi licenciado de outra empresa. Embora este núcleo fosse multi-tarefa, o contrato impedia a Palm de expor para as aplicações as funções de manipulação de tarefas (ou seja, a aplicação era composta de uma única tarefa).

Uma das minhas surpresas ao aprender a programar para o PalmOS foi descobrir o que acontecia quando se chaveava de uma aplicação para outra: a aplicação anterior encerrava e a nova era executada. Cabia à aplicação salvar o seu contexto e restaurá-lo para dar uma experiência semelhante ao Alt Tab no Windows. Apesar disto, o chaveamento era muito rápido.

Do ponto de vista da interface com o usuário, a Palm sempre considerou que as soluções usadas no desktop não são apropriadas para os equipamentos portáteis, com telas pequenas e operados com uma caneta. Por exemplo, não existe o "duplo tap" e as aplicações (e a maioria das janelas) sempre ocupam toda a tela.

Tentando evitar a situação da Apple com o Mac, a Palm licenciou o PalmOS para outras empresas, como Sony, Samsung e Symbol. Estas empresas tinham grande liberdade para alterar a plataforma, criando produtos bastante diferenciados.

A Microsoft concorreu com a Palm desde quase o início, porém sua linha foi outra. Ao invés de um sistema compacto, investiu em um sistema mais completo que suportasse um subconjunto da API do Windows. A Microsoft especificou em detalhes a plataforma, não permitindo grandes variações entre os produtos. A primeira geração, chamada de Palm-sized PC, sofria para rodar em um processador RISC a 133MHz com 16M de Ram. Era comum você ver a tela se desenhar aos poucos. A bateria durava poucos dias. A interface com o operador tentava seguir o padrão do Windows no desktop (e até hoje se usa o "duplo tap").

Mais uma vez a Microsoft apostava suas fichas na Lei de Moore. Animada com o sucesso, a Palm acabou apostando contra. Por exemplo, a Microsoft adotou cedo as telas coloridas, a Palm insistia em que eram inúteis e que consumiam muita bateria. Em 2000 a Microsoft lançou o Pocket PC e encostou. Vieram depois o Pocket PC 2002 e o Windows Mobile. No lado do hardware veio o StrongArm e os 64M de Ram.

A Palm teve também uma história turbulenta como empresa. Antes de conseguir o sucesso com o Palm III os fundadores a venderam para a U.S. Robotics (por falta de recursos financeiros), que logo depois foi comprada pela 3Com. Embora tudo parecesse maravilhoso, os fundadores sairam da Palm para criar uma outra empresa, a Handspring, que licenciou o PalmOS e passou a competir com a Palm. Mais adiante a 3Com decidiu separar a Palm, que posteriormente se desmembrou em uma empresa de hardware e uma empresa de software (PalmSource). A empresa de hardware veio a se juntar à Handspring, com o nome de PalmOne.

Durante todas estas mudanças coorporativas, o PalmOS pouco avançou. O Palm III utilizava o PalmOS 3. A versão 4 tentou unificar os vários aperfeiçoamentos criados independentemente pelos licenciados. Pelo menos duas tentativas de criar um novo sistema fracassaram. A primeira não chegou a ser liberada e nenhuma equipamento foi produzido com a segunda. Pressionada pela falta de competitividade do processador original, a PalmSource seguiu o caminho do Mac e migrou para uma plataforma RISC emulando por software o processador original (com muito sucesso). Os equipamentos PalmOS atualmente em produção utilizam esta versão.

Finalmente, no final de 2005, a PalmSource foi comprada por uma empresa japonesa (Access). Algum tempo depois foi anunciado o fim do PalmOS como sistema operacional: os esforços agora para colocar a interface do PalmOS sobre um núcleo baseado no Linux. A PalmOne voltou a ser Palm e tem concentrado os novos desenvolvimentos em smartphones, inclusive modelos usando Windows CE.

É uma pena, pois a Palm era uma grande empresa, criou produtos inovadores e a concorrência com a Microsoft foi certamente benéfica para os usuários.

quarta-feira, novembro 08, 2006

Adventure - Parte I


Neste post vou começar a falar sobre um tipo de jogo que aprecio muito: Adventure. Este tipo de jogo é às vezes chamado de Ficção Interativa, pois o objetivo principal é contar uma história de forma interativa, com o jogador controlando um personagem.

Ao longo do post menciono varios sites onde alguns jogos podem ser baixados legalmente.

Colossal Cave Adventure - A Aventura Original

O primeiro jogo deste tipo foi criado em Fortran, em um minicomputador PDP. A história completa de porque e como este jogo foi criado pode ser encontrada aqui.

O formato usado foi o padrão por muito tempo. A interface é toda em texto, com o jogador digitando comandos, tipicamente na forma . O jogador passeia entre locais (salas no jargão dos desenvolvedores e fãs), recolhendo e usando objetos. Existe um objetivo (no caso, existem tarefas e tesouros que dão pontos ao jogador) e diversos problemas a serem resolvidos (tipicamente usando os objetos recolhidos). Concluir o jogo (isto é, resolver todos os problemas) é normalmente uma tarefa de dias ou semanas.

A Aventura Original foi migrada, adaptada, re-escrita e aperfeiçoada diversas vezes. Até mesmo a Microsoft chegou a comercializar uma versão, na época do lançamento do IBM PC. Uma adaptação direta da original, em Fortran, pode ser baixada daqui. Donald Knuth escreveu uma adaptação em C, usando um sistema de documentação a partir do fonte desenvolvida por ele; ela pode ser baixada aqui.

Adventure International - A Aventura Chega aos Micros Pessoais

Scott Adams (não confundir com o homônimo que é o autor do Dilbert) foi quem primeiro transportou este tipo de jogo para os micros pessoais. Para colocar o jogo em micros com 16K de memória (e que usavam fita cassete para armazenamento), Scott usou descrições curtas, limitou o vocabulário e, mais importante, criou um interpretador de aventuras. A aventura propriamente dita eram os dados processados pelo interpretador. Por exemplo, existiam as listas de verbos e objetos. Uma tabela relacionava combinações de verbos, objetos e condições com ações a serem executadas. Por exemplo, se o jogador digitar ACENDER FOSFORO e a DINAMITE estiver na sala atual deve ser executa da ação "perde o jogo".

No site do Scott Adams exitem links para baixar as aventuras que ele comercializou. Uma delas é a Pirate Adventure, cujo código foi publicado na revista Byte e eu penei para converter em Cobol e rodar no computador a que eu tinha acesso.

Para quem for fluente em inglês, tem uma entrevista do Scott Adams para baixar em MP3 aqui. Particularmente divertida é a parte em que ele joga uma aventura com a plateia.

Infocom - O Auge da Aventura em Texto

Pode ser surpresa, mas uma das principais empresas de jogos no começo dos micros pessoais desenvolvia apenas aventuras em texto. A história completa pode ser vista aqui e aqui. Basicamente foi um bando de amigos que pretendiam fazer um software "sério" mas que como primeiro produto resolveram lançar um jogo que tinham feito na faculdade - assim surgiu o Zork (mais especificamente Zork I, Zork II e Zork III, pois o jogo teve que ser quebrado para caber nos micros).

Os jogos da Infocom se caracterizavam por descrições longas e caprichadas e uma grande capacidade de interpretar os comandos do jogador. No lugar de , o parser aceitava frases completas. Como Scott Adams, a Infocom também utilizava um interpretador, os jogos eram escritos para uma máquina virtual chamada Z-Machine.

Uma outra característica dos jogos da Infocom foram as embalagens e complementos sofisticados. Além de ajudarem na imersão no jogo, isto dificultava e tornava menos atraente a pirataria.

Os jogos Zork I, II e III podem ser baixados aqui.

Os Fãs das Aventuras de Texto

Embora as aventuras de texto não sejam mais comercializadas, ainda existem algumas legiões de fãs na Internet. Entre as suas criações, existem ambientes para desenvolvimento de aventuras, como o Inform, e interpretadores para formatos populares como a Z-Machine e o usado por Scott Adams.

Existe até um concurso anual. Entretanto, a regra do concurso é que o jogo deve ser avaliado após jogar por duas horas, portanto são normalmente jogos curtos.

As Aventuras Ilustradas

Um recurso que surgiu bem cedo foi substituir as descrições dos locais por imagens estáticas. A Sierra (vamos falar mais sobre ela) fez várias aventuras assim para o Apple II.

Mesmo no tempo dos PCs com placas EGA e Soundblaster ainda existiam aventuras deste tipo. Uma delas é Gateway, baseada no livro de ficção científica de mesmo nome. A versão que eu tenho em casa foi baixada do site da editora (Legend Entertainment), onde o jogo estava disponível gratuitamente para download para promover a venda de uma coletânea de jogos antigos. Infelizmente, a Legend fechou e portanto o site não existe mais. O jogo pode ser encontrado em sites de Abandonware, porém a legalidade destes downloads é discutível.

Gerenciamento de Memória - Bibliografia

Aqui está a lista dos livros que consultei ao escrever os posts sobre Gerenciamento de Memória. São todos livros antigos e em inglês.

Gates - Stephen Manes e Paul Andrews - Ed Touchstone 1994
Biografia de William Henry Gates III, conhecido por todos como Bill Gates. Um livro fascinante de onde extraí não somente detalhes históricos mas também alguns detalhes técnicos. Ainda disponível na Amazon.

The 80386/387 Architecture - Stephen Morse, Eric Isaacson e Douglas Albert - Ed Wiley, 1987
Uma descrição completa do processador 386 e do co-processador 387. A Ed Campus publicou uma tradução em 1989 (o tardutor foi um tal de Daniel Quadros...)

DOS 6 A Developer's Guide - Al Williams - M&T Books, 1993
Um livro incrivelmente completo sobre o DOS, da época em que o DOS estava chegando ao final. Inclui até os fontes de um pequeno DOS Extender.

Programming Windows 3.1 - Charles Petzold - Microsoft Press, 1992
Nos tempos do Windows 16 bits, se você queria programar para Windows, tinha que ler os livros do Petzold.

Advanced Windows Third Edition - Jeffrey Richter - Microsoft Press, 1997
O complemento perfeito para os livros do Petzold sobre Win32, foca em Processos, Memória e I/O.

segunda-feira, novembro 06, 2006

DVD: Rick Wakeman The Legend (Live in Concert 2000)

Como já mencionei alguma vez, sou fã do chamado "rock progressivo". Minha juventude foi particularmente marcada pelas obras de Rick Wakeman. Além de gostar das músicas, tinha a vantagem de não expulsar o meu pai da sala :)

Dando uma olhada nas prateleiras de uma Livraria Saraiva, encontrei o DVD "Rick Wakeman The Legend" e acabei comprando. Já tinha outros DVDs dele, mas este tem algumas diferenças:
  • é um show solo, sem acompanhamento de banda (na maioria das músicas tem um discreto acompanhamento em playback);
  • embora o palco tenha vários teclados, ele se concentra em apenas um ou dois em cada música e evita os sons mais radicais (desta vez não usa o minimoog);
  • o repertório é bastante variado, incluindo alguns sucessos óbvios (extraído de As Seis Esposas de Henrique VIII, Viagem ao Centro da Terra e Mitos e Lendas do Rei Arthur), algumas músicas do Yes e algumas peças clássicas (Cannon in D e Clair de Lune); e
  • além das músicas, inclui algumas das famosas histórias que ele costuma contar durante o show. A da única vez em que ele esteve bêbado no palco é impagável!
O resultado é um show fantástico que destaca a técnica e a capacidade de interpretação de Rick Wakeman.

O DVD inclui ainda mais algumas músicas gravadas em estúdio, somente em audio.

É o melhor de tudo é que o preço é razoável (paguei R$19,90 na loja, na internet está por R$18,90 mais o frete).

Gerenciamento de Memória - Windows 32 bits

Como vimos na parte anterior, a versão 3 do Windows 16 bits finalmente levou os programas ao modo protegido dos processadores x86. Não era, porém, a única opção que a Microsoft fornecia para isto: existia também o OS/2, um gigantesco projeto conjunto com a IBM.

O desenvolvimento do OS/2 foi marcado principalmente pelas diferenças entre a Microsoft e a IBM, em termos de concepção do produto e forma de trabalhar. Esta tensão chegou ao limite após o lançamento da versão 3 do Windows, o que levou a uma separação entre as duas empresas. Esta separação deixou com a Microsoft o que a IBM chamava OS/2 3.0.

Este projeto, iniciado em 1988, era comandado por David Cutler (que tinha larga experiência no projeto de sistemas operacionais adquirida na DEC) sob o nome de NT - New Technoly. No começo de 1991, era anunciado o desenvolvimento do Windows NT e a expansão da interface de programação do Windows de 16 para 32 bits - o Win32. O Windows NT só veio a ser lançado na metade de 93 e teve um aceitação lenta (em parte por exigir a extravagância de 16 Megabytes de Ram, numa das raras ocasiões em que o preço da memória estava subindo ao invés de descer).

Uma das características do NT era a independência do processador utilizado, inicialmente o NT estava disponível não somente para o x86 mas também para processadores RISC como MIPS, Alpha e POWER. Isto influenciou algumas decisões na parte de gerenciamento de memória.

Enquanto que o Windows NT foi escrito praticamente a partir do zero, uma outra implementação do Win32 foi feita a partir do Windows 16 bits, criando o Windows 95.

Para tentar ajudar a migração aos 32 bits, existia uma "adaptação técnica" que implementava um subconjunto do Win32 sobre o Windows 16 bits - o chamado Win32s. Para os fins deste post vamos ignorar o Win32s.

O Mapa da Memória

No Win32 os recursos de gerenciamento de memória do processador são usados para dar a cada processo o seu próprio espaço de endereçamento com 4GB (é claro que a maior parte desde espaço normalmente não tem memória física associada).



No Windows 9x (95, 98 e Me), os 4GB são divididos da seguinte forma:
  • os primeiros 4M (endereços 0x00000000 a 0x003FFFFF) são reservados para o sistema operacional (DOS e Windows 16 bits) e não devem ser acessados pelas aplicações (porém apenas os primeiros 4K estão protegidos)
  • os bytes seguintes até a metade do espaço de endereçamento (0x00400000 a 0x7FFFFFFF) estão diponíveis para o processo. Esta memória é privada ao processo; outros processos não podem acesssá-la.
  • em seguida existe 1G (de 0x80000000 a 0xBFFFFFFF) de endereçamento compartilhado por todos os processos. É nesta região que são colocados os arquivos mapeados em memória e DLLs compartilhadas.
  • O último gigabyte (0xC0000000 a 0xFFFFFFFF) contém o sistema operacional e não deve ser acessado pelas aplicações (porém não está protegido e é compartilhado por todos os processos)
Portanto, embora o Windows 9x protega as aplicações entre elas, ele não protege o sistema operacional em si.

No Windows NT (e 2000 e XP), os 4GB são divididos um pouco diferente:
  • os primeiros 64K (0x00000000 a 0x0000FFFF) são inacessíveis, para facilitar a detecção de ponteiros inválidos (tipicamente com NULL).
  • de 0x00010000 a 0x7FFEFFFF (2G - 128K) fica a região privada do processo. Ela é usada para o código e dados do processo, os arquivos mapeados em memória e as DLLs.
  • os 64K no final da primeira metade (0x7FFF0000 a 0x7FFFFFFF) são inacessíveis, para facilitar a detecção de ponteiros inválidos.
  • os dois últimos gigabytes (0x80000000 a 0xFFFFFFFF) contém o sistema operacional e não podem ser acessados pela aplicação.
Portanto o Windows NT é extremamente rigoros em termos de separação entre os processos e de proteção da memória ocupada pelo sistema operacional.

Usando o Espaço de Endereçamento

Quando um processo é criado, a maior parte do seu espaço de endereçamento é marcada como livre. Uma tentativa de acessar um destes endereços causará um erro.

O primeiro passo apra usar a memória é alocar uma região usando a função VirtualAlloc. A alocação não associa memória física à região, apenas a marca como em uso. O endereço inicial da região deve ser múltiplo da granularidade de alocação (64KB) e o tamanho deve ser múltiplo do tamanho da página do mecanismo de memória virtual (o que varia conforme o processador). A função VirtualFree libera uma região.

O passo seguinte é associar memória às páginas da região (commit). O Commit é controlado no nível de página, portanto não é necessário associar todas as páginas da região de uma só vez. O commit é feito também pela VirtualAlloc; VirtualFree pode ser usada para cancelar o commit liberando a memória. A memória associda não corresponde necessáriamente a RAM física, o Win32 utiliza os recursos de memória virtual do processador para controlar a movimentação das páginas entre a Ram e o disco (arquivo de paginação), simulando uma memória Ram maior que a real se necessário.

Arquivos Mapeados na Memória

O mesmo recurso que é usado para simular uma memória Ram maior que a real, através da movimentação de páginas entre a Ram e o arquivo de paginação pode ser usado com arquivos comuns.

O resultado são arquivos mapeados em memória: do ponto de vista do programador é como se todo o arquivo tivesse sido carregado para a memória, ficando acessível via ponteiros ao invés de funções de acesso a arquivo. Isto é usado no Win32 de três formas principais:

  • para carregar e executar arquivos EXE e DLL. Desta forma a paginação do código é feita diretamente entre a Ram e o arquivo original, não envolvendo o arquivo de paginação.
  • para simplificar o acesso a dados em um arquivo. O programa manipula o arquivo através de ponteiros sem precisar se preocupar em chamar as funções de acesso a arquivo ou gerenciar buffers de leitura e escrita.
  • como forma de compartilhamento de dados e inter-comunicação entre processos rodando em uma máquina. Dois ou mais processos podem mapear em memória o mesmo arquivo, desta forma as alterações feitas por um são visíveis a todos.

segunda-feira, outubro 30, 2006

Livro do Mês: The End

Meros 12 dias após sair da Amazon, chegou em minhas mãos The End. As resenhas na Amazon tem oscilado fortemente entre os que adoraram e os que detestaram o livro.

As críticas principais tem a ver com a falta de resposta a vários mistérios e ao final inconclusivo da história. Na minha opinião, quem leu os livros anteriores não devia esperar coisa diferente. O livro "Lemony Snicket: The Unauthorized Biography" já era bem emblemático: cada capítulo tinha como título uma pergunta frequente, riscada pelo autor e substituída por uma pergunta mais estranha e misteriosa.

O livro aborda diretamente estes questionamentos. Na parte das respostas, diz que muitas respostas são irrelevantes e que toda resposta traz mais perguntas. E algumas respostas importantes estão lá, mas nunca de forma direta. Com relação a um final inconclusivo, Lemony Snicket é categórico: é impossível contar "Toda a História". Existem infinitas histórias entrelaçadas e é tolice falar em início em fim. Daí, parar a história num ponto apropriado qualquer é o melhor que se pode esperar.

A trama em si do livro é muito boa. Novamente os Bauldelaires estão em algum lugar estranho, cercados de personagens únicos. É possível enxergar vários simbolismos para os acontecimentos, com conclusões conflitantes. E tem o clímax com a morte de dois personagens (que traz mais um imenso mistério não respondido).

E assim chegamos ao fim. Ou não.

terça-feira, outubro 24, 2006

Gerenciamento de Memória - Windows 16 bits

O início da história das interfaces gráficas com o usuário (GUIs) é provavelmente o computador Alto, demonstrado pela Xerox em 1973 e nunca lançado comercialmente. O Alto, e o seu sucessor o Star, foram desenvolvidos por um centro de pesquisa da Xerox chamado PARC.

Em 1980, algumas semanas antes da Microsoft fechar as negociações do DOS com a IBM, um dos desenvolvedores da Xerox bateu na porta da Microsoft. Era Charles Simonyi, um húngaro que tinha desenvolvido o processador de textos do Alto, provavelmente o primeiro editor "WYSIYWYG". Alguns meses depois ele estava contratado como diretor de desenvolvimento de produtos avançados, se dedicando inicialmente ao desenvolvimento do tipo de aplicações que atualmente chamamos de Office (planilha eletrônica, editor de texto, etc).

As idéias da PARC corriam soltas na nascente indústria de microcomputadores. Na Apple, geraram o Lisa e depois o Mac. Na Comdex de 1982 Bill Gates levou um susto com um produto chamado VisiOn. Desenvolvido pela empresa responsável pelo VisiCalc (a primeira planilha eletrônica), o VisiOn era um pacote de aplições completo com interface gráfica, rodando no PC. A única boa notícia é que o produto ainda não estava pronto. Ao longo de 1983 diversos outros sistemas gráficos e multitarefa foram anunciados.

A resposta da Microsoft chamava-se inicialmente Interface Manager. Na Comdex de 1983 já estava rebatizado para Microsoft Windows e era objeto de uma campanha de marketing sem precedentes. Após várias mudanças de curso e uma negociação em cima da hora com a Apple, o Windows foi finalmente lançado na Comdex de 1985. Embora as primeiras notícias tenham sido favoráveis, testes mais completos revelaram um sistema lento, com suporte limitado a periféricos e com uma ausência quase total de aplicativos.

A primeira versão do Windows sofria com um processador sem a capacidade necessária, com placas de vídeo extremamente limitada e, o que aqui nos interessa mais, da falta de recursos de hardware para gerenciamento de memória.

Windows 1

Do ponto de vista visual, o Windows 1 tinha uma grande diferença em relação a todas as versões seguintes: não apresentava janelas sobrepostas.

Do ponto de vista de memória, o Windows 1 suportava apenas os até 640K de memória convencional do 8088 e 286. Entretanto, já apresentava uma série de recursos avançados:
  • Ao executar múltiplas instâncias de um mesmo programa, era usada um única cópia em memória do código e dos resources.
  • Grande parte das áreas de memória alocada através do windows podiam ser movidas, para agrupar as áreas livres criando blocos contíguos maiores ou para permitir expandir o tamanho de uma área alocada anteriormente.
  • Segmentos de código e resources eram normalmente carregados sob demanda, só sendo trazidos para memória quando necessários.
  • Os segmentos de código e resources eram normalmente descartáveis, podendo ser retirados temporariamente da memória (e posteriormente recarregados a partir do .EXE) para liberar memória.
Desta forma, o Windows 1 já era capaz de rodar "simultaneamente" vários programas que ocupavam junto mais memória que a disponível fisicamente. Entretanto, isto requeria acessos frequentes ao disco, com consequente queda de performance.

Windows 2

A principal alteração no Windows 2 foi o suporte a janelas sobrepostas e melhoramentos na parte visual (o que causou uma disputa judicial com a Apple).

Do ponto de vista de memória, a novidade foi a adição de suporte à memória expandida (LIM EMS).

A Microsoft criou também uma versão específica para o 386 (Windows386), que implementava memória expandida na memória extendida e usada o modo 8086 virtual para suportar múltiplas janelas DOS. O Windows e as aplicações continuavam rodando no modo real tanto no 286 como no 386.

Windows 3

A terceira versão finalmente suportou o modo protegido. A mágica foi feita pela iniciativa isolada de um programador, num momento em que a Microsoft estava concentrada no OS/2.

Do ponto de vista visual, o Windows 3 apresentava alguns efeitos simples de "3D".

O Program Manager e o File Manager substituiam o "MS-DOS Executive", fornecendo uma interface mais gráfica para disparar programas e manipular arquivos.

O Windows 3 era capaz de operar em três modos:
  • real mode: da mesma forma que o Windows 2, suporta o 8088 e 286/386 com pouca memória. Largamente ignorado por desenvolvedores e usuários e abandonado na versão 3.1.
  • standard mode: para máquinas com um 286 e 1M de Ram ou mais (ou máquinas com 386 e menos de 2M de Ram), usa o modo protegido do 286.
  • 386 enhanced mode: além de usar o modo protegido do 286, utiliza dois recursos do 386: paginação (para implementar memória virtual) e o modo 8086 virtual (para suportar múltiplas janelas DOS).
Organização da Memória no Windows 16 bits

A memória gerenciada pelo Windows é chamada de "memória global" ou "global heap" (global no sentido de total) e vai do ponto onde o Windows foi carregado pelo DOS até o fim da memória disponível.

O Windows 16 bits utiliza segmentos de até 64K. Cada bloco alocado da memória global é um segmento. Um programa possui um ou mais segmentos de código e um ou mais segmentos de dados. O Windows cria dois segmentos adicionais para cada um programa, um compartilhado por todas as instâncias e outro único para cada instância. Os resources são também carregados em segmentos.

Normalmente os segmentos são considerados movíveis. No modo real, quando um segmento se move, os ponteiros far (aqueles que incluem segmento e offset) precisam ser ajustados. No modo protegido, o Windows precisa apenas alterar o descritor do segmento e os ponteiros far continuam válidos. Um segmento pode ser marcado como fixo, mas isto irá atrapalhar o gerenciamento de memória, criando "buracos" na memória livre.

Para permitir a movimentação de segmentos no modo real, o Windows utiliza com frequência handles ao invés de endereços. Os handles são índices ou offsets para tabelas que contém o endereço real. Quando um segmento é movido, apenas as tabelas precisam ser atualizadas. Ao alocar memória (usando a rotina GlobalAlloc) um programa recebe um handle. Para acessar a memória, o segmento é temporariamente fixado e convertido em um endereço (usando GlobalLock), o acesso é feito e a memória é desbloqueada (usando GlobalUnlock). Para causar o mínimo impacto ao sistema, a memória deve ficar fixa somente enquanto uma mensagem de janela é tratada.

Uma outra consequência das limitações do modo real, é que um programa só pode conter inicialmente um segmento de dados movível, os demais serão fixos. Isto ocorre porque o Windows não tem como interferir com o código gerado pelo compilador para acessar dados em outros segmentos. Na prática, os programas tinham apenas um segmento de dados e criavam os outros dinamicamente (usando GlobalAlloc).

O resumo de tudo isto é que era muito complicado fazer programas no Windows 1 e 2 (ou no modo real do Windows 3) que precisassem de bastante memória.

No lado do código as coisas eram melhores, com o Windows suportando múltiplos segmentos de forma transparente (porém ao custo de desempenho). Aliás, era uma estratégia frequente quebrar programas em um número absurdo de pequenos segmentos (por exemplo, o programa Write que era incluído no Windows tinha 220K de código distribuído em 83 segmentos de código, todos movíveis e descartáveis e nenhum deles com mais de 10K). Desta forma, o Windows conseguia rodar (ou melhor, engatinhar) mesmo em um 8088 com memória bastante restrita.

A passagem para o modo protegido deixou para trás a maior parte destas preocupações. As poucas que sobraram foram embora com a passagem para os 32 bits, com o Windows NT e o Window 95.

domingo, outubro 15, 2006

Gerenciamento de Memória - Revisitando o MS-DOS

Como vimos na descrição do 8086, as primeiras versões do MS-DOS eram bastante pobres em termos de gerenciamento de memória. O DOS em si não evoluiu muito em relação a isto. Até o seu final (?), o DOS se restringiu a gerenciar de forma muito simples os primeiros 640K de Ram (o que veio a ser chamado de memória convencional).

Entretanto, muito cedo se percebeu que era errado dizer que "640K é toda a memória que alguem vai precisar" (como teria afirmado Bill Gates). O resultado foi uma série de complementos para aumentar a memória disponível para programas rodando sob o DOS.

EMS - Expanded Memory Specification

Definido em conjunto por Microsoft, Intel e Lotus*, a especificação EMS define uma forma de programas solicitarem a um driver remapear um bloco de memória no primeiro 1M de endereçamento. Tipicamente este bloco era mapeado em alguma região não usada na parte alta da memória, entre a memória da placa de vídeo e o BIOS.

Inicialmente isto era feito através de hardware especial, usando o chaveamento de bancos (que já vimos quando falamos do 8080). A partir do 386 é possível fazer um driver EMS usando os recursos de gerenciamento do processador.

* para os mais novos, a Lotus era uma das grandes empresas de software do início do PC, graças à planilha eletrônica 123. Infelizmente, seus outros produtos não tiveram muito sucesso e ela não conseguiu fazer uma transição bem sucedida para o Windows. Acabou comprada pela IBM.

Extended Memory e VDISK

A memória acima do primeiro 1M era denominada Extended Memory no tempo do DOS. A forma correta de acessar esta memória é colocando o processador no modo protegido.

Ao lançar o PC-AT a IBM forneceu os seguintes suportes à memória acima de 1M:
  • Foi incluída no BIOS uma função para informar o tamanho total da memória.
  • Foi incluída no BIOS uma função para copiar dados entre a memória convencional e a extendida. Isto era feito colocando o processador 286 no modo protegido, fazendo a cópia e gerando um reset para voltar ao modo real.
  • Junto com o PC-DOS (versão do MS-DOS customizada pela IBM) vinha um driver chamado VDISK que simulava um disco na memória acima de 1M, usando a função de cópia do BIOS.
Além dos inconvenientes do reset do processador, isto não criava uma interface padrão para vários programas compartilharem a memória acima de 1M. A solução adotada pela maioria dos programas foi alocar memória a partir dos endereços mais altos e interceptar a função do BIOS que informa o tamanho da memória para esconder a parte alocada.

HMA - High Memory Area

Como vimos quando falamos no 286, os primeiros 64K acima de 1M podem ser acessados no modo real, graças a uma pequena falha do 286 em emular o 8086.

UMB - Upper Memory Blocks

Com o 386 passou a ser possível mapear RAM para todos os espaços livres acima de 640K. Embora esta memória pudesse ser gerenciada por um driver EMS, uma outra forma era usar as funções normais de alocação do DOS, incluindo estes blocos na memória alta (UMBs) na lista de blocos gerenciados pelo DOS.

XMS - eXtended Memory Specification

A XMS fornece uma interface para coordenar o uso da memória não convencional (UMBs, HMA e Extended).

Gerenciadores de Memória

No mundo DOS, um gerenciador de memória é um device driver que usa os recursos do 386 para implementar os recursos que acabamos de ver. Inicialmente eram vendidos à parte do sistema operacional; a Microsoft o incluiu no MS-DOS a partir da versão 5.

O principal objetivo dos gerenciadores de memória era aumentar a memória livre abaixo de 1M para os programas. Alguns gerenciadores eram bastante agressivos nisto, por exemplo mapeando dinamicamente parte do BIOS para dentro ou para fora.

Á medida em que foram surgindo programas que usavam o modo protegido sob o DOS, os gerenciadores passaram a ser importantes como forma de coordenação do uso da memória, implementando a XMS.

A Microsoft utilizava dois drivers para o gerenciamento de memória no DOS e no Windows 16 bits:

  • HIMEM.SYS é responsável pelo gerenciamento em si, controlando o acesso à HMA, o controle da linha A20 de endereçamento e o uso da memória extendida. Para isto ele implementa a XMS, exceto pela parte referente aos UMBs.
  • EMM386.EXE é quem controla os recursos de mapeamento da memória do 386, podendo implementar a EMS e criar UMBs.

DOS Extenders

As soluções vistas até agora possibilitam apenas acessar em pequenas porções a memória acima de 1M. Embora sejam razoáveis para armazenar dados, são totalmente desajeitadas para código.

Uma solução melhor, e mais radical, é rodar sob o DOS uma aplicação no modo protegido. A grande complicação é que o DOS em si não pode ser rodado no modo protegido. Além disso, o DOS não consegue acessar diretamente a memória acima de 1M.

Vários sistemas foram criados para permitir isto (um exemplo muito conhecido é o Windows 16 bits). Diversas empresas se especializaram em vender bibliotecas e até compiladores para isto, os chamados DOS Extenders.

Alguns DOS Extender suportavam até o 286. Neste caso, quando as aplicações protegidas chamavam as funções do DOS, o processador precisava ser ressetado para retornar ao modo real.

Para o 386 existiam DOS Extenders com suporte a 16 e/ou 32 bits. As chamadas ao DOS podiam ser implementadas retornando o processador ao modo real ou usando o modo 8086 virtual.

Concluindo

De uma forma geral, o gerenciamento de memória sob o DOS era um conjunto de "adpatações técnicas" (tb conhecidas como "gambiarras") e o resultado era bastante instável.

No final da vida do DOS, as coisas estavam bastante complicadas. A VGA ocupava uma parte considerável da memória acima dos 640K e eram precisos drivers para as placas de som e rede e para o CD. Discos de boot (disquete com o DOS configurado de uma forma toda especial) era comum para quem gostava de jogar os jogos mais modernos (como Doom ou Duke Nuken 3D).

A vida para quem programava para Windows 16 bits não era muito melhor, como veremos na próxima parte.

quinta-feira, outubro 12, 2006

Contador de Visitas

Acrescentei ao template do blog um contador de visitas. Optei pelo StatCounter após uma olhada rápida nos contadores sugeridos pelo help do Blogger.

O motivador inicial era a curiosidade em saber se alguém visitava o blog. Confesso, entretanto, que fiquei surpreso com a quantidade de informações que podem ser obtidas do browser (veja o demo na página do StatCounter). Não é atoa que recentemente foi gerada uma versão do Firefox com o objetivo de permitir a navegação anônima.

Gerenciamento de Memória - 386


Introdução

Como vimos nas partes anteriores, o 8086 não tinha recursos para gerenciamento de memória. O 286 possuia, mas os recursos não eram usados devido às incompatibilidades com o 286. Em 1985, quando parecia que a Intel estava perdendo a batalha dos microprocessadores, foi lançado o 386 que, de uma só vez:
  • evoluiu a arquitetura x86 para 32 bits
  • aumentou a capacidade de endereçamento
  • acrescentou o recurso de paginação da memória
  • introduziu o modo 8086 virtual
Do ponto de vista prático, estas características viabilizaram sistemas multitarefa com proteção entre tarefas e memória virtual sem sacrificar a compatibilidade com o 8086 (ou com o 286).

Podemos dizer que a arquitetura de software do 386 definiu o padrão para as duas décadas seguintes.

Neste post foi falar basicamente do processador, em posts seguintes vou falar sobre o impacto do 386 no DOS e sobre o gerenciamento de memória no Windows 16 bits.

Passando dos 16 para os 32 bits

Assim como os registradores do 8086 eram uma extensão dos registradores do 8080, o 386 são uma extensão dos registradores do 8086:

O 386 pode trabalhar com operandos de 8, 16 e 32 bits. Novos modos de endereçamento foram introduzidos, permitindo em vários casos usar qualquer registrador onde antes somente alguns podiam ser usados. O processador passou a ser capaz de multiplicar automaticamente um índice por um fator de escala de 1, 2, 4 ou 8.

Por estes motivos, o 386 é capaz de operar em um modo 16 bits (com as instruções codificadas como no 8086 e 286) e num novo modo 32 bits. O modo "default" é definido pelo descritor do segmento de código (como veremos adiante), porém pode ser alterado instrução a instrução, acrescentando prefixos a ela. Isto significa que mesmo sob o DOS, rodando em 16 bits, um programa pode fazer operações de 32 bits.

Existe um prefixo para alterar o tamanho do operando. No modo 32 bits, os operandos tem 8 ou 32 bits; no modo 16 bits os operandos tem 8 ou 16 bits. Um outro prefixo controla o tamanho do endereço entre 32 e 16 bits.

O 386 continua usando registradores de segmento. Entretando, com deslocamentos de 32 bits passa a ser muito incomum precisar dividir código ou dados de um programa em vários segmentos.

Modo Protegido no 386

Como o 286, o modo 386 pode operar em modo real e em modo protegido. No modo protegido os registradores de segmentos continuam sendo índices para uma tabela de descritores. Tanto no 286 como no 386 os descritores ocupam 8 bytes, porém no 386 o endereço base e o deslocamento foram aumentados para 32 bits, aproveitando bytes não usados no 286.

O fato do formato dos descritores serem diferentes entre o 386 e 286 permite ao processador descobrir que tipo de código está no interior do segmento e utilizar o modo default de operação (32 ou 16 bits) adequado.

O 386 permite retornar do modo protegido para o modo real, mas isto é praticamente desnecessário graças ao modo 8086 virtual.

Modo 8086 Virtual

No 286, a emulação do 8086 estava restrita ao modo real, que afeta o comportamento de todas as tarefas e desliga as proteções e mapeamentos do gerenciamento de memória. O modo 8086 virtual permite ao 386 executar tarefas que emulam o 8086 dentro do ambiente protegido.

No modo 8086 virtual, os endereços são calculados como no 8086. O modo default de operação é 16 bits. O sistema operacional pode controlar que instruções críticas e quais portas de entrada e saída o programa pode utilizar. Quando o programa tenta executar um instrução proibida ou acessar uma porta bloqueada, o controle passa ao sistema operacional, que pode emular a instrução ou acesso se desejar.

Paginação da Memória

No 386 os endereços lineares obtidos tanto no modo protegido (a partir do descritor do segmento) como no modo 8086 virtual (somando o segmento multiplicado por 16 ao deslocamento) passam por mais uma etapa antes de gerarem um acesso à memória física.

Na paginação, o endereço linear é quebrado em páginas de 4K. Estas páginas são convertidas em endereços físicos através de duas tabelas:
  • Diretório de páginas: divide os 4G de endereçamento linear em 1024 grupos de página com 4M cada. A cada grupo está associado uma entrada de 32 bits que indica se o grupo está na memória e, se sim, qual o endereço da tabela de páginas correspondente.
  • Tabela de páginas: possui uma entrada de 32 bits para cada página. Esta entrada indica se a página está na memória. Se sim, indica qual o endereço físico correspondente, se ela foi acessada e se ela foi alterada. Estas duas últimas informações podem ser usadas pelo sistema operacional para otimizar o swap entre a memória e o disco. Quando a memória física ficar cheia e o sistema precisar mover uma página para o disco, pode ser implementada uma política LRU (retirar a página que foi acessada a mais tempo). Se uma página foi carregada do disco para a memória e não foi alterada, ela no precisa ser salva em disco antes de usar a memória física para outra página.
Questões Comercias e Estratégicas

Do ponto de vista técnico, o 386 foi uma ruptura comparável à passagem do 8080 ao 8086. O seu impacto, porém, não se limitou à parte técnica:
  • Para a Microsoft, o 386 viabilizou o Windows. Primeiro por fornecer a capacidade de processamento e endereçamento necessária e segundo por viabilizar a transição gradual, através das janelas DOS.
  • Para a Intel, o 386 foi o momento de se desgrudar dos demais fabricantes de chips. Até esta época era praxe um fabricante licenciar os seus projetos para os outros, criando o second source. Isto permitia ao fabricante original aumentar a capacidade de produção sem maiores investimentos e dava uma garantia adicional de fornecimento aos compradores. Por outro lado, isto reduzia o lucro do fabricante original. A Intel não licenciou o 386 para outros fabricantes. Foi somente após longos trabalhos de engenharia reversa e longas disputas judiciais que a Intel voltou a ter concorrentes na linha x86.
  • Para a IBM, o 386 aumentou o medo. Alí estava um chip que rivalizava os recursos de seus computadores (não pessoais) de pequeno e médio porte, a um preço muito inferior.
  • Para os demais fabricantes, foi o momento em que a IBM piscou. O primeiro computador com o 386 foi lançado não pela IBM mas por uma empresa mais conhecida pelos seus computadores portáteis: a Compaq. Apesar da tentativa com o PS/2, a IBM não voltou a controlar a plataforma.
Por tudo isto, existiu uma pressão muito grande a favor do 386 e contra o 286. Inicialmente o custo do 386 limitou o seu uso aos sistemas mais sofisticados. Posteriormente a Intel lançou o 386SX que utilizava memória de 16 bits (estatégia semelhante à do 8088).

quarta-feira, outubro 04, 2006

The End Is Near!

Em setembro do ano passado eu resolvi me juntar aos "infelizes" leitores de A Series of Unfortunate Events (ASoUE como costumam chamar os americanos). Para quem não conhece, é uma série de livros teoricamente infantis, recheados de humor negro e surrealismo. A série conta as desventuras de três orfãos e a trama é cheia de reviravoltas. Toda vez que você pensa que vai cair em um padrão, dá uma guinada. O visual dos livros é outra atração, simulando livros antigos.

Os livros estão disponíveis em português com uma bela apresentação gráfica, mas eu tenho pena do tradutor pois são repletos de jogos de palavras e anagramas. A começar pelos títulos que tem sempre (exceto o último) o formato "The Xxxxx Xxxxx" (The Bad Beginning, The Reptile Rom, The Wide Window, etc). Para quem for comprar na Amazon, minha dica é comprar as caixas com três livros pois conta como um volume para o cálculo do frete (os livros não relativamente curtos).

Tem também um filme, baseado nos três primeiros livros, com o quase sempre exagerado Jim Carrey. Os créditos iniciais e finais do filme são um espetáculo a parte. Vale a pena alugar.

Além dos livros da série em si, tem dois livros adicionais: "Lemony Snicket: The Unauthorized Biography" e "The Beatrice Letters" (recém lançado). Lemony Snicket é o autor do livro, que vira personagem no meio da trama. Todos os livros tem uma dedicatória macabra para "Beatrice" (por exemplo, "To Beatrice - No one could extinguish my love, or your house"). Quem exatamente são Lemony Snicket e Beatrice são alguns dos mistérios.

E mistérios não faltam. Os livros adicionais só levantam mais dúvidas, deixando desesperados os milhares de fãs.

Bem, agora a série vai terminar, no 13o livro que sairá sexta feira 13 de outubro. O livro se chama simplemente "The End". O meu já está encomendado.

Para quem quiser saber mais sobre a série, seguem alguns links:

site oficial: http://www.lemonysnicket.com (repleto de pistas sobre o novo livro)
na Wikipedia: http://en.wikipedia.org/wiki/A_Series_of_Unfortunate_Events
um site de fãs: http://www.thequietworld.com/
um message board de fãs: http://asoue.proboards11.com/index.cgi

terça-feira, outubro 03, 2006

Gerenciamento de Memória - 286, o Processador "Brain-Dead"


Como vimos nas partes anteriores, os processadores 8080 e 8086 não tinham nenhum recurso de gerenciamento de memória. Isto mudou com o processador 286 (também conhecido como 80286 e iAPX286), que acrescentou ao 8086
  • capacidade para endereçar até 16MBytes de memória física
  • endereçamento virtual de 1 GByte
  • facilidades para implementação de swap entre memória e disco
  • proteção de memória
  • níveis de privilégio
Infelizmente, embora estas características sejam bastante úteis para sistemas multi-tarefa e até tenham sido implementadas de forma elegante, elas tinham um preço muito caro no 80286: a incompatibilidade com as aplicações DOS. A principal concessão de compatibilidade no 286 consistia no real mode, modo inicial no qual ele se comportava como um 8086, sem nenhum recurso de gerenciamento de memória. Para ter acesso a estes recursos, o processador precisava ser colocado no incompatível modo protegido. Para agravar a situação, a Intel achou que o modo protegido era tão maravilhoso que ninguém iria querer sair dele; a única forma de retornar ao real mode era fazendo um reset (via hardware).

O modo protegido se baseia em mudar a interpretação dos registradores de segmento. No 8086, os registradores de segmento guardavam uma parte do endereço que era somada ao deslocamento especificado pela instrução sendo executada. No modo protegido, o registrador de segmento contém um índice para uma tabela que descreve o segmento.

Entrando um pouco mais em detalhes, no modo protegido o valor em um registrador de segmento é interpretado da seguinte forma:
  • os 13 bits mais significativos são o índice para uma tabela de descritores
  • o bit seguinte indica se é usada a tabela global (GDT) ou local (LDT). Existe ainda uma terceira tabela, para os segmentos usados no vetor de interrupções
  • os 2 bits menos significativos indicam o nível de privilégio
O endereço inicial de cada tabela de descritores é armazenado em um registrador especial (GDTR, LDTR e IDTR). Um sistema operacional pode, por exemplo, trabalhar com uma LDT para cada processo, isolando desta forma a memória acessível por cada um.

Um descritor de segmento no 286 contém:
  • o offset máximo acessível no segmento (16 bits)
  • o endereço físico inicial do segmento (24 bits)
  • um byte de controle de acesso. Este byte indica se o conteúdo do segmento pode ser executado, lido ou escrito (não é permitido ter um segmento que possa ser executado e escrito). Contém ainda um bit que indica se o segmento está presente na memória física e outro para indicar se o segmento foi acessado; estes bits podem ser usados pelo sistema operacional para controlar o swap entre disco e memória. Por último, este byte pode indicar alguns tipos especiais de segmentos/descritores.
Quem estiver curioso em saber mais detalhes, de uma olhada neste documento.

Embora o modo protegido do 286 seja um imenso avanço sobre o 8086, ele tem algumas restrições:
  • a carga de um valor nos registradores de segmento passa a ser lenta, já que envolve um acesso à tabela de descritores que está na Ram, fora do processador
  • os segmentos continuam limitados a 64KBytes
  • o swap entre disco e memória é controlado no nível de segmento
  • não suporta programas que fiquem fazendo contas com os registradores de segmentos, escrevam nos segmentos de código e executem instruções nos segmentos de dados - o que as aplicações DOS costumavam fazer.
O resultado foi que o 286 foi usado como um 8086 rápido pelos usuários do DOS (que eram a maioria). O modo protegido só viria a ser popular com o 386. Como veremos no próximo post desta série, existem vários motivos que levaram Bill Gates a ser referir ao 286 como "brain-dead".

O PC/AT, DOS, Xenix e OS/2

A IBM utilizou o 286 no terceiro micro da linha PC, o PC-AT (o PC original e o PC-XT utilizavam o 8088). Embora fosse muito mais rápido que os modelos anteriores (além de usar um clock mais rápido, o 286 executava as instruções em menos ciclos e o HD também era mais rápido) a IBM claramente segurou o desempenho com medo de atrapalhar as vendas de seus computadores maiores (por exemplo, o PC-AT original usava um clock de 6MHz apesar de os esquemas no manual de referência mencionaram 8MHz). Ao final da "era 286" a IBM tinha menos de metade do mercado (a liderança estava com "Outros") e tinha os modelos mais lentos (8MHz contra 12, 20 ou mesmo 25MHz).

O BIOS do PC/AT trabalhava quase que inteiramente no real mode. A principal exceção era uma função para copiar dados entre o primeiro 1M e o resto da memória. Esta função desabilitava as interrupções, colocava o processador no mode protegido, fazia a cópia e ressetava o processador (através do controlador de teclado). Este processo era suficientemente demorado para atrapalhar uma comunicação serial em andamento.

Junto com o PC/AT a IBM lançou a versão 3 do DOS. A principal alteração no DOS era interna, para permitir o compartilhamento de discos em rede. Entretanto, esta alteração não ficou pronta a tempo; o DOS 3.00 saiu com esta parte do código desabilitada. A versão 3.10 suportava rede porém tinha uma série de bugs que foram corrigidos na versão 3.20. O suporte do DOS ao 286 estava limitado a um driver de ramdisk capaz de usar a memória acima de 1MByte, como visto acima isto não era rápido e podia ter efeitos colaterais indesejados.

O modo protegido do 286 foi usado pelos sistemas *nix, como o Xenix. Entretanto, a ênfase dada era para sistemas multiusuários e a capacidade de um 286 era ainda baixa para isto.

Um legado do 286 foi a insistência da IBM em suportar exclusivamente o modo protegido do 286 na versão 1 do OS/2, ignorando o 386. Isto trouxe uma série de limitações ao OS/2, mesmo em relação ao Windows 3.0, dificultando ainda mais a sua aceitação.

HIMEM

Uma última curiosidade sobre o 286. No 8086 ao somar o segmento deslocado ao offset, o eventual vai-um era ignorado. No 286, que possuia mais bits de endereço físico, este vai-um ia para o bit 20 do endereço. Com medo que isto criasse uma incompatibilidade, a IBM colocou um hardware externo que normalmente forçava o bit 20 do endereço em zero. Entretanto, isto podia ser desligado por software, permitindo acessar 64K acima de 1M no real mode. Isto veio a ser usado no final da vida do 286 e do DOS, quando os 640KBytes de Ram estavam ficando muito apertados.

segunda-feira, outubro 02, 2006

Gerenciamento de Memória - 8086, 8088, o PC-IBM e o MS-DOS


Com o sucesso dos microprocessadores de 8 bits e o constante avanço da micro-eletrônica, os fabricantes partiram para projetos mais ousados.

A Motorola, por exemplo, abandonou a arquitetura de 8 bits do 6800 e desenvolveu o 68000, com 16 registradores de 32 bits de uso geral e modos usuário e supervisor para proteção do sistema operacional. A Zilog partiu para o sofisticado Z8000.

A Intel, entretanto, se mostrou bastante conservadora com o 8086. Os registradores de uso geral do 8086 (AX, BX, CS e DX) são uma expansão direta dos registradores do 8080. Inclusive, cada registrador ?X pode ser acessado como dois registrados de 8 bit, ?H e ?L.

Isto, mais alguns cuidados na definição do conjunto de instruções, permitiu a conversão automática de código fonte assembler do 8080 para o 8086. Vários programas de sucesso no CPM/80, como WordStar e Dbase II utilizaram este processo para sair na frente no lançamento do PC IBM (por outro lado, estes programas convertidos ficaram em desvantagem quando concorrentes feitos especificamente para o PC ficaram disponíveis).

Como vimos anteriormente, embora o 8080 seja um processador de 8 bits, ele possui algumas instruções para manipular 16 bits, tipicamente endereços. O 8086, entretanto, manipula quase que exclusivamente 16 bits. Isto criou um problema, pois, mesmo no final dos anos 70, era evidente que 16 bits de endereçamento (64Kbytes) era pouco. A gamb^H^H^H^B adaptação técnica (TM Rodrigo Strauss) adotada pela Intel custou muitas noites de sono para os desenvolvedores de aplicações e compiladores. As instruções normais trabalham com endereços de 16 bits, estes endereços são convertidos para 20 bits somando com o valor de registradores especiais também de 16 bits, porém deslocados de 4 bits para a esquerda. Parece confuso? É confuso mesmo.

Estes registradores especiais são chamados registradores de segmentos. O 8086 tem 4 destes registradores, chamados CS, DS, SS e ES. Por default, estes registradores são usados, respectivamente para acesso a código, dados e pilha (o registrador ES só é usado implicitamente por algumas instruções especiais). É possível (com certas restrições) usar explicitamente um registrador de segmento diferente colocando um byte de prefixo na frente da instrução.

Vamos tentar esclarecer com um exemplo. Vamos supor que os registradores BX, DS e ES contenham, respectivamente, 0x1234, 0x9000 e 0x4321 (0x indica número hexadecimal, se você não sabia disso provavelmente está no blog errado). A instrução assembler MOV AX,[BX] carrega em AX o valor na posição de memória de endereço DS*16 + BX (ou seja, 0x91234). A instrução MOV AX,ES:[BX] usa o registrador ES no lugar do DS, carregando em AX o valor na posição de memória de endereço 0x44444.

É costume no 8086 falar em endereços na forma segmento:offset, onde segmento e offset são valores de 16 bits. No nosso exemplo anterior, o endereço 0x44444 poderia ser referenciado como 0x4321:0x1234. Ou 0x4000:0x4444. Ou outras 64K-2 formas diferentes (o 8086 ignora o "vai um" quando soma o segmento deslocado com o offset, guarde esta informação para quando formos falar do 286).

O que tudo isto significa na prática? Em primeiro lugar, que o 8086 é capaz de endereçar até 1M de memória. Em segundo lugar, que uma aplicação precisa fazer uma certa ginástica para usar mais que 64K de código ou dados. No caso do código, existem o JUMP e CALL intersegmento, mas são instruções mais longas e mais demoradas. No caso de dados, para acessar uma estrutura que ocupe mais de 64K é preciso fazer umas contas medonhas. Os compiladores C para o 8086 costumam suportar alguns modelos de endereçamento:
  • Tiny: Tudo fica em um único segmento de 64K. Os quatro registradores de segmento apontam para o início do segmento no início da execução e não são mais alterados. Altamente eficiente e simples, até que o seu programa não caiba em 64K.
  • Small: Um segmento de código (apontado por CS) e um segmento de dados (apontado por DS e SS). Novamente os registradores não precisam ser alterados durante a execução.
  • Medium: Um segmento de código para cada rotina e um segmento único de dados. Cada chamada de rotina passa de 3 para 5 bytes; o seu código que não cabia por pouco em 64K agora ocupa 70K.
  • Large: Múltiplos segmentos de código e dados, mas nenhuma estrutura passa de 64K. Os registradores CS e DS mudam a toda instante, o tamanho do código cresce e o desempenho cai.
  • Huge: Múltiplos segmentos de código e dados, permite estruturas com mais de 64K. Avançar um ponteiro de dados passa a ser uma operação lenta.
Neste altura vocês devem estar achando que a Intel fez uma grande besteira. Entretanto, simplificando o processador ela simplificou o processo de fabricação, saindo na frente dos concorrentes e obtendo mais chips bons por waffer de silício e portanto chips mais baratos. Além disso, a compatibilidade parcial com o 8080 permitiu ter rapidamente uma boa oferta de software. Enquanto os outros processadores de 16 bits eram usados apenas em projetos mais sofisticados, o 8086 foi ganhando terreno. Quando a IBM foi ouvir os conselhos da Microsoft (que aliás tinha muito software para 8080 e CPM/80, a ponto de ter desenvolvido uma placa de expansão com Z80 para ter penetração no mercado Apple) a estratégia deu frutos.

Um ponto interessante no interior do 8086 é a divisão do processador em uma unidade de execução e uma unidade de acesso de memória. Esta segunda unidade é a responsável por acionar os pinos de endereçamento do chip e faz algumas coisas especiais:
  • no caso de um acesso a uma valor de 16 bits que está em um endereço impar, gera dois acessos à memória. Desta forma existe uma penalidade de tempo, mas o software é executado quase que normalmente.
  • aproveita quando a unidade de execução está processando a instrução para pegar as instruções seguintes e colocá-las numa pequena fila. Não chega a ser um cache, mas dá um pequeno ganho de performance e permite usar memórias mais lentas.
A existência da unidade de acesso à memória simplificou criar o 8088, que é identico ao 8086 porém usa uma memória de 8 bits. Do ponto de vista de software, nada muda. Do ponto de vista de hardware, o custo de um sistema simples cai, pois os chips de memória típicos eram de 16K ou 64K posições de 1 bit. Com o 8088, dava para fazer um sistema usando 8 chips de memória, com o 8086 era preciso no mínimo 16 chips.

Ao contrário do 8080, o 8086 inicia a execução no final da memória, no endereço 0xFFFF0. Novamente, isto simplifica o projeto, pois pode-se colocar uma memória não volátil no fim da memória e Ram no começo. No início da memória existe uma tabela importante o vetor de interrupções. Esta tabela contém os endereços das rotinas que tratam as interrupções de hardware e software.

O PC-IBM

Por sugestão da Microsoft, a IBM utilizou o 8088 no PC IBM. Na placa principal havia lugar para até 64K de Ram, na forma de 32 chips de 16Kx1. No PC XT eram usados chips de 64Kx1, permitindo 256K na placa mãe.

O 1M de endereçamento foi dividido em três grandes partes: os primeiros 640K (0x00000 a 0x9FFFF) para a Ram, os últimos 64K (0xF0000 a 0xFFFFF) para a memória não volátil com o BASIC e o BIOS e o resto (0xA0000 a 0xEFFFF) para uso pelas placas de expansão (notadamente a Ram das placas de vídeo em 0xB0000 e 0xB8000 e o BIOS da controladora de HD em 0xC0000).

Uma curiosidade é que o chip de DMA da Intel (responsável entre outras coisas por transferir para a memória os dados das controladoras de disco) também era limitado a 16 bits. Para endereçar toda a memória, a IBM precisou acrescentar um registrador externo de 4 bits. Isto criou uma nova barreira de 64K: não era possível ler diretamente do disco para um trecho de memória que contivesse uma mudança nos 4 bits mais significativos do endereço. O BIOS se limitava a recusar este tipo de transferências, deixando por conta do sistema operacional ou aplicação contornar esta limitação.

O BIOS possui as rotinas de iniciação do hardware e rotinas básicas de entrada e saída. A memória de 0x00000 a 0x003FF contem os vetores de interrupção, de 0x00400 a 0x004FF estão as variáveis do BIOS.

O MS-DOS

A Seattle Computer foi uma das primeiras empresas a fazer um micro usando o 8086. Entretanto o único software disponível era o BASIC da Microsoft. Cansados de esperar pelo CP/M-86, eles desenvolveram o QDOS (Quick and Dirty Operationg System). Quando a IBM também se cansou de esperar pelo CP/M-86, a Microsoft licenciou o QDOS e o ofereceu para a IBM. O resto, como dizem, é história. (Recomendo para quem quiser os detalhes o livro Gates de Stephen Manes e Paul Andrews).

Apesar das inúmeras diferenças em relação ao CP/M-80, o MS-DOS suporta uma interface de programação muito semelhante. Como vimos na parte anterior, no CP/M-80 a interface entre a aplicação e o sistema operacional é feita através de uma estrutura no início da memória. No MS-DOS esta estrutura é simulada no Prefixo de Segmento de Programa (PSP). Lá estão a linha de comando, as estruturas de acesso a arquivos (FCBs) e até mesmo a chamada ao SO. Nas versões futuras do MS-DOS algumas destas características foram perdendo importâncio, mas continuam lá e sobrevivem até no Windows.

Ao contrário do CP/M-80, o MS-DOS reside nos endereços baixos. A memória disponível para os programas começa após o final do SO (mais rigorosamente, após a parte residente do COMMAND.COM) e vai até o fim da Ram (o final da Ram é também usado pelo parte transiente do COMMAND.COM). Na versão 1 o DOS não oferecia nenhuma função de gerenciamento de memória, exceto o Terminate and Stay Resident, através da qual um programa podia encerrar deixando uma parte de si na memória (ou seja, controle de memória do DOS se limitava ao endereço ondem os programas eram carregados). A partir da versão 2, o DOS passou a oferecer funções simples de alocação de memória, colocando um pequeno prefixo no final de cada bloco alocado.

O MS-DOS suporta dois formatos de arquivos executáveis: COM e EXE.

Um arquivo COM é uma imagem binária de um programa. Esta imagem é carregada no offset 0x100 de um segmento, os registradores CS, DS, ES e SS apontam para o início do segmento e a execução é iniciada em CS:0x100. No começo do segmento é colocado o PSP. Este esquema, muito semelhante ao CP/M-80, é apropriado para programas no modelo tiny.

O arquivo EXE suporta programas com múltiplos segmentos. Para isto ele possui um cabeçalho para para acertar as referências inter-segmentos conforme o segmento em que o programa foi carregado. O PSP é criado na memória antes do primeiro segmento do programa. No início da execução, os registradores DS e ES apontam para o PSP, os registradores CS, IP, SS e SP são carregados com informações obtidas do cabeçalho do EXE.

Do ponto de vista de gerenciamento de memória, o 8086 e o MS-DOS não trazem grandes vantagens em relação ao 8080 e CP/M-80 (exceto por suportarem uma memória maior). Isto ficou para a geração seguinte. Infelizmente, o 286 seguiu na direção errada, como veremos no próximo post desta série.

Programando em C#

Como estou acostumado a programar principalmente em C, programar em C# traz algumas novidade e desafios para mim:
  • Excetos pelas variáveis numéricas, enumerações e estruturas (value types), tudo é alocado no heap gerenciado (reference types) e será liberado da memória pelo Garbage Collector. Ou seja, é um monte de X x = new X(). Para quem está acostumado a gerenciar os seus bytes um a um com muito carinho é um grande desafio de confiança.
  • No C# não existem variáveis globais e tudo tem que estar dentro de uma classe. Por exemplo, imagine que você queira criar uma rotina chamada Arredonda e uma constante chamada ValorMinimo, que você queira usar em vários lugares. Você precisa declará-los como membros estaticos de alguma classe. No C# 2005, é possível criar classes estáticas úteis justamente para este tipo de coisa.
  • Os controles geram eventos quando são alterados pelo operador ou pelo programa. Por exemplo, se você selecionar um item de um combox por programa, a rotina que trata o evento de mudança de seleção será chamada. Em alguns casos isto é muito útil mas em outros causa algumas complicações.
Como disse anteriormente um grande problema é que o framework é imenso e o help é muito sucinto. Estou toda hora procurando coisas no Google. Duas dicas das que acumulei até agora:

Pegar a versão do programa no assembly

No properties do projeto é definida a versão que será colocada no assembly. Para pegar este valor, por exemplo para o diálogo de Sobre, basta usar

Assembly.GetExecutingAssembly().GetName().Version.Major.ToString()
Assembly.GetExecutingAssembly().GetName().Version.Minor.ToString()

Usar um LinkLabel

Ainda no diálogo Sobre, imagine que você quer colocar um link para abrir a sua home page. O controle LinkLabel faz isto, se você souber usar. Coloque o LinkLabel no diálogo e altere a propriedade Text para o URL desejado (por exemplo, http://www.microsoft.com). No construtor do formulário, copie o texto para a lista de links:

linkHomepage.Links.Add(0, linkHomepage.Text.Length, linkHomepage.Text);

No evento LinkClicked, siga a receita abaixo (encontrada em http://www.peterritchie.com/Hamlet/Articles/63.aspx)

string strLink = e.Link.LinkData.ToString();
Process process = new Process();
process.StartInfo.FileName = "rundll32.exe";
process.StartInfo.Arguments = "url.dll,FileProtocolHandler " + strLink;
process.StartInfo.UseShellExecute = true;
process.Start();

A solução apresentada no help é mais simples

System.Diagnostics.Process.Start (e.Link.LinkData as string);

só que não funciona...

terça-feira, setembro 26, 2006

Gerenciamento de Memória - 8080 e CPM/80


Assistindo a palestra do Rodrigo Strauss sobre Gerenciamento de Memória no Windows, surgiu a idéia de fazer alguns posts sobre o gerenciamento no nível do microprocessador, começando lá no tempo dos 8 bits.

Como vocês provavelmente sabem, o primeiro microprocessador disponível comercialmente foi o 4004 da Intel, de 4 bits. Posteriormente a Intel criou o 8008 de 8 bits, que rapidamente evoluiu para o 8080, cujas influências estão presentes até hoje nos processadores Intel.

Quando dizemos que o 8080 é um processador de 8 bits, isto se deve principalmente a duas características:
  • a unidade lógica aritmética (ALU) faz diretamente operações com valores de 8 bits
  • a ligação com a memória utiliza 8 bits de dados
O endereçamento da memória utiliza 16 bits, permitindo endereçar diretamente até 64 Kbytes. Ao ser re-iniciado, o 8080 começa a execução sempre pelo endereço zero de memória.

A figura acima mostra os registradores do 8080. O programa counter (PC) e o stack pointer (SP) são registradores de 16 bits. Em quase todos os casos, o acumulador contém um dos operandos e recebe o resultado das operações aritméticas e lógicas.Os registradores B, C, D, E, H e L podem ser usados como registradores de uso geral de 8 bits. Entretanto, algumas instruções permitem tratar estes registradores aos pares (BC, DE e HL) para manipular valores de 16 bits. Como a ALU só consegue manipular 8 bits de cada vez, estas instruções precisam dar duas passadas pela ALU, sendo mais lentas.

Como dito, nas operações aritméticas e lógicas um dos operandos é normalmente o acumulador. O outro é um dos registradores gerais ou a posição de memória apontada pelo par HL. Em outras palavras, o registrador HL é usado principalmente como um ponteiro para a memória (endereçamento indireto).

As instruções que permitem manipular par de registradores como valores de 16 bits são:
  • LXI carrega um valor imediado num par de registradores
  • XCHG, XTHL trocam o conteúdo de HL respectivamente por DE e pelos dois bytes no topo da pilha
  • SPHL carrega SP com o valor em HL
  • LHLD carrega HL com o valor em duas posições consecutivas da memória
  • SHLD guarda em duas posições consecutivas da memória p valor em HL
  • INX e DCX respectivamente incrementam e decrementam um valor em um par de registradores
  • DAD soma BC, DE, HL ou SP a HL
O objetivo principal destas instruções é permitir manipular endereços, para implementar ponteiros, arrays e tabelas de desvios.

A rigor podemos dizer que o 8080 não possui nenhum recurso de gerenciamento de memória. O endereço determinado pelas instruções é colocado diretamente nos pinos que endereçam a memória. Não existe nenhum recurso de mapeamento, proteção ou memória virtual.

O CPM/80

O CPM/80 foi o principal sistema operacional para os computadores "sérios" de 8 bits e influenciou diretamente o MSDOS e indiretamente o Windows. (Talvez mereça um post específico no futuro).

Do ponto de vista de gerenciamente de memória, o CP/M80 era muito simples. Os primeiros 256 bytes de memória possuíam uma estrutura fixa, contendo o endereço de chamada ao sistema operacional e a linha de comando usada para executar os aplicativos (no MSDOS, esta estrutura virou o PSP - prefixo de segmento de programa). Os aplicativos em si eram sempre carregados logo em seguida (endereço 0x100); o sistema operacional em si residia no final da memória. Obviamente, o CP/M 80 suporta a execução de apenas um aplicativo de cada vez.

A chamada ao sistema era feito através de uma instrução CALL para o endereço 5. Nesta posição existia um desvio (JMP) para a primeira posição ocupada pelo CP/M, fazendo com que os endereços 6 e 7 indicassem o fim da memória disponível para o programa. Isto permitia criar um primeiro tipo de TSR (terminate and stay resident - programa que fica na memória após ter terminado do ponto de vista do sistema operacional). O programa se copiava para o fim da memória, antes do sistema operacional, colocava um JMP para o SO no seu inicio e alterava o JMP no endereço 5.

Quando armazenados em disco (em arquivos com extensão COM), os programas já estavam com os endereços reais de execução, nenhum tipo de relocação era necessária.

Ultrapassando a barreira dos 64K

De uma forma geral os aplicativos e o CP/M 80 não tinham suporte para nenhum esquema que aumentasse a capacidade de endereçamento do 8080. Este aumento exigia um hardware adicional externo ao processador para selecionar entre diversas regiões de memória que compartilham o mesmo endereço do processador. Esta técnica é chamada de chaveamento de memória.

O chaveamento de memória no CP/M 80 era usado na parte específica do equipamento, já então chamada de BIOS. No mínimo precisa ser usada para a carga do sistema operacional, mapeando uma memória não volátil no endereço zero (onde inicia a execução do 8080 e onde posteriormente é preciso ter RAM). Outra opção comum era "esconder" as rotinas de manipulação do hardware, reduzindo o BIOS e liberando mais memória para o aplicativo.

Outros processadores de 8 bits

Alguns funcionários da Intel saíram para fundar uma nova empresa, a Zilog, que lançou uma versão muito aprimorada do 8080, o Z80. Além de ser mais rápido, o Z80 possuiu várias instruções adicionais, principalmente fornecendo formas mais flexíveis de endereçamento da memória. Entretanto, os recursos de gerenciamento de memória continuaram inexistentes. O CP/M 80 e os aplicativos que rodavam sob ele não usavam as instruções adicionais, tratando o Z80 da mesma forma que um 8080.

Posteriormente a Intel lançou o 8085 que tinha apenas pequenos avanços em relação ao 8080.

Outro processador de 8 bits popular na época era o 6502 (usado no Apple I e Apple II). O conjunto de registradores e instruções do 6502 era completamente diferente, valorizando o acesso indireto à memória. O Apple II usava extensamente a técnica de chaveamento de memória, inicialmente para as rotinas de tratamento das placas nos slots e posteriormente para aumento da capacidade gráfica e da memória disponível.