On Tue, 14 May 2019 19:44:01 +0200, Mike Wey wrote:

On 14-05-2019 05:10, Alex X wrote:

Any news on this?

https://forum.dlang.org/thread/bznpylcjostbrrwzhmst@forum.dlang.org

It's severely cramping my style ;/

Unfortunately no.

Ok, So I figured you probably don't care enough to invest your time to fix it so I went ahead and looked in to it and was able to get it fixed:

// The following code bypasses GTK windows hooking that causes problems with visual studio debugging(slow keyboard, it is a hack and may not work in general)
debug {
	import core.sys.windows.windows, core.stdc.string;
	alias HHOOK function(int, HOOKPROC, HINSTANCE, DWORD) SetWindowsHookExAProc;
	alias HHOOK function(int, HOOKPROC, HINSTANCE, DWORD) SetWindowsHookExWProc;
	static extern (Windows) HHOOK KBHook(int, HOOKPROC, HINSTANCE, DWORD)
	{
		asm
		{
			naked;
			ret;
		}
	}

	DWORD old;
	auto err = GetLastError();

	auto hModule = LoadLibrary("User32.dll");
	auto proc = cast(SetWindowsHookExAProc)GetProcAddress(hModule, "SetWindowsHookExA");
	err = GetLastError();
	VirtualProtect(proc, 40, PAGE_EXECUTE_READWRITE, &old);
	err = GetLastError();

	memcpy(proc, &KBHook, 7);
	// Cleanup	
	//FreeLibrary(hModule);
}

The code above is based on the idea from

https://github.com/microsoft/Detours

I didn't feel like investing the time to integrate it in to my code.

The code I've included is a hack that simply bypasses all hooking routines and hence the screwed up keyboard hook.

It only works for x64 since ret works to return properly(x86 messages with the stack and requires a bit more code).

You could easily make it work in general by using Detours or modify the code to work more generally. It works for my purpose. I do not know if it will allow keyboard input in to the gtk app though but it is irrelevant for my purposes now.

The main issues are:

1. It must be able to decode the instruction set properly so it can a proper overwrite without screwing things up. Detours does this and works for a range of architectures.

2. It should detect the keyboard hooks so others are not prevented.

3. Ideally it will still call the keyboard hooks but prevent them from slowing things down(possibly use a thread).

If you could get Detours to work then you could include it and simply hook the function and write a little code to get everything to work.

On Thu, 16 May 2019 19:53:33 +0200, Mike Wey wrote:

On 15-05-2019 13:32, Alex X wrote:

On Tue, 14 May 2019 19:44:01 +0200, Mike Wey wrote:

On 14-05-2019 05:10, Alex X wrote:

Any news on this?

https://forum.dlang.org/thread/bznpylcjostbrrwzhmst@forum.dlang.org

It's severely cramping my style ;/

Unfortunately no.

Ok, So I figured you probably don't care enough to invest your time to fix it so I went ahead and looked in to it and was able to get it fixed:

That is indeed partly the case, although i did find an option for win XP
and older.

This seems like an interesting solution, overriding the memory that
holds the original SetWindowsHookExA. That does mean care should be
taken that the size of the replacement function is not to large.

As you can see, I'm simply using a single ret to break out of the call so when gtk calls it, nothing actually happens and the hook doesn't get set.

This works on my system because I inspected the assembly code. I won't work for x86 because the code is more complex and the stack needs to be free'ed. Since I'm not using x64 and only using this for debugging I'll go with the hack.

As I said, Detours is a C library that does this stuff correctly so if you want a solution that should work in general this would be the way to go. It actually correctly deals with redirection.

If you you can isolate the call to a local spot in code and disable it using this method then it would be optimal(and of course have it optional).

It does what I need it to do. If you don't do anything with it at least others have a chance of having a working solution.

I don't use XP... but what's the solution?