0

I am running PDFXCview.exe (for pdfxchange viewer portable version) under wine to open a pdf file, by

PDFXCview.exe 1.pdf

When I do the same for another file, the other file will be opened by the same process of PDFXCview.exe. Can I open it in a different process? The reason is that the application becomes slower to non-responsive when there are two pdf files opened in the same process.

Is running a different process or not determined by the executable PDFXCview.exe? Is it because the exe file runs as a server?

is the solution the same for other native linux applications?

Thanks.

2 Answers 2

3

Natively, several processes can be run with the same executable code. If this isn't happening naturally then yes, the program itself made it happen. However, I couldn't tell you how this is done on a Windows (or at least, Windows-quite-like) system. On Linux, we mostly use .pid files.

Is it because the exe file runs as a server?

Well, this could also be the case. There actually is an option that allows this in Emacs. However, I don't quite see the point for a PDF viewer... On a Linux system, I can think of two widely used solutions for this:

  • A UNIX socket which allows two instances to communicate.
  • Signals : when a second instance is spawned, it merely sends a signal to the first one (saying: Wake up!) and exits.

First thing you might want to check: is this configurable? On VLC for instance, this can be set (and that's quite awesome) :

VLC option

For some reason (which I don't really want to discover), I can't run Wine anymore. However, in a Virtual Machine, I came accross these in the Edit > Preferences menu:

Single document

Multiple instances

Switching to Single document and allowing Multiple instances should turn this little thing into the PDF viewer you're looking for!

On a Linux system, you could probably try to play with the .pid file created by the application. This could end up in nasty results, but if you delete the file after the application has started, you should be able to trick the new instance, provided it does not look for other instances further than the .pid file.

Another solution would be to run the second program as another user, since two users can't share a same process, the program will have to start twice. This is how some people successfully start Skype twice on Linux (even though it does not take that much effort).

You might want to keep in mind that an application running in single-instance mode probably has a good reason to do so. Also, most of the time, this is a user choice more than an actually necessary design.

Pros

  • There's only one process running, that means one memory address space for everyone, and therefore, easy communication between what would have been two processes, two instances.

  • Some graphical programs are run very often. Take the example of VLC: every time I open an MP3 file in my Music directory, it would create a new window! That is, every 3 or 4 minutes, when a music ends, I have to close the old window, and open the new file. That's not handy. At all. However, having the current VLC instance register the next song in its queue without closing/reopening, that's neat.

  • Another advantage: take the case of a super heavy application, like a fancy video game. This application takes a lot of time and resources to start up, and we all know how easy it is to accidentally start an application by mistake. By setting the application to run in single-instance mode, restarting it will usually just bring the first instance back in the foreground. Many game developers also use this to prevent users from logging in with several accounts at the same time.

Cons

  • Well, as you can see: a tendency towards poor design. Indeed, since it makes communication so much easier (no need for interprocess communication, IPC), some lazy developers might try to force their applications into a single-instance state all the time. For most applications, it's not really a problem, but for a PDF viewer, that's ridiculous.

  • No really a con, but a bad scenario: not offering this as an option. Unless your application really needs to run in single-instance mode, you should always make this a user choice (or just use multi-instance when it's not disturbing).

However in the end, the main concern here is user experience. This is why the single-instance mode is often an option, because it really depends on how you use the program. If you merely watch 1 or 2 video files a month, you probably don't care about VLC running in multiple instance. If you listen to music 100% of the time, you do care about this, because you don't want to end up with n VLC processes, with n-1 inactive ones.

4
  • thanks. when a program starts, it creates a .pid file somewhere? WHere is it?
    – Tim
    Oct 10, 2014 at 20:21
  • It might create a .pid file, if that's how it designed its single-instance behaviour. This is clearly application-dependent. These files are usually stored in /run, but of course, this is Unix behaviour. I gave an example and a bit more details in the answer I linked above. It could also create a socket (stored at the same location), or just detect the instance by querying the kernel, maybe through /proc (which is rarer). Oct 10, 2014 at 20:25
  • What are the advantagnes and disadv that a program runs in a single instance (e.g with multiple tabs/windows inside it such as Firefox), rather than in multiple instances?
    – Tim
    Oct 10, 2014 at 20:30
  • This is mostly about user experience, but I edited my answer to provide a little more information on this point. Again, this is mostly about application design, not performance. Oct 10, 2014 at 20:41
1

In general, no. If a program never calls execve, you have no opportunity to intercept anything, unless you manage to write code to preload over a symbol, but I'm not sure that even works with WINE.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.