Jump to content
PeterPanettone

Add a system-menu item to all applications?

Recommended Posts

1 minute ago, PeterPanettone said:

Are there any grown-up people here?

Come on. Let us to have some fun, life is not only strict and serious work.

After all, there are people who always try to put some humor into their writing.

  • Like 1

Share this post


Link to post
Posted (edited)
27 minutes ago, PeterPanettone said:

Are there any grown-up people here?

Yes, there are... (although I could also appreciate the comment of FredS :classic_ninja:)

 

I have it working here in 64 bit.

Besides the INVALID_HANDLE_VALUE I mentioned earlier, you need to use the correct GetMsgProc() definition.

The one now used is only valid in 32 bit.

If you change it into this it worked here (both in the implementation and interface part).

 

Quote

function GetMsgProc(Ignore: integer; wParam: Windows.WPARAM; uMessage: Windows.LPARAM): LRESULT; stdcall;

(although you might want to avoid a parameter named wParam because it is also a type in the Windows unit which you need, solved here with unit-prefixing)

 

 

Edited by rvk
  • Like 1

Share this post


Link to post

Before this gets out of hand, @PeterPanettone, may I suggest looking at the nickname FredS a bit closer and then cross reference it with the person you are looking for. Then have a good laugh and perhaps get some solid help with your issue.

Share this post


Link to post
Just now, PeterPanettone said:

... that would be GREAT!

See my previous post, because I already got this working.

 

Share this post


Link to post
Posted (edited)
6 hours ago, rvk said:

already got this working

Feeling ignored?

 

That code is literally from last century and had no incling about WIN64..

Although I haven't really looked at it your changes is what I needed to change in my code. Which by the way is blocked by Delphi and is NOT a commercial solution.

There has been little demand for hooks in my current project so there was no need to even look at it other than as  an exercise.

 

Another reason not to get involved here is that I and you can find the solution with very little effort, but system wide hooks in Windows 1984.. err.. 10 are not so reliable.
The one place we use a hook that absolutely needs to work madCodeHook is used in a signed Driver (special certificate).

 

 

Edited by FredS

Share this post


Link to post
On 10/7/2019 at 11:00 AM, PeterPanettone said:

Unfortunately, when I try to start a debug session for any Win64 project in my Delphi 10.3.1, I get the following error (debugging Win32 projects does work):

 

image.png.447daffa25390aac0c84c74ed366d31b.png

 

Why is there an error in a CPP file if I try to start a debug session for a DELPHI project?

Because the error is happening inside the debugger itself, which is obviously written in C++.

 

Maybe this will help you:

 

64-bit Debugger Assertion Failure lastErr == WSAEINTR

 

Can't run new project in win64 mode, but win32 mode works fine

 

Share this post


Link to post
On 10/8/2019 at 9:48 AM, PeterPanettone said:

Are there any grown-up people here?

Adulthood is overrated.

  • Like 1
  • Haha 1

Share this post


Link to post

<OT> (c) Monty Python

Quote

Now, nobody likes a good laugh more than I do...except perhaps my wife and some of her friends...oh yes and Captain Johnston. Come to think of it most people likes a good laugh more than I do.

</OT>

Share this post


Link to post
5 hours ago, FredS said:

Some of Hooks-Made-Easy updated and now on GitHub.

Thank you very much!! I am sorry for my late answer, I was away for a personal issue.

 

PS: How can I show you my gratitude? May I send you a small donation?

Edited by PeterPanettone

Share this post


Link to post
19 hours ago, FredS said:

Some of Hooks-Made-Easy updated and now on GitHub.

I have downloaded it and tried the GetMsgHook demo (Delphi 10.3.1, Windows 7 x64):

 

The 32-bit worked well straightaway, without signing the DLL etc.

 

The 64-bit version did not work the first time, so I followed the recommendations from the GitHub page:

 

• uiAccess="true"
• Code MUST be digitally signed
• Your application MUST reside in a trusted location (e.g.; Program Files) 

 

As the 64-bit version still did not work, I tried to trace all methods in HooksMadeEasy.GetMsg.pas with CodeSite. So I saw that the procedures TGetMsgHook.Hookup and TGetMsgHook.Stop worked well, but then the tracing in the TGetMsgHook.GetMsgProc loop seemed to get too much strain on my system and messed it up so I had to reboot the computer.

 

Strangely, after rebooting and recompiling the 64-bit DLL without the GetMsgProc tracing, the 64-bit version suddenly DID WORK: Clicking a system menu item in a 64-bit program showed up in the TestGetMsgHooks.exe feedback list.

 

1. So why did it work with 64-bit programs only after rebooting?

 

2. To make it work with BOTH 32-bit programs and 64-bit programs supposedly I would have to start BOTH a 32-bit exe with a 32-bit DLL AND a 64-bit exe with a 64-bit DLL? Or is there a way to activate both the 32-bit hook AND the 64-bit hook with ONE SINGLE exe?

Share this post


Link to post
3 hours ago, PeterPanettone said:

To make it work with BOTH 32-bit programs and 64-bit programs supposedly I would have to start BOTH a 32-bit exe with a 32-bit DLL AND a 64-bit exe with a 64-bit DLL?

Correct.

3 hours ago, PeterPanettone said:

Or is there a way to activate both the 32-bit hook AND the 64-bit hook with ONE SINGLE exe?

There is not, because you cannot combine 32-bit and 64-bit code into a single executable, so you will need separate 32-bit/64-bit DLLs, and thus will need separate 32-bit/64-bit processes to install their hooks into target 32-bit/64-bit processes.

Share this post


Link to post
4 hours ago, PeterPanettone said:

Or is there a way to activate both the 32-bit hook AND the 64-bit hook with ONE SINGLE exe?

I'm not sure but there might be a way to do it from one exe. But that might be really advanced stuff (haven't looked st the details).

 

A 64-bit process can access a 32-bit DLL across a process boundary if the 32-bit DLL is loaded into a separate 32-bit surrogate process space, and the application makes use of the built-in IPC mechanisms that support data exchange between 32-bit and 64-bit processes.

 

https://blog.mattmags.com/2007/06/30/accessing-32-bit-dlls-from-64-bit-code/

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×