Thread: throwing memory around from exe to exe

  1. #1
    Software Developer jverkoey's Avatar
    Join Date
    Feb 2003
    Location
    New York
    Posts
    1,905

    throwing memory around from exe to exe

    K, this question could fit either in the win32 section or in the C++ section, as it has to do more with memory management and pointers, but uses win32 functions....so if any mods feel this is the wrong place, feel free to move it.

    Anyways, my problem is this:

    In my OST2 compiler, I am trying to make it so that when you load an instance of OST2, and then go double click on a .ost/.osh/.osp file, it loads that file in to the already running instance of OST2....know what I mean?

    I already have it in the installer to register the filetypes to run with my compiler's IDE, so no need to worry there. I also already have it so when you double click the file after opening the IDE, it finds the already open compiler and does the following:

    Code:
     	HWND oldWnd=FindWindow(CLASSNAME,NULL);
     
     	if(oldWnd)
     	{
     		if(lpCmd && lpCmd[0]!='\0')
     		{
     			HANDLE hGlobal=GlobalAlloc(GPTR|GMEM_SHARE,strlen(lpCmd)+1);
     			LPVOID cmd=GlobalLock(hGlobal);
     			memcpy(cmd,(void*)lpCmd,strlen(lpCmd)+1);
     			GlobalUnlock(hGlobal);
     
     			SendMessage(oldWnd,MESSAGE_OST2ADDNEW,0,(LPARAM)hGlobal);
     			return 0;
     		}
     	}
    It's kinda sloppy right now.....but then later in the program where I process the messages for the main IDE's window:

    Code:
     	case MESSAGE_OST2ADDNEW:
     		{
     			LPVOID vcmd=GlobalLock((HANDLE)lParam);
     			char cmd[1024];
     			strcpy(cmd,(char*)vcmd);
     			GlobalUnlock((HANDLE)lParam);
     			GlobalFree((HANDLE)lParam);
     
     			lpCmd=cmd;
     			MessageBox(hWnd,cmd,"blah",0);
     			ProcessCommandLine();
     		}
     		break;
    k, so my problem is this:
    When I try to send the command line argument to the other program, i send it, then close the other instance right away, causing the memory to either be lost immediately or at any time, which is really not a good situation....I thought maybe a globalalloc call would work...but it doesn't seem to retain the data that I stored in the memory. I'm not sure if I'm using GlobalAlloc correctly or not though is the thing.

    So, yah, I've decided on a few alternatives to fix this problem:

    a) Keep the other instance running until the old one sends a message back saying it processed the information (not sure if this would work or not, if one program is allowed to access another program's memory directly)
    b) screw it and make people just open the files from the file->open menu like I've been doing (which would be kinda a stupid and lazy way to go)
    c) post on cboard after failing to understand why it's not working and hope that after about 5 minutes after posting, I find the answer myself and then feel stupid for posting...and just as i'm about to say i figured it out, have someone post a solution to the problem already

    i'm going with c...

    OST2 release #10.....still in production, trying to figure out something really useful for it, I initially intended the language to be used in games as a game scripting language...but it's turned more in to a pet project now, heh, and is turning more in to just it's own language....so, *shrugs* I dunno, I'm going to go play some dynasty warriors 3 or something

  2. #2
    Yes, my avatar is stolen anonytmouse's Avatar
    Join Date
    Dec 2002
    Posts
    2,544
    No, memory allocated with GlobalAlloc() can not be shared amongst different processes. GlobalAlloc is obsolete and should be avoided where possible.

    You need some form of IPC (InterProcess Communication - look it up in MSDN). Fortunately, there is a very simple IPC method for your situation, in the form of the WM_COPYDATA message:
    Code:
     	if(oldWnd)
     	{
     		if(lpCmd && lpCmd[0]!='\0')
     		{
    			COPYDATASTRUCT cds = { 0 };
    
    			cds.dwData = MESSAGE_OST2ADDNEW;     // function identifier
    			cds.cbData = lstrlenA(lpCmd) + 1;    // size of data
    			cds.lpData = lpCmd;                  // pointer to data to send
    
    			// probably should use SendMessageTimeout for interprocess message calls.
     			SendMessage(oldWnd, WM_COPYDATA, 0, (LPARAM) &cds);
     			return 0;
     		}
     	}
    Code:
    	case WM_COPYDATA:
    	{
    		PCOPYDATASTRUCT pcds = (PCOPYDATASTRUCT) lParam;
    
    		switch(pcds->dwData)
    		{
    			case MESSAGE_OST2ADDNEW:
    
    				// If we are security minded we should not rely on cross process
    				// communication being null terminated. lpData is not valid after this 
    				// message returns.
    				OSTProcessCommand((char*) pcds->lpData, pcds->cbData);
    				return TRUE;
    		}
    		break;
    	}
    If you need to compile your app for unicode you should avoid using the ansi lpCmd as it will prevent your program opening paths which contain unicode characters.

  3. #3
    Software Developer jverkoey's Avatar
    Join Date
    Feb 2003
    Location
    New York
    Posts
    1,905
    Thanks anonytmouse, I'll definitely try that code out in a bit and see if it works. By looking at it, I don't see any reason why it wouldn't, so thanks in advance for the help.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 4
    Last Post: 01-13-2008, 02:14 AM
  2. Question regarding Memory Leak
    By clegs in forum C++ Programming
    Replies: 29
    Last Post: 12-07-2007, 01:57 AM
  3. Memory problem with Borland C 3.1
    By AZ1699 in forum C Programming
    Replies: 16
    Last Post: 11-16-2007, 11:22 AM
  4. Suggestions on this C style code
    By Joelito in forum C Programming
    Replies: 11
    Last Post: 06-07-2007, 03:22 AM
  5. Memory allocation and deallocation
    By Micko in forum C++ Programming
    Replies: 3
    Last Post: 08-19-2005, 06:45 PM