Meio Bit » Arquivo » Hardware » Executar softwares de outras plataformas: uma faca de dois gumes

Executar softwares de outras plataformas: uma faca de dois gumes

18 anos atrás

Fora da plataforma Windows existe todo um universo de sistemas e programas a ser explorado. Muitos usuários não tem essa percepção e grande parte do mercado, principalmente no segmento doméstico, desconhece completamente esses horizontes. Provavelmente por isso é comum que usuários de sistemas e plataformas de menor penetração encontrem problemas ao buscar produtos e serviços que funcionem adequadamente em seus sistemas de escolha. Isso prejudica a liberdade de opção, sem dúvida, mas o pior aspecto seja, talvez, os efeitos colaterais que a ampla adoção em massa de um único padrão ou sistema impliquem ao mercado.Ecossistema de uma criatura só
O primeiro efeito colateral da adoção pela quase totalidade do mercado doméstico de uma única plataforma é a possibilidade da proliferação de malware. Assim como na biologia, onde a existência de grandes populações de indivíduos geneticamente idênticos abre campo para que um vírus ou uma bactéria ataquem toda uma espécie com pequeno esforço; na informática o fato de 90% dos computadores pessoais rodarem a mesma plataforma permite que ataques focados em um pequeno ponto fraco causem grande estrago. É claro para muitos especialistas em segurança que uma maior diversidade seria uma barreira para grandes contaminações de software malicioso. Até por conta disso atribui-se a relativa segurança experimentada por usuários de plataformas menos difundidas à sua pequena base instalada. Em um cenário com 3 ou 4 plataformas distintas dividindo igualmente o mercado seria preciso um ataque conjunto muito complexo para causar um efeito nocivo semelhante aos já verificados na situação atual, onde apenas uma plataforma detém uma fatia muito grande do mercado.

O segundo efeito colateral é um círculo vicioso. Sistemas com pouca penetração de mercado e com pequena base de usuários recebem pouca atenção de grandes desenvolvedores de software. Isso significa que poucas aplicações de grande porte serão desenvolvidas naquela plataforma, e isso causa pouca atração de novos usuários. Sem boas aplicações a base instalada não cresce, sem base instalada não surgem boas aplicações e novos usuários são empurrados para a mesma plataforma que a maioria do mercado usa. Essa plataforma cresce cada vez mais e monopoliza ainda mais as atenções dos grandes desenvolvedores que irão cada vez menos sentir-se tentados a escrever software para outros sistemas. Esse panorama é negativo por diversos aspectos, primeiro por negar aos usuários a chance de testar outros sistemas e descobrir novas formas de fazer as coisas. Segundo por implicar em uma oferta de software caro, pobre de recursos e que não atende as necessidades de seus usuários, já que não há uma forte competição. Terceiro por desenvolver uma metodologia de criação de software que se preocupa com o genérico; os softwares são escritos para tentar resolver todos os problemas, pois não há concorrentes e cada solução deve tentar atender à todos; mas acabam não resolvendo nenhum problema bem o bastante para atender aos usuários de forma satisfatória.

O terceiro efeito é a criação e manutenção de uma cultura na mente do mercado de que as coisas são como são e nada pode-se fazer para mudar isso. Se um software não atende às suas necessidades ou se ele é problemático demais, paciência. Acostume-se com isso ou não faça as coisas. Conheço dezenas de pessoas que reclamam do sistema operacional porque ele é pesado ou lento, do processador de textos porque ele é muito grande e ocupa muito espaço no HD, da planilha de cálculos porque ela não tem este ou aquele recurso e usa muita memória RAM. Entretanto elas continuam usando essas mesmas aplicações versão após versão e continuam reclamando, porque o mercado as sugestionou a acreditar que não existe outra alternativa. Ou usam aqueles programas ou abdicam de usarem seus computadores para aquelas funções. Também por isso as pessoas desenvolveram uma descrença irreal nos computadores. Certa vez em uma fila de banco, há muito tempo, o caixa avisou que não poderia atender os clientes pelos próximos 15 minutos pois “o sistema estava fora do ar”. Nesse momento um senhor parado ao meu lado disparou “normal, computadores vivem dando problemas”. Isso deveria ser normal? E ainda que hoje esse tipo de problema tenha quase desaparecido no mercado bancário (à exceção do web-banking) não precisa muito para que o atendente de sua fornecedora de serviços de telefonia celular solte um “nosso sistema está um pouco lento hoje” enquanto você aguarda por informações sobre sua conta. Computadores não deveriam ser assim, são máquinas lógicas que deveriam sempre trabalhar de uma maneira uniforme. A falta de competitividade no segmento de software gera software ruim. E anos de software ruim criaram no mercado a imagem de que computadores são máquinas falíveis nas quais não devemos confiar.

O quarto efeito é a opção pela marca e não pela funcionalidade. As pessoas não instalam um software de desenho vetorial, instalam o Corel; não usam uma aplicação de edição de imagens, usam o Photoshop; não fazem curso para operação de processadores de texto, fazem “curso de Word”. Na faculdade estudantes de engenharia recebem aulas de AutoCAD e web-designers tornam-se proficientes em Flash. Nenhum outro mercado tolera tanto a substituição da funcionalidade pela marca quanto o mercado de informática, mostrando que isso não é um comportamento natural do consumidor, mas sim uma mecânica implementada pela própria indústria para segmentar o mercado à sua própria escolha e assim dividí-lo. Pergunte-se porque a Microsoft entrou no mercado de processadores de texto, varrendo o WordPerfect e o Lotus, mas nunca mexeu de verdade com o mercado da Macromedia (agora comprada pela Adobe) ou da AutoDesk.

Existem, entretanto, vantagens na adoção em larga escala de uma mesma plataforma. A mais nítida é a compatibilidade. Os usuários podem executar a mesma aplicação em diversos equipamentos distintos. Eles poderiam até trocar aplicações entre si se isso não fosse ilegal na maioria dos casos. Entretanto esse benefício é pouco se comparado com os problemas verificados e a criação de padrões de compatibilidade seria o bastante para criar o ambiente necessário para essa possibilidade tornar-se uma verdade. Isso é assunto para outro artigo, mas por hora basta dizer que é óbvio que não é interessante para quem domina o mercado permitir que outros sistemas executem seus binários ou que haja um binário universal compatível com todos; já que é a incompatibilidade entre plataformas o grande passaporte para a manutenção do domínio de mercado, como explanado até aqui.

Rodando programas de outras plataformas
Usuários e desenvolvedores de plataformas mais “alternativas” normalmente sentem carência de aplicações consagradas. Principalmente usuários que migram de uma plataforma para outra que trazem consigo a experiência de uso de aplicações de talvez eles não encontrem em seu novo sistema de escolha. Essas e outras necessidades levaram à busca de formas de conseguir executar aplicativos de certas plataformas sobre outras. Existem também necessidades localizadas no segmento corporativo como manter compatibilidade com aplicações de legado e implementar novas funcionalidades mas nesse artigo vamos nos ater ao segmento desktop.

Entre as formas mais comuns de buscar a possibilidade de rodar aplicações de outras plataformas encontramos a emulação, a implementação direta de API (também chamada de Camada de Compatibilidade) e a Virtualização Plena ou Nativa. Vamos discutir aqui essas três técnicas distintas e sua aplicabilidade prática hoje lembrando que não são as únicas existentes. Que fique claro entretanto que essas são consideradas técnicas de virtualização em um nível ou outro apenas diferindo nos conceitos básicos do que é virtualizado de fato.

Emulação
É um processo pelo qual busca-se reproduzir da forma mais fiel possível e em diversos níveis o comportamento de certa plataforma de hardware ou software. Em teoria um programa rodando sobre um emulador não deve ser capaz de descobrir que não roda sobre sua plataforma original. A grande vantagem da emulação consiste no fato de almejar reproduzir todos os estados da plataforma alvo resultando portanto em um grau muito elevado de compatibilidade com a plataforma original. A emulação penaliza severamente o desempenho pois cabe ao software emulador reproduzir todo um ambiente formado pelo hardware e pelo software original, entretanto na maioria dos casos esse aspecto guarda pouca importância já que hoje a emulação é usada principalmente para recriar sistemas antigos e de legado que apresentavam desempenho várias vezes inferior aos sistemas atuais. Entretanto a emulação de sistemas atuais com o objetivo de rodar aplicativos de outras plataformas mais modernas apresenta-se como um verdadeiro desafio técnico.

Some à esse quadro a falta de documentação disponível sobre as plataformas proprietárias e a emulação torna-se um passo tão difícil quanto a própria ação de portar aplicativos entre uma plataforma e outra. A ausência de informações sobre o funcionamento e problemas de desempenho impedem, por exemplo, que haja um emulador realmente funcional de PlayStation 2, um console lançado há mais de meia década. Esses mesmos problemas também impedem, por exemplo, a criação de um emulador de plataforma Windows para outros sistemas, como o MacOS e o Linux. Um emulador de Windows deveria reproduzir com alto grau de fidelidade o comportamento interno do sistema operacional da Microsoft algo impossível sem que ela própria colabore com o processo. Mesmo que esse nível de reprodução fosse atingido, provavelmente o impacto na performance da execução de programas tornaria a experiência um pouco decepcionante, especificamente para aplicações mais exigentes. Ainda assim seria possível executar de forma relativamente normal boa parte das aplicações.

De fato a emulação é uma das técnicas mais usadas para a criação de máquinas virtuais de uma plataforma sobre essa própria plataforma (não confundir comVirtualização Plena). Isso deve-se ao fato de que todo o comportamento esperado para a plataforma já encontra-se implementado e em funcionamento. Mesmo para plataformas diferentes em certos níveis mas com grandes semelhanças operacionais a emulação tem sido fortemente usada com desempenho aceitável. Exemplos bem sucedidos de emuladores de plataforma x86 são o Parallels e o iEmulator e Microsoft VirtualPC para PPC para plataforma Mac. Todos esses emuladores dedicam-se à emular um computador x86 típico para que sobre ele se possa executar um outro sistema operacional e seus aplicativos. Para sistemas operacionais UNIX as alternativas são o Bochs e o Qemu que também permitem a instalação de outros sistemas operacionais além do Microsoft Windows. Um ponto em comum entre esses emuladores é a forma como eles funcionam. Normalmente um arquivo armazena as configurações da máquina emulada e também uma imagem de partição que serve como HD para o emulador. Dentro desse arquivo um outro sistema e aplicativos são instalados e não tem nenhum conhecimento do que exista fora desse HD virtual. A maioria dos emuladores usa técnicas para, intencionalmente, poderem ser reconhecidos como diferentes de um sistema real podendo assim fornecer ao sistema hospedado meios necessários de acessar dispositivos fora da máquina emulada, como placas de redes, dispositivos USB e outros.

Camadas de Compatibilidade (ou implementações diretas de API)
São camadas ou layers de software implementados para criar compatibilidade binária de um sistema com uma plataforma alvo. Pode-se usar essa técnica para criar compatibilidade inter ou intra-plataforma, ou seja, podemos tornar compatíveis entre si sistemas totalmente diferentes ou sistemas semelhantes de uma mesma classe. Sua vantagem é o desempenho pois a compatibilidade implementada em camadas funciona tão bem e quase tão rápido quanto software nativo da plataforma. Entretanto para isso é necessário que a camada seja implementada durante a compilação do sistema operacional. Isso exige, portanto, que o proprietário do código do sistema operacional autorize ou ele próprio efetue a implementação. Assim a única forma de efetuar isso no Windows passa pela Microsoft, fazer isso no MacOS passa pela Apple.

Para contornar as dificuldades óbvias desse processo os desenvolvedores criaram uma técnica de implementação em tempo de execução, que promove alguma degradação no desempenho mas que ainda mostra-se como uma opção melhor do que a emulação. Implementações em camadas em tempo de execução são comuns em plataformas UNIX e existem até para o ambiente Windows. A mais conhecida delas é o Wine uma implementação da API Windows para sistemas *nix. Com o Wine pode-se executar aplicações Windows em Linux, BSD, MacOS e virtualmente em qualquer outro sistema, pois o Wine é software livre e pode ser portado por qualquer pessoa para qualquer plataforma. Entretanto o Wine é um trabalho de longo prazo que não conta com nenhuma colaboração da Microsoft para atingir seu objetivo, ao contrário aliás. A Microsoft tem tomado esforços para impedir que suas aplicações Windows rodem sobre Wine em outras plataformas. O trabalho dos desenvolvedores do Wine baseia-se em engenharia reversa, isto é, entender o que um programa espera da API e escrever rotinas que reproduzam esse comportamento. A diferença desse processo para a emulação é que o Wine não procura reproduzir o comportamento de um Windows real mas apenas suas interações com os aplicativos da plataforma alvo.

O Wine possui um primo comercial chamado Cedega de uma empresa chamada Transgaming. O Cedega é uma camada de compatibilidade construída sobre o Wine que busca permitir que jogos da plataforma Windows possam ser executados sobre Linux. Sua aplicabilidade e desempenho são muito bons e a empresa tem contribuído bastante para a evolução do Wine. Atualmente além de jogos é possível rodar softwares bastante complexos como o MS Word e o AutoDesk AutoCAD sobre o Wine.

Camadas de compatibilidade são usadas no WindowsXP para permitir suporte a software legado. Aplicações antigas de Windows 9x e NT usam camadas para rodarem adequadamente no WindowsXP. Mas não são essas as únicas camadas disponíveis para o sistema da Microsoft. O Cygwin é um porte da API do Linux para o MS Windows. Ele promove um ambiente Linux-like sobre a plataforma Windows o que permite que uma série de serviços e funções comuns apenas a ambientes UNIX estejam disponíveis, como um servidor gráfico X, por exemplo. Isso não significa, entretanto, que aplicações Linux possam rodar no Windows, como faz o Wine. Aplicações Linux precisam ser compiladas especificamente para o Cygwin antes que possam ser executadas, mas uma vez que isso seja feito as aplicações rodam normalmente. Não é um problema para usuários do Cygwin, já que seu objetivo é permitir o uso em um ambiente misto de uma mesma aplicação que tenha seu código fonte disponível.

Não exatamente uma camada de compatibilidade o POSIX (Portable Operating System Interface) busca ser uma padronagem que permita que qualquer sistema operacional compatível rode qualquer aplicação desenhada para o padrão. É o POSIX o responsável pelo fato de que diversos sistemas operacionais distintos consigam compilar e/ou executar uma mesma aplicação. Extremamente forte no mundo UNIX o padrão POSIX foi normatizado pela ISO 9945 e só isso deveria servir para que nunca tivéssemos essa discussão. Diversos outros sistemas adotaram compatibilidade com o POSIX como o BeOS e atualmente o MacOS X. Camadas de compatibilidade POSIX foram criadas para diversos sistemas, mas a constante relutância de algumas empresas em aceitá-lo e seu contínuo esforço de implementar um padrão próprio acabaram por inviabilizar sua aplicação generalizada pelo mercado low-end. Atualmente um novo layer está sendo discutido e implementado, chamado Single UNIX Specification o novo padrão busca manter compatibilidade para aplicativos e de funcionamento entre todos os sistemas Unix-like.

Virtualização Plena ou Nativa
Normalmente descrita como a organização de recursos computacionais ou de um subconjunto destes de forma que gerem mais benefícios do que em seu estado original a virtualização plena pode, em termos mais gerais, ser vista como o uso lógico de recursos reais. Podendo ser implementada em software ou em hardware a virtualização plena envolve o manejo de recursos computacionais lógicos (virtuais) de forma a obter melhores resultados finais do que aqueles produzidos pelo simples uso dos recursos reais. A virtualização plena permite assim a execução de programas de um sistema operacional sobre outro desde que ambos funcionem e estejam rodando sobre a mesma arquitetura de hardware. Essa abordagem reproduz virtualmente apenas o estritamente necessário para isolar o sistema convidado do hospedeiro e repassa diretamente ao hardware as requisições do sistema aninhado, daí a necessidade de ambos operarem sobre a mesma plataforma. Essa também é a razão para seu desempenho superior se comparada com técnicas de emulação usadas por certos sistemas. A Virtualização Plena é usada pelo mais conhecido programa de virtualização do mercado soho, o VMWare e também pela versão x86 do MS VirtualPC. Ambos usam a virtualização plena para criar uma máquina virtual x86 básica e que pode executar diversos sistemas operacionais diferentes. Rodando em Windows e Linux o VMWare pode carregar diversos sistemas operacionais ao mesmo tempo, todos independentes, e trabalhar com eles em rede e como servidor de aplicações. O desempenho das virtualizações plenas costumam ser melhores que dos emuladores também devido à recursos de hardware implementados nos novos processadores como multi-threading e instruções de execução paralela.

A virtualização por hardware já é usada há muito tempo, principalmente em computadores de grande porte e mainframes. Máquinas IBM com arquitetura POWER podem virtualizar centenas de processadores e rodar um número muito grande de aplicações criando redundância dentro de um único gabinete. É possível limitar o acesso a discos e a memória para cada máquina virtual e isolar cada sistema ou fazê-los trocar informações se necessário. Instruções específicas para virtualização permitem que softwares possam abrir novas máquinas e carregar ou fechar sistemas operacionais. Sistemas distintos podem ser carregados sem que um afete a execução dos demais. Entretanto também nesse caso o sistema operacional hospedeiro e os sistemas visitantes devem ser preparados para esse tipo de execução o que faz com que o Linux seja a primeira escolha para esse tipo de aplicação.

Intel e AMD que possuem maior penetração de mercado no segmento de desktops já estão incluindo tecnologias de virtualização em seus processadores mais recentes. A Intel com o Vanderpool e a AMD com o Pacifica almejam criar condições em suas plataformas para servidores de alto desempenho que usem suas instruções de virtualização para a execução conjunta em paralelo de vários sistemas operacionais ao mesmo tempo. A necessidade de reduzir o consumo de energia e geração de calor dos processadores levou os fabricantes à uma busca de maior eficiência de processamento por cada Watt utilizado. O resultado é que um processador das últimas séries de Intel e AMD com cerca de 2GHz de clock consegue facilmente superar chips mais antigos trabalhando a freqüências maiores. Entretanto, como os novos processadores podem executar um número bem maior de instruções a cada ciclo manter uma máquina em funcionamento sem aproveitar todo esse potencial também acaba desperdiçando energia. A solução então é concentrar mais tarefas sobre cada processador, aproveitando assim ao máximo cada watt elétrico usado pela peça. Mas no mundo corporativo empilhar diversas tarefas em uma mesma máquina significa arriscar perder mais dados caso uma falha ocorra. Ao rodar um servidor web e um servidor de aplicações na mesma máquina corre-se o risco de perder produtividade caso um ataque de DoS ocorra deflagrado da web, por exemplo. Ao virtualizar uma destas aplicações, digamos o web server, isolamos o servidor de aplicações que nada sofrerá caso um ataque ou pane ocorra. Assim emprega-se de forma mais segura e mais racional os recursos computacionais.

Virtualização no Desktop
Já entendemos as diferenças entre os distintos tipos de virtualização e observamos sua importância para servidores e para empresas. Sabemos que um MS VirtualPC rodando em PPC é uma emulação e um MS VirtualPC rodando em x86 é virtualização plena e descobrimos que podemos rodar algumas aplicações para Windows nativamente em sistemas UNIX com o auxílio de uma camada de compatibilidade como o Wine. Qual a importância desse processo para o usuário de computadores no desktop? Muita.

Como foi dito diversos usuários de plataformas com menor participação no mercado interessam-se por rodar aplicativos de outros sistemas, notoriamente aplicativos para MS Windows. Usuários de MacOS normalmente interessam-se por jogos e produtividade, como CAD enquanto que usuários de Linux preferem aplicativos de desenvolvimento de conteúdo, gráficos e também por jogos. Depois da mudança de hardware da Apple para Intel x86 as coisas facilitaram um pouco. Agora todos usamos o mesmo hardware e assim basta conseguir reproduzir a API ou emular o sistema Windows para conseguir executar aquelas aplicações, certo? Quase isso.

A solução de reprodução de API mais difundida no mercado Cedega/Wine ainda demonstra certa imaturidade precisando de muitas configurações, ajustes e paciência para que algumas aplicações possam rodar, mas a maioria delas simplesmente não roda. O Cedega consegue rodar uma lista apreciável de jogos, mas possui um custo a ser pago, em dólar. O Wine, livre e gratuíto, conta com diversas melhorias e aprimoramentos, mas é entregue sem nenhum suporte, deixando o usuário à própria sorte.

Os pacotes de emulação e virtualização disponíveis funcionam bem e até podem ajudar para resolver uma situação ou outra, mas mesmo eles talvez não sejam suficientes para rodar o Half Life 2, por exemplo, a não ser que sua máquina seja realmente muito potente. E ainda existem os custos de licença da ferramenta e do sistema operacional visitante, já que mesmo para rodar o Windows dentro de uma máquina virtual você deve pagar sua licença.

Para usuários de MacOS X talvez ainda seja mais interessante aproveitar o BootCamp para rodar um jogo ou uma aplicação disponível apenas para o Windows, depende da performance conseguida com a dupla Parallels, VirtualPC. Para usuários de Linux além do dual boot com o sistema da MS resta buscar funcionalidade com o Wine e esperar melhorias na API ou tentar usar os emuladores e virtualizadores disponíveis.

Nesse campo todos estão querendo alguma coisa. A Apple quer consolidar a posição de seu hardware como de único computador que você precisa, daí o investimento em soluções para rodar o MS Windows nos computadores com o símbolo da maçã. A MS não quer perder sua posição de mercado e manter o Windows rodando no maior número de computadores possível. E o Linux almeja conseguir uma posição melhor no segmento de desktops. Todos estão investindo em tecnologias de virtualização para conseguir executar aplicações dos concorrentes sem deixar que suas próprias aplicações pulem a “cerca”. Não seria bem mais fácil desenvolver um padrão comum e deixar o usuário escolher qual sistema quer usar?

Impacto negativo
Discutimos no começo do artigo sobre o círculo vicioso de base instalada versus quantidade de aplicativos. A virtualização aparece como uma boa alternativa para quebrar esse ciclo e atrair novos usuários. É assim que a Apple está pensando e tem investido em propagandas que colocam o Mac como um computador que roda MacOS e Windows, sendo o único computador que você precisa. Parte da comunidade de usuários de Linux também pensa que a melhor forma de atrair usuários de Windows é mostrar a eles que podem manter suas aplicações. Acho que todos esqueceram a lição ensinada pelo OS/2.

O OS/2 foi um sistema operacional desenvolvido pela parceria entre IBM e Microsoft para substituir o MS-DOS nos computadores IBM PS/2 https://en.wikipedia.org/wiki/IBM_Personal_System/2 . O OS/2 poderia executar nativamente suas próprias aplicações e aplicações de MS-DOS, sem emulação ou virtualização, via implementação de API. Mais tarde, após o lançamento do MS Windows, o OS/2 executava nativamente também as aplicações 16-bit de Windows. Em certas versões do OS/2 o MS-Windows 3.1 acompanhava o produto e era instalado ele próprio como uma aplicação que poderia ser aberta. Usando o OS/2 Warp você poderia rodar aplicações nativas de 32-bit, aplicações MS-DOS, aplicações Windows 16-bit e sistemas Windows 3.1 completos, quantos quisesse. Rodar todas as aplicações do mercado parecia então uma grande vantagem competitiva para o OS/2 sobre o próprio Windows. Então os desenvolvedores começaram a se perguntar: pra que escrever aplicações OS/2 se ele executa programas de Windows?

O resultado é que as aplicações nativas de OS/2 eram raras e normalmente desenvolvidas por pequenas empresas ou programadores em tempo livre enquanto o mercado era enxurrado de aplicações para Windows. Quando a MS mudou a API do Windows para o Win95 e não licenciou o uso para o OS/2 a plataforma da IBM não havia amarrado nenhuma grande empresa de desenvolvimento. As grandes haviam colocado dinheiro em software para Windows e agora precisavam proteger esse investimento e não havia grandes aplicações para OS/2.

Se todos os outros sistemas rodarem bem aplicações de Windows novamente os desenvolvedores não terão motivos para investir em outras plataformas e esse é o panorama obscuro que as possibilidades de virtualização discutidas aqui podem apresentar para MacOS e Linux.

relacionados


Comentários