Após rumores do Surface Phone, Wine quer rodar apps Windows no Android

android-windows-10-xiaomi

Será que os smartphones um dia se tornarão potentes a ponto de rodarem programas e jogos mais exigentes? Bem, se depender da boa vontade dos desenvolvedores é bem possível.

Rumores altamente confiáveis apontam que o Surface Phone, próximo dispositivo móvel da Microsoft, poderá rodar programas x86 em dispositivos com processadores ARM, um grande feito não só para a empresa de Redmond mas para o rumo da tecnologia como um todo.

Mas se você já usou o Linux alguma vez na sua vida, provavelmente sentiu falta de algum programa que só o Windows possuía. Para suprir tal lacuna, era necessário se valer do emulado chamado Wine.

Agora, ficamos sabendo que o Wine não ficará restrito apenas ao Linux e Mac, mas chegará ao Android.

Mas tem alguns poréns….

O lançamento do Wine 2.0, que acontecerá entre Dezembro e Janeiro, terá suporte para o DirectX 11 o que significa que o usuário conseguirá executar jogos mais recentes, concebidos apenas para Windows, em sistemas Apple e Linux. No entanto ainda não será nesta versão que haverá suporte oficial para o Android.

Na verdade, a Wine para Android só tem previsão para funciona em Chromebooks com processadores da Intel. Além disso, para funcionar smartphones com Android seria necessário ter um processador x86 também, algo que a minoria esmagadora possui. Para celulares, ainda não existe previsão, mas é uma possibilidade. Outro problema para o sistema do Google é que a Intel cortou o suporte para o seu sistema móvel.

Bem, esperamos que a Microsoft faça o dever de casa, e também vamos torcer para que o Wine no Android funcione e se torne popular, seria só mais um incentivo para o Surface Phone e seu Continuum.

O que vocês acham do Wine?

105 comments on “Após rumores do Surface Phone, Wine quer rodar apps Windows no Android

    1. Não fala isso, coisa feia, o povo do Android não admite que falemos que o Android é emulado, mas é emulado e pronto, roda numa Máquina virtual ART, mas eles, falam que não é emulado… Vai entender.

          1. Funciona? Recentemente comprei um J5 e só trava. Em contrapartida, tenho um 640 XL fará um ano e meio e, apesar de também travar, isto ocorre com uma menor frequência. Além do mais, o próprio sistema W10M tem funções que no Android só se terá acesso através de um app. E, ainda, tenho uma certa sincronização com meu PC pelo W10M, o qual não tenho no Android. Única vantagem do meu J5 é que o Android possui uma loja com mais apps, porém, em sua maioria (uns 99%) inúteis.

          2. Funciona sim.
            Vamos la. Que funcoes? Tenho uma sincronização perfeita entre meu zenfone 2 e meu pc.
            99 inuteis? Sei…contra outra.

            E claro que j5 trava. Compra um android customizado com touchwhiz barato. Android barato tem que ser puro e no minimo com 2 gb de ram

          3. Moto Maxx top de linha não fiquei um mês com ele por engasgava mas que Moto G que também trava. Nexus 4 e 5 nunca tive boa experiência de uso do sistema tanto que por causa do Nexus 4 que comprei meu primeiro Windows. Posso contar nos dedos quantas vezes cada um dos meus aparelhos travaram. Você ainda no final diz que Android tem que ser puro e ter 2Gb de ram como requisitos mínimos. Eu comprei um com 4 espero que funcione ja que tem o dobro de ram.

          4. Como voces conseguem tal proeza? kkkk
            Ja tive muitos androids. O unico que tive problema foi lg g3 beat. Era uma porcaria. Agora, zenfone 6, 5, 2, nexus 5 (ja tive 2), z3 compact…nunca tive problema…e olha que instalo coisa pra caramba hein

          5. Pois é, o mais legal é saber que tem muita gente que consegue essas proezas que inclusive aparece direto lá do grupo do Android…

          6. Engraçado tive um Xiaomi Mi4 e hoje tenho um Oneplus One e Oneplus 3 e nunca tive esse travamento todo que as pessoas dizem, nem jogando..e também tive um Lumia 920, quando ele rodava no windows phone 8.0 era excelente também raramente travava, com o windows phone 8.1 a quantidade de retomando já ficou maior..e com a versão do windows 10 insider nem se fala..nenhum sistema é perfeito, o Android trava? claro que trava em aparelhos de configurações mais modestas, mas o windows 10 também trava, principalmente nos “Lumias Lagados” da geração X20 e X30.

          7. O JAVA é um tiro no pé de um sistema, estive desenvolvendo aqui o sistema na empresa onde trabalho, em linguagem JAVA, e o acumulo de lixo é impressionante. Ele consumiu os incríveis 3.99 GB de RAM no NetBeans (IDE de desenvolvimento) e acumula muito a paginação e atribuições em cache… Pra resolver isso tenho que reiniciar o JAVA, sem contar que quando a JVM começa a alocar memória de mais, o sistema que eu uso (Fedora) começa a travar… Android melhorou muito, mas uma hora ou outra você passará por isso por causa do JAVA e a máquina virtual dele pra interpretar os apps..

          8. As vezes dar uma travada? ja passei por isso…mas acontece com todo sistema, pra falar a verdade. Porém nao vou entrar na parte de programação pois nao sei nada, mas realmente vejo muitas criticas ao java mesmo

          9. Android não usa Java Virtual Machine(JVM), pois o funcionamento é completamente diferente e os bytecodes são incompatíveis.

          10. Dizem que não usam, mas o JIT ou o que o android usa funciona da mesma forma … A Oracle já entrou com processo contra a Google por usar o JAVA de uma forma modificada (alterando a ideia de universalidade da linguagem)

          11. Entrou com um processo e perdeu, pois o Android não usa uma JVM. Existem diferenças no funcionamento da DVM e JVM: https://aatul.me/2013/04/17/dvm-vs-jvm/

            Assim como o Android não usa o SHM e usa o ASHMEM para gerir a memória compartilhada: http://elinux.org/Android_Kernel_Features

            Por exemplo se vc quiser rodar PostgreSQL no Android vc tem q compilar um kernel com SHM, pois ele foi removido do Android.

            Só para constar quem tentou fazer uma JVM e queria quebrar a universalidade foi a Microsoft. Ela pegou a especificação do Java, criou uma VM e chamou de JVM, porém os bytecodes eram incompatíveis com outras JVM’s e a Sun processou a MS na época. Diferente da Google q criou uma VM e converte os bytecodes Java em bytecode para o Android, lembrando q existem várias ferramentas de “conversão” de bytecodes entre linguagens e nem por isso eles são processados.

          12. Sim sou chato 🙂 Pessoal fica repetindo mentidas sobre Android/Windows/Linux/Mac e vc quer q fique como verdades? Maioria lá e aqui mal testou algo e fica vivendo de suposições, eu sou tão fanboy e tenho um Lumia 925 e tive vários Windows Mobile pq eu desenvolvia para eles, vc não me vê falando mal dele ou metendo o pal no Windows 10 Mobile. Android nem de longe é perfeito, na verdade nenhum SO é, mesmo alguns falando q X resolve tudo ou Y. Linux também não é a melhor solução, por isso existem outros kernels e SO’s.

        1. (********* Principio de Programação ***********)
          O problema é o seguinte: Pra emulação de uma máquina dentro de uma outra máquina, é necessário ter o dobro de processamento e o dobro de memória, segue a lógica de divisão de um estrela do mar… Você tem uma potência e ao dividi-la vc terá duas potencias pela metade, ou seja, para um Smartphone que possui sistema emulado (JVM) que usa Java (no caso Android) será necessário o dobro de processamento e memória pra entregar as configurações descritas por ele, isso não ocorre, por exemplo, com o iPhone.
          Seria bacana se o Google largasse de vez o JAVA (parasse com a emulação) e utilizasse de APIs e Frameworks do SWIFT.

          1. Na verdade, pra emular você não precisa necessariamente do dobro do hardware, esse “principio” nao existe.

          2. Para obter uma experiencia de acordo com a configuração da emulação é necessário o dobro do hardware… Quem é programador sabe do que estou falando, JAVA é interpretado.

          3. Também sou programador, e sim, é necessário um hardware melhor para a emulação ser boa, mas não necessariamente o “dobro”, isso que eu falei, bom dia 😉

          4. Ele é interpretado em tempo de execução, ou seja, ele é pré-compilado gerando arquivos .class que serão INTERPRETADOS pela JVM no tempo de execução e para ter uma performance maior a JVM guarda as informações interpretadas por um período de tempo, caso seja necessário reutiliza-las já estarão pré-prontas. Vejo que quem não entende é você; Tenha um bom dia

          5. Exato é feito em tempo de execução, ela é hibrida assim como C# e outras linguagens q são usadas por ai. Lembrando q a MS está com esse projeto aqui: https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110).aspx Mas falar q ela é “interpretada” e q por isso demora o dobro de outras linguagens é um absurdo. Vc dá a entender q ela é igual a php e outras linguagens scripts q são somente interpretadas. E sim entendo q ela não roda nativamente, pq essa é uma das vantagens e desvantagens dela.

          6. De boa, é q o pessoal lê e entende isso q “leva o dobro de instrução”, e existe uma diferença absurda entre elas e como sempre existem vantagens e desvantagens. Sim essa é uma das desvantagens do Java, porém vc consegue reduzir isso modificando alguns parâmetros do GC mas nem tudo são flores. Assim como se vc fizer um código em C# o GC também irá afetar o desempenho do programa, e por exemplo se o programador não fizer certo no C a liberação e reutilização da memória pode ficar mais lento q o Java ou outra linguagem q usa GC. Porém esse consumo excessivo não é só no Java, vejo que a maioria dos novos programadores não se preocupa com o tipo de tamanho das variáveis, pois hj em dia memória RAM é barata e colocam tudo Long com milhares/milhões de objetos na memória mesmo sem a necessidade de se usar um objeto, ou até se o campo é de 2 posições numérico e me coloca “Long” em vez de usar um byte. Ou até mesmo os q usam String em vez de StringBuilder q afeta drasticamente o desempenho, pois as Strings são estáticas.

          7. É isso é verdade, foi o sofrimento para os novos DEVs do WP8 que a Microsoft verificada de forma Drástica o uso excessivo de memória. O bom era que o sistema eliminava automaticamente a execução do app quando o limite de memória atingia, pra não prejudicar o sistema, infelizmente quem sentia isso era o usuário 🙁

          8. Vão me chamar de hater mas essa é verdade, o gerenciamento de memória no WM 5-6 não era muito bom também. Pq se vc arrastasse simplesmente os Controls o código gerado para executar era um atendado aos olhos( Assim como a maioria das IDE, não importando linguagem ), ele recriava um objeto de Font para cada elemento não reutilizando o mesmo, fora outras enumerações q também eram criados novos objetos se todos iriam ser digamos “Top+Left”. E como vc sabe os aparelhos mal possuíam RAM e vc tinha q batalhar por cada byte =/ Tinha uma tela no sistema q demorava 10 segundos para carregar completamente em alguns aparelhos, fiz um programa para otimizar o fonte do “Designer” e criei Controls usando o padrão Proxy e reduzi para 3 segundos, claro q fiz um método para “desfazer” para permitir a edição pelo VS. ListView do WM mesmo era um sofrimento quando vc colocava milhares de registros, a solução era vc criar um “scrollbar” e controlar uma lista limitada de 7-10 registros visíveis para ganhar velocidade. Ou vc era um pouco mais hardcore e usasse o canvas para desenhar um table, pq era isso ou ficar escutando q era lento o scroll pq cada add/remove disparava uma validação….

            O que quebrou mais ainda com o WM 6.5 foi a “alta resolução”, a MS teve problemas graves com gerenciamento de memória. Ao ponto do SO começar a emitir OutOfMemory entre os componentes do Windows e como explicar para o cliente q o problema era no SO, isso depois de vc ficar semanas com um aparelho testando e não acontecendo o erro. Isso aconteceu no Android também e nós ficamos de mãos atadas, pq como vc vai provar para o usuário q o problema não é com vc. No WM 6.5 eu descobri pq vi q as sombras dos componentes começavam a “sumir” e dali para frente todo programa q usasse uma “grande” quantidade de memória era afetado, seja ele de terceiro ou até mesmo da MS.

          9. Pois é, vi um problema semelhante com o WP8.0, onde o próprio componente criado pela Microsoft falhava por falta de memória ou simplesmente congelava. Nessa época eu corri atrás de ajuda com o próprio pessoal da Microsoft e eles não sabiam me responder, alguns desenvolvedores disseram no fórum que simplesmente não tinha solução o jeito era esperar uma atualização do SO pra ver se a Microsoft iria corrigir. No fim das contas ela corrigiu, mas como dizer para o usuário que o defeito está no SO e não no software? É complicado. (Esse componente era o WebBrowser)

          10. Já vi muito disso, não importa o SO ou linguagem sempre vai ter algo q está fora do alcance e vc tem q dar um “jeito”. Fugimos completamente do tópico do Wine, mas só para rir um pouco eu descobri um gargalo sem querer no software antigo q rodava somente em Windows, quando fui testar um possível port dele para Linux usando o Wine. Ele tinha um processo q tinha um painel com todos os processos mostrando em várias progressbar, até ai tudo bem vc pensa “atualizar uma progressbar é rápido”, o que descobri q um processo no Windows visualizando essa tela demorava até 2-3 horas dependendo do tamanho da base e nos meus testes no Linux demorava 45 min a 1 hora olhando para ela e 15 min se vc colocasse na workspace do lado(sem mostrar a tela), ai descobri q o Wine gerenciava “melhor” os “repaints” da tela. Demorei para provar para o outro programador q era um baita problema, mas no final ele mudou e o processo e no Windows reduziu para uns 30 min. Eu sou meio chato com esse negócio de velocidade, peguei essa mania com um q trabalhava aqui, ele me enchia o saco quando eu era novato pq meus códigos não eram altamente otimizados, um exemplo q vc usa contains antes de adicionar no Map em vez de usar get e testar se é null, outra é utilizar o bitwise para controlar permissões etc.

          11. meu 930 tem 2 de ram, e a otimização do edge é tão porca que ele não consegue as vezes deixar duas abertas

          12. “Muito sobre essa coisa de o java ser mais lento se deve ao fato de ele ser interpretado e o C não. Tipo, entre o C e o hardware não tem nada. (A não ser o SO claro…). Mas entre o java e o hardware tem o JVM ainda… ou seja, mais uma camada de software.
            Eu não li toda essa matéria, mas pelo q eu vi assim rápido, tá dizendo que implementações atuais do JVM atingem uma performance consideravelmente maior se comparada com o C. No caso ele tava falando de alocação e liberação de memória.
            Eu concordo que inovações tecnológicas podem fazer com q a JVM atinja uma performance bastante alta que então leve a uma compensação do fato de ter uma camada de software a mais com relação ao C.
            Eu não sou defensor de nenhuma das duas… na verdade eu gosto mtu de programar em todas as duas. Eu gosto do controle do C e do nível de abstração q o Java proporciona. Mas eu vejo q futuramente o Java pode conseguir se igualar com o C. Quem sabe computadores com JVM’s implementadas no hardware… ” extraído de:

            http://www.unidev.com.br/index.php?/topic/20275-lendas-urbanas-sobre-a-performance-da-java/

          13. Google não roda Java no Android, e não faço ideia de onde vc tirou esse principio de programação completamente errado.

          14. Então o Android uma JVM ( https://docs.oracle.com/javase/specs/jvms/se7/html/ ), interessante vou tentar rodar um bytecode aqui ¬¬’

            “Standard Java bytecode executes 8-bit
            stack instructions. Local variables must be copied to or from the
            operand stack by separate instructions. Dalvik instead uses its own 16-bit instruction set that works directly on local variables. The local variable is commonly picked by a 4-bit “virtual register” field. This lowers Dalvik’s instruction count and raises its interpreter speed.”

            https://en.wikipedia.org/wiki/Dalvik_(software)

          15. Se pensar assim o Xamarin usa “Java” 🙂 O Google escolheu Java pela grande quantidade de devs, senão seria C++ ou sei lá podiam inventar uma. Mas acho q não faria muito sucesso, lembrando q existem compiladores de outras linguagens q criam o DEX.

      1. Cara para de repetir essa mentira, já te expliquei milhares de vezes a diferença do Android e de uma JVM, E se vc chama o Android de “emulado” por usar VM, quero relembrar q o Windows usa também VM para conseguir rodar apps usando CLR. Vc realmente é um ignorante mor, pq cansei de explicar pq vc não consegue rodar um bytecode JAVA em uma VM no Android, pois ambos possuem diferenças no tamanho de cada instrução e de como cada VM funciona. E fico mais indignado é o pessoal falar tanta besteira como se fosse verdade sobre Java, se nem ao menos usam a linguagem ou nem são programadores. Uso java desde a versão 1.3, sei as desvantagem e vantagens dela e uso ela gerenciando bases com milhões de registros todos os dias. Vc me falou uma vez q 64 bits dobrava desempenho, uma mentira absurda q só leigos ficam republicando mesmo depois q alguém prova na prática q isso não é verdade. A maioria dos programadores mal sabe a diferença de C e C++, não faz ideia da diferença de struct e class no C#, não sabe no java quando usar Long e long, não sabe o que é um hash, não faz ideia q vc consegue usar cada bit separadamente de um byte… Aqui existem alguns benchmarks comparando linguagens: http://benchmarksgame.alioth.debian.org/u64q/java.html E só para constar Wine é uma camada como o WLS e nem por isso é um emulador como o redator informou, se for assim os programas q usam o WoW no Windows são emulados ¬¬”’

      2. Emulado ou não tá aí funcionando muito bem, vendendo muito bem e tem novos apps funcionando emulado s muito bem! Oq realmente importa está funcionando muito bem é claro

  1. Eu discordo, pois não seria um incentivo ao mítico Surface Phone é sim sua ruína prematura. Por que eu vou pro Windows se todos os programas podem rodar no meu Android, que já possui mais apps do que o Windows 10 Mobile, como Clash Royale?

      1. para defender o wine eu até digo. ele foi criado para programas específicos. pode ser que rode em outros, mas é pura sorte. eu fiquei um tempo vivendo de ubuntu e Linux mint (debian), ví o wine fazer maravilhas específicas. mas de longe dá pra ver que ele não faz milagre.

        1. Eu brinco q o wine foi basicamente para rodar CS, pq nunca vi um fix sair tão rápido quando tinha algum problema no CS era quase instantâneo alguém com a solução nos fóruns 🙂 E sim ele não faz milagre, porém alguns ports usaram ele já q ele é apenas uma camada.

    1. Pq vc acha q a microsoft abandonou o astoria? Pq percebeu q trazer apps de android para windows iria estimular os devs a só desenvolver para o robozinho, agora imagina o contrario.

          1. Só se eles colocassem uma versão propiá e mexessem no código fonte do android. acho que daria mt trabalho e como o cara falou, a galera ia deixar de fazer apps pro w10mobile e prejudicaria os UWPs

      1. Acho que esse negócio de desestimular os devs é meio caído, tanto que ainda existe o Projeto Islandwood (iOS p/ Windows), creio que o problema foi técnico mesmo.

    2. Pq essa compatibilidade é apenas para processadores X86, no caso existem poucos celulares com ele e só vai diminuir, já que a intel abandounou o x86 mobile, ou vc poderiam instalar o remix os em um pc e usar o wine nele

          1. com a popularidade de remix OS subindo as fabricantes podem começar a usá-lo, existem muitos tablets com ele e dual boot com Windows 10, mas isso encarece com a licença do Windows, no caso elas poderiam economizar e quem sabe o cliente usar o wine

    1. playonlinux vs wine vs crossover

      O WINE em si parece ser mais para quem sabe configurar. Já esses outros já vem tudo meio pronto e funcionam melhor.
      Não é muito minha praia, mas trabalho com dois caras que sabem muito sobre Linux e o que fazem rodar no Linux deles na empresa e que em muitos casos rodam melhor que no Windows. Sei lá, mas é bem foda.
      Para meros mortais como eu, nem dá pra acreditar.
      Então, nem tento fazer algo pois pode não funcionar bem e ainda vou sair falando mal por eu não ter dado conta de fazer direito.

      1. Só se a Google mudou os planos, já que o Chrome OS é tido como um fracasso. A Google estava pretendendo criar um outro sistema chamado Fuchsia, para substituir o Android e Chrome OS. Esse tal fuchsia seria um sistema multiplataforma, assim como o W10, mas aí ficaria a velha questão: E os apps? Rodar apps de Android num Desktop? Sendo que a grande maioria não é adaptada para telas maiores. Seria a mesma dificuldade que o Windows 10 Mobile está tendo para acompanhar o PC, só que de modo reverso.

        1. O ChromeOS vem crescendo muito principalmente no uso em educação, como é tido como fracasso?
          Sinceramente aposto que ta dentro do que o Google espera, para um sistema focado em cloud, obviamente o mercado será restrito.
          Eu duvido que o Google abandone duas plataformas de sucesso pra investir em outra. Nem a MS com o WMBosta faz isso.
          Acho que o Fuchsia como várias outras tecnologias, surgem dentro do Google por iniciativa dos funcionários, que a própria empresa incentiva muito isso. Mas viajar na maionese assim é cedo demais. Tipico de site mesmo que precisa de colocar um titulo cool pra ganhar views.
          Dart tbm é bem antiga e nunca colou muito. Acho que o que deve acontecer com as aplicações do Google mesmo são migrar tudo pra Webapps.

          1. Se nem o Linux com toda sua leveza e dinamismo conseguiu bater o Windows, quem dirá um Chrome OS… Webapps? Basear tudo neles é suicídio, apesar de serem um bom incremento, eles não podem ser o foci de um sistema, pelo simples fato de não serem cômodos como uma aplicação independente de internet. Se o Fuchsia não vier à tona logo, vai Flopar.

          2. Dinamismo onde? Em um sistema que não tem nem uma forma unificada de instalar software? Que um usuário básico precisa fazer um curso pra saber como instalar um software lá? A quantidade de vezes que um usuário precisa recorrer a ajudas palalelas para diversos problemas no Linux é muito maior que no Windows.
            Ta ficando mais userfriendly mas está a anos luz de distancia de achar que vai agradar usuários básicos sendo tão trabalhoso e exatamente por isso, nunca, NUNCA vai bater o Windows.

            E é ai que o ChromeOS bate o Linux. Sendo seguro sem ter que perder tempo com anti-vírus e instalando softwares direto da ChromeStore e posteriormente da Playstore, rápido, leve. Eu uso e recomendo muito.

            Eu ainda acredito. Por que seria uma forma de unificar mais facilmente todas as plataformas como Android, AndroidTV, ChromeOs e Chrome.
            Com Dart e AngularJS aí… O Ionic já é muito usado hoje em dia e prometeram coisas legais no 2.

          3. Só nos seus sonhos um sistema baseado em webapps vai conseguir se destacar. Ser seguro é um ponto positivo, mas ser escravo invariável de internet não traz praticidade, e hoje em dia é disso que as pessoas precisam. O Android pode ser líder absoluto no setor mobile, por suas qualidades, mas para fazer uma junção multiplataforma com Android+ChromeOS… A Google vai ter que comer muito arroz com feijão para alcançar o que a MS já alcançou nesse quesito.

          4. Quando me referi a Webapps, também me referi a híbridos que vem ganhando força do próprio AngularJS do Google e a evolução do Javascript. 😉
            Isso ta sendo uma plataforma que não só leva aos móveis, como também leva até as smart tvs.
            O ChromeOS é seguro, sendo aberto, o Windows não sendo fechado. E? A plataforma menos segura sempre será a mais utilizada no mercado, sendo opensource ou não. 😉
            O objetivo do ChromeOS é trazer um sistema seguro, rápido, leve e simples de usar. E faz isso muito bem.

          5. o futuro vai ser webapps, por isso que nadella fala moblie primeiro, nuvem primeiro, pois um aparelho em que seu sistema fica na nuvem, pode hora ser um celular, hora um pc. Outra, google já tem uma linguagem para desenvolvimento de webapps para android, mas pouco difundida em noticias. No futuro vai ser ruim para a apple, já que ela não foca em nuvem

      2. Não serão unificados, o ChromeOS continua sendo ChromeOS porém com suporte a Playstore (ainda em modo desenvolvedor. Há algum tempo atrás dava pra rodar apks no Chrome com uma extensão).
        Mas pensa, o Wine já é uma bosta, piorou emulando Windows, no Android emulado no ChromeOs ainda restrito a processadores Arm.
        Fazer uma matéria digando é ir no extremo da bosta que seria essa aplicação.

        1. Vc já consegue fazer isso desde 2014 em qualquer SO: https://archon-runtime.github.io/
          E a poucos meses o Google colocou essa funcionalidade nativa de rodar apps do Android no ChromeOS, ele basicamente é uma “extensão” do Chrome mas já é oficia e existem aparelhos tanto com ARM e x86: https://developer.android.com/topic/arc/device-support.html

          E Wine não é uma bosta e nem é um emulador…. Só pq não roda todos os programas 100% o pessoal mete o pal, porém ele funciona normalmente com alguns… Quem nunca teve problemas de compatibilidade no próprio Windows com jogos ou programas recentes q nem o modo compatibilidade resolve, algumas vezes a solução é evitar um pacote de atualizar, até a empresa do programa corrigir o problema e se corrigir.

          Acho q ficar distribuindo ódio contra os outros SO’s ou programas q vc mal sabe usar ou funciona é complicado… Vc já testou o React OS? Pq eles fazem um SO compatível com os binários do Windows e colaboram com o Wine e alguns programas rodam nele sem problemas já outros não rodam ainda, e ele seria uma solução para substituir máquinas q usam sistemas legados da MS e vc não possui mais suporte de atualizações de segurança.

          E só uma curiosidade parece q o drawbrige da MS parece q está sendo utilizado para os ports das tecnologias para Linux, quem sabe a próxima contribuição da MS seja com o projeto Wine assim como ela colaborou com o Samba: http://www.zdnet.com/article/microsoft-contributes-open-source-code-to-samba/

          1. Não fui muito com a cara do objetivo do projeto, mesmo nesse caso, o Linux + Wine não seria melhor que React OS?
            Continuo não achando sentido nenhum usar wine android em um ChromeOS e duvido que irá conseguir funcionar de forma convincente. Se estiver vivo até lá, testo. Melhor já usar crouton mesmo.

  2. Só acho que a Microsoft deveria restringir esse tipo de coisa, impedindo que esse modelo sutil de ‘pirataria’ se propagasse, mas tudo bem! =/

    1. Não é pirataria se tiver a licença do programa. Sabia disso?
      Pois o WINE não é um emulador do sistema Windows com um todo e sim uma camada de compatibilidade para rodar programas que rodam no Windows.
      Agora, as DLLs usadas podem ter alguma entrave, mas confesso que nessa parte não posso opinar, ainda.

  3. Wine (originally an acronym for “Wine Is Not an Emulator”)

    WINE é uma camada de compatibilidade.
    E já tentaram, se não me engando, fazer algo para Android há um bom tempo, mas esbarram no tipo de plataforma usada entre outras coisas.

    Já para o Chromebook (com x86) pode sim funcionar melhor.

  4. Irá rodar apenas x86, que são apps que não são otimizados pra touch

    ou seja, o celular teria que ter dois aplicativos pra fazer a mesma coisa.

  5. “Para suprir tal lacuna, era necessário se valer do emulado chamado Wine.”

    O significado de WINE é Wine Is Not an Emulator. Porra, galerinha do mal, pesquise antes de postar.

    WINE, como o próprio nome já diz, não é EMULADOR

    1. Eu aprendi isso há muitos anos com os caras que trabalham comigo. Não entendo como funciona de fato. Mas, é por uma tal de camada de compatibilidade. Sei lá. É quase algo direto.

  6. Quando vocês vão entender que o WINE não é um emulador? Ele é praticamente a parte central do Windows rodando nativamente em ambiente Unix. O desempenho e muito superior e melhor que uma emulação, por isso que ele ainda não consegue executar todos os programas do Windows.

  7. Agora destacam o corte que a Intel fez nos processadores móveis, mas quando os rumores apontavam pro Surface Phone viriam com processador Intel, sempre davam desculpas, rs.
    O foco de rodar um programa Windows realmente é no Desktop. E com Chromebooks com processador Intel, a coisa pode dar certo para programas mais simples sim.
    Emulação é meio que um quebra galho mesmo. Não dá pra exigir muito.

  8. Não entendo essa fixação em querer rodar aplicativos de PC no celular. PC é PC, smartphone é smartphone. São plataformas diferentes, com abordagens (muito) diferentes, principalmente em termos de interface. É inviável utilizar um Word “tradicional” no smartphone, por exemplo, assim como é bem ruim usar aplicativos “touch” no PC tradicional.

  9. algumas coisas me deixam desconfortável.
    para fazer um emulador de app do android no windows, precisa ser perfeito, desde o principio. e mesmo assim o usuário (talvez hater) reclama que “poderia” ter varias funções e criam especulações sobre o assunto, que gera mais sentimento negativos. por coisas desse tipo ninguém nem tenta lançar ou fazer.
    No android cada um só olha o seu umbigo. e faz pra funcionar o que precisa, pode esquentar, drenar a bateria e tornar o sistema instável ou bricar o aparelho. não importa, sempre terá um cara que para chamar a atenção vai falar: -Mas comigo funcionou!”
    agora meu sentimento: daí nos fóruns de android eu meto bala dizendo que “ta tudo uma merda se for assim é melhor nem lançar” e o povo vem dizer que eu sou incoerente e que as coisas não são feitas assim.
    minha conclusão: Dois pesos e duas medidas. se tivesse um programa para o Windows emular os apps de androids, acho que seria o holocausto nos sites de Windows. a Microsoft fez um favor ao não liberar de qualquer jeito aquele “wine”.
    Sorry for my bad portuguese.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *