Add a system-menu item to all applications?

[aehimself 396]

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.

[rvk 33]

27 minutes ago, PeterPanettone said:

Are there any grown-up people here?

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

 

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 October 8, 2019 by rvk

[Sherlock 663]

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.

[PeterPanettone 157]

5 minutes ago, Sherlock said:

get some solid help with your issue

... that would be GREAT!

[rvk 33]

Just now, PeterPanettone said:

... that would be GREAT!

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

 

[FredS 138]

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 October 8, 2019 by FredS

[Remy Lebeau 1394]

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):

 

 

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

 

[Lars Fosdal 1792]

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

Are there any grown-up people here?

Adulthood is overrated.

[Rollo62 536]

<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>

[FredS 138]

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

[PeterPanettone 157]

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 October 14, 2019 by PeterPanettone

[PeterPanettone 157]

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?

[Remy Lebeau 1394]

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.

[FredS 138]

Dunno, where is the Minimal, Reproducible Example 🙂

 

If it works on a Windows 10 Sandbox then the code works, all else is up to AVs and Windows security.

 

I tried to get an API Hooking using AppInit_DLLs example to work but that fails for me even in a Windows 10 Sandbox, works in W7 though.

[rvk 33]

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/

[PeterPanettone 157]

1 hour ago, FredS said:

where is the Minimal, Reproducible Example

On your GitHub web page. I didn't change anything, just compiled your demo.