Que DLLs de vinho eu deveria * não * substituir com a coisa real?

Question

Eu tenho uma instalação legítima do Windows XP e dual boot com o Ubuntu (atualmente Karmic). WineHQ diz que é possível usar DLLs de uma instalação real do Windows no lugar de "DLLs que o Wine não implementa muito bem ".

Portanto, gostaria de criar apenas softlinks que apontam para todas as DLLs na minha pasta real do Windows System32, sob a teoria de que isso ajudaria as coisas a funcionarem melhor e se comportariam de uma maneira menos nativa e com menos bugs.

Mas devo ir tão longe quanto substituir as DLLs do Wine pelas reais? Em caso afirmativo, existem DLLs que precisam permanecer como estão para compatibilidade com o mundo do Linux? Quais são seguros para substituir?

Além disso, como isso conflitaria / interceptaria a execução de Winetricks ?

    

Answer 1

Enquanto você provavelmente poderia substituir as dlls do WINE, não há como determinar quais delas podem ser substituídas, a menos que você seja um desenvolvedor do projeto Wine. Na maioria dos casos, as DLLs rodarão muito bem, ao agitar o sistema, é mais provável que você resolva bugs do que resolver seus problemas.

Se você perceber que um programa em particular está tendo dificuldades, talvez seja necessário determinar em que parte do programa o problema está acontecendo. Tente descobrir qual dll pode possivelmente estar relacionada ao problema e tente um link flexível e veja se isso resolve o problema.

Eu ficaria com o que o Wine recomenda explicitamente, se substituir as dlls funcionasse e fizesse uma melhoria, o Wine recomendaria elas mesmas.

    

Answer 2

link

O AppDB lista as modificações necessárias para cada programa que funciona no Wine. Portanto, para o aplicativo que não está sendo executado nativamente, basta verificar com o AppDB e substituir as DLLs adequadamente.

    

Answer 3

gdi32.dll , kernel32.dll e user32.dll são as bibliotecas do Windows de nível mais baixo e, como tal, não devem ser utilizadas para substituir os equivalentes no vinho, uma vez que serão as primeiras a falar principalmente com o SO subjacente.

wsock32.dll faz o tratamento TCP / IP, por isso deve ser deixado sozinho também.