CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 18
  1. #1
    Join Date
    Jul 1999
    Posts
    27

    SendMessage() with shared memory?

    I'm writing an app which communicates with other running apps, navigating through their controls. For example, suppose I have the hwnd of a ComboBox in some app. I might do:

    SendMessage(hwnd, CB_GETLBTEXT, idx, (LPARAM)namebuf)

    to get the text associated with the idx'th combo box entry.

    The problem I'm having is that Win95/98 will often crash. I'm assuming the reason is that the memory buffer I'm passing (namebuf) is only valid for my app -- when the other app tries to access it, it's an invalid memory access.

    Does this sound right? If so, is there a way to get a memory address which would be valid for both apps -- in effect, a shared memory address?


  2. #2
    Join Date
    Aug 2000
    Location
    Winnipeg, Canada
    Posts
    344

    Re: SendMessage() with shared memory?

    How did you declare namebuf? Maybe you're not declaring it correctly.

    O-Deka-K


  3. #3
    Join Date
    Sep 1999
    Location
    Michigan
    Posts
    215

    Re: SendMessage() with shared memory?

    Sounds like you need to use GlobalAlloc. It allocates memory outside of your process ( think - sending data to the clipboard ).


  4. #4
    Join Date
    Aug 2000
    Location
    Winnipeg, Canada
    Posts
    344

    Re: SendMessage() with shared memory?

    GlobalAlloc() is only provided for backwards-compatibility with 16-bit apps. There's no such thing as a "local heap" in Win32, so there's no longer any use for GlobalAlloc(), LocalAlloc(), near, or far (well, unless you're making a 16-bit app in VC++ 1.x).

    New Win32 apps should use VirtualAlloc() instead. The docs say it's faster than the old two. You may want to use new instead of VirtualAlloc() though, depending on the situation.

    O-Deka-K


  5. #5
    Join Date
    Aug 2000
    Location
    New York, NY, USA
    Posts
    5,656

    Re: SendMessage() with shared memory?

    "...there's no longer any use for GlobalAlloc()..."
    One exception (from MSDN):
    However, the global functions are still used with DDE and the clipboard functions.
    Yes, you can pass global handle to another process and it could then do a GlobalLock() on it to get to that memory.
    Unfortunately, in the case of WM_GETTEXT message, the recipient is NOT going to do a GlobalLock, he will just attempt to write to the specified memory address.
    If you are lucky, this will cause immediate GPF. If that other process happen to have memory allocated at the provided address, he will write all over himself, and might fail randomly for no apparent reason...
    VirtualAlloc(), however new it is, only allocates memory in your own process address space, which is not helping us here.
    You could use VirtualAllocEx() to allocate memory in another process address space, and then read it with ReadProcessMemory().


    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    I do not do it for the rating. Oh, wait... Sure, I do!
    Vlad - MS MVP [2007 - 2012] - www.FeinSoftware.com
    Convenience and productivity tools for Microsoft Visual Studio:
    FeinWindows - replacement windows manager for Visual Studio, and more...

  6. #6
    Join Date
    Jul 1999
    Posts
    27

    Re: SendMessage() with shared memory?

    Thanks -- that sounds promising...


  7. #7
    Join Date
    Jul 1999
    Posts
    27

    Re: SendMessage() with shared memory?

    Excellent! Top rating! Give that man a cookie!

    Sounds like you understand the exact problem, and your solution sounds like it will work. I'll give it a try.

    Many thanks!


  8. #8
    Join Date
    Jul 1999
    Posts
    27

    Re: SendMessage() with shared memory?

    Er, ummm, well......



    func()
    {
    char namebuf[100];

    ...
    SendMessage(hwnd, CB_GETTEXT, 0, namebuf);
    }





    (he sheepishly admits...)


  9. #9
    Join Date
    Jul 1999
    Posts
    27

    Re: SendMessage() with shared memory?

    Unfortunately, looking into it a bit, I see that VirtualAllocEx() only works under NT (4.0+) -- not Win95/98.

    Could it be that there is no solution for Win95/98? There _must_ be some dastardly sort of trick which could be used...




  10. #10
    Join Date
    May 1999
    Location
    Southern California
    Posts
    12,266

    Re: SendMessage() with shared memory?

    My copy of VC 5 SDK samples has 395 occurrence of GlobalAlloc, some of which are comments and some probably are for DDE and the clipboard functions, but probably many of them are uses that the documentation implies are not valid. So as much as the documentation seems to indicate that it is a mistake to use GlobalAlloc, it is probably more useful than the documentation indicates.

    My VC 5 MFC source uses GlobalAlloc 21 times and 7 of those use GMEM_SHARE.

    http://support.microsoft.com/support.../q119/7/65.asp is current for VC 6 and uses GlobalAlloc.


    "Signature":
    My web site is Simple Samples.
    C# Corner Editor

  11. #11
    Join Date
    May 1999
    Location
    Southern California
    Posts
    12,266

    Re: SendMessage() with shared memory?

    According to the documentation, the only way to get shared memory is by using file sharing. If you read my other reply, though, you will see that the SDK samples and even MFC itself uses GlobalAlloc. So try using something such as:hGlob = GlobalAlloc(GPTR | GMEM_SHARE, (DWORD)nLen);
    if (hGlob)
    lpStr = (LPSTR)GlobalLock(hGlob);

    I do not know if it will work but it might.


    "Signature":
    My web site is Simple Samples.
    C# Corner Editor

  12. #12
    Join Date
    Jul 1999
    Posts
    27

    Re: SendMessage() with shared memory?

    As I understand it, GlobalLock() is giving you a memory address in your process's virtual address space. The other app would have to likewise do a GlobalLock() on the handle in order to get a pointer to the same memory (and the pointer would be different).

    I think.


  13. #13
    Join Date
    May 1999
    Location
    Southern California
    Posts
    12,266

    Re: SendMessage() with shared memory?

    I think we are getting into some undocumented features of 32-bit Windows. You are correct that that is how it works according to the documentation. In a 16-bit environment it was easy to do what you want to do, and I think that 32-bit Windows still supports some of those features but does not say so in the documentation. The only reason why I suspect that some features are still supported is because the SDK samples and the MFC source code seem to be using features that are not documented. I think that Windows designates a range of memory addresses that is shared by all processes and hopefully requesting a shared area of memory allocates memory in that range and if so then the memory would be addressable to all proceses.

    I cannot find the documentation page I saw a couple of weeks ago but I did see a nice diagram showing designated address ranges in Windows.


    "Signature":
    My web site is Simple Samples.
    C# Corner Editor

  14. #14
    Join Date
    Jul 1999
    Posts
    27

    Re: SendMessage() with shared memory?

    Earlier, while reading docs, I saw that 1GB of address space is shared among processes (Win95/98):



    Windows 95 and Windows 98: The 4 MB partition in low memory (0x00000000 to 0x00000FFF) is used for compatibility with MS-DOS and 16-bit Windows, the next approximately 2G partition (0x00400000 to 0x7FFFFFFF) is available to the process for private use, the next 1 GB partition (0x80000000 to 0xBFFFFFFF) is shared by all Win32 processes, and the 1 GB partition in high memory (0xC0000000 to 0xFFFFFFF) is used by the system.






    Perhaps you're right that GlobalAlloc() gives you memory in that space, and that it isn't necessary for the other process to GlobalLock() it. Worth a try -- thanks for the suggestion!


  15. #15
    Join Date
    Aug 2000
    Location
    Winnipeg, Canada
    Posts
    344

    Re: SendMessage() with shared memory?

    Okay, I guess I was wrong. I was just going by the documentation though, and you know how great MS docs are. ;-P

    e.g.
    GlobalAlloc
    ...
    "This function is provided only for compatibility with 16-bit versions of Windows."
    ...
    GMEM_DDESHARE, GMEM_SHARE
    "This flag is provided primarily for compatibility with 16-bit Windows. However, this flag may be used by some applications to enhance the performance of DDE operations and therefore can be specified if the memory is to be used for DDE. ."

    I highlighted the inconsistent parts. Notice that there are two periods at the end too (editing mistake?). Looks like you guys are right.

    O-Deka-K


Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured