Loading ...
Sorry, an error occurred while loading the content.

RE: [perlguitest] Re: Hooking

Expand Messages
  • Maricel Ciupitu
    Hi, Before 1.49 I have to read some data from ListView32 control. So I made a dll which uses VirtualAllocEx to read data from the control. Then from perl with
    Message 1 of 14 , Feb 14, 2005
    • 0 Attachment
      Hi,

      Before 1.49 I have to read some data from ListView32 control. So I made
      a dll which uses VirtualAllocEx to read data from the control. Then from
      perl with Win32api call this dll. I attach the source code for dll if
      need it.

      -----Original Message-----
      From: pkaluski [mailto:pkaluski@...]
      Sent: Monday, February 14, 2005 11:37 AM
      To: perlguitest@yahoogroups.com
      Subject: [perlguitest] Re: Hooking




      --- In perlguitest@yahoogroups.com, "Dennis K. Paulsen"
      <ctrondlpaulsden@y...> wrote:
      >
      >
      > In the latest CVS builds of Win32::GuiTest/GuiTest.xs, the windows
      > hook (WH_CALLWNDPROC) is *part* of the puzzle we use, so that we
      can
      > interface with various 32bit custom controls, marshall data back from
      > these controls, etc...
      >
      > For example, with a ListView32 control we can't simply just issue a
      > call to ListView_GetItemText() to read an item's text, because of the
      > process boundary limiation, you'll normally end up getting an access
      > violation because your accessing data outside of the processes address

      > space...
      >
      > Regards,
      > D
      >

      Dennis,
      If I understand you correctly, hooking solution (in Win32::GuiTest)
      works as follows:
      For each control related operation (like getting ListView32 contents)
      a hook is set, so the actual list processing is run in address space
      of the process which hosts this control.
      This solution is correct (it is used by Richter in his book) but I
      think it brings some maintainability problems. Expanding
      Win32::GuiTest for handling new controls would reguire changes in .xs
      file and recompilation.
      I believe I have found more flexible solution. Have a look:
      http://www.mathimagics.com/TechNote001.html, "Cross-process buffers"
      section. The full example with the code can be found here:
      http://www.visualbasicforum.com/showthread.php?t=38276

      In short, instead of hooking, the solution uses VirtualAllocEx
      function. This function allocates memory is other process's address
      space. So what you do is this: you allocate memory in address space
      of a process, which hosts a control. You get pointer to this memory.
      Then, you call Send/PostMessage passing this pointer. Control will
      respond writting to proper address space.
      If we manage to create a consistent interface to this functionality,
      we will deliver a mechanism to handle new controls without writing
      any new C code.

      -Piotr

      PS: What is WM_LV_GETTEXT, WM_LV_SELBYTEXT and so on in HookProc?
      Both google and MSDN did not return anything.







      Yahoo! Groups Links









      Prezentul mesaj si orice fisier atasat constituie informatie
      confidentiala si este proprietatea exclusiva a MobiFon S.A.. Mesajul se
      adreseaza numai persoanei fizice sau juridice mentionata ca destinatara,
      precum si persoanelor autorizate sa-l primeasca. In cazul in care nu
      sunteti destinatarul vizat sau persoana autorizata sa primiti acest
      mesaj , va aducem la cunostinta ca dezvaluirea, copierea, distribuirea
      sau initierea unor actiuni pe baza prezentei informatii sunt strict
      interzise si atrag raspunderea dvs. civila si penala. Daca ati primit
      acest mesaj dintr-o eroare, va rugam sa ne anuntati imediat si sa-l
      stergeti apoi din sistemul dvs.
      Nu putem garanta ca transmisia acestui mesaj este securizata sau fara
      erori.


      This message and any files or documents attached are classified as
      MobiFon SA confidential and Propietary Information. It is intended only
      for the individual or entity named and others authorized to receive it.
      If you are not the intended recipient or authorized to receive it, you
      are hereby notified that any disclosure, copying, distribution or taking
      any action in reliance on the contents of this information is strictly
      prohibited and may be unlawful. If you have received this communication
      in error, please notify us immediately then delete it from your
      system.Please also note that transmission cannot be guaranteed to be
      secure or error-free.


      [Non-text portions of this message have been removed]
    • pkaluski
      Hi, Can you place the zip file with the source code in the files section? -Piotr ... made ... from ... if ... from ... a ... the ... access ... address ...
      Message 2 of 14 , Feb 14, 2005
      • 0 Attachment
        Hi,
        Can you place the zip file with the source code in the files section?

        -Piotr

        --- In perlguitest@yahoogroups.com, "Maricel Ciupitu"
        <maricel.ciupitu@c...> wrote:
        >
        >
        > Hi,
        >
        > Before 1.49 I have to read some data from ListView32 control. So I
        made
        > a dll which uses VirtualAllocEx to read data from the control. Then
        from
        > perl with Win32api call this dll. I attach the source code for dll
        if
        > need it.
        >
        > -----Original Message-----
        > From: pkaluski [mailto:pkaluski@p...]
        > Sent: Monday, February 14, 2005 11:37 AM
        > To: perlguitest@yahoogroups.com
        > Subject: [perlguitest] Re: Hooking
        >
        >
        >
        >
        > --- In perlguitest@yahoogroups.com, "Dennis K. Paulsen"
        > <ctrondlpaulsden@y...> wrote:
        > >
        > >
        > > In the latest CVS builds of Win32::GuiTest/GuiTest.xs, the windows
        > > hook (WH_CALLWNDPROC) is *part* of the puzzle we use, so that we
        > can
        > > interface with various 32bit custom controls, marshall data back
        from
        > > these controls, etc...
        > >
        > > For example, with a ListView32 control we can't simply just issue
        a
        > > call to ListView_GetItemText() to read an item's text, because of
        the
        > > process boundary limiation, you'll normally end up getting an
        access
        > > violation because your accessing data outside of the processes
        address
        >
        > > space...
        > >
        > > Regards,
        > > D
        > >
        >
        > Dennis,
        > If I understand you correctly, hooking solution (in Win32::GuiTest)
        > works as follows:
        > For each control related operation (like getting ListView32
        contents)
        > a hook is set, so the actual list processing is run in address
        space
        > of the process which hosts this control.
        > This solution is correct (it is used by Richter in his book) but I
        > think it brings some maintainability problems. Expanding
        > Win32::GuiTest for handling new controls would reguire changes
        in .xs
        > file and recompilation.
        > I believe I have found more flexible solution. Have a look:
        > http://www.mathimagics.com/TechNote001.html, "Cross-process
        buffers"
        > section. The full example with the code can be found here:
        > http://www.visualbasicforum.com/showthread.php?t=38276
        >
        > In short, instead of hooking, the solution uses VirtualAllocEx
        > function. This function allocates memory is other process's address
        > space. So what you do is this: you allocate memory in address space
        > of a process, which hosts a control. You get pointer to this
        memory.
        > Then, you call Send/PostMessage passing this pointer. Control will
        > respond writting to proper address space.
        > If we manage to create a consistent interface to this
        functionality,
        > we will deliver a mechanism to handle new controls without writing
        > any new C code.
        >
        > -Piotr
        >
        > PS: What is WM_LV_GETTEXT, WM_LV_SELBYTEXT and so on in HookProc?
        > Both google and MSDN did not return anything.
        >
        >
        >
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >
        >
        >
        > Prezentul mesaj si orice fisier atasat constituie informatie
        > confidentiala si este proprietatea exclusiva a MobiFon S.A..
        Mesajul se
        > adreseaza numai persoanei fizice sau juridice mentionata ca
        destinatara,
        > precum si persoanelor autorizate sa-l primeasca. In cazul in care nu
        > sunteti destinatarul vizat sau persoana autorizata sa primiti acest
        > mesaj , va aducem la cunostinta ca dezvaluirea, copierea,
        distribuirea
        > sau initierea unor actiuni pe baza prezentei informatii sunt strict
        > interzise si atrag raspunderea dvs. civila si penala. Daca ati
        primit
        > acest mesaj dintr-o eroare, va rugam sa ne anuntati imediat si sa-l
        > stergeti apoi din sistemul dvs.
        > Nu putem garanta ca transmisia acestui mesaj este securizata sau
        fara
        > erori.
        >
        >
        > This message and any files or documents attached are classified as
        > MobiFon SA confidential and Propietary Information. It is intended
        only
        > for the individual or entity named and others authorized to receive
        it.
        > If you are not the intended recipient or authorized to receive it,
        you
        > are hereby notified that any disclosure, copying, distribution or
        taking
        > any action in reliance on the contents of this information is
        strictly
        > prohibited and may be unlawful. If you have received this
        communication
        > in error, please notify us immediately then delete it from your
        > system.Please also note that transmission cannot be guaranteed to be
        > secure or error-free.
        >
        >
        > [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.