gamedevlists-windows — List for discussing game development on the Windows platform

Re: [GD-Windows] Debugging multiple apps

[Chris J. <cj...@ob...>]

One way I've dealt with stuff like this in the past is to put a simple
loop like this as the first thing in your WinMain:

    bool wait =3D true;
    while (wait);

Once the process is launched, just attach to it with the debugger and
break.  Set wait to false and start stepping.

Chris

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...]=20
> On Behalf Of Research
> Sent: Friday, August 18, 2006 12:28 AM
> To: Gam...@li...
> Subject: [GD-Windows] Debugging multiple apps
>=20
> I cannot figure out how to debug multiple apps in Visual=20
> Studio, and I can't seem to find the right google words to=20
> find this either.
>=20
> I'm have one application that launches another with=20
> ShellExecute. They are both in the same solution. I put=20
> breakpoints on the WinMain of the launched app and it never=20
> gets called.
>=20
> I know how to attach to something already running, but I need=20
> to trap the app on entry. So I want to step on the=20
> ShellExecute and have the other app start and immediately break.
>=20
> Is this possible in Visual Studio?
>=20
> Thanks,
> Brett=20
>=20
>=20
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier Download IBM WebSphere Application Server=20
> v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> 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

Re: [GD-Windows] Debugging multiple apps

[brian s. <bri...@gm...>]

You can use gflags.exe (google it) to specify that the second application
should always be launched with a debugger attached.  This would be a
separate instance of Visual Studio, however.

--brian

On 8/18/06, Research <res...@ga...> wrote:
>
> I cannot figure out how to debug multiple apps in Visual Studio, and I
> can't
> seem to find the right google words to find this either.
>
> I'm have one application that launches another with ShellExecute. They are
> both in the same solution. I put breakpoints on the WinMain of the
> launched
> app and it never gets called.
>
> I know how to attach to something already running, but I need to trap the
> app on entry. So I want to step on the ShellExecute and have the other app
> start and immediately break.
>
> Is this possible in Visual Studio?
>
> Thanks,
> Brett
>

[GD-Windows] Debugging multiple apps

[Research <res...@ga...>]

I cannot figure out how to debug multiple apps in Visual Studio, and I can't 
seem to find the right google words to find this either.

I'm have one application that launches another with ShellExecute. They are 
both in the same solution. I put breakpoints on the WinMain of the launched 
app and it never gets called.

I know how to attach to something already running, but I need to trap the 
app on entry. So I want to step on the ShellExecute and have the other app 
start and immediately break.

Is this possible in Visual Studio?

Thanks,
Brett 

Re: [GD-Windows] Limiting to one instance

[Daniel V. <Dan...@ep...>]

We're using something close to the below snippet to determine whether
the game is already running, in which case we don't write to shared
resources like shader caches so running multiple instances works fine
for network testing and such.

HANDLE NamedMutex =3D CreateMutex( NULL, TRUE, TEXT("UniqueNameForGame")
);
if( NamedMutex && GetLastError() !=3D ERROR_ALREADY_EXISTS )
{
	// We're the first instance!
	GIsFirstInstance =3D TRUE;
}
else
{
	// There is already another instance of the game running.
	GIsFirstInstance =3D FALSE;
	ReleaseMutex( NamedMutex );
	NamedMutex =3D NULL;
}

Seems to work fine for us.

-- Daniel, Epic Games Inc. =20

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...]=20
> On Behalf Of Wismerhill
> Sent: Thursday, August 17, 2006 4:25 AM
> To: Game Development for MS Windows
> Subject: Re: [GD-Windows] Limiting to one instance
>=20
> Some info here: http://www.ddj.com/dept/windows/184416853
>=20
>=20
> 2006/8/15, Research <res...@ga... >:
>=20
> 	Is the preferred method of not allowing multiple=20
> instances of a game to run
> 	at the same to use named mutexes via CreateMutex and=20
> test for it's
> 	exeistence on startup?
> =09
> 	I found an example on MSDN, but it seems targeted at=20
> .NET applications. I'm
> 	not sure if there's an easier way to prevent mutliple=20
> launches for a Win32=20
> 	app.
> =09
> 	Thanks,
> 	Brett Bibby
> 	GameBrains
> =09
> =09
> =09
> --------------------------------------------------------------
> -----------
> 	Using Tomcat but need to do more? Need to support web=20
> services, security?
> 	Get stuff done quickly with pre-integrated technology=20
> to make your job easier=20
> 	Download IBM WebSphere Application Server v.1.0.1 based=20
> on Apache Geronimo
> =09
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642=20
> 	_______________________________________________
> 	Gamedevlists-windows mailing list
> 	Gam...@li...
> =09
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-wind
> ows=20
> <https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows>=20
> 	Archives:
> 	http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
> =09
>=20
>=20
>=20

Re: [GD-Windows] Limiting to one instance

[Wismerhill <wis...@gm...>]

Some info here: http://www.ddj.com/dept/windows/184416853

2006/8/15, Research <res...@ga...>:
>
> 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
>

Re: [GD-Windows] Limiting to one instance

[Alen L. <ale...@cr...>]

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

Re: [GD-Windows] Limiting to one instance

[Jon W. <hp...@mi...>]

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+

Re: [GD-Windows] Limiting to one instance

[Chris C. <can...@gm...>]

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
>

Re: [GD-Windows] Limiting to one instance

[Richard M. <mi...@tr...>]

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

Re: [GD-Windows] Limiting to one instance

[Alen L. <ale...@cr...>]

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

Re: [GD-Windows] Limiting to one instance

[Jon W. <hp...@mi...>]

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+

Re: [GD-Windows] Limiting to one instance

[Dan T. <da...@ar...>]

You have to prefix "Local\" in order to allow for multiple concurrent 
users. However if you still run on 9x, you have to remove the Local as 
its reserved or somesuch.

-Dan

Scoubidou944 (Hotmail) wrote:
> void main (void)
> {
>     HANDLE hMutex;
>     hMutex = ::CreateMutex (NULL, TRUE, "MyMutexName");
>     if ((hMutex == NULL) || (::GetLastError() ==ERROR_ALREADY_EXISTS))
>     {
>         // Can't create mutex, another instance running
>         return;
>     }
>
>     // Continue init
>     // [...]
>
>     // End, release handle
>     ::CloseHandle (hMutex);
> }
>
> -------------------------------------------------------------------------
> 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
>
>
>   

Re: [GD-Windows] Limiting to one instance

[Jason S. <ja...@mi...>]

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

Re: [GD-Windows] Limiting to one instance

[Stefan B. <Ste...@di...>]

> 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

Re: [GD-Windows] Limiting to one instance

[Stefan B. <Ste...@di...>]

   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

Re: [GD-Windows] Limiting to one instance

[Scoubidou944 \(Hotmail\) <sco...@ho...>]

void main (void)
{
    HANDLE hMutex;
    hMutex = ::CreateMutex (NULL, TRUE, "MyMutexName");
    if ((hMutex == NULL) || (::GetLastError() ==ERROR_ALREADY_EXISTS))
    {
        // Can't create mutex, another instance running
        return;
    }

    // Continue init
    // [...]

    // End, release handle
    ::CloseHandle (hMutex);
}

Re: [GD-Windows] Limiting to one instance

[Dirk R. <ri...@ph...>]

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

Re: [GD-Windows] Limiting to one instance

[Alen L. <ale...@cr...>]

> 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

Re: [GD-Windows] Limiting to one instance

[Andrew G. <ag...@cl...>]

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
> 

Re: [GD-Windows] Limiting to one instance

[Mat N. \(BUNGIE\) <Mat...@mi...>]

You'll need a way to synchronize multiple instances of an app; you can =
either use shared memory or a mutex.
=20
MSN

________________________________

From: gam...@li... on behalf of =
Research
Sent: Mon 8/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=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

[GD-Windows] Limiting to one instance

[Research <res...@ga...>]

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 

Re: [GD-Windows] Array foreach in scripting languages

[Alen L. <ale...@cr...>]

> The reason I'd like to have this work is that it is a
> recurring pattern in lots of code I see (iterating a
> list and deleting/inserting entries).

In my experience, rather than trying to get the "modification of the
list while walking it" right, it is much easier to instead just change
the algorithm slightly to work by rewriting the input list into an
output list. Simple and fool-proof. And for a scripting language,
it should be a very useable solution.

Cheers,
Alen

Re: [GD-Windows] Array foreach in scripting languages

[Jon W. <hp...@mi...>]

Carsten Orthbandt wrote:
> I tested this with both, my DynamicArray and std::vector.
> Since we're talking about a scripting language here, the
> actual implementation doesn't matter. It can be alinked
> list, contigous memory block, hashmap, whatever.
>   

The actual implementation DOES matter, because std::list<> makes the 
guarantee that you can delete items ahead of, or behind, the current 
iterator, without ill effects. An array, on the other hand, explicitly 
forbids that practice.

Thus, depending on which semantic you prefer to expose, you should 
choose one, or the other. That's one of the reasons that C++ defines 
both data types, and lets the programmer decide.

In the case where you're using a data type that invalidates iterators, I 
suggest that you (at least in debug mode) detect the invalid iterator 
and assert out on first use. The sooner you detect potentially invalid 
usage, the better.

Cheers,

             / h+

Re: [GD-Windows] Array foreach in scripting languages

[Carsten O. <car...@se...>]

I tested this with both, my DynamicArray and std::vector.
Since we're talking about a scripting language here, the
actual implementation doesn't matter. It can be alinked
list, contigous memory block, hashmap, whatever.
Simply think of it as a resizeable array. As stated before,
even the case where the current element gets removed from
the list can be handled correctly because I can control the
real lifetime of any object. So if the current element is
removed in the foreach, there's still a reference to it from
the iterator. Therefor it won't be freed immediately.

Best regards,

Carsten Orthbandt
Founder + Development Director
SEK SpieleEntwicklungsKombinat GmbH
http://www.sek-ost.de

Wenn ich Visionen habe, gehe ich zum Arzt. - Helmut Schmidt
 =20

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...]=20
> On Behalf Of Jon Watte
> Sent: Sunday, August 13, 2006 10:05 PM
> To: Game Development for MS Windows
> Subject: Re: [GD-Windows] Array foreach in scripting languages
>=20
> What's confusing is that your code uses the name DynamicArray=20
> (which I=20
> suppose is close to ArrayList in .NET), and your C++ test sample=20
> probably used std::vector, but you keep referring to the=20
> container as a=20
> "list". They are very different kinds of containers.
>=20
> You will note that C++ allows you to insert and delete objects in a=20
> std::list, but not in a std::vector. The reason is that vectors are=20
> guaranteed to be contiguous, and thus iterators (which may be simple=20
> pointers) would get invalidated when resizing the underlying storage.=20
> Meanwhile, when deleting from a list, the only iterator that gets=20
> invalidated is an iterator pointing to the element being deleted.
>=20
> Cheers,
>=20
>                       / h+
>=20
>=20
> Carsten Orthbandt wrote:
> > The obvious question is how should an active iterator react=20
> if the traversed list
> > changes? To answer this, I simply tried it out in two=20
> languages I know that do
> > provide both dynamic arrays and foreach: STL, Tcl and C#.
> >  =20
>=20
>=20
>=20
> --------------------------------------------------------------
> -----------
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make=20
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on=20
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> 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

Re: [GD-Windows] Array foreach in scripting languages

[Research <res...@ga...>]

Although it can have other side effects, you may be able to live with "Lazy 
Deletion". You mark a list entry as "deleted" when deleted during an 
iterator but not do the delete until your done iterating. Even if you bail 
out of the iteration, the list header can indicate that there are "deleted" 
members in the list and clean them up before the next iteration begins 
(and/or add the list to a list of stuff that needs maintenance between 
frames). Of course this can have side effects, but there are cases where 
this is acceptable and can allow an iterator to split up a list among 
processing units by knowing that the part of the list they are working on is 
safe.

Brett Bibby
GameBrains

----- Original Message ----- 
From: "Carsten Orthbandt" <car...@se...>
To: <Gam...@li...>
Sent: Saturday, August 12, 2006 9:46 PM
Subject: [GD-Windows] Array foreach in scripting languages


> I'm currently building a small scripting language for interactive stuff. 
> Now I
> know there's plenty out there, I'm just doing this for fun.
>
> A tricky question came up and I'd like to collect opinions and experiences 
> on
> this. It's about foreach for dynamic arrays. Consider this C++-like pseudo 
> code:
>
> DynamicArray<int> list;
> int i;
> for(i=0;i<20;i++){list.Add(i);};
> foreach(i in list){
>    print(i);
>    if(i==8){list.Delete(12);};
> };
>
> The obvious question is how should an active iterator react if the 
> traversed list
> changes? To answer this, I simply tried it out in two languages I know 
> that do
> provide both dynamic arrays and foreach: STL, Tcl and C#.
>
> In STL C++ code, I get an exception because of iterator incompatibility.
> In Tcl this problem isn't one because the iterator takes a snapshot of the 
> list
> object on start and there's no language construct to actually change this 
> instance.
> In C# with the List<int> generic, I get an exception because the iterated 
> object
> changes (interestingly, this happens on ANY change to the list, even 
> appending).
>
> Now what I'd like to know:
> - how do other languages cope with this? (Tcl doesn't need to, C++/C# 
> simply fails)
> - what do YOU think would be sensible behaviour?
>
> Currently I'm considering having all iterators be elements of a 
> double-linked list
> and let the array object be the dl-list head. So if the number of array 
> elements
> changes, it can run through all attached iterators and fix their indices 
> or stop them.
>
>
> Carsten Orthbandt
> Founder + Development Director
> SEK SpieleEntwicklungsKombinat GmbH
> http://www.sek-ost.de
>
> Wenn ich Visionen habe, gehe ich zum Arzt. - Helmut Schmidt
>
>
>
> -------------------------------------------------------------------------
> 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