Configurando o PlayOnLinux: Parte 2

Parte 2 de 2 deste grande tutorial, para todos aqueles que querem entender melhor como o PlayOnLinux (WINE) funciona, ajudando a solucionar os principais problemas de compatibilidade que encontrarem com aplicações e games.

| Se você apoia nosso site, desative o AdBlock quando visitá-lo, inclusive em Mobile!
Os anúncios são poucos e não invasivos. Se quiser contribuir com nosso trabalho, clique em qualquer banner de sua preferência, exceto dos Parceiros. Mais detalhes clicando aqui.

Parte 2

Dividido em 2 partes, nesta segunda parte vou mostrar detalhes do lado técnico sobre DLL’s e bibliotecas para otimizar os games do Wine e explicarei como debugar um game que, uma vez instalado, está problemático.
Também vou apresentar o básico sobre análise hexadecimal de um executável!

Para fins de praticidade, os programas PlayOnLinux, PlayOnBSD e PlayOnMac serão referenciados apenas como PlayOn* ao longo do tutorial! Assim como tais, tudo que aqui for referenciado de configuração para PlayOnLinux poderá ser aplicado no PlayOnBSD e no PlayOnMAC.

Este tutorial requer a leitura da Parte 1
Caso tenha perdido, leia aqui.

Continuando…

Como dito na Parte 1, a equipe de desenvolvimento do Wine reescreveu várias DLLs do Windows, permitindo que elas sejam livres para uso, opensource e ainda sejam compatíveis com os programas originalmente nativos do Windows. É uma ideia muito boa que funciona na maior parte dos programas e games mais antigos.

E, mesmo com a listagem enorme de DLL’s reescritas nativas do WINE, elas por si só não são 100% eficientes.

Temos casos ainda bem comuns de games e programas que utilizam DLLs especificas e originais do Windows e por isso ainda causam muitos erros no sistema. E vou ensiná-los a utilizar um recurso do PlayOnUnix:

Instalação de DLL’s nativas do Windows.

Antes de qualquer coisa, quero deixar claro que:

1. Este tutorial se reserva apenas em mostrar como utilizar um recurso nativo dos programas PlayOn*, que é a possibilidade de aplicar e utilizar DLL’s nativas originais do Windows.
2. Você vai precisar possuir uma cópia original do Windows 7 x32, porque x32 bits é o modo mais compatível do Wine e o 7 por ser obsoleto, o que poderá lhe trazer menos problemas legais. Além disso, sua compatibilidade é maior.
3. Não postarei links de download por estes infringirem termos de uso da Microsoft. Este humilde redator recomenda fortemente que utilizem Windows original para isso.
4. Quem utiliza DualBoot pode se beneficiar disso por ser mais fácil de fazer o procedimento de pegar as DLL’s diretamente do Windows.
5. Façam dos frutos deste tutorial o que bem quiserem; mas não redistribuam suas wineprefixes modificadas com DLL’s originais do Windows extraídas do mesmo, o ato não deixa de violar termos de uso das mesmas e configura como pirataria por serem proprietários da Microsoft.

Recado dado, vamos ao tutorial!

Debugando um Programa

Vou utilizar de exemplo um programa que tentei e consegui rodar aqui chamado APPHotel, da empresa Fator Sistemas, ele é um gestor pra hotelaria. Ele, resumidamente, é um cliente gestor de bancos de dados SQL. Um colaborador executa-o, coloca as credenciais de acesso, abre e pode manusear seu conteúdo como contatos, informações dos quartos, consumo, etc.

Esse exemplo eu citei diversos meios de debugar um programa mas que servem de exemplo pra debugar um game ou outro aplicativo que você tentar executar no PlayOn* e for mal sucedido.

Ao instala-lo num wineprefix limpo sem nenhum adicional e executá-lo com o DEPURADOR, vi que o programa possuía diversos erros logo de cara:

 

O primeiro era erro de “DLL’s não encontradas” o programa chama muitas DLL’s mas não encontra elas. Note a quantidade de DLL’s citadas que estavam ausentes – not found.

Nesse caso você deve ter em mente uma noção de como o programa funciona.
No Windows, no meu exemplo, o atalho possui 2 diretórios, ele chama o .exe na raíz, porém trabalha em cima do diretório …/exe/dll, uma pasta com aproximadamente 50 DLLs do Windows que foram modificadas. O Wine por padrão não suporta trabalhar com o .exe em uma linha e direcionar outra pasta de trabalho em outro campo, tal qual até mesmo o BASH nativamente suporta. – Sabe quando você faz por exemplo “cd ~”? Isso modifica a pasta de trabalho atual, mas o PlayOn* não o suporta por padrão.

Mas existe um método até simples pra contornar isso.

Na pasta /home/$USER/.PlayOnLinux/shortcuts ao abrir a pasta do atalho desse programa (APPHotel) temos:

#!/usr/bin/env playonlinux-bash
[ "$PLAYONLINUX" = "" ] && exit 0
source "$PLAYONLINUX/lib/sources"
export WINEPREFIX="/home/flordeminas/.PlayOnLinux//wineprefix/APPHotel"
export WINEDEBUG="-all"
cd "[...]/APP/Plus/Recursos/Exe/Dll"
POL_Wine[...]/APP/Plus/Recursos/Exe/WinHotelPlus.exe "$@"

Eu não deveria mas encurtei, apenas para demonstração, as linhas com […] no começo!
Portanto em seu sistema você deve dar o caminho completo do diretório sem atalhos.
O que fiz foi demonstrativo pois o caminho era longo e teria problemas no layout do site.

Esse é um padrão de todos os executáveis no PlayOn*. Todos os atalhos na pasta shortcuts tem esse layout.
Note as ultimas linhas, a primeira começa com “cd” e a segunda com “POL_WINE”.
Em cd, eu coloquei o caminho da pasta de trabalho do atalho, em /dll dentro do caminho do APPHotel instalado.
Já na segunda, em POL_WINE, o caminho completo do .exe do atalho do programa.

Esse exemplo serve pra qualquer programa que reconhecidamente possua uma pasta com DLLs do Windows!
Se no Windows seu atalho possuía um diretório de trabalho diferente do atual diretório do .exe, indique-o dessa forma. Assim, seu .exe vai ter á mão todas as DLLs necessárias.

Prosseguindo, uma nova tentativa de executar o programa.
Agora, apresentou um erro diferente:

Esse erro é sobre a ausencia da dll GDS32.DLL, uma dll do Firebird que instalei nesse Wineprefix.
Tambem me era sabido que o APPHotel precisa de uma versão especifica dessa dll. Explorei o conteúdo de Arquivos de Programa/Firebird/Bin, peguei a dll fbclient.dll e copiei para a pasta /DLL do APPHotel.
Assim o apphotel.exe não apenas encontraria a pasta /dll mas também a dll do Firebird! Esse é no caso uma característica do funcionamento do APPHotel, não uma regra.
Renomeei a fbclient.dll para GDS32.DLL, pois era o nome antigo dessa dll. – Conforme nota-se na mensagem de erro, você deveria saber que a GDS32.DLL é uma dll exigida que faz vinculo com o Firebird, sua ausência causa erros.

Mais uma tentativa de execução!

OPA, agora conseguimos progresso!
O programa abre sua tela de boas vindas, onde eu devo definir os diretórios do servidor.

Se o programa rodasse num Windows, ele teria uma pasta remota montada em C:\ com acesso a esse diretório remoto, e dele o cliente faz a conexão com o banco de dados.

No Linux faremos algo semelhante, observem…

Instale o pacote cifs-utils em seu sistema. Baseados em Debian:

$ sudo apt install cifs-utils

Crie em sua /home/$USER um arquivo chamado “.smb” e dentro dele coloque as seguintes linhas:

username=USUARIO
password=SENHA
workgroup=GRUPO # padrão é WORKGROUP

Essas são as credenciais do acesso á conexão SAMBA da pasta do banco de dados do servidor!

Crie uma pasta chamada remoto em /media, assim:

$ sudo mkdir /media/remoto

Agora abra o /etc/fstab com seu editor de textos favorito.
Adicione a ele a seguinte linha:

//192.168.0.xx/app /media/remoto cifs 
credentials=/home/$USER/.smb,users,noauto 0 0

Note a quebra de linha!

Com essa linha, você poderá fazer a montagem da pasta remota.
Note que você deve informar o IP do servidor e seu usuário.

Pra finalizar, edite os parâmetros do disco virtual do seu programa no PlayOn* indo em “Configurações”,  “Configurar o Wine”, e na janela que abriu, clicar em “Unidades”. Crie uma nova chamada D: e direcione-a para a pasta do seu servidor em /media/remoto.

Assim seu programa cliente no PlayOn* reconhece a pasta remota!

No exemplo do meu programa, apontei o bando de dados pra 192.168.0.xx:c:/app/banco – isso é inerente ao programa! – e mudei os diretórios de configurações para D:, ou seja, pasta remota. Não darei detalhes por questões de privacidade, segue a tela de configurações para terem uma ideia de como fica a conexão.

Nova tentativa de executa-lo………………….. Bem sucedida agora.

Consegui fazer o login com meu usuário e o programa abriu:

Aqui encerra-se o exemplo. Note que foi uma jornada e tanto até pegar os detalhes que permitiram que ele rodasse. Infelizmente, esse tipo de trabalho exige que você domine o Windows e domine a maneira como o programa funciona, quais DLLs ele exige, como ele executa, como é seu atalho, etc.

O mesmo vale para games.

Debugando – Mais opções

Muito bem, você está tentando rodar um programa mas meu exemplo acima não foi de grande ajuda.
Segue abaixo mais algumas opções de debug que podem te ajudar!

Alguns programas darão outros erros diversos.
Esse outro programa que tentei rodar, o Invoice por exemplo chega a construir parte da janela de acesso ao login e senha dos usuarios mas ele é interrompido. O erro no depurador aponta a ntdll.dll.

Se você pesquisar um bocado, descobre que o erro do NTLM é algo vinculado á ntdll.dll, uma dll “fraca” do Wine responsável por muitos problemas. E é aqui que começa nossa aventura de substituir DLLs do Windows.

Você vai abrir a pasta System32 do Windows 7 e pegar a ntdll.dll dele, ir lá na System32 do PlayOn* e colar.
Simples assim.

De uma System32 para outra System32. Você vai notar que a nova DLL é até maior, de seus 20kb pra 500kb, 1Mb. As dll’s originais do Windows possuem maior tamanho, acessam mais registros, possuem mais iterações, variáveis e chamadas. E justamente aí que mora o perigo! Dependendo da DLL que você importar do Windows, o WINE quebra porque infelizmente muitas dll’s são casadas entre si, uma depende da outra. E substituir TODAS é impossivel, em dado momento elas vão querer o kernel NT original e o do WINE não servirá.

Voltando ao exemplo, você deve registrá-la, como mostra o print abaixo:

Você abre as configurações do seu wineprefix (seu programa), abre a aba Bibliotecas e lá você clica no quadradinho em cima (na setinha é melhor) e digita o nome da dll sem a extensão.
Se era ntdll.dll, digite apenas “ntdll” sem aspas.
Você verá que ela está na lista! Quer dizer que existia uma original do WINE que será substituida.
Entao você seleciona a referida dll dessa listinha e clica em Adicionar.
Você verá ela abaixo como a tag (nativa, embutida).
Significa que foi devidamente configurada e o PlayOn* vai reconhecer ela como uma DLL original do Windows!

Assim o Wine vai executar já com as chamadas especiais projetadas para DLL’s nativas.

Agora, você aplica, dá Ok e clica no botão “Reinicialização do Windows”.
Se não ocorrer nenhum erro, a substituição foi bem sucedida.
Se houver erros, pode ser que essa substituição te traga problemas e seja melhor criar um wineprefix novo SEM NENHUM COMPONENTE EXTRA. Reforçando, quanto mais puro melhor.

Prosseguindo, ao executar o programa em Depurador, no  PlayOn*, você vai ver que o programa está com NOVOS erros! Mas estes erros costumam ter nome e sobrenome: As DLL’s que o ntdll tem vinculo e não existem ou estão incompativeis. Você então repete todo o processo da ntdll, copiando as dll’s faltantes da System32 do Windows 7 e colando na System32 do wineprefix do seu aplicativo instalado no PlayOn*. Sempre registrando a DLL como acima e tentando de novo.

Logo que você colar as novas DLL’s vinculadas á anterior (DLL’s comunicam-se entre si), os erros novos logo vão desaparecer e consigo os erros antigos.

Vá depurando dessa maneira, procurando qual dll está relacionada com aquele erro, instalando a original do Windows 7, registrando ela nas configurações, “reiniciando o windows”, etc.

Ao contrário de usar as DLL’s padrão do WINE, pegando as originais do Windows você terá codigo extra pra processar e poderá tornar seu wineprefix mais lento; Porém a compatibilidade vai aumentar muito!

OBS: O WINE, a base do PlayOn*, ainda é uma API compativel com Win32 do Windows. Ou seja, ela possui suas limitações e nem sempre adicionar e trocar DLL’s nativas do WINE pelas nativas do Windows 7 vão resolver o problema. Talvez as DLL’s do Windows XP sejam ideais ou mesmo as do Windows 10. É tudo relativo e depende da necessidade de cada programa e/ou game.

Verificação Hexadecimal

Essa ultima parte, explicarei como ir nas entranhas do aplicativo/game problemáticos, com um editor Hexadecimal!

Instale um editor hexadecimal, popular dos repositórios do pinguim chamado Bless:

$sudo apt install bless

Com ele, você abre o arquivo .exe do programa e explora suas dependências direto da fonte.
Na busca, digite “DLL” e vá seguindo os resultados.
Depois repita pra “dll’ por ser case sensitive! – Note o exemplo abaixo:

Anote todas as .dll’s que você encontrar dessa maneira:
São elas que precisarão ser substituídas no PlayOn* para melhorar a compatibilidade do software que está tentando executar, seja ele game ou programa.

Conclusão

Infelizmente o Wine e sua interface PlayOn * são ferramentas poderosas e igualmente complicadas de se lidar no Linux. Quem ousar tentar usa-los, poderá se deparar com questões que nem mesmo usuários avançados de Windows estão tão acostumados. Para entender do Wine, você precisará entender como o Windows e seus programas funcionam, suas dependências e a satisfação de DLL’s ausentes. Dependendo da sua necessidade, pode ser ou não viável essa mão de obra, tudo depende de você.

Não vou mentir, demorei 3 meses para entender a fundo como o APPHotel funciona e como faze-lo funcionar no PlayOnLinux. Todo dia tentando de novo e de novo, tentativa e erro, ligando na assistência deles pra aprender como instala-lo no Windows e depois aplicando e adaptando o conhecimento no PlayOnLinux… Não é fácil. Mas isso me livrou de muitos problemas, principalmente no fato de que consegui substituir 2 máquinas com Windows para Linux, diminuindo drasticamente custos com licenças de uso e problemas de médio prazo como malwares pela rede, falhas por picos de energia e outras moléstias que já presenciei noutros tempos.

#UrbanCompassPony