TechTudo

Na coluna anterior vimos como obter, instalar e criar uma conta (que, como veremos adiante, se a capacidade de armazenamento desejada não ultrapassar os 2 GB, será gratuita) no sítio do programa Dropbox. Vimos ainda que, ao fazê-lo, são criadas duas pastas “Dropbox”, uma no computador em que o programa foi instalado e a conta acabou de ser criada e a segunda, um espelho exato da primeira, nos servidores da empresa Dropbox, ou seja, “na nuvem”. E que cada alteração que se faça na pasta armazenada no computador, como criar, editar, mover ou remover um arquivo, será imediatamente refletida na que reside na nuvem.

Figura 1: Pasta Dropbox

Mais ainda: vimos que, criada a conta em um computador, o programa Dropbox pode ser instalado em mais quantos se queira, ou em dispositivos portáteis de limitada capacidade de armazenamento (como telefones espertos e tabletes). E que as pastas Dropbox criadas nos primeiros, de maior capacidade de armazenamento, refletem tanto a estrutura quanto o conteúdo da pasta mantida na nuvem, enquanto que as criadas nos últimos armazenam a estrutura da pasta porém, devido à necessidade de preservar o limitado espaço de armazenamento destes dispositivos, contêm apenas ponteiros para os arquivos.

Finalmente, vimos ainda que os arquivos e pastas de qualquer pasta Dropbox podem ser gerenciados (ou seja, criados, editados, movidos e removidos) diretamente no computador em que residem. E que, caso este computador disponha de uma conexão ativa à Internet, as alterações serão imediatamente sincronizadas com a pasta contida na nuvem e, dela, replicadas em todas as demais pastas Dropbox ligadas à conta daquele usuário assim que o dispositivo onde reside cada uma delas se conectar à Internet.

Uma importante consequência disto é que, nos computadores, os arquivos podem ser criados, abertos, movidos, removidos e editados diretamente em suas pastas Dropbox independentemente de haver ou não uma conexão ativa à Internet. Se houver, a sincronização com a pasta da nuvem será feita assim que o arquivo for fechado. Se não houver, o sistema aguardará até que a Internet esteja novamente acessível e então fará automaticamente a sincronização, independentemente da ação do usuário. Já no caso dos dispositivos de limitada capacidade de armazenamento onde a pasta Dropbox armazena apenas ponteiros para os arquivos, uma conexão ativa é indispensável para consultar ou alterar um destes arquivos, pois não estando armazenado no dispositivo, terá que ser transferido da nuvem para ele. E, da mesma forma, ao ser fechado, a sincronização somente poderá ser feita se houver uma conexão à Internet disponível.

Como resultado disto qualquer arquivo pode ser editado de qualquer computador ou dispositivo portátil e as alterações serão replicadas em todos os demais.

Vejamos um exemplo prático e real: eu instalei o programa Dropbox em todo meu arsenal computacional, a saber: três computadores fixos (dois deles na rede de casa e um no escritório), dois móveis (meus “notebook” e “netbook”) e dois portáteis (meu telefone Nexus S e meu tablete Galaxy Tab). Com isto, além da pasta Dropbox residente na nuvem, tenho mais sete nos dispositivos mencionados. As cópias mantidas em meus computadores principais de trabalho, um em casa e outro no escritório, estão sempre sincronizadas, já que os mantenho permanentemente ligados e conectados à Internet por conexões de alta taxa (“banda larga”). No computador auxiliar de casa, ligado somente quando preciso dele, sua pasta Dropbox é sincronizada através da conexão permanente à Internet apenas quando o ligo. Já os móveis (“notebook” e “netbook”), também mantêm cópias integrais da pasta, porém só efetuam a sincronização quando estabelecem uma conexão à Internet. Finalmente os portáteis (telefone e tablete), mantêm cópias sempre sincronizadas (ambos dispõem de conexão permanente à Internet padrão 3G), porém contendo apenas ponteiros para os arquivos.

Assim, eu posso começar a escrever uma coluna no computador de casa, interromper a edição, gravar o arquivo na pasta Dropbox deste computador, seguir para o escritório, acessar a pasta Dropbox do computador de lá – que, como visto acima, está sempre sincronizada – abrir o mesmo arquivo e continuar a edição do ponto em que parei. Se não houver tempo para terminar o texto, posso gravar o arquivo na pasta Dropbox do computador do escritório, que será imediatamente sincronizada com a da nuvem. Caso eu siga para um local onde exista uma conexão WiFi ativa e acessível, posso ligar meu “notebook”, conectá-lo à Internet via WiFi, aguardar alguns momentos até que sua própria pasta Dropbox seja sincronizada (na próxima coluna veremos como ter certeza que a sincronização foi feita) e abrir o mesmo arquivo no qual estava trabalhando para continuar a edição. Ao terminar o texto, gravarei o arquivo na pasta Dropbox do “notebook” que, se ainda estiver conectado à Internet, efetuará imediatamente a sincronização com a da nuvem de onde o arquivo, já pronto, será replicado em todas as pastas Dropbox de todos os dispositivos onde instalei o Dropbox e cadastrei minha conta.

Como se vê, usando o Dropbox, posso iniciar a edição de um arquivo em um local, interrompê-la e prosseguir de diferentes locais e distintos computadores. O importante é ter em mente que não estarei editando o mesmo arquivo, mas diversos exemplares dele (que, tomadas os cuidados e providências devidos, serão idênticos), cada um armazenado na pasta Dropbox do dispositivo em que eu estiver trabalhando naquele momento. E, para que o procedimento alcance o fim almejado (ou seja, dar continuidade ao trabalho no mesmo arquivo em diferentes locais), é importante estar seguro que o exemplar no qual estou trabalhando em um dado momento é uma cópia exata daquele no qual eu estive trabalhando antes e gravei em outro local, ou seja, que os exemplares estão sincronizados.

Mas como eu posso ter certeza disto?

Bem, o próprio Dropbox se encarrega de avisar.

Veremos como na próxima coluna.

Até lá.

B. Piropo

Na coluna anterior vimos um tipo de acesso remoto baseado em armazenamento incorporado à rede (NAS, de “Network Attached Storage”) no qual os arquivos permanecem armazenados em um dispositivo físico de propriedade do usuário, conectado diretamente à sua rede (doméstica ou de pequena empresa) e cujo acesso é feito através da Internet (exceto pelos computadores ligados fisicamente à mesma rede onde o NAS está conectado). No caso examinado, o dispositivo foi um iX2 da Iomega, que traz com ele o software necessário para gerenciar o acesso remoto via Internet através de uma técnica que a Iomega denominou de “nuvem pessoal”.

Hoje veremos uma forma alternativa de acesso remoto a arquivos. Também é baseada naquilo que se convencionou chamar de “acesso em nuvem”. Porém, neste caso, diferentemente da tecnologia usada pela nuvem pessoal da Iomega, uma cópia dos arquivos permanece no(s) computador(es) remoto(s). Trata-se, então, de um tipo de armazenamento misto baseado em uma forma de prestação de serviços onde uma empresa oferece seus servidores, localizados fisicamente não se sabe (nem importa) onde para armazenar cópias dos arquivos dos usuários que poderão ter acesso a eles seja diretamente em seus computadores, seja através da Internet. O serviço é oferecido pela empresa DropBox.

No Brasil, que eu saiba, o Dropbox não é muito popular. Na verdade, segundo estimativas recentes, seu número total de usuários em todo o mundo alcança apenas 50 milhões. Estranhou um “apenas” precedendo uma cifra da ordem de dezenas de milhões? É que, considerando a utilidade do serviço prestado pelo Dropbox, 50 milhões é quase nada.

Dropbox é um serviço de hospedagem de arquivos baseado na Internet que usa a nuvem para permitir que os usuários cadastrados (ou seja, os que criaram sua conta Dropbox) armazenem e compartilhem arquivos e pastas com sincronização de arquivos.

O ponto mais importante do parágrafo anterior talvez não tenha chamado devidamente sua atenção, portanto é conveniente ressaltá-lo: a expressão “com sincronização de arquivos”. Isto porque, ao contrário da maioria de seus concorrentes como o Google com seu GoogleDocs, ou a MS com o Windows Live SkyDrive (cujos arquivos são armazenados exclusivamente em seus servidores, ou “na nuvem”), o que o Dropbox armazena “na nuvem” é uma cópia dos arquivos. Os originais permanecem nos dispositivos de armazenamento do computador do usuário, mais especificamente em uma pasta denominada “Dropbox”. Quando se deseja mover, remover, acrescentar ou editar um destes arquivos, isto é feito nesta pasta, que pode ser aberta como se fosse uma pasta comum no próprio Windows Explorer (isto partindo-se do princípio que o usuário esteja trabalhando com Windows; mas Dropbox é compatível com todos os sistemas operacionais de uso corrente, inclusive Linux, MacOS, Android, Windows Phone e iOS). A grande sacada é que, havendo uma conexão Internet disponível e ativa, todas as alterações feitas na pasta Dropbox do computador do usuário serão imediatamente refletidas na pasta Dropbox correspondente “na nuvem”, armazenada nos servidores do Dropbox. Ou seja: todas as pastas Dropbox de um usuário são automaticamente sincronizadas e tudo isto é feito de forma transparente, sem qualquer interferência deste usuário.

Até agora, aparentemente, o Dropbox serve apenas para criar uma cópia adicional (que funciona como cópia de segurança) de todos os arquivos armazenados na pasta Dropbox do computador do usuário.

E de fato, serve para isto. O que, diga-se de passagem, não é uma serventia desprezível. Mas este é o aspecto menos importante.

O mais importante é que, tendo o usuário aberto sua conta (o que, dependendo da capacidade de armazenamento desejada, pode ser feito gratuitamente, como veremos adiante), o programa Dropbox pode ser instalado simultaneamente em tantos computadores e dispositivos portáteis (como tabletes e telefones espertos) quantos se queira, sejam quais forem seus sistemas operacionais. E em cada um deles é criada uma pasta Dropbox, sincronizada com a mantida nos servidores da empresa. Vejamos isto com mais detalhes.

Figura 1: página de abertura do sítio da Dropbox

A instalação do Dropbox é feita executando-se o arquivo “Dropboxnnn.exe” (onde “nnn” corresponde ao número da versão) baixado diretamente do sítio da empresa clicando no botão “Download Dropbox” (veja figura; e, se você pretende baixar o programa e é versado em inglês, sugiro dar uma espiada no vídeo oferecido).

Na primeira instalação é necessário criar uma conta fornecendo alguns dados pessoais e escolhendo seu tipo entre “Basic” (gratuita, com capacidade de 2 GB), “Pro 50” (US$ 9,99/mês ou US$ 99,00/ano com capacidade de 50 GB) e “Pro 100” (US$ 19,99/mês ou US$ 199/ano com capacidade de 100 GB). Há ainda a modalidade “Teams” para criação de grupos de trabalho colaborativo, com capacidades maiores e administração centralizada, mas nosso foco aqui é o usuário doméstico.

Nas instalações subsequentes basta efetuar o registro (“login”) fornecendo identidade de usuário e senha.

Em qualquer caso, a pasta Dropbox é criada na unidade de armazenamento do computador onde o programa foi instalado, seu conteúdo sincronizado com a pasta correspondente no servidor da Dropbox e seu ícone exibido na Área de Trabalho.

Ao ser instalado em uma máquina dotada de razoável capacidade de armazenamento, como um computador de mesa ou móvel tipo “notebook” ou “netbook” com disco rígido ou SSD, a sincronização é completa: a pasta Dropbox criada na máquina replica exatamente a existente nos servidores da empresa tanto em estrutura quanto em conteúdo. E a partir de então toda atividade exercida em uma destas duas pastas (criação, edição, movimentação e remoção de arquivos e pastas) é refletida na outra e sincronizada com as demais. A sincronização é automática e só depende de haver uma conexão ativa à Internet.

Já nos dispositivos portáteis de pequena capacidade de armazenamento, como telefones e tabletes, é criada apenas a estrutura da pasta Dropbox que, para não desperdiçar o precioso espaço de armazenamento destes pequenos dispositivos, conterá apenas ponteiros para os arquivos, não os próprios arquivos. Mas se o dispositivo for capaz de exibir ou editar o arquivo, basta solicitar sua abertura para que ele seja imediatamente baixado via Internet (cuja conexão deve estar ativa, naturalmente) e posto à disposição do usuário. Que, após consultá-lo e, eventualmente, editá-lo, deve fechá-lo para que a sincronização seja efetuada e o arquivo descarregado da memória do dispositivo portátil, deixando livre seu espaço de armazenamento.

O resultado disto é que cada computador conterá uma pasta Dropbox com todos os seus arquivos e cada dispositivo portátil conterá a estrutura da pasta Dropbox com ponteiros para todos os arquivos. Cada uma destas pastas, quando sincronizada (e basta que o computador que a contém se conecte à Internet para que a sincronização seja feita), refletirá exatamente o conteúdo da pasta Dropbox armazenada na nuvem.

Na próxima coluna veremos como usar tudo isto em nosso benefício e como compartilhar arquivos com segurança.

Até lá.

B.Piropo

Eu não tenho “um trabalho”, como a maioria das pessoas. Tenho vários. Pois, além daquele trabalho diário que todos temos e cuja jornada é cumprida no chamado “horário normal de expediente”, tenho outras ocupações que se entrelaçam, como escrever quatro colunas semanais publicadas regularmente em diferentes meios de comunicação (esta é uma delas), dar aulas em duas diferentes universidades e manter tudo isto mais ou menos organizado no Sítio do Piropo. Dá um trabalho danado, naturalmente. Mas compensa. Não financeiramente, é claro. Escrever e dar aulas não são propriamente as formas mais garantidas de ficar rico, mas há recompensas melhores e mais importantes que dinheiro, como o brilho nos olhos de um aluno que acabou de entender um conceito particularmente difícil graças a uma boa explicação ou um comentário destes que se lê com prazer no pé de uma coluna.

Assim, parte do meu trabalho é feita em casa, parte no escritório e parte seja lá onde eu estiver no momento em que dispuser de um computador móvel conectado e do tempo necessário para fazer algo de útil.

O problema é que dispor do computador não basta. É preciso, também, acesso aos arquivos. E, o que é mais importante, acesso aos mesmos arquivos exatamente no estado em que estavam no momento em que os gravei pela última vez. E isto, naturalmente, deve ocorrer independentemente do lugar onde eu esteja e do computador que estiver usando. Pois não são poucas as vezes em que começo a escrever um texto em um computador, continuo em outro e faço a revisão e postagem em um terceiro. E esta é quase a regra, não a exceção.

A primeira tentativa bem sucedida de resolver o problema foi criar uma nuvem pessoal.

Já falei sobre o assunto aqui mesmo há pouco menos de um ano, na coluna “Nuvem pessoal”.  O conceito é simples: se você mantém uma pequena rede em casa ou no escritório e esta rede está permanentemente conectada à Internet por uma conexão via cabo ou ADSL (por exemplo: no Rio, Velox, em São Paulo, Speedy), pode comprar e configurar um dispositivo de armazenamento concebido para ser conectado a uma rede (um “NAS”, de “Network Attached Storage”) que venha com o software necessário para “criar uma nuvem” (ou seja, armazenar arquivos e administrar sua distribuição e acesso pela Internet). O que eu uso (e recomendo) é o iX2 da Iomega, que cria e administra aquilo que a Iomega batizou de “nuvem pessoal”, permitindo acesso aos arquivos que armazena através de qualquer computador conectado à Internet e registrado na tal “nuvem pessoal”, desde que o roteador da rede à qual o NAS está conectado esteja ligado e sua conexão à Internet permaneça ativa.

O assunto é extraordinariamente interessante e poderei abordá-lo em detalhes caso vocês, leitores, manifestem interesse (se for o caso, façam isto na seção de comentários à coluna). Mas como nesta pequena série de colunas o objetivo é descrever formas diversas de acesso remoto a arquivos, hoje seremos sucintos.

O conceito de “nuvem pessoal” da Iomega é simples. Vou usar meu próprio caso como exemplo para facilitar o entendimento. Em minha casa, ligado à minha rede doméstica, tenho um NAS da Iomega modelo iX2 onde criei pastas nas quais armazeno meus arquivos. Todo e qualquer arquivo de dados criado em qualquer dos computadores da rede é armazenado no NAS, não nas unidades de disco dos próprios computadores. O que não é problema, pois como o NAS está conectado à rede, todos os arquivos nele armazenados podem ser acessados por qualquer computador da rede, desde que o usuário disponha de privilégios para acessá-los (o direito ao acesso é gerenciado pelo administrador da rede).

Isto, naturalmente, não é uma nuvem pessoal, é apenas a base na qual ela se assentará.

A nuvem pessoal será criada pelo administrador da rede usando o software de gerenciamento do iX2 e seguindo os procedimentos devidos e indicados pela Iomega.

Criada a nuvem, basta enviar convites via Internet para os computadores remotos que dela participarão.

É claro que o procedimento é cercado de toda segurança, como esperado, mas o resultado final é o seguinte: cada computador remoto que receber um convite para se integrar à nuvem pessoal pode baixar o software de gerenciamento diretamente do sítio da Iomega e, após instalá-lo, usá-lo para se inserir na nuvem com toda a segurança. E todo computador inserido na nuvem pode acessar remotamente os arquivos armazenados no NAS de forma simples e direta, já que as pastas criadas no NAS podem ser mapeadas como unidades adicionais no gerenciador de arquivos do computador remoto (no caso de Windows, o Windows Explorer).

Figura 1: Pastas da nuvem pessoal mapeadas em um computador remoto

Veja, na Figura 1, um exemplo ilustrativo que mostra uma janela do Windows Explorer do computador “AUXILIAR”, ligado à rede do escritório, no qual estou trabalhando no momento. No painel da esquerda, as unidades “SYSTEMDISK (C:)” e “DADOS_Part (D:)” são efetivamente as unidades de disco “C:” e “D:” do computador, onde residem os arquivos de sistema e os executáveis dos programas aqui instalados. Mas todas as demais unidades que aparecem listadas em “Computador” cujo nome inicia com “BP” na verdade são o resultado do mapeamento de pastas que se aninham no dispositivo NAS, ligado fisicamente à minha rede doméstica. É neles que residem os arquivos de dados que crio quando trabalho em casa (ou em qualquer outro lugar, como já veremos).

Mas basta um clique no painel esquerdo sobre o nome de uma das unidades mapeadas para que o painel direito mostre seu conteúdo: pastas e arquivos, que podem ser acessados mediante mais um clique. Ou seja: os arquivos aparecem como se estivessem armazenados em unidades de disco conectadas diretamente a este computador do escritório em cujo teclado estou batucando no momento, quando na verdade se situam fisicamente em uma unidade de armazenamento da minha rede doméstica, distante mais de trinta quilômetros daqui.

Este arquivo no qual estou trabalhando agora poderia ter sido iniciado ontem, em casa, e gravado ainda inacabado em uma das pastas da unidade NAS. E eu poderia, ao chegar ao escritório hoje pela manhã, ligar a máquina na qual estou trabalhando, conectá-la à Internet, me registrar na minha nuvem pessoal, acessar daqui a mesma pasta onde gravei o arquivo, abri-lo e prosseguir em sua edição. Mais tarde, interrompê-la ainda inacabado, gravar a nova versão do arquivo na mesma pasta, seguir para um compromisso no Centro do Rio e, de lá, usar meu computador móvel tipo “notebook” (previamente convidado para fazer parte de minha nuvem pessoal e já nela inserido), conectar-me à Internet através da rede sem fio, digamos, de um destes cafés que também servem Internet, entrar na minha nuvem, abrir o mesmo arquivo (sempre gravado no NAS da rede doméstica), continuar sua edição e, por fim, gravá-lo em seu formato definitivo na mesma pasta da mesma unidade do NAS.

Em resumo: o arquivo permanece gravado no mesmo local, na minha unidade de armazenamento em rede da minha rede doméstica, permanentemente conectada à Internet. Eu posso ter acesso a ele, alterá-lo e regravá-lo ali mesmo seja de onde eu estiver, desde que use para isto um computador previamente inserido na minha nuvem pessoal.

Parece uma maravilha, pois não?

E é mesmo. A solução é excelente. Particularmente quando você se der conta que, como administrador do iX2, pode conceder a terceiros, seletivamente, acesso a uma ou mais pastas de sua nuvem pessoal. Desta forma, pessoas que fazem parte de sua equipe podem ter acesso imediato aos arquivos de um determinado projeto, sempre em sua versão mais atual, e caso lhe tenham sido concedidos os privilégios para tanto, modifica-los e regravá-los no mesmo local.

Mas é claro que, por mais extraordinariamente útil que seja, a rede pessoal não é perfeita e tem lá seus inconvenientes. Dos quais o principal é exigir que o computador no qual se pretende abrir um determinado arquivo armazenado na nuvem esteja conectado à Internet no momento em que se precisa fazer o acesso.

Na próxima coluna veremos uma solução alternativa que contorna esta dificuldade (mas, naturalmente, apresentará outras).

Até lá.

B. Piropo

Na coluna anterior descrevemos superficialmente o Windows Defender Offline, um programa oferecido gratuitamente pela Microsoft (ainda em versão beta, porém inteiramente funcional) que executa com notável eficiência a difícil tarefa de localizar, identificar e extirpar programas mal intencionados do tipo “rootkit” de máquinas por eles contaminadas.

E prometemos que nesta discutiríamos os detalhes sobre como obter, instalar e usar o programa.

Então, mãos à obra.

O primeiro passo, naturalmente, é baixar o programa da página correspondente do sítio da Microsoft (como logo se verá, o que se baixará não será o programa, mas uma ferramenta capaz de montá-lo em uma mídia removível, juntamente com o sistema operacional que carrega com ele).

Para isto, usando uma máquina que você tenha certeza que não está contaminada com o “rootkit” e que disponha de uma conexão com a Internet, vá até a página acima citada, procure a versão do WDO correspondente ao Windows instalado na máquina a ser examinada, clique no botão “Download…”, baixe o arquivo e rode-o para criar um dispositivo (CD, DVD ou disco de memória tipo “flash”) contendo o WDO e capaz de inicializar a máquina.

Complicou? Calma que eu explico.

Primeiro, um ponto importante: quando me refiro “ao Windows instalado na máquina a ser examinada” quero deixar claro que não se trata da versão de Windows (ou seja, Windows XP, Windows 7 ou Windows Vista, por exemplo), mas ao fato de se tratar de uma versão “de 32 bits” (ou x86) ou “de 64 bits” (ou x64). E se você quer saber que versão roda na máquina que pretende examinar, ligue-a, vá ao Menu Iniciar, clique com o botão direito em “Computador”, selecione a entrada “Propriedades” e, no grupo “Sistema”, verifique o que consta em “Tipo de sistema”: de 32 ou de 64 bits. É toda a informação necessária para identificar a versão do WDO que deverá ser baixada. Escolha a correspondente à versão da máquina que pretende verificar, baixe e execute o arquivo “Mssstool32.Exe” se o Windows nela instalado for “de 32 bits” ou “Mssstool64.Exe” se for “de 64 bits”.

Figura 1: Janela de instalação

Ao ser executado, o arquivo abrirá uma janela semelhante à da figura 1. Segundo a MS, trata-se ainda de uma versão beta e talvez por isto só esteja disponível a interface em inglês. Mas não se preocupe que tudo é muito simples e as mensagens que se sucedem são essencialmente as mesmas aqui discutidas. E, como acima mencionado, este programa ainda não é o WDO, é apenas a ferramenta que será usada para montar um dispositivo de inicialização que conterá o banco de dados de assinaturas, o próprio WDO e o sistema operacional que o carregará .

Grande parte do material necessário para efetuar esta montagem será baixado da Internet. Portanto é essencial que mesmo depois que a ferramenta tenha sido transferida, a máquina permaneça conectada à rede enquanto monta o dispositivo.

A janela 1 é apenas de boas vindas. Nela, clique no botão “Next” e você passará para a seguinte, onde escolherá o meio de armazenamento no qual o WDO e seu SO serão instalados, mostrada na Figura 2.

Figura 2: escolha do meio de instalação

Agora você terá que decidir onde gravar seu WDO. A terceira opção grava uma imagem ISO do disco com o programa, banco de dados e SO é apenas lhe interessará se você desejar criar múltiplas cópias do disco sem ter que passar por todo este procedimento novamente. Mas eu presumo que a grande maioria dos usuários escolherá uma das duas primeiras.

A primeira gravará o WDO em um disco ótico, CD ou DVD inicializável. A segunda fará o mesmo em um disco de memória tipo “flash” USB (“pen-drive”). Qual escolher?

Bem, se a máquina a ser inspecionada não dispuser de um drive de disco ótico (a maioria dos portáteis com fator de forma “netbook” não dispõe) você terá que escolher a segunda e usar um “pen-drive”. Mas, se optar por ela leve em conta que: 1) o “pen-drive” deve ter uma capacidade maior que 250 MB e será formatado no processo, portanto todo seu conteúdo será perdido; e 2) a máquina onde ele será usado deverá dispor de um ajuste no “setup” que permita inicializa-la a partir de um “pen-drive” conectado a uma entrada USB.

Já se você se decidir por um disco ótico, basta que a máquina possa ser ajustada para ser inicializada a partir do acionador de discos óticos (CD ou DVD). Mas note que, seja qual for a mídia escolhida, considerando que o WDO traz com ele o próprio sistema operacional, é essencial que a máquina possa ser ajustada para carregar o sistema a partir da mídia que você está se preparando para criar.

Escolhida a mídia, insira-a no local apropriado, marque a opção correspondente (a primeira, para CD ou DVD, a segunda para “pen drive”), clique em “Next” e seja paciente, porque o processo de criação é demorado, principalmente se sua conexão com a Internet não for muito rápida. Ao final você se verá diante da janela da Figura 3.

Figura 3: tela de “Instalação completa”.

Sua mídia inicializável contendo o WDO está instalada e o programa pronto para ser usado. Clique no botão “Finish” para fechar a janela, remova a mídia da máquina onde foi criada e vamos usá-la na máquina suspeita de contaminação.

O primeiro passo, durante o processo de inicialização desta máquina, é ter acesso aos ajustes do “setup” para fazer com que ela procure o sistema operacional na mídia que você acabou de montar com o WDO (“pen-drive” conectado a uma porta USB ou disco ótico inserido no respectivo acionador). Como fazer isto varia de máquina para máquina. Se você não souber como fazê-lo na máquina onde pretende rodar o WDO talvez consiga alguma orientação (para este e para diversos outros problemas que podem ocorrer durante o uso do WDO) na página de respostas a perguntas frequentes sobre o WDO – infelizmente, apenas em inglês.

Feito o ajuste no “setup” para garantir que o sistema operacional seja carregado da mídia onde está o WDO, basta inseri-la no local adequado (porta USB ou acionador de discos óticos) e reinicializar a máquina. Se tudo correu bem, em vez de carregar o Windows instalado na máquina ela carregará a versão contida na mídia removível.

Terminada a carga você se deparará com uma tela com o aspecto da Figura 4 (e, neste ponto, cabe uma explicação: ao contrário das demais figuras que foram obtidas com o excelente programa de captura de telas ScreenShot Pilot, gratuito, a Figura 4 e as duas seguintes foram obtidas fotografando a tela de um computador portátil pois, como o WDO roda sobre sua própria versão de sistema operacional, não há como carregar programas adicionais enquanto ele se assenhora da máquina; portanto ficam aqui minhas desculpas pela má qualidade das ilustrações).

Figura 4: Tela de abertura do WDO

O WDO oferece apenas quatro abas: a “Home”, onde se pode escolher o tipo de varredura (“scan”) a ser feita, a “Update” que permite verificar se o programa (mais particularmente, o banco de dados de assinaturas) está atualizado, a “History”, que lista detalhes sobre as varreduras previamente executadas e a “Settings”, que permite fazer alguns ajustes.

O usuário que acabou de instalar o WDO e o carregou em uma máquina suspeita de contaminação estará naturalmente interessado na primeira delas. Repare que ela permite escolher entre três níveis de varredura: “Quick”, “Full” e “Custom”. Esta última, se selecionada e acionada, fará se abrir uma janela estilo Windows Explorer com uma árvore hierárquica de arquivos onde será possível escolher apenas um ou alguns ramos a serem examinados e só deve ser usada caso se tenha uma boa ideia de onde o programa mal intencionado está alojado. A primeira, “Quick”, ou rápida, executará uma varredura apenas naqueles ramos escolhidos preferencialmente pelos programas mal intencionados para se alojarem. E, finalmente, a “Full”, completa, fará uma varredura arquivo por arquivo dos discos rígidos da máquina suspeita.

Evidentemente, esta última seria sempre a preferível não fora por um detalhe: o tempo de varredura. Executei uma varredura completa em um computador portátil adquirido há menos de dois meses, com um número relativamente pequeno de programas instalados e pouquíssimos arquivos de dados e a demora foi de duas horas e meia, enquanto na mesma máquina uma varredura rápida demorou pouco mais de sete minutos. Há casos em que a varredura completa pode demorar mais de oito horas.

O ideal, portanto, é começar com uma varredura rápida e, caso ela tenha localizado e eliminado o “rootkit” ou outro programa mal intencionado (você será avisado), reinicializar a máquina e verificar se o problema foi efetivamente resolvido. E apenas executar a varredura completa se a rápida em nada resultou e você mantém as suspeitas que a máquina continua contaminada.

Uma alternativa, para ser usada quando se tem fortes suspeitas que a máquina está de fato contaminada, é iniciar uma varredura completa à noite, pouco antes de você se preparar para dormir. Comande-a, espere se abrir uma janela semelhante à da figura 5 e vá para a cama. Na manhã seguinte provavelmente o resultado estará à sua espera na forma de uma lista de ameaças potenciais eventualmente encontradas que oferece a possibilidade de remover, ignorar ou enviar para quarentena cada uma delas.

Figura 5: varredura sendo executada

Finalmente, na aba Settings mostrada na Figura 6você poderá excluir arquivos e pastas selecionados de seu disco rígido, excluir arquivos de acordo com seu tipo (e, neste caso, o tipo será determinado pela extensão do nome do arquivo) e se filiar ao Microsoft Active Protection Service (até recentemente conhecida por “Microsoft SpyNet”), uma comunidade gerida pela MS que tem por finalidade a defesa contra ameaças à segurança (saiba mais sobre ela aqui).

Figura 6: aba Settings do WDO

Em suma: se sua máquina anda se comportando de forma estranha ultimamente e os melhores pacotes de segurança disponíveis nada conseguiram encontrar de errado com ela, talvez o Windows Defender Online seja a solução. Pelo menos para lhe dar a certeza que, se algo há de errado, não é um “rootkit”.

B. Piropo

Fechamos a coluna anterior comentando que a forma aparentemente mais lógica de descobrir se uma máquina está contaminada por um “rootkit”, um programa mal intencionado que se assenhoreia das funções do sistema operacional impedindo que sua presença seja detectada por este sistema, é rodar um programa que seja capaz de identificar a presença do “rootkit” sem que o sistema operacional seja carregado.

É óbvio que aqueles entre os leitores que possuem noções mínimas de informática acharam a assertiva um bocado estranha. Afinal, como carregar um programa sem carregar antes o sistema operacional se é o sistema operacional que carrega os programas?

Bem, de fato a coisa é aparentemente impossível. É claro que existem rotinas capazes de rodar antes que o sistema operacional seja carregado – o que, aliás, é evidente por si mesmo: se não fosse possível rodar uma rotina de programação antes da carga do sistema operacional, como seria possível carregar o próprio sistema operacional?

Mas existe uma grande diferença entre rodar rotinas específicas capazes de testar o hardware e carregar o sistema operacional (como as que rodam no procedimento de inicialização da máquina) e rodar um utilitário relativamente poderoso, capaz de inspecionar os arquivos contidos nos dispositivos de armazenamento secundário (como os discos rígidos) para detectar uma eventual contaminação por “rootkit”.

Quer dizer: parece que estamos frente a um impasse. Uma situação tipo “se ficar o bicho come, se correr o bicho pega”.

Mas nada em informática é muito complicado (quem afirma o contrário está apenas fazendo um esforço para impressionar a plateia e valorizar o pouco conhecimento que tem). Tudo é de fato muito simples. E basta ter um pouco de paciência que logo veremos como é possível que um utilitário relativamente “pesado” como o que usaremos adiante seja capaz de rodar antes da carga do sistema operacional instalado na máquina e inspecionar os arquivos deste sistema.

Então vamos nessa.

Windows Defender

Você já ouviu falar do Windows Defender? Um programeto da MS destinado a proteger o computador contra infecções de programas espiões (“spywares”)? O produto foi desenvolvido originalmente por uma companhia chamada GIANT AntiSpyware, comprada pela MS em 2004, e relançado como “Microsoft AntiSpyware” no ano seguinte. Em 2006 ele foi rebatizado de Windows Defender, posto à disposição dos usuários como produto gratuito para Windows XP e, mais tarde, incorporado aos Windows Vista e 7.

Windows Defender

Depois a MS comprou ainda outra empresa, a Sybari, cujo produto foi ligeiramente modificado e passou a ser distribuído pela MS sob a forma de um programa antivírus denominado MS Forefront . Cuja versão mais recente, revista, atualizada e transformada em um pacote (quase completo) de segurança, foi rebatizada de “Microsoft Security Essentials” (MSE) e também posta à disposição gratuitamente dos usuários de Windows.

Pois bem: se você baixar e instalar o pacote MSE em uma máquina onde já tenha instalado o Windows Defender, este último será desabilitado, já que suas funções, além de muitas outras, são cumpridas pelo pacote MS Security Essentials.

É por isto que hoje em dia quase não se ouve falar mais do Windows Defender.

Em resumo: aquele Defender que você conheceu – se é que conheceu – morreu de morte natural. E seu nome ficou dando sopa por aí (dentro da Microsoft, naturalmente).

Então, se você conheceu o Windows Defender, esqueça-se dele.

Windows Defender Offline

Agora, vou apresenta-lo ao Windows Defender Offline, ou WDO. Um produto cuja única coisa que tem em comum o velho Windows Defender é o nome “Defender” que, como estava dando sopa, foi aproveitado (coisas do mercado, naturalmente; pior vem fazendo a Intel com seus i3, i5, i7, i-isso e i-aquilo, que fazem uma confusão infernal na cabeça de quem pretende se manter atualizado com as características técnicas de seus processadores).

Diferentemente de seu xará mais velho, o Windows Defender Offline não é um programa “antispyware”. Sua principal função é procurar e, se encontrar, eliminar “rootkits”. Além disto, em máquinas que eventualmente se recusem a inicializar devido à presença de algum programa mal intencionado, pode-se rodar o WDO para fazer uma varredura nos dispositivos de armazenamento secundário e tentar identificar, localizar e eliminar o responsável, seja ele um “rootkit” ou não.

Para cumprir suas funções ele tem que ser capaz de fazer justamente aquilo que mencionamos pouco acima e que parecia impossível: rodar sem que o sistema operacional tenha sido carregado. Ou quase isso.

Vamos tentar destrinchar a coisa: o Windows Defender Offline não é capaz de rodar “sem um sistema operacional”. Na verdade, não há programa minimamente útil que seja capaz de fazer isto. O que o Windows Defender Offline é capaz de fazer é rodar sem que seja carregado o sistema operacional instalado na máquina a ser examinada (aquele que se suspeita de estar contaminado com o “rootkit” ou que se recusa a inicializar o micro). E pode fazer isto porque carrega consigo seu próprio sistema operacional. Que não chega a ser uma versão completa de Windows, mas um sistema bastante mais simples, porém suficientemente robusto para oferecer o suporte para que o WDO rode, faça uma varredura na máquina (cujo grau pode ser ajustado na configuração feita pelo usuário) e detecte a eventual presença de um “rootkit”. É por isto que se chama “Offline”.

É também por isto que o WDO pode funcionar como um utilitário autônomo: como traz consigo a espinha mestra de um sistema operacional – que é carregado antes do instalado na máquina a ser inspecionada, que deve então ser ajustada para isto – não depende de qualquer outro recurso, inclusive do SO da máquina. Que pode então ser inspecionado arquivo por arquivo diretamente do disco rígido onde está armazenado, sem que possa interferir no processo. É assim que o WDO pode identificar, isolar e remover um “rootkit” entranhado em um sistema operacional sem que este sistema operacional possa interferir para protege-lo.

Engenhoso, pois não?

Resumindo: o Windows Defender Offline, ou WDO, é um utilitário que deve ser instalado em uma mídia removível e inicializável (por exemplo: um disco ótico tipo CD ou DVD ou um disco de memória “flash” tipo “pen-drive”, desde que se possa proceder a inicialização da máquina por ele). A mídia carregará, além do programa executável do WDO e do banco de dados de definições de vírus e “rootkits”, sua própria versão do sistema operacional, simplificada porém suficientemente robusta para oferecer suporte ao WDO enquanto ele executa sua faina de efetuar uma varredura na máquina supostamente contaminada em busca de “rootkits” e outros programas mal intencionados.

É um produto da Microsoft, portanto provém de uma fonte confiável, e é gratuito.

Na próxima coluna veremos como obter, instalar e usar o Windows Defender Offline.

Até lá

B. Piropo

Antigamente a escola era risonha e franca. E os computadores domésticos não eram conectados. A única forma de comunicação entre eles era a transferência de programas via disquetes.

Pois não é que ainda assim um calhorda inventou o vírus de computador?

A partir de então surgiram as preocupações com os problemas de segurança. No princípio, bastante limitadas: para infectar uma máquina com um vírus era necessário introduzir no acionador de disquetes um disco que contivesse um arquivo contaminado e executar o arquivo. Quer dizer: quem sabia como a coisa funcionava tinha que ser um bocado descuidado para se contaminar.

Mas a imaginação criativa dos mequetrefes que desenvolvem programas mal intencionados não tem limites. E tão logo se deram conta que, naqueles tempos, a primeira coisa que o micro fazia ao ser ligado era procurar no acionador de disquetes por um disco que contivesse o sistema operacional e carrega-lo de lá, só procurando o sistema no disco rígido da máquina caso não encontrasse um disquete com o sistema no “drive A:”, aproveitaram-se disto para criar os então temidos “vírus de inicialização” (ou de “boot”), um código mal intencionado alojado no chamado “setor de inicialização” do disquete que, caso este disquete fosse esquecido no “drive A:”, era lido logo após a máquina ser ligada e se alojava no setor de inicialização do disco rígido do micro, contaminando a máquina.

Cavalo de Troia

Surgiram então os procedimentos de segurança (por exemplo, desabilitar a busca pelo sistema operacional no “drive A:”, fazendo com que ele fosse lido diretamente do disco rígido independentemente de haver ou não um disquete no acionador) e começaram a aparecer os programas antivírus, com seus bancos de dados de “assinaturas” (trechos de código característicos de todos os vírus conhecidos) e coisa e tal. E, quando a Internet se popularizou em meados da última década do século passado conectando direta ou indiretamente praticamente todos os computadores domésticos do planeta, as possibilidades de contaminação atingiram níveis antes inimagináveis. E os tipos de programas mal intencionados multiplicaram-se proporcionalmente: além dos vírus, apareceram os programas mal intencionados que não necessitavam serem executados pelos usuários pois se propagavam automaticamente (vermes), programas que aparentemente executam alguma “gracinha” inocente como abrir um cartão de Natal ou tocar uma musiquinha enquanto em segundo plano provocam danos ou roubam dados (cavalos de Troia), programas capazes de capturar as teclas acionadas pelo usuário incauto e enviá-las para o pilantra que infectou a máquina (“keyloggers”), outros que além das teclas armazenam e enviam a posição do cursor do mause a cada clique (”screenloggers”), programas espiões, programas que espreitam o tráfego da rede (inclusive da Internet) e capturam dados sigilosos (“sniffers”), programas invasores que mantém um vínculo com seu “dono” e permitem que a máquina infectada seja controlada por ele (“bots” e “backdoors”) e, finalmente, os “rootkits”.

Mas que diabos vem a ser um “rootkit”?

Os “rootkits”

Um “rootkit” é um programa mal intencionado diabolicamente engenhoso. Sua função básica é se esconder nas entranhas do sistema e passar totalmente despercebido. Por si mesmo não causa qualquer dano: apenas se esconde e logra todas as tentativas de detectá-lo. O problema é que sua capacidade de dissimulação não se restringe ao próprio código. Ou seja: ele não somente consegue se esconder, impedindo que programas antivírus e pacotes de segurança o detectem, como também faz o mesmo com outro programa, quase sempre um programa mal intencionado do tipo “backdoor” que, este sim, pode causar danos imensos ao permitir que terceiros tenham acesso e controlem a máquina infectada.

O nome “rootkit” deriva do fato de que estas pragas se parecem com “kits” para o desenvolvimento de programas para plataformas abertas, como Unix e Linux (na verdade, foi assim que se originaram). Já “root”, ou “raiz”, em inglês, é o título que recebe o administrador de um sistema em uma destas plataformas, um usuário que detém privilégios ilimitados. Um usuário “root” tudo pode, domina a máquina.

Malware

Então “rootkit” é um conjunto de rotinas que, ao serem “plantadas” em um sistema operacional (não apenas das plataformas abertas como Unix e Linux, mas qualquer sistema operacional, incluindo todas as versões de Windows), dá a quem as “plantou” controle total e irrestrito do sistema. Um controle tão completo que permite que estas rotinas interceptem os serviços e processos que rodam no computador (inclusive e principalmente os disparados pelos programas antivírus e pelos pacotes de segurança) impedindo que estes processos e serviços detectem a presença não apenas do próprio “rootkit” como também do programa mal intencionado que ele se destina a proteger.

Um “rootkit” é, então, uma espécie de capanga que protege um malfeitor impedindo que tanto sua presença quando a do malfeitor sejam percebidas.

Os mestres da camuflagem

Como isto é possível? Bem, para começo de conversa, um “rootkit” eficiente desenvolvido para Windows consegue esconder totalmente não apenas suas “chaves” no Registro como também seus próprios processos no Gerenciador de Tarefas, fazendo com que ele não apenas rode em segundo plano como também o faça de forma praticamente indetectável. Como consegue interceptar as rotinas de localização de arquivos no disco rígido usadas pelo sistema, caso o usuário (ou o pacote de segurança) efetue uma varredura do disco em busca dos arquivos que contêm as rotinas do “rootkit” (e do programa a que ele se destina a proteger) tudo o que consegue de volta é uma resposta do tipo “arquivo inexistente”.

Finalmente, alguns “rootkits” conseguem se “disfarçar”, aparecendo para o sistema como um gerenciador de dispositivos (“driver”), ou seja, um arquivo usado pelo sistema operacional para ter acesso ao hardware.

Em suma: o “rootkit” consegue disfarçar sua presença se misturando aos arquivos de sistema de forma tão indistinguível que tanto ele quanto o programa mal intencionado a que se destina a proteger tornam-se virtualmente indetectáveis não apenas pelo usuário como também pela maioria dos programas antivírus e pacotes de segurança. Inclusive os de boa qualidade.

Em resumo: se desenvolvido por um programador habilidoso, um “rootkit” eficiente é uma arma terrível e praticamente invisível.

Ora, se um “rootkit” é capaz de se entranhar de tal maneira no sistema operacional, misturando-se com os arquivos do sistema e confundindo-se com eles, que torna praticamente impossível detectar sua presença quando o sistema operacional está carregado, então como descobrir se a máquina está infectada com uma destas pragas e eliminá-la?

Bem, a forma que parece mais lógica é rodar um programa que seja capaz de fazê-lo sem que o sistema operacional esteja carregado.

Mas como rodar um programa sem que o sistema operacional esteja carregado?

Bem, isto é papo para a próxima coluna.

Até lá

B. Piropo

Para se entender o alarde que cercou o lançamento do IBM PC é preciso ter uma ideia do que representava a IBM no campo da informática no início dos anos oitenta do século passado. Hoje, não há empresa que exerça um domínio de mercado sequer parecido. Nem a Microsoft chegou perto nos seus anos dourados do final do século. Afinal, estamos falando de uma empresa tão poderosa e com tal influência que acabara de se desvencilhar de um processo antimonopólio movido pelo Governo Americano dando-se por feliz de não ter sido fracionada em empresas menores como mais tarde ocorreu com a empresa telefônica americana. Sua liderança no mercado era incontestável e cada movimento seu era acompanhado com imensa atenção pela imprensa, pelos concorrentes e por mais quem tivesse qualquer interesse na área de computadores.

O lançamento foi uma festa de arromba. Em 12 de agosto de 1981 a IBM reuniu a imprensa especializada em tecnologia e negócios nos salões do Hotel Waldorf Astoria e apresentou triunfalmente seu computador pessoal. Para não deixar dúvidas sobre o segmento do mercado a que ele se destinava, batizou-o justamente de PC, ou “Personal Computer”. E para tornar claro que o produto manteria os padrões de qualidade que fizeram da IBM uma das marcas mais respeitadas da indústria, juntou seu próprio nome e logotipo. Assim nasceu o IBM PC.

Hoje, o termo “computador” não assusta mais ninguém. Vivemos cercados deles, os carregamos nas pastas, nos bolsos e até nos pulsos, os vemos onde quer que olhemos e muitos de nós (acredito que todos os que estão lendo estas mal traçadas) sequer conseguem imaginar a vida sem eles. Mas há trinta anos as coisas eram diferentes. Ainda havia quem se referisse a computadores como “cérebros eletrônicos” e sua menção trazia à mente grandes salões refrigerados com uma assustadora parafernália eletrônica de fitas magnéticas, impressoras imensas e leitoras de cartões perfurados.

Em um tempo como aqueles a expressão “computador pessoal” sequer fazia muito sentido. Na verdade, chegava a assustar. Sobre o assunto dizem Campbell-Kelly e Aspray, em seu livro “Computer – A history of the information machine”: “A máquina foi astutamente batizada de Computador Pessoal IBM sugerindo que ‘máquina IBM’ e ‘computador pessoal’ eram sinônimos. Para o usuário corporativo, o fato de a máquina ostentar o logotipo IBM era suficiente para legitimá-la no campo empresarial. Entretanto, para o usuário doméstico, pesquisas de mercado haviam revelado que embora um computador pessoal fosse encarado como uma coisa boa, era também considerado como algo intimidador – e a própria IBM era tida como ‘fria e distante’”.

O Vagabundo e o PC

Era então preciso afastar estes temores. E a empresa de publicidade contratada pela IBM deu um golpe magistral: usou, como mote de lançamento e figura central da campanha um sósia do “The Tramp”, o adorável vagabundo encarnado por Charlie Chaplin, o Carlitos, no filme “Tempos modernos”. Era uma clara alusão à possibilidade do homem comum enfrentar uma luta contra a tecnologia e sair vencedor. Ainda segundo Campbell-Kelly e Aspray, “a figura de Carlitos reduziu o fator de intimidação e deu à IBM uma ‘face humana’”.

Foi um sucesso. No dia seguinte o Wall Street Journal publicava: “A International Business Machines Corp. entrou agressivamente no mercado de computadores pessoais e os analistas acreditam que a gigante dos computadores poderá assumir a liderança da jovem indústria em um prazo de dois anos”.

E assim foi.

Mas que máquina era aquela, a que foi lançada?

Era um computador desenvolvido em torno do processador 8088 da Intel, como sabemos. Vinha com uma unidade de disco flexível (de uma face e 160 KB de capacidade) e uma memória primária (memória RAM) de 64 KB (que poderia ser expandida até 256 KB). Era fornecido com teclado e monitor monocromático capaz de exibir apenas texto (para exibir gráficos era necessário acrescentar uma “placa gráfica” e adquirir um novo monitor). Custava US$ 1.595. Se agregada uma impressora (matricial, naturalmente) e os demais opcionais, o preço poderia subir para cerca de seis mil dólares americanos. E isso para uma máquina com poder de processamento inferior ao de telefones celulares modernos – e não os de última geração…

O IBM PC

Para comercializá-la, pela primeira vez a IBM recorreu ao varejo e não aos canais que costumava usar para distribuir seus produtos. O IBM PC era vendido pelas cadeias de lojas Computerland e Sears.

Um ano e meio depois, no final de 1982, e pela primeira vez na história, o “homem do ano”, a tradicional – e esperadíssima – matéria de capa de final de ano da revista Time, não foi um homem, mas uma máquina. Justificaram os editores: “Há ocasiões em que a força mais significativa no noticiário anual não é apenas um indivíduo, mas um processo… O ‘Homem do Ano’ da Time para 1982, a maior influência para o bem ou para o mal, não é um homem de forma alguma. Trata-se de uma máquina, o computador… O PC, de ‘Personal Computer’, de cor branca cremosa, lançado em agosto de 1981… determinou um padrão de excelência para a indústria”.

Em 1983, dois anos após o lançamento, havia no mercado americano várias dúzias de publicações semanais ou mensais dedicadas exclusivamente ao IBM PC.

Don Estridge e a equipe de desenvolvimento do PC de Boca Ratón romperam radicalmente os métodos empresariais que sempre prevaleceram na IBM e conseguiram em menos de três anos levar um empreendimento do zero a quatro bilhões de dólares americanos (uma fortuna inimaginável, na época). Sem mencionar o fato de que criaram um padrão que influencia a sociedade até os dias de hoje e deu origem às dezenas de diferentes modelos de computadores que constituem a “linha PC”.

Um feito e tanto.

Eu poderia continuar ainda por semanas escrevendo sobre a história dos computadores, particularmente sobre o papel seminal dos desenvolvedores dos softwares pioneiros para computadores pessoais, como Dan Bricklin e seu Visicalc, Mitch Kapor e seu Lotus 123, ou os editores de texto como o WordStar e o banco de dados DBase.  Mas esta série já se alongou demais e está na hora de mudar de assunto. Mesmo porque tem um monte de novidades por aí e convém falar nelas. Quem sabe um dia voltaremos a lembrar um pouco o passado. Pois, afinal, sempre vale a pena repetir: só quem conhece o passado pode entender o presente e fazer previsões factíveis para o futuro.

Como eu disse, procurei basear esta série de colunas em livros da época e em minha já um tanto combalida memória, evitando sempre que possível a Internet. Assim foi feito. E, a páginas tantas, prometi citar a lista dos principais livros consultados. Aqui vai ela em ordem cronológica de publicação:

“Hard Drive – Desejo de Vencer – Bill Gates e a criação do império da Microsoft” de James Wallace e Jim Erickson, publicado em 1992, tradução de Ronaldo Sérgio de Biasi, editado pela Distribuidora Record de Serviços de Imprensa S.A.

“A Guerra dos computadores – as batalhas pela liderança da tecnologia da informação”, de Charles H. Ferguson e Charles R. Morris, publicado em 1993 pela Ediouro.

“Impérios Acidentais – Como os garotos do Vale do Silício ganham milhões mas não arranjam namorada” de Robert X. Cringely, tradução de Roberto Raposo, editado pela Ediouro em 1995

“Computer – A history of the information machine” de Martin Cambbell-Kelly e William Aspray, publicado em 1996 por Basic Books

“Passado e futuro da Era da Informação” de Ricardo Rangel, publicado em 1999 pela Editora Nova Fronteira.

Aí estão eles. Consultei mais alguns, mas deles não extrai nada que efetivamente prestasse. Mas estes, se vocês encontrarem em algum sebo, comprem que vale a pena.

Até a próxima.

B. Piropo

Como vimos na coluna anterior, a Microsoft não tinha o sistema operacional para o computador pessoal que a IBM estava projetando mas sabia onde encontra-lo. E no dia seis de janeiro de 1981, há quase exatos 31 anos, Bill Gates e Rod Brock, o dono da Seattle Computers que detinha a propriedade do 86-QDOS desenvolvido pelo seu programador Tim Paterson, assinaram um contrato que dava à MS o direito não exclusivo de comercializar o sistema operacional.

Há detalhes curiosos. Apesar do contrato ter sido assinado por ambos, Gates e Brock jamais se encontraram pessoalmente (mais tarde Brock comentou que apenas ouviu a voz de Gates através da porta de sua sala quando o mesmo discutiu os últimos detalhes com seu sócio Paul Allen). Pelos direitos não exclusivos de comercialização a MS pagou dez mil dólares americanos. Pelo código fonte do sistema, que a MS pretendia alterar antes de licenciá-lo à IBM, foram pagos cinco mil dólares adicionais. E pelo contrato global foram pagos mais dez mil dólares. Em suma: por 25 mil dólares a MS adquiriu os direitos de comercializar com quem quisesse aquilo que viria a ser a base do MS-DOS, o sistema operacional do IBM PC. Há quem diga que este foi o melhor negócio do mundo. Se foi, não sei. Mas garanto que foi o melhor negócio da história da informática (consta que o preço foi fixado pelo próprio Brock após um telefonema para a Digital Research indagando quanto eles cobravam para licenciar seu CP/M, valor que foi tomado como base das negociações).

É claro que Brock não fazia a menor ideia de quem seria o cliente da MS interessado no sistema operacional que estava licenciando. Mesmo porque era vedado à MS fornecer esta informação pela famosa cláusula de confidencialidade dos contratos da IBM, aquela mesma que impediu as negociações com a Digital Research mas que havia sido assinada sem pestanejar por Gates quando firmou contrato com a IBM para o desenvolvimento das linguagens de programação para a nova máquina.  Também é fato que Gates não tinha interesse em divulgar a identidade do cliente, pois se Brock soubesse que a gigantesca IBM estava interessada no seu sistema o preço poderia subir consideravelmente. Por isto mesmo constava textualmente em uma das cláusulas do contrato que “nada, neste acordo de licenciamento, obriga a Microsoft a indicar o seu cliente à Seattle Computer Products”.

Diga-se de passagem que, na ocasião, somente os pouquíssimos viventes diretamente envolvidos nas negociações (e, portanto, impedido de comentar o assunto em virtude da cláusula de confidencialidade) sabiam que a IBM planejava entrar no negócio dos computadores pessoais, já que o assunto estava cercado por uma densa e quase impenetrável cortina de sigilo.

O “quase” aí de cima corre por conta de uma intrigante nota na InfoWorld (que já existia desde dezembro de 1978 com o nome de “The Intelligent Machines Journal” e que hoje existe < http://www.infoworld.com/ > apenas na Internet) publicada cerca de um mês antes do lançamento do PC com o título “A IBM se prepara para entrar no mercado dos micros”, anunciando que a gigante da informática planejava lançar um micro baseado no 8088.

A IBM prontamente desmentiu o que qualificou de “boato” e, para despistar a imprensa e a indústria, lançou alguns dias depois um novo exemplar de sua linha de computadores Datamaster, o System 23, projetado para concorrer com os minicomputadores da DEC. O despiste eu certo: não se falou mais do IBM PC até seu lançamento. Mas o vazamento foi suficiente para botar uma pulga atrás da orelha de Bill Gates. Pois, naquela altura dos acontecimentos, com o projeto quase pronto e a um mês do lançamento, ele já estava convencido que o micro seria um sucesso e que não era um bom negócio para a MS dispor apenas dos direitos de comercialização não exclusivos de seu sistema operacional. O que realmente interessava eram os direitos de propriedade – que, pelo contrato firmado em janeiro daquele ano, continuavam nas mãos da Seattle Computers. E cujo custo dispararia caso o PC viesse a fazer o sucesso que ele esperava.

A pechincha do século (passado)

Com isto em mente, Gates propôs a Rod Brock a compra destes direitos por cinquenta mil dólares.

Em condições normais o negócio seria recusado. Mas dois meses antes, no final de abril de 1981, Tim Paterson desentendeu-se com Brock devido a uma discordância sobre a forma de comercialização dos produtos (Brock insistia que a venda fosse feita apenas por reembolso postal e Paterson achava que havia mais futuro na revenda direta aos consumidores). Resultado: Paterson pediu demissão da Seattle Computers.

Até hoje há quem jure que “Bill Gates aliciou Tim Paterson, convencendo-o a deixar a Seattle Computer e trabalhar para a MS para lá continuar a desenvolver seu sistema operacional”. Mas a verdade é que Gates nada teve a ver com isto: desempregado, Paterson procurou Paul Allen, sócio de Gates, que conhecia bem em virtude das negociações de venda de seu QDOS, pedindo emprego. E, naturalmente, foi pronta e alegremente admitido. Entrou na empresa em primeiro de maio de 1981, juntou-se imediatamente a Bob O’Rear, o programador da MS que tratava de adaptar o QDOS para o IBM PC (e foi somente então que tomou conhecimento de qual era o cliente para o qual a MS pretendia licenciar seu sistema) e lá permaneceu por quase vinte anos até pedir demissão, fundar sua própria empresa, a Paterson Technology, passar a pilotar carros de corrida e trabalhar em uma série de televisão (figuraça, este Paterson, pois não?).

Ora, sem Paterson para continuar desenvolvendo o sistema, Brock não tinha muito interesse em manter seu direito de propriedade. Mesmo porque a proposta da MS parecia altamente vantajosa já que a Seattle Computer venderia os direitos do sistema mas, em tese, nada perderia. Isto porque a propriedade passaria para a MS, que então deteria direitos exclusivos de comercialização e poderia cobrar royalties por licença fornecida, mas pelo contrato a ser assinado a Seattle Computer conservaria o direito ilimitado de usar o sistema, ou seja, poderia fornecê-lo juntamente com suas placas a quem quer que fosse sem pagar nada à MS. E mais: seria um direito perpétuo, mantido ao longo do tempo mesmo que a MS alterasse o sistema operacional e desenvolvesse novas versões. O único senão, do qual Brock não se deu conta – ou, se deu, não percebeu o quanto era importante – é que o contrato estabelecia que este direito de comercialização era exclusivo da Seattle Computer, portanto inalienável.

O contrato de compra dos direitos do DOS foi assinado em 27 de agosto de 1981. E talvez tenha sido a pechincha do século.

É verdade que nem todos na MS estavam convencidos do acerto da compra. Havia quem achasse que a empresa, especializada no desenvolvimento de linguagens de programação, não tinha nada que se meter na área de sistemas operacionais, até então tacitamente “pertencente” à Digital Research. Mas seja como for, a MS fechou imediatamente o primeiro acordo de licenciamento do sistema: com a própria IBM, que o batizou de PC-DOS.

Também é verdade que estes 75 mil dólares (os 25 mil do licenciamento inicial mais os 50 mil da compra dos direitos) não foi o total de recursos recebidos pela Seattle Computers pelo seu sistema. Cinco anos mais tarde, com sua empresa à beira da falência, Rod Brock decidiu vende-la. A empresa em si mesma nada valia, mas os direitos ilimitados de uso e comercialização do MS-DOS, já então na versão 3.x e campeão absoluto de vendas, que a empresa detinha, estes sim poderiam valer uma nota preta. Tanto que Brock pretendia vendê-los à Tandy Computers. Antes, porém, resolveu informar disto a MS a quem fez uma oferta de preferência de compra pelo preço módico de vinte milhões de dólares.

A resposta não tardou. Na verdade, veio no mesmo dia: a MS informava que lamentava a “interpretação exagerada” de Brock sobre o assunto e lembrava que, segundo o contrato de venda, os direitos de comercialização do DOS eram inalienáveis. Brock, naturalmente, estrilou, mas nada lhe restou a não ser recorrer aos tribunais. O processo correu em 1986 e durou três semanas. Enquanto os jurados deliberavam sobre o veredito, os advogados das partes, MS e Seattle Computers, fecharam um acordo privado na qual a primeira concordava em pagar 925 mil dólares à segunda para encerrar o processo. Consta que mais tarde se soube que os jurados dariam o ganho da causa à Seattle Computers por oito votos a quatro, fazendo-a embolsar 60 milhões de dólares, o valor da causa. Por outro lado, Brock admitiu que durante todo o tempo estava disposto a abrir mão dos direitos caso a MS concordasse em pagar-lhe quinhentos mil dólares, o que foi sempre teimosamente recusadoos por Gates. Mundo curioso e cheio de surpresas este, dos negócios…

Seja como for, computando os 75 mil dólares desembolsados cinco anos antes e o valor do acordo, o custo total do DOS para a MS foi de um milhão de dólares.

Foi assim que nasceu o MS-DOS, o programa responsável por transformar a MS em um gigante corporativo e tornar Bill Gates bilionário. E que, com o hardware desenvolvido em Boca Raton e o BASIC residente criado pela própria MS, deixou o IBM PC pronto para o lançamento.

Que foi feito com toda a pompa e circunstância pela IBM em 12 de agosto de 1981 nos salões do Hotel Waldorf Astoria, em Nova Iorque, menos de quinze dias depois da MS haver comprado os direitos de propriedade do (já então) MS-DOS. Uma máquina que mudou o perfil de nossa sociedade, construíu fortunas e forjou a reputação de poderosos executivos. Mas cuja estratégia de lançamento foi montada em torno de um personagem popular dotado de muito charme porém nenhuma grana, encarnado por Charlie Chaplin, o Carlitos: “The tramp”, o “vagabundo” do filme Tempos Modernos (na foto, obtida da Wikipedia).

Mas isto é papo pra semana que vem.

B. Piropo

Talvez o que me motivou a iniciar esta série de colunas (esta já é a quinta e não será a última como prometi alhures…) sobre a história do IBM PC tenha sido a nostalgia que nesta época do ano nos ataca – ou, pelo menos, ataca as pessoas que, como eu, entraram naquela fase da vida que alguém dotado de um fino humor e não menos fina ironia resolveu batizar de “melhor idade” (provavelmente tendo em mente a alternativa). Ou, quem sabe, tenha sido a percepção adquirida no decorrer dos anos de que somente quem conhece o passado pode entender o presente e tentar antever o futuro. Mas, seja lá qual a razão, é certo que há muito não sinto tanto prazer em escrever sobre um tema (é verdade que a decisão que tomei logo no início de evitar a Internet e me restringir a minhas próprias lembranças e consultas a livros da época tem ajudado bastante: folhear velhos alfarrábios já cobertos pela poeira dos tempos é um deleite que raramente nos é permitido nesta era de livros virtuais). Prazer que, presumo, esteja sendo compartilhado com vocês, caros leitores. E trata-se de mera presunção e não certeza porque aqui neste canto de tela vocês têm se mostrado particularmente avaros no que toca a comentários, o que não me permite saber o que de fato estão achando. Mas, presunçoso que sou, sigo adiante.

Seja como for, já tomamos conhecimento das razões que levaram a poderosa IBM a lançar seu computador pessoal, dos motivos que a levaram a decidir por uma “arquitetura aberta” para sua nova máquina, das discussões que cercaram a decisão sobre o sistema operacional a ser usado e, na coluna imediatamente anterior a esta, dos motivos que levaram a IBM a desistir de sua escolha natural, o CP/M.

Resultado: a IBM mantinha, eu seu centro de desenvolvimento de Boca Ratón, uma equipe projetando uma máquina revolucionária, cujas linguagens de programação estavam sendo desenvolvidas pela então desconhecida Microsoft com a qual se mantinha em estreito contato, porém ainda não tinha ideia de qual sistema operacional usar no novo micro. E já estavam no final de 1980, a cerca de um semestre da data aprazada para o lançamento.

O assunto se revestia, portanto, de incontestável urgência.

Ao retornar a Boca Ratón de sua viagem ao Vale do Silício após os infrutíferos entendimentos com a Digital Research para que esta última fornecesse o sistema operacional para seu PC, e lá encontrando os representantes da Microsoft envolvidos nas discussões sobre o desenvolvimento de suas linguagens de programação, o pessoal da IBM tomou a atitude que lhe pareceu mais sensata: perguntar a Bill Gates se a MS não poderia fornecer o SO.

Em seis meses seria impossível desenvolver um sistema operacional que prestasse partindo do zero, portanto o natural seria esperar que Bill Gates respondesse que não. Mas Gates nunca foi homem de perder um bom negócio. E respondeu que sim. E o fez porque tinha boas razões para fazê-lo. Pois, mesmo não tendo um sistema operacional para uma máquina baseada no Intel 8088 nem condições de desenvolver um em tão pouco tempo, por certas contingências tão comuns no mundo dos negócios, ele sabia quem tinha. E, baseado neste conhecimento e em seu tino para negócios, garantiu à IBM que a MS poderia fornecer o sistema operacional para o PC dentro do prazo disponível.

Tim Paterson, o criador do 86-QDOS

Pois acontece que a IBM não era a única empresa dos EUA a desenvolver uma placa de circuitos baseada nos novos processadores de dezesseis bits da Intel. Em Seattle, casualmente a cidade natal de Bill Gates e sede da Microsoft, havia uma pequena empresa, a Seattle Computers, de propriedade de Rod Brock, dedicada à fabricação de placas de memória para computadores, onde trabalhava Tim Paterson, um entusiasta por corridas de automóveis e programador brilhante. E foi esta empresa que, muito antes da IBM cogitar em usar o 8088 em seu computador, decidiu fabricar uma placa de circuitos para o novo “chip” da Intel.

Quem convenceu Brock a fabricar a placa foi justamente Paterson, entusiasmado com uma apresentação da Intel que havia assistido em 1978 sobre o novo chip. A diferença é que, enquanto o futuro IBM PC usaria o 8088, a placa da Seattle Computers usava o 8086, a versão original e mais poderosa do processador da Intel.

O protótipo da placa da Seattle Computers ficou pronto em maio de 1979, um ano antes das < http://www.techtudo.com.br/platb/hardware/2011/12/22/a-era-pc-por-que-nao-o-cpm/ > negociações entre IBM e Digital Research serem encetadas. Mas a placa não foi lançada no mercado senão muitos meses depois porque  para tanto precisava de software.

Para conseguir o software para a nova placa Tim Paterson, o responsável pelo projeto, o procurou nas fontes naturais.

Primeiro – exatamente como mais tarde faria a IBM, porém sem qualquer complicação de ordem jurídica – entrou em contato com a Digital Research e solicitou a Gary Kildall que desenvolvesse uma versão do CP/M para o novo processador. Kildall aceitou a missão e prometeu fornecer a primeira versão do que seria o CP/M 86 em dezembro de 79. Mas não conseguiu entregar o SO no prazo prometido.

Nesta altura dos acontecimentos, segundo Rod Brock (citado no livro “Hard Drive – Desejo de Vencer”), a Seattle Computer “tinha um bom produto, mas estava parada esperando que a Digital terminasse sua versão do sistema operacional para o 8086. Eles só diziam que estava quase pronta. A demora estava começando a prejudicar nossas vendas. É difícil vender um produto sem um sistema operacional. Estávamos vendendo umas cinco ou dez placas por mês mas poderíamos estar vendendo muito mais”.

Diante da demora, o próprio Tim Paterson perdeu a paciência, pôs mãos a obra e desenvolveu ele mesmo um SO para a nova placa. E o fez da única forma que considerou viável: consultou a documentação impressa da proposta do CP/M 86 fornecida pela própria Digital Research e, usando diretamente a linguagem de máquina do novo “chip”, programou uma a uma cada função a ser cumprida pelo sistema operacional.

É claro que um produto feito desta maneira não ostentava o menor grau de sofisticação. Era algo tão simples que o próprio Paterson o batizou de “86-QDOS”.

QDOS eram as iniciais de “Quick and Dirty Operating System” (ao pé da letra a expressão “Quick and Dirty” é traduzida como “rápido e sujo”, mas este não é seu sentido corrente; ela é usada correntemente no inglês dos EUA para qualificar algo “feito depressa e sem os devidos cuidados”; em português, é grosseiramente equivalente a “feito em cima da perna” ou “feito de qualquer jeito”). Foi, portanto, um trabalho expedito, simples e rápido, mas bastou para que a Seattle Computers pudesse fornecer suas placas com um sistema operacional funcional. E, quando ficou pronto, Paterson procurou Paul Allen, sócio de Bill Gates na Microsoft, para perguntar se a empresa não estaria disposta a adaptar seus programas e linguagens ao novo SO.

Foi assim, segundo Tim Paterson, que a Microsoft tomou conhecimento da existência de um sistema operacional para o novo chip da Intel, o 8086, absolutamente compatível com o 8088 escolhido pela IBM para sua nova máquina. E foi este sistema que serviu de base à galinha dos ovos de ouro da Microsoft, o MS DOS.

Mas de tais desdobramentos tomaremos conhecimento na próxima semana. Ou, se preferirem, no ano que vem. Que, espero de todo coração, transcorra pleno de realizações para cada um de vocês, meus amigos leitores.

Feliz Ano Novo.

B. Piropo

Se você vem acompanhando estas colunas, sabe por que a IBM resolveu lançar seu próprio computador pessoal e que o projeto da nova máquina foi praticamente orientado pelos cuidados inspirados pelo processo antimonopólio sofrido pela empresa. Sabe também que a opção inicial da IBM, apoiada pela Microsoft, foi adotar o sistema operacional mais popular na época para micros pessoais, o CP/M. E, com este objetivo, procurou a Digital Research que o desenvolvia.

Só não sabe ao certo o que aconteceu durante os entendimentos entre IBM, DR e MS envolvendo as discussões sobre o desenvolvimento de um sistema operacional para a IBM PC.

MS / IBM / DR

Se este é seu caso, não se preocupe. Na verdade ninguém sabe. Nem mesmo os diretamente engajados no processo de escolha, já que havia segredos industriais envolvidos, delicados relacionamentos pessoais, intrincados acordos comerciais e egos gigantescos feridos. Disto tudo só poderia resultar um mundo de versões, algumas inteiramente conflitantes. E ainda que se possa garantir que fulano ou sicrano não está mentindo sobre o assunto, não se pode ter certeza que o que ele diz é a verdade: pode ser apenas o que ele, de boa fé, pensa que é verdade (lembre-se da questão sobre a escolha do 8088 para a máquina, onde Bill Gates jura que ele foi adotado por sugestão sua enquanto a IBM jura que a decisão de adotá-lo já havia sido tomada quando um projeto falso de máquina de oito bits foi apresentado a Gates durante a discussão dos aspectos comerciais da questão).

Mas sabemos todos que há duas versões: a corrente e a verdadeira.

Comecemos pela primeira.

A versão corrente

Em um trecho de seu livro “Hard Drive – Desejo de vencer” James Wallace e Jim Erickson dizem, textualmente:

“O que aconteceu no dia em que a IBM procurou pela primeira vez a Digital Research em Pacific Grove, Califórnia, perto da panorâmica Highway 1, se tornou parte do folclore da indústria de computadores pessoais, uma história que é contada sempre que a conversa em um congresso industrial ou jantar de negócios se volta para a Microsoft e seu monopólio bilionário, o DOS. Gary Kildall jogou fora a oportunidade do século, dizem alguns. … Nos doze anos que se passaram desde aquele dia fatídico [NA: o livro foi publicado em 1992] muitas versões diferentes apareceram em livros, revistas e jornais. Poucos relatos são coincidentes. Os detalhes divergem bastante. Os dois atores principais, Gary Kildall e Jack Sams se lembram dos acontecimentos de maneira bem diversa”.

Dorothy McEwen

Como se vê, não há consenso. Mas reza a lenda que a equipe da IBM, encabeçada por Jack Sams e constituída por ele mesmo, um advogado da empresa e dois assessores, partiu da sede da Microsoft em Seattle para Pacific Groves, uma pequena cidade litorânea da Califórnia onde ficava a sede da DR, para a reunião marcada no dia seguinte. Lá, foi recebida por Dorothy McEwan, cuja foto obtida da Wikipedia é mostrada na figura acima, mulher de Kildall, representando a empresa, e seu advogado. Gary Kildall estava “pilotando seu bimotor particular” no horário marcado com os homens de terno azul da IBM. Dorothy, por sua vez, se recusou a assinar o acordo de confidencialidade da IBM. Sem isto, não poderia haver negociação. A equipe da IBM, ultrajada, voltou para Boca Ratón sem um sistema operacional para a nova máquina. Sabendo disto, Bill Gates ofereceu os serviços da Microsoft para desenvolver seu próprio sistema, o que foi aceito pela IBM. E o resto da história todos conhecem (e os que não conhecem conhecerão breve se continuarem acompanhando estas colunas).

Assim, conforme a versão corrente, Gary Kildall desprezou os representantes da poderosa IBM e foi passear no horário aprazado para reunir-se com eles que, ofendidos, retornaram a Boca Ratón sem fechar o acordo comercial e a oportunidade acabou caindo no colo de Gates.

(Uma tentativa de estabelecer) a versão verdadeira

Agora, baseado nos relatos publicados na época e nos anos seguintes, além dos depoimentos de alguns dos participantes, tentemos reconstituir o que de fato ocorreu e estabelecer a versão verdadeira. Ou algo próximo dela, já que há tantas e tão desencontradas versões contadas desde pontos de vista tão diferentes que a verdadeira, mesmo, ninguém sabe. O que vai narrado adiante é, portanto, a versão mais plausível segundo pude compilar de diversas fontes da época. E, de fato, parece mais veraz que a acima citada.

Então vamos a ela. Mas, antes, convém citar Robert Cringely em seu livro “Impérios Acidentais”, traduzido em português, sobre o acordo de confidencialidade da IBM, um documento que exerceu papel relevante em todo o quiproquó. Diz ele:

“Os acordos de confidencialidade impõem limites sobre a capacidade de ambas as partes de revelar os segredos das organizações com as quais estão negociando. O acordo de confidencialidade que a IBM costuma usar vai ainda mais longe. Assinando o acordo da IBM os fornecedores em potencial concordam que o que disserem à IBM não é confidencial ao passo que o que a IBM disser a eles é confidencial. Em outras palavras: enquanto o sujeito da IBM sentado do outro lado da mesa pode dizer a quem quiser o que você lhe revelou acerca de sua firma e de seus planos, ele pode processá-lo se você repetir uma de suas piadas e principalmente revelar qualquer um dos segredos da IBM. E, se a IBM recorrer à justiça, o acordo proíbe que a outra parte se defenda”.

Note que isto é uma citação, não uma opinião minha. A última oração me parece inacreditável. Mas asseguro que os termos draconianos do malfadado acordo de confidencialidade da IBM eram temidos por toda a indústria e refletiam a arrogância com que a empresa, em seus áureos tempos, costumava tratar seus fornecedores.

Mas prossigamos. Começando pela estrutura organizacional da Digital Research.

Gary Kildall

Gary Kildall era um professor e programador. Brilhante em ambas as atividades, mas um desastre para negócios. Assim, quem cuidava da parte administrativa e financeira da Digital Research era Dorothy, sua mulher, assessorada quando era o caso pelo advogado da empresa. Portanto, nada mais natural que fossem eles os encarregados de receber a equipe da IBM que vinha propor um negócio e não discutir aspectos técnicos.

É fato que no horário acertado para a reunião Gary estava realmente pilotando seu bimotor. Mas não fazia uma viagem de recreio. Na qualidade de desenvolvedor do CP/M, cabia a ele o suporte técnico do produto. E a viagem destinava-se justamente a atender a um cliente. E mais: as discussões entre Dorothy e Sams demoraram tanto que ele já estava de volta à sede da empresa à tempo de participar da reunião. Não participou porque administração e finanças não lhe diziam respeito.

O que ocorreu de fato, de acordo com a maioria das fontes, é que toda a discussão centrou-se no acordo de confidencialidade. A real natureza do negócio sequer foi abordada já que, pelas regras da empresa, a IBM não dava um pio sobre qualquer negócio antes que a outra parte assinasse o famoso acordo de confidencialidade. E Dorothy, responsável pela administração de uma empresa promissora, em fase de evidente crescimento, porém insignificante diante de uma IBM, compreensivelmente se recusou a assinar um documento com cláusulas tão pesadas.

Diz Robert Cringely em seus “Impérios Acidentais”:

“Voltemos a Pacific Grove onde a Digital Research nem ao menos tinha o seu próprio acordo de confidencialidade. Gary estava ainda sobrevoando alguma parte das montanhas de Santa Cruz enquanto Dorothy Kildall examinava o acordo de confidencialidade da IBM imaginando leiloar sua casa nova com estábulo e banheira de água quente em consequência de um processo da IBM na justiça. Recusou-se a assiná-lo…”

O máximo que Sams conseguiu depois de horas de reunião infrutífera foi um documento assinado por Dorothy se comprometendo a não divulgar que a IBM ali esteve. O objetivo mesmo da visita, ou seja, o licenciamento do CP/M ou o desenvolvimento de um sistema operacional pela DR para o IBM PC não foi sequer mencionado.

É por isto que o sistema operacional do primeiro PC foi o MS-DOS.

Que, presumo, você pensa que foi desenvolvido pela Microsoft, certo?

Errado.

Não, de novo o Piropo não pirou.

Mas você só vai saber por que na próxima coluna. Depois que tiver desfrutado um mais que feliz Natal e aberto todos os seus presentes.

B. Piropo