Thread: Re: [GD-Windows] Limiting to one instance
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-windows
|
From: Andrew G. <ag...@cl...> - 2006-08-15 07:01:35
|
A named Mutex is the best way to do this. Call CreateMutex with a very unique name, if there's an existing instance then GetLastError returns something like ERROR_EXISTS (I'm sure the exact error is in the CreateMutex documentation). I remember at an old company one genius tried to prevent multiple instances of an app by binding a port, and was then surprised when it failed for pretty much everyone who was running a firewall! A. > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] > On Behalf Of Research > Sent: Monday, August 14, 2006 11:14 PM > To: Gam...@li... > Subject: [GD-Windows] Limiting to one instance > > Is the preferred method of not allowing multiple instances of > a game to run at the same to use named mutexes via > CreateMutex and test for it's exeistence on startup? > > I found an example on MSDN, but it seems targeted at .NET > applications. I'm not sure if there's an easier way to > prevent mutliple launches for a Win32 app. > > Thanks, > Brett Bibby > GameBrains > > > -------------------------------------------------------------- > ----------- > Using Tomcat but need to do more? Need to support web > services, security? > Get stuff done quickly with pre-integrated technology to make > your job easier Download IBM WebSphere Application Server > v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057& > dat=121642 > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 > |
|
From: Dirk R. <ri...@ph...> - 2006-08-15 08:22:16
|
One thing to keep in mind when using global objects in windows is Fast = User Switching in Windows XP, where in fact multiple users are logged in = at the same time. When you use CreateMutex you block the application = from running under ALL other user accounts as well. This could as well = apply to FindWindow. If you do not want this to happen, you have to use = a technique which is per user, like the old unix style pid file stored = under the users home directory. Dirk -----Urspr=FCngliche Nachricht----- Von: gam...@li... = [mailto:gam...@li...] Im Auftrag = von Alen Ladavac Gesendet: Dienstag, 15. August 2006 10:13 An: Andrew Grant Cc: Game Development for MS Windows Betreff: Re: [GD-Windows] Limiting to one instance > I remember at an old company one genius tried to prevent multiple = instances > of an app by binding a port, and was then surprised when it failed for > pretty much everyone who was running a firewall! Actually, it's not such a weird idea. Some applications rely on IP ports as a simple yet very portable IPC mechanism. Firewalls should really know better, by handling 127.0.0.1 specifically by default. But apparently even the best in class don't. Btw, in my book, even using a named mutex in that way is a bit hacky because you are relying on error. But what can we do, when there's no real API intended for that purpose. Personally, I've been using FindWindow(xyz, NULL) to find a main window by class name. Same principle (with same weaknesses as a named mutex), but doesn't require an extra object creation, as you probably already have a window, and you can use this to test even for foreign applications, because it doesn't require access to the code of the tested application. A nice side effect is that once you have the window, you can report messages like "Cannot start, please close ABCD application first", where you get the ABCD from the application's main window caption. Cheers, Alen -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job = easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 |
|
From: Jason S. <ja...@mi...> - 2006-08-15 09:26:53
|
Ya and if a parent (the administrator) has setup Windows Vista time = limits on computer usage for a child account (a standard user), the = child account will be fast user switched out when their computer time = slot is up. The game & other apps will continue to run in the = background however but the user won't be able to log back in until the = potentially the next day. In theory there could be a case where a 2nd = user could log in and want to play the same game after this happened. = It's kinda a corner case, but possible... Jason -----Original Message----- From: gam...@li... = [mailto:gam...@li...] On Behalf Of = Dirk Ringe Sent: Tuesday, August 15, 2006 1:22 AM To: Alen Ladavac; Game Development for MS Windows; Andrew Grant Subject: Re: [GD-Windows] Limiting to one instance One thing to keep in mind when using global objects in windows is Fast = User Switching in Windows XP, where in fact multiple users are logged in = at the same time. When you use CreateMutex you block the application = from running under ALL other user accounts as well. This could as well = apply to FindWindow. If you do not want this to happen, you have to use = a technique which is per user, like the old unix style pid file stored = under the users home directory. Dirk -----Urspr=FCngliche Nachricht----- Von: gam...@li... = [mailto:gam...@li...] Im Auftrag = von Alen Ladavac Gesendet: Dienstag, 15. August 2006 10:13 An: Andrew Grant Cc: Game Development for MS Windows Betreff: Re: [GD-Windows] Limiting to one instance > I remember at an old company one genius tried to prevent multiple=20 > instances of an app by binding a port, and was then surprised when it=20 > failed for pretty much everyone who was running a firewall! Actually, it's not such a weird idea. Some applications rely on IP ports = as a simple yet very portable IPC mechanism. Firewalls should really = know better, by handling 127.0.0.1 specifically by default. But = apparently even the best in class don't. Btw, in my book, even using a named mutex in that way is a bit hacky = because you are relying on error. But what can we do, when there's no = real API intended for that purpose. Personally, I've been using FindWindow(xyz, NULL) to find a main window = by class name. Same principle (with same weaknesses as a named mutex), = but doesn't require an extra object creation, as you probably already = have a window, and you can use this to test even for foreign = applications, because it doesn't require access to the code of the = tested application. A nice side effect is that once you have the window, = you can report messages like "Cannot start, please close ABCD = application first", where you get the ABCD from the application's main = window caption. Cheers, Alen -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job = easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 -------------------------------------------------------------------------= Using Tomcat but need to do more? Need to support web services, = security? Get stuff done quickly with pre-integrated technology to make your job = easier Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 |
|
From: Stefan B. <Ste...@di...> - 2006-08-15 08:52:36
|
But you don't need a global mutex, just a named session mutex, no? = I.e. just a plain named Mutex (without \\global\ prefix) will do if you = want the mutex to apply only to the current user session. /Stefan > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On Behalf = Of > Dirk Ringe > Sent: 15 August 2006 10:22 > To: Alen Ladavac; Game Development for MS Windows; Andrew Grant > Subject: Re: [GD-Windows] Limiting to one instance >=20 > One thing to keep in mind when using global objects in windows is Fast > User Switching in Windows XP, where in fact multiple users are logged = in > at the same time. When you use CreateMutex you block the application = from > running under ALL other user accounts as well. This could as well = apply to > FindWindow. If you do not want this to happen, you have to use a = technique > which is per user, like the old unix style pid file stored under the = users > home directory. >=20 > Dirk >=20 > -----Urspr=FCngliche Nachricht----- > Von: gam...@li... > [mailto:gam...@li...] Im Auftrag = von > Alen Ladavac > Gesendet: Dienstag, 15. August 2006 10:13 > An: Andrew Grant > Cc: Game Development for MS Windows > Betreff: Re: [GD-Windows] Limiting to one instance >=20 > > I remember at an old company one genius tried to prevent multiple > instances > > of an app by binding a port, and was then surprised when it failed = for > > pretty much everyone who was running a firewall! >=20 > Actually, it's not such a weird idea. Some applications rely on IP > ports as a simple yet very portable IPC mechanism. Firewalls should > really know better, by handling 127.0.0.1 specifically by default. But > apparently even the best in class don't. >=20 > Btw, in my book, even using a named mutex in that way is a bit hacky > because you are relying on error. But what can we do, when there's no > real API intended for that purpose. >=20 > Personally, I've been using FindWindow(xyz, NULL) to find a main > window by class name. Same principle (with same weaknesses as a named > mutex), but doesn't require an extra object creation, as you probably > already have a window, and you can use this to test even for foreign > applications, because it doesn't require access to the code of the > tested application. A nice side effect is that once you have the > window, you can report messages like "Cannot start, please close ABCD > application first", where you get the ABCD from the application's main > window caption. >=20 > Cheers, > Alen >=20 >=20 > = -------------------------------------------------------------------------= > Using Tomcat but need to do more? Need to support web services, = security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo > = http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 >=20 >=20 >=20 > = -------------------------------------------------------------------------= > Using Tomcat but need to do more? Need to support web services, = security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache = Geronimo > = http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 |
|
From: Stefan B. <Ste...@di...> - 2006-08-15 08:54:03
|
> Btw, in my book, even using a named mutex in that way is a bit hacky > because you are relying on error. But what can we do, when there's no > real API intended for that purpose. But CreateMutex etc *is* intended for the purpose. /Stefan |
|
From: Alen L. <ale...@cr...> - 2006-08-16 07:40:35
|
Jon wrote: > Using FindWindow() introduces a possible race condition I stand corrected. I was using this for installers, not for actually preventing double-startup of the same app. So scratch my remark on FindWindow being useful here. Stefan wrote: > But CreateMutex etc *is* intended for the purpose. Well, I was replying to Andrew's comment on IP ports not being suitable for that purpose. In that context, I believe CreateMutex is not any more suitable. CreateMutex (named) is intended for the purpose of synchronizing two processes by actually using a mutex. Using the mutex's mere existance to note anything is as much of a hack as using an IP port for that. The fact that there are personal firewalls in the modern world is another hack as well. IP port creation was not supposed to be intercepted in this way - in the original design, AFAIK. Simply trying to point out the fact that we frequently have to use something for what it is not supposed to be used for. And often one can't predict all possible side-effects. Like that poor guy didn't predict that a firewall would make the IP-port solution useless, like FindWindow is not perfect due to a possible race condition, like the CreateMutex might have possible user-switching problem (although not likely, as local creation is default, IIRC). Put simply: unless the manual says "this can be used to do XYZ", then if you are using it for that, you are risking possible problems. (Although, you are probably risking possible problems even if it does say so. :p ) JM2C, Alen |
|
From: Jon W. <hp...@mi...> - 2006-08-16 16:35:16
|
Alen Ladavac wrote:
> Put simply: unless the manual says "this can be used to do XYZ", then
> if you are using it for that, you are risking possible problems.
> (Although, you are probably risking possible problems even if it does
> say so. :p )
>
I just checked the documentation for CreateMutex() on MSDN, and it
actually discusses the usage for preventing double-launch, in some
detail. It even mentions the possible denial of service by creating the
same mutex in another program. It also suggests a rather cumbersome
work-around.
Cheers,
/ h+
|
|
From: Alen L. <ale...@cr...> - 2006-08-17 05:03:45
|
Jon wrote: > I just checked the documentation for CreateMutex() on MSDN, and it > actually discusses the usage for preventing double-launch, in some > detail. It even mentions the possible denial of service by creating the > same mutex in another program. It also suggests a rather cumbersome > work-around. Indeed it does. Oh well, there I go. :) Alen |
|
From: Alen L. <ale...@cr...> - 2006-08-15 08:13:27
|
> I remember at an old company one genius tried to prevent multiple instances > of an app by binding a port, and was then surprised when it failed for > pretty much everyone who was running a firewall! Actually, it's not such a weird idea. Some applications rely on IP ports as a simple yet very portable IPC mechanism. Firewalls should really know better, by handling 127.0.0.1 specifically by default. But apparently even the best in class don't. Btw, in my book, even using a named mutex in that way is a bit hacky because you are relying on error. But what can we do, when there's no real API intended for that purpose. Personally, I've been using FindWindow(xyz, NULL) to find a main window by class name. Same principle (with same weaknesses as a named mutex), but doesn't require an extra object creation, as you probably already have a window, and you can use this to test even for foreign applications, because it doesn't require access to the code of the tested application. A nice side effect is that once you have the window, you can report messages like "Cannot start, please close ABCD application first", where you get the ABCD from the application's main window caption. Cheers, Alen |
|
From: Jon W. <hp...@mi...> - 2006-08-15 17:51:45
|
Alen Ladavac wrote:
> Personally, I've been using FindWindow(xyz, NULL) to find a main
> window by class name. Same principle (with same weaknesses as a named
> mutex), but doesn't require an extra object creation, as you probably
> already have a window, and you can use this to test even for foreign
>
Using FindWindow() introduces a possible race condition in your
application, because two instances starting up at the same time (because
the impatient user double-clicked twice) MAY both first run the test,
find that there's no other window, and then create the window.
Mutex creation name resolution is guaranteed by the kernel to be atomic,
and thus there is no race condition; the first one in, gets it. Note
that you don't actually then use the mutex at all; all you do is using
the creation of the mutex as your existence test, given that a mutex is
reasonably lightweight, and the kernel rules surrounding their lifetime
are iron-clad. Of course, if you're worried about pranksters, consider
that someone might create a mutex with the same name just to spite you :-P
Btw: you don't need to close the handle before exit, because the kernel
can clean it up. Trust the kernel. The kernel is your friend!
Cheers,
/ h+
|
|
From: Richard M. <mi...@tr...> - 2006-08-16 07:48:16
|
http://support.microsoft.com/default.aspx?scid=kb;en-us;106385 I guess it is an officially recommended technique. A mutex is a proper kernel object, so should be pretty safe. -- ()() Richard Mitton ( '.') (")_(") code jester .:. treyarch .:. mi...@tr... On 16 Aug 2006, at 12:37 am, Alen Ladavac wrote: > Jon wrote: >> Using FindWindow() introduces a possible race condition > > I stand corrected. I was using this for installers, not for actually > preventing double-startup of the same app. So scratch my remark on > FindWindow being useful here. > > Stefan wrote: >> But CreateMutex etc *is* intended for the purpose. > > Well, I was replying to Andrew's comment on IP ports not being > suitable for that purpose. In that context, I believe CreateMutex is > not any more suitable. CreateMutex (named) is intended for the purpose > of synchronizing two processes by actually using a mutex. Using the > mutex's mere existance to note anything is as much of a hack as using > an IP port for that. The fact that there are personal firewalls in the > modern world is another hack as well. IP port creation was not > supposed to be intercepted in this way - in the original design, > AFAIK. > > Simply trying to point out the fact that we frequently have to use > something for what it is not supposed to be used for. And often one > can't predict all possible side-effects. Like that poor guy didn't > predict that a firewall would make the IP-port solution useless, like > FindWindow is not perfect due to a possible race condition, like the > CreateMutex might have possible user-switching problem (although not > likely, as local creation is default, IIRC). > > Put simply: unless the manual says "this can be used to do XYZ", then > if you are using it for that, you are risking possible problems. > (Although, you are probably risking possible problems even if it does > say so. :p ) > > JM2C, > Alen > > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 |
|
From: Chris C. <can...@gm...> - 2006-08-16 09:14:22
|
It would seem like a combination of the two approachs avoids the drawbacks of either, no? Use a named mutex to protect the initialisation process, so that if FindWindow fails to find an existing window, the mutex is held until after the window is created. In a switch user case, the window will have long since been created, and so the mutex won't be held open. The logic becomes "no two users can start the application" rather than "no two users can run the application". Personally I've always used the named mutex alone to protect the app, and found it to be stable and robust; but I've never had to write a shipping PC title or deal with limited user cases... C Black Company Studios On 16/08/06, Richard Mitton <mi...@tr...> wrote: > > http://support.microsoft.com/default.aspx?scid=kb;en-us;106385 > > I guess it is an officially recommended technique. > A mutex is a proper kernel object, so should be pretty safe. > > -- > ()() Richard Mitton > ( '.') > (")_(") code jester .:. treyarch .:. mi...@tr... > > > > > On 16 Aug 2006, at 12:37 am, Alen Ladavac wrote: > > > Jon wrote: > >> Using FindWindow() introduces a possible race condition > > > > I stand corrected. I was using this for installers, not for actually > > preventing double-startup of the same app. So scratch my remark on > > FindWindow being useful here. > > > > Stefan wrote: > >> But CreateMutex etc *is* intended for the purpose. > > > > Well, I was replying to Andrew's comment on IP ports not being > > suitable for that purpose. In that context, I believe CreateMutex is > > not any more suitable. CreateMutex (named) is intended for the purpose > > of synchronizing two processes by actually using a mutex. Using the > > mutex's mere existance to note anything is as much of a hack as using > > an IP port for that. The fact that there are personal firewalls in the > > modern world is another hack as well. IP port creation was not > > supposed to be intercepted in this way - in the original design, > > AFAIK. > > > > Simply trying to point out the fact that we frequently have to use > > something for what it is not supposed to be used for. And often one > > can't predict all possible side-effects. Like that poor guy didn't > > predict that a firewall would make the IP-port solution useless, like > > FindWindow is not perfect due to a possible race condition, like the > > CreateMutex might have possible user-switching problem (although not > > likely, as local creation is default, IIRC). > > > > Put simply: unless the manual says "this can be used to do XYZ", then > > if you are using it for that, you are risking possible problems. > > (Although, you are probably risking possible problems even if it does > > say so. :p ) > > > > JM2C, > > Alen > > > > > > ---------------------------------------------------------------------- > > --- > > Using Tomcat but need to do more? Need to support web services, > > security? > > Get stuff done quickly with pre-integrated technology to make your > > job easier > > Download IBM WebSphere Application Server v.1.0.1 based on Apache > > Geronimo > > http://sel.as-us.falkag.net/sel? > > cmd=lnk&kid=120709&bid=263057&dat=121642 > > _______________________________________________ > > Gamedevlists-windows mailing list > > Gam...@li... > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=555 > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X