Beta 11f multiple monitor bug

[Ralph]

During the process of providing John some screen shots of multiple monitor setups I think I may have found a new bug. At one time it was possible to run multiple copies of the same beta. Jim fixed that but... trying to run a second instance now... creates problems.
In full screen mode there is no problem as it is impossible to start a second application. But in a windowed mode.. an attempt at starting the second instance brings up the splash screen on the second monitor and can only be removed by stopping the original instance.
The splash screen occasionally is a segmented full screen display but the display settings do not seem to directly influence it and at other times it is just a black screen. Right clicking on that second monitor brings up an option to go full screen which seems to work

[Jim Sachs]

Are you clicking on the same icon or filename to start the second instance?

[cjmaddy]

The best solution, (assuming it's simple to implement! ), might be to prevent any second window instance, if a window is already running?

I can partly confirm Ralph's experience. (Though I didn't see the splash screen). - Yes, I did click on the same desktop icon for the second instance.

This is not common only to 11f. The same also applies to the official 10d. - Exiting closes both instances.

[Ralph]

Originally posted by Jim Sachs:

Are you clicking on the same icon or filename to start the second instance?  

Yes

[Jim Sachs]

All versions of Marine Aquarium have used a technique called a Mutex, which is SUPPOSED to prevent a copy of the program from starting if another is already running. Somehow, you guys are able to get around this, but in looking through (Edgar's) code, I don't see how. The reason I asked if the same icon was being used to start the program is that the Mutex uses the internal name of the program to see if it's the same one that's already running. Previous versions, Beta versions, etc. have different internal names, so they would not be prevented from starting.

[Dale]

Originally posted by Jim Sachs:

... the Mutex uses the internal name of the program to see if it's the same one that's already running. Previous versions, Beta versions, etc. have different internal names, so they would not be prevented from starting.  

How do we see the internal name of the program?

Is it possible that this Mutex doesn't work with .scr files? Perhaps depending on the version of Windows being used?

[Jim Sachs]

It definitely works here. Putting in breakpoints in my debugger, I can watch as a new instance finds an old instance running and shuts down.

[Ralph]

From yesterdays observations.. it seems that the second instance is related to the settings in the display panel. Where there are instructions to use or not use the second monitor, the second instance (possibly the same instance but asked to do it over??) finds these instructions confusing and thus the various displays I noted yesterday. From showing the splash screen to a black screen to segments of my wallpaper showing through a black screen.

[Dale]

Ralph; what version of Windows (I'm told that Mutex works slightly differently in Windows 7).

Originally posted by Jim Sachs:

All versions of Marine Aquarium have used a technique called a Mutex, which is SUPPOSED to prevent a copy of the program from starting if another is already running. Somehow, you guys are able to get around this, but in looking through (Edgar's) code, I don't see how. .  

Of course, I can't see the code. Presumably you know that a Mutex, by itself, does not prevent a copy of the program from starting -- a Mutex is a mechanism for coordinating (synchronizing) the sharing of resources. Some additional code would be required for the 2nd copy to "commit suicide" if it can't get the resource. At least that's how it normally is coded.

That's not the "intended use" of Mutex (detecting when a program should kill itself). When it works, it works fine - but Mutex implementation can change when operating systems change, and also the "right" way for a program to commit suicide may be different between operating systems.

Of course, I'm making some really broad assumptions about how this is coded. In particular, I'm assuming that it's the responsibility of the "2nd copy" to detect the "problem" and commit suicide.

[Ralph]

My system is running Windows XP SP3

[cjmaddy]

My belief is that this second-instance problem only occurs where there is a secondary monitor present. It isn't possible for me to completely simulate only having one monitor because MA3 still thinks that there are two screens, due to Windows seeing a Dual DVI-out Video card and therefore MA3 still shows two Monitor tabs in the MA3 Display Settings, even when one monitor connecting lead has been completely removed. And under those conditions, opting to 'Display nothing on this monitor', does not have the desired effect of simulating only having one screen.

It isn't really a problem. I'm confident that it wouldn't happen on a singe monitor setup, and why would we want to re-select the same app a second time?

I say, live with it. - Put it down to the joys of having multiple-monitors! - There are other more important considerations that we need to be aware of when running dual-screens.....

As I've reported in the past, it should be pointed out that the FPS will drop dramatically if any part of a window is allowed to extend onto the second monitor. ie: The window must be contained within the 'Primary' monitor only, - if the expected FPS are to be maintained.

Also, which monitor is to be chosen as the Primary, (and how it is chosen), is another important but thorny subject that has also been covered on a number of occasions.

[Jim Sachs]

Yes, I'll probably ignore the dual-instance issue for this release. Without being able to duplicate it, anything I would try would be a complete shot in the dark. Could take weeks to track down that way, if ever.

[Ralph]

Fair enough... possibly we can try to pin it down with the next release. As Cliff states this is not a big deal and one should not try to run two instances anyway.

[cjmaddy]

Agreed! .... Don't do it, Jim.... Don't even think about it!

If you try to cover the setup of Dual-Monitors to include all situations of Widows OS, different video cards, different driver settings, different screen sizes/resolutions, and the multitude of different settings in different places..... You will not only open-up a very large can of worms, - but you will probably get the mother of all headaches!

[JohnWho]

I agree as well.

MA appears to work in some manner on most, if not all, multi- monitor systems.

If one has such a system, enjoy it as best as you can.

Although, a "very large can of worms" might feed our fish for a long time!

[feldon34]

In my programming experience, I checked to see if another program was running on the computer with the same internal program name. Never heard of a Mutex.

[Dale]

Originally posted by feldon34:

In my programming experience, I checked to see if another program was running on the computer with the same internal program name. Never heard of a Mutex.  

Think of Mutex as "Mutual Exclusion"

Assume there is a critical resource (serially-reusable but non-reentrant) that is needed by two or more programs. Those programs do not need to be doing the same tasks, and do not need to have the same program name - they just need exclusive use of the resource for a while.

Each of the several programs will get access to the critical resource by issuing a Mutex.

The effect is like each program asked the system: "Please give me access to this resource, and if you can't do that right now, then put me in a queue (in request order with everybody else who wants that resource), and suspend my execution until I can have that resource.

Mutex is not normally/generally/usually used in the way MA3 is apparently using it: "Give me that resource right now, or I intend to commit suicide".

Footnote: Not that it makes any difference, but it's also not clear what "resource" MA3 is looking at.

[Jim Sachs]

In this case, the Mutex IS the resource. MA3 attempts to create a Mutex called Marine Aquarium 3. If the call fails because one already exists, the program exits.

[Dale]

Originally posted by Jim Sachs:

In this case, the Mutex IS the resource. MA3 attempts to create a Mutex called Marine Aquarium 3. If the call fails because one already exists, the program exits.  

That precisely explains why it doesn't work sometimes.

Thanks for the clarification.

[Jim Sachs]

Using a Mutex is a very common way to prevent a second instance of a program from opening.