Single instance problem in Win32s
Rene M. Laviolette -- mti@map.com
Thursday, February 15, 1996
I'm trying to limit my application to one instance. I'm using MSVC++ 4.0
and I'm using the code from the ONET32 sample.
I run into problems when I run my app from Windows 3.1 (Win32s 1.30a), the
first instance starts correctly but when I attempt to launch a 2nd instance,
the system returns with the following message: "Insufficient memory to run
this application. Quit one or more Windows applications and then try again"
I have no other apps running.
The odd part is if I first start the ONET32.EXE program and then launch my
app, everything works ok with no insufficent memory messages.
If I start my application then start ONET32.EXE, the ONET32 program crashes
with the messages: "Initialization of a dynamic link library failed. The
process is terminating abnormally" then the "Unexpected DOS error: 21"
message box appears.
Any and all suggestions are welcome. Is this something I'm doing wrong? Is
this a Win32s limitation or error?
Thanks.
Mike Blaszczak -- mikeblas@interserv.com
Saturday, February 17, 1996
On Thu, 15 Feb 96, "Rene M. Laviolette" wrote:
>I'm trying to limit my application to one instance. I'm using MSVC++ 4.0
>and I'm using the code from the ONET32 sample.
Where did you get the ONET32 sample? Isn't it the one that uses a named
synchromization object to let other instances know that the first instance is
running?
If that's the case, it won't work under Win32s because Win32s doesn't support
threads or thread synchronization objects.
.B ekiM
--
TCHAR szDisc[] = _T("These words are my own; I do not speak for Microsoft.");
Derick J.R. Qua-Gonzalez -- dqua@holland-c.it.earthlink.net
Sunday, February 18, 1996
[Mini-digest: 3 responses]
> On Thu, 15 Feb 96, "Rene M. Laviolette" wrote:
> >I'm trying to limit my application to one instance. I'm using
> >MSVC++ 4.0 and I'm using the code from the ONET32 sample.
>
> Where did you get the ONET32 sample? Isn't it the one that uses a
> named synchromization object to let other instances know that the
> first instance is running?
>
> If that's the case, it won't work under Win32s because Win32s
> doesn't support threads or thread synchronization objects.
>
Guys, aren't we thinking a little too deep and complex here? Why
could you not use a lock file that you create in the InitInstance and
delete during ExitInstance? During a subsequent InitInstance, you
could stat the file and terminate if it exists. In the event of a
crash, it is simple for one to manually delete the file (or, if you
want to be a little fancier, instead of just terminating if it
exists, present the user with an option to proceed, recreating the
lock file if needed). Alternatively, you could use an entry in the
registry, but I think the lock file should be sufficient.
Best regards,
Derick.
-----From: mikeblas@interserv.com
On Sun, 18 Feb 1996, "Derick J.R. Qua-Gonzalez"
wrote:
>Guys, aren't we thinking a little too deep and complex here?
No, I don't think so.
> Why could you not use a lock file that you create in the
>InitInstance and delete during ExitInstance?
>In the event of a crash, it is simple for one to
>manually delete the file
Most users (and certainly all helpdesks) don't want to deal with this kind of
thing. Further, a file gives you no way to ask the previous instance of the
application to activate itself.
.B ekiM
--
TCHAR szDisc[] = _T("These words are my own; I do not speak for Microsoft.");
-----From: Mario Contestabile
>I'm trying to limit my application to one instance. I'm using MSVC++ 4.0
>and I'm using the code from the ONET32 sample.
See Faq section 11.8
Derick J.R. Qua-Gonzalez -- dqua@finland-c.it.earthlink.net
Monday, February 19, 1996
> -----From: mikeblas@interserv.com
> On Sun, 18 Feb 1996, "Derick J.R. Qua-Gonzalez"
> wrote:
> > Why could you not use a lock file that you create in the
> >InitInstance and delete during ExitInstance?
>
> >In the event of a crash, it is simple for one to
> >manually delete the file
>
> Most users (and certainly all helpdesks) don't want to deal with
> this kind of thing. Further, a file gives you no way to ask the
> previous instance of the application to activate itself.
>
I still don't see what the big bother is with this method or with
deleting a file (especially if done automatically). Its extremely
portable, and while it may not be fancy, it does work.
A file _can_ give the functionality you demand. You can, for
example, record the process id of the previous instance; the rest is
academic. There are many ways to approach this problem, and if the
check is encapsulated in a function, then it can readily be changed
from the simple lock file to contacting a license manager on a
network server. [DQG]
David W. Gillett -- DGILLETT@expertedge.com
Tuesday, February 20, 1996
[Mini-digest: 2 responses]
> Guys, aren't we thinking a little too deep and complex here? Why
> could you not use a lock file that you create in the InitInstance
> and delete during ExitInstance? During a subsequent InitInstance,
> you could stat the file and terminate if it exists. In the event
> of a crash, it is simple for one to manually delete the file (or,
> if you want to be a little fancier, instead of just terminating if
> it exists, present the user with an option to proceed, recreating
> the lock file if needed). Alternatively, you could use an entry in
> the registry, but I think the lock file should be sufficient.
It's perhaps worthwhile to point out that while this should work
under Win32s, it's not sufficient for 95 or NT because you can get
preempted between the stat() call and creating the file if it didn't
exist.
Dave
-----From: beriksen@cda.com
And if the program crashes before deleting the lock file in ExitInstance...
______________________________ Reply Separator _________________________________
Subject: Re: Single instance problem in Win32s
Author: mfc-l@netcom.com at Internet_Mail
Date: 2/20/96 4:58 PM
> -----From: mikeblas@interserv.com
> On Sun, 18 Feb 1996, "Derick J.R. Qua-Gonzalez"
> wrote:
> > Why could you not use a lock file that you create in the
> >InitInstance and delete during ExitInstance?
>
> >In the event of a crash, it is simple for one to
> >manually delete the file
>
> Most users (and certainly all helpdesks) don't want to deal with
> this kind of thing. Further, a file gives you no way to ask the
> previous instance of the application to activate itself.
>
I still don't see what the big bother is with this method or with
deleting a file (especially if done automatically). Its extremely
portable, and while it may not be fancy, it does work.
A file _can_ give the functionality you demand. You can, for
example, record the process id of the previous instance; the rest is
academic. There are many ways to approach this problem, and if the
check is encapsulated in a function, then it can readily be changed
from the simple lock file to contacting a license manager on a
network server. [DQG]
Simon Wilson -- simon@techsoft.demon.co.uk
Thursday, February 22, 1996
On Thu, 15 Feb 96 17:39 EST, you wrote:
>I'm trying to limit my application to one instance. I'm using MSVC++ 4.0
>and I'm using the code from the ONET32 sample.
>
>I run into problems when I run my app from Windows 3.1 (Win32s 1.30a), the
>first instance starts correctly but when I attempt to launch a 2nd instance,
>the system returns with the following message: "Insufficient memory to run
>this application. Quit one or more Windows applications and then try again"
>I have no other apps running.
>
>The odd part is if I first start the ONET32.EXE program and then launch my
>app, everything works ok with no insufficent memory messages.
>
>If I start my application then start ONET32.EXE, the ONET32 program crashes
>with the messages: "Initialization of a dynamic link library failed. The
>process is terminating abnormally" then the "Unexpected DOS error: 21"
>message box appears.
>
>Any and all suggestions are welcome. Is this something I'm doing wrong? Is
>this a Win32s limitation or error?
>
>Thanks.
>
Guys,
Do calm down and read the FAQ, 11.0 "How do I limit my MFC application
to one instance". That's what its there for after all.
"If all else fails, read the FAQ!"
Cheers,
===========================================================
Simon Wilson Technisoft Ltd.
simon@techsoft.demon.co.uk Macclesfield
Consultancy Services England
Windows (NT), OOP, OOA +44 1625 434533
===================================================
Mike Blaszczak -- mikeblas@interserv.com
Saturday, February 24, 1996
On Thu, 22 Feb 1996, Simon Wilson wrote:
>Do calm down and read the FAQ, 11.0 "How do I limit my MFC application
>to one instance". That's what its there for after all.
>"If all else fails, read the FAQ!"
Niels' code in the FAQ will work, but RegisterWindowClass() is a pretty
expensive call... and this approach, too, leaves little room for notifying
the original instance that it ought to become active.
I'll still maintain my original point: using a named synchronization resource
is a noticably better solution, unless you're using Win32s. It's
lightweight, atomic, it creates and destroys trivially, and it can be used to
signal the other application.
.B ekiM
--
TCHAR szDisc[] = _T("These words are myself; my bike has Microsoft spokes.");
| Вернуться в корень Архива
|