Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. WM_COPYDATA message

WM_COPYDATA message

Scheduled Pinned Locked Moved C / C++ / MFC
performancequestion
5 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T Offline
    T Offline
    tom groezer
    wrote on last edited by
    #1

    Does WM_COPYDATA use some kind of shared memory concept when it uses the structure COPYDATASTRUCT?

    B 1 Reply Last reply
    0
    • T tom groezer

      Does WM_COPYDATA use some kind of shared memory concept when it uses the structure COPYDATASTRUCT?

      B Offline
      B Offline
      Bogdan Apostol
      wrote on last edited by
      #2

      When sending WM_COPYDATA message to another application, lParam must point to a COPYDATASTRUCT, and the passed data must not contain any addresses (pointers or references) that would not be available in the other process. Until the thread sending the message returns from the call, the data structure should be either locked or not modified by other threads of the calling process. The data received by the other process cannot modify / return any of the structure's content. The reason behind all these is that the OS is copying the given structure as a block, from the calling process to the receiving process. It is like calling WriteProcessMemory, on some temp variable (thread stack address) in the target process. The communication is one way! Regards,

      Bornish ESRI Developer Network Compilers demystified - Function pointers in Visual Basic 6.0 Enables the use of function pointers in VB6 and shows how to embed native code in a VB application.

      T 1 Reply Last reply
      0
      • B Bogdan Apostol

        When sending WM_COPYDATA message to another application, lParam must point to a COPYDATASTRUCT, and the passed data must not contain any addresses (pointers or references) that would not be available in the other process. Until the thread sending the message returns from the call, the data structure should be either locked or not modified by other threads of the calling process. The data received by the other process cannot modify / return any of the structure's content. The reason behind all these is that the OS is copying the given structure as a block, from the calling process to the receiving process. It is like calling WriteProcessMemory, on some temp variable (thread stack address) in the target process. The communication is one way! Regards,

        Bornish ESRI Developer Network Compilers demystified - Function pointers in Visual Basic 6.0 Enables the use of function pointers in VB6 and shows how to embed native code in a VB application.

        T Offline
        T Offline
        tom groezer
        wrote on last edited by
        #3

        While using the structure could we say that the OS implements one as a shared memory?

        L 1 Reply Last reply
        0
        • T tom groezer

          While using the structure could we say that the OS implements one as a shared memory?

          L Offline
          L Offline
          Lost User
          wrote on last edited by
          #4

          Yes. The way I understand it... when you post a WM_COPYDATA message, the kernel creates a temporary memory mapped file containing the bytes at the location specified relative to the senders address space. This memory mapped file is accessable to the recieving application. Upon SendMessage() returning the memory mapped file is marked for deletion. Best Wishes, Randor (David Delaune)

          B 1 Reply Last reply
          0
          • L Lost User

            Yes. The way I understand it... when you post a WM_COPYDATA message, the kernel creates a temporary memory mapped file containing the bytes at the location specified relative to the senders address space. This memory mapped file is accessable to the recieving application. Upon SendMessage() returning the memory mapped file is marked for deletion. Best Wishes, Randor (David Delaune)

            B Offline
            B Offline
            Bogdan Apostol
            wrote on last edited by
            #5

            Hmm,... reading a few times what MSDN, I understood that you cannot return data in the buffer given by the sending application... but, since I've never tried myself, I would consider David's interpretation. Have already found some sample code on CP using such technique to share memory... 2 ways. Well, it wouldn't be the first time when MSDN is missleading! Still, the opinions found are divided almost 50-50. If you're planning to try it out, please let us know about your findings. It would be great if you can try it out on different OS versions. While searching more info about it, I came across an interesting aspect: http://www.flounder.com/wm_copydata.htm[^] Hope you'll find this idea useful, and couldn't hurt using a GUID as explained there. Best wishes,

            Bornish ESRI Developer Network Compilers demystified - Function pointers in Visual Basic 6.0 Enables the use of function pointers in VB6 and shows how to embed native code in a VB application.

            1 Reply Last reply
            0
            Reply
            • Reply as topic
            Log in to reply
            • Oldest to Newest
            • Newest to Oldest
            • Most Votes


            • Login

            • Don't have an account? Register

            • Login or register to search.
            • First post
              Last post
            0
            • Categories
            • Recent
            • Tags
            • Popular
            • World
            • Users
            • Groups