Detecting Multiple Instances of an Application in VC++

Environment: VC6

This is a very simple way to detect the running instance of an application. It can be achieved by declaring a data variable in the compiler's own data section called shared.

#pragma data_seg("Shared")
LONG g_Counter = -1;
#pragma data_seg()

After this, the Linker will be noticed to make the Shared section readable, writable, and shared.

#pragma comment(linker, "/section:Shared, rws")

Now, whenever the application runs, the data variable declared in the compiler's data section will be incremented by 1 and until or unless the application gets closed, the data variable's value will not be decremented. Now, at this point, if we start the application again, it will check for the value of the variable declared in the data section of the compiler. If it's greater than 1, splash message of duplicate instance; else, start the application.

The value in the data variable of the compiler's data section is incremented or decremented by the functions declared in winbase.h; these are InterLockedIncrement and InterLockedDecrement. Just pass the address of the variable and the rest will be performed by the function.

Downloads

Download demo project - 112 Kb


Comments

  • Just another way similiar to the 'named mutex'

    Posted by Legacy on 12/22/2003 12:00am

    Originally posted by: Rudolf M�hlbauer

    the way i do it:
    
    

    BOOL CXXXApp::InitInstance()
    {
    HANDLE hEvent;

    hEvent = CreateEvent(NULL, FALSE, FALSE, "PreAlignerMultipleInstance");
    if(hEvent)
    {
    if(GetLastError() == ERROR_ALREADY_EXISTS)
    {
    // Exit the Application
    AfxMessageBox("Application already Running!");
    return FALSE;
    }
    }
    ...
    ...
    }

    that's all whats needed!


    it's quite similiar to the way shown in the example with the named mutex.

    Reply
  • another way...

    Posted by Legacy on 10/16/2003 12:00am

    Originally posted by: um

    This way is found on named kernel-objects (KO).
    1. During process loading you can try to OpenXXX yours unique named KO, likes h=OpenMutex(...,"MyUniqueMutex").
    2. If function results the INVALID_HANDLE_VALUE, then this instance is the first and single. So you should instantiate your KO, likes h=CreateMutex(...,"MyUniqueMutex"). Else you know that this process is not first.
    3. If your call OpenXXX on step 1. results the good handle value you must call CloseHandle(h);

    Reply
  • So its a rip-off. Atleast the knowledge is accessible to others.

    Posted by Legacy on 08/13/2003 12:00am

    Originally posted by: Jay Horak

    It's not too much to put this up. It's too bad he did give credit to the author.

    Reply
  • booooooooooooo :-(((

    Posted by Legacy on 04/01/2003 12:00am

    Originally posted by: Valerio

    why do you need to post this owful piece of code here?
    

    Reply
  • HOW DARE YOU

    Posted by Legacy on 03/30/2003 12:00am

    Originally posted by: HOW DARE YOU

    This code snippet you have provided has been ripped off of Jeffery Richter's Advanced Windows Programming Book.

    Either come up with your own code and knowledge or at the very least give credit to the original author. or better yet, if you are going to copy someone else's work, at least change the variable names.

    • **** You

      Posted by sandy_bassi on 03/23/2005 02:02am

      Tere ko kaya lene ka hain.

      Reply
    Reply
  • Application in a different folder

    Posted by Legacy on 03/28/2003 12:00am

    Originally posted by: Rejeesh.T.S

    If you copy the application file to a different folder and then execute each separately, the application will not detect the existing instance. That is, the path of first and second instance should be same if the shared data segment is used.

    The better and easy solution is to use a named mutex.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • With JRebel, developers get to see their code changes immediately, fine-tune their code with incremental changes, debug, explore and deploy their code with ease (both locally and remotely), and ultimately spend more time coding instead of waiting for the dreaded application redeploy to finish. Every time a developer tests a code change it takes minutes to build and deploy the application. JRebel keeps the app server running at all times, so testing is instantaneous and interactive.

  • The exponential growth of data, along with virtualization, is bringing a disruptive level of complexity to your IT infrastructure. Having multiple point solutions for data protection is not the answer, as it adds to the chaos and impedes on your ability to deliver consistent SLAs. Read this white paper to learn how a more holistic view of the infrastructure can help you to unify the data protection schemas by properly evaluating your business needs in order to gain a thorough understanding of the applications …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds