Como enganar um aplicativo para executar processos diferentes?

0

Estou executando o PDFXCview.exe (para a versão portátil do visualizador pdfxchange) abaixo do wine para abrir um arquivo pdf, por

PDFXCview.exe 1.pdf

Quando faço o mesmo para outro arquivo, o outro arquivo será aberto pelo mesmo processo do PDFXCview.exe. Posso abri-lo em um processo diferente? A razão é que o aplicativo fica mais lento para não responder quando há dois arquivos pdf abertos no mesmo processo.

Está executando um processo diferente ou não determinado pelo arquivo executável PDFXCview.exe? É porque o arquivo exe é executado como um servidor?

a solução é a mesma para outras aplicações nativas do Linux?

Obrigado.

    
por Tim 04.10.2014 / 22:31

2 respostas

2

Nativamente, vários processos podem ser executados com o mesmo código executável . Se isso não está acontecendo naturalmente, então sim, o programa em si fez acontecer. No entanto, eu não poderia dizer como isso é feito em um sistema Windows (ou, pelo menos, Windows-like). No Linux, usamos principalmente .pid files.

Is it because the exe file runs as a server?

Bem, isso também pode ser o caso. Na verdade, existe uma opção que permite isso no Emacs. No entanto, eu não vejo o ponto para um visualizador de PDF ... Em um sistema Linux, posso pensar em duas soluções amplamente utilizadas para isso:

  • Um soquete do UNIX que permite que duas instâncias se comuniquem.
  • Sinais: quando uma segunda instância é gerada, ela simplesmente envia um sinal para a primeira (dizendo: Acordar! ) e sai.

A primeira coisa que você pode querer verificar: isso é configurável? No VLC, por exemplo, isso pode ser definido (e isso é incrível):

Poralgumarazão(queeurealmentenãoquerodescobrir),eunãopossomaisusaroWine.Noentanto,emumamáquinavirtual,euviissoemEditar>Preferênciasmenu:

Mudar para Documento único e permitir que Várias instâncias transforme essa pequena coisa no visualizador de PDF que você está procurando!

Em um sistema Linux, você provavelmente poderia tentar jogar com o arquivo .pid criado pelo aplicativo. Isso pode acabar em resultados desagradáveis, mas se você excluir o arquivo após o aplicativo ter sido iniciado, você poderá enganar a nova instância, desde que não procure outras instâncias além do arquivo .pid .

Outra solução seria rodar o segundo programa como outro usuário, já que dois usuários não podem compartilhar o mesmo processo, o programa terá que iniciar duas vezes. É assim que algumas pessoas iniciam com sucesso o Skype duas vezes no Linux (mesmo que não seja necessário muito esforço).

Você pode querer ter em mente que um aplicativo em execução no modo de instância única provavelmente tem um bom motivo para isso. Além disso, na maioria das vezes, essa é uma escolha do usuário mais do que um design realmente necessário.

Prós

  • Existe apenas um processo em execução, o que significa um espaço de endereço de memória para todos e, portanto, uma comunicação fácil entre o que teria sido dois processos, duas instâncias .

  • Alguns programas gráficos são executados com muita frequência. Tomemos o exemplo do VLC: toda vez que eu abro um arquivo MP3 no meu diretório Music, ele cria uma nova janela! Ou seja, a cada 3 ou 4 minutos, quando uma música termina, eu tenho que fechar a janela antiga e abrir o novo arquivo. Isso não é prático. Em absoluto. No entanto, ter a instância atual do VLC registra a próxima música em sua fila sem fechar / reabrir, isso é legal.

  • Outra vantagem: veja o caso de um aplicativo super pesado, como um videogame sofisticado. Este aplicativo leva muito tempo e recursos para iniciar, e todos nós sabemos como é fácil acidentalmente iniciar um aplicativo por engano. Ao definir o aplicativo para ser executado no modo de instância única, a reinicialização normalmente trará a primeira instância de volta ao primeiro plano. Muitos desenvolvedores de jogos também usam isso para impedir que os usuários façam login com várias contas ao mesmo tempo.

Contras

  • Bem, como você pode ver: uma tendência ao design pobre. De fato, como facilita muito a comunicação (sem necessidade de comunicação entre processos, IPC), alguns desenvolvedores preguiçosos podem tentar forçar seus aplicativos em um estado de instância única o tempo todo. Para a maioria das aplicações, não é realmente um problema, mas para um visualizador de PDF, isso é ridículo.

  • Não é realmente um engodo, mas um cenário ruim: não oferecer isso como uma opção. A menos que seu aplicativo realmente precise ser executado no modo de instância única, você deve sempre fazer isso como uma escolha do usuário (ou apenas usar várias instâncias quando não estiver incomodando).

No entanto, no final, a principal preocupação aqui é experiência do usuário . É por isso que o modo de instância única é muitas vezes uma opção, porque realmente depende de como você usa o programa. Se você simplesmente assistir a 1 ou 2 arquivos de vídeo por mês, provavelmente não se importará com o VLC sendo executado em várias instâncias. Se você ouvir música 100% do tempo, você se importa com isso, porque você não quer acabar com os processos VLC n , com n-1 inativo queridos.

    
por 10.10.2014 / 22:08
1

Em geral, não. Se um programa nunca chamar execve , você não terá oportunidade de interceptar nada, a menos que você consiga escrever código para pré-carregar um símbolo, mas não tenho certeza se isso funciona mesmo com o WINE.

    
por 05.10.2014 / 02:51

Tags