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) :
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:
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.
