Announcement

Collapse
No announcement yet.

Communicating between two programs??

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Communicating between two programs??

    I need to write a program which acts as a brige between two
    Windows applications (call them A & B) allowing “A” to
    send msgs to “B” and vice versa. For example, "A" might send
    a request for data from "B". "B" needs to respond to "A"
    with the requested data immediately. I do not want to use a
    polling method to check for incomming messages, rather, I
    want any incomming msg to trigger some event so the
    receiving app will reply quickly.

    I was thinking about a 32bit DLL using the "CALL DWORD"
    command. First "A" and "B" would register their receiving
    function with the DLL. Then when the "A" sends a msg to "B"
    it does it by the "CALL DWORD" which would send the msg
    directly to "B's" receiving function and vice versa.

    Is this the best method or what do you recommend?

    Thank you!


    ------------------

  • #2
    I belief that a exported function in the exe's would do.
    But i'm not sure.

    I read (and used) that WM_SETTEXT between processes is using filemapping internally.

    WM_SETTEXT is really easy and even possible between a 16bit and 32bit app.

    Sharing data should be done using filemapping.
    Notifications.., i'm not sure however, you can link processes.
    If you do that i guess you can do anything.

    On the internet is a sample for VB ForceForegroundwindow.
    This shows 'linking' processes.


    ------------------
    [email protected]
    hellobasic

    Comment


    • #3
      Doug --

      If I understand what you are saying about using CALL DWORD, it simply won't work. You see, as the two EXE programs link to the DLL, each will be operating in its own "process" and they will be invisible to each other. Each EXE will have its own complete set of GLOBAL variables in the DLL. They cannot "share data" in this way. Even if you call an exported function that is located in a different EXE (like two EXEs calling each other's functions) the GLOBAL data will definitely not be shared.

      The general topic that you are describing is called InterProcess Communication, or IPC. Windows makes several different IPC functions available, each with their own advantages and disadvantages. Common techniques include Mailslots, Named Pipes, Anonymous Pipes, and Memory Mapped Files, and there are several others. Search MSDN for "IPC" and you will find lots of information.

      If you can be more specific about a few things I can give you some pointers. For example, will the two programs always be running on the same PC, or might they have to communicate across a network? Will the programs always run on Windows NT or 2000, or might they run on 9x or ME systems? Is one program the "child" of the other, i.e. does one program launch the other, or are they 100% separate programs? How large are the messages that must be passed back and forth? Is the communication "message" oriented, or is it more like a stream of data with no specific "block" or "segment" structure?

      Depending on your answers, it will become clear which is the best IPC method to use...

      -- Eric

      ------------------
      Perfect Sync: Perfect Sync Development Tools
      Email: mailto:[email protected][email protected]</A>

      "Not my circus, not my monkeys."

      Comment


      • #4
        There is a package getting ready to be, or already released to do this for you, pretty simple too....

        I'll email Jim and see how it's coming along, what I've seen of it looks right nice...


        Scott

        ------------------
        Scott
        mailto:[email protected][email protected]</A>
        Scott Turchin
        MCSE, MCP+I
        http://www.tngbbs.com
        ----------------------
        True Karate-do is this: that in daily life, one's mind and body be trained and developed in a spirit of humility; and that in critical times, one be devoted utterly to the cause of justice. -Gichin Funakoshi

        Comment


        • #5
          Doug,

          There are a couple of ways to perform inter-process communication that
          are both reasonably straight forward.

          Registering a private windows message as follows is clean simple and tidy.

          WM_SENDMSG = RegisterWindowMessage("Inter_Process_Message_A")
          WM_RECEIVE = RegisterWindowMessage("Inter_Process_Message_B")

          You then use,

          SendMessage %HWND_BROADCAST,WM_SENDMSG,0,0

          and at the other program,

          Case WM_RECEIVE

          You can register any unique name that suits your requirement and if the
          string is identical in both apps, they can communicate this way.

          To pass data,

          GLOBAL cds as COPYDATASTRUCT

          --------

          a$ = "This is a test !!!!"

          cds.dwData = 0
          cds.cbData = len(a$)
          cds.lpData = StrPtr(a$)
          SendMessage lParam,%WM_COPYDATA,hWin,ByVal VarPtr(cds.dwData)

          and at the other app, process the message,

          Case %WM_COPYDATA

          With more work you can use memory mapped files if you need this type of
          capacity.

          Regards,

          [email protected]

          ------------------
          hutch at movsd dot com
          The MASM Forum

          www.masm32.com

          Comment


          • #6
            Thank you everyone! I will study your recommendations.

            ------------------

            Comment


            • #7
              Doug, is it a threaded app or not?
              If it is not a threaded application, you could consider a controlling
              exe, which calls the seperate programs as dll's one by one, while
              passing the info through.

              Herman..


              ------------------
              You gotta run, and don't loop back.

              Comment

              Working...
              X