Comments on: Getting the shell to run an application for you – Part 1: Why http://brandonlive.com/2008/04/26/getting-the-shell-to-run-an-application-for-you-part-1-why/ Seattle Geek with lots to say. Thu, 03 May 2012 09:25:06 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Fashion shows. http://brandonlive.com/2008/04/26/getting-the-shell-to-run-an-application-for-you-part-1-why/comment-page-1/#comment-131452 Fashion shows. Mon, 12 Jul 2010 21:54:03 +0000 http://brandonlive.com/2008/04/26/getting-the-shell-to-run-an-application-for-you-part-1-why/#comment-131452 <strong>Renaissance fashion....</strong> Plus size fashion. Elizabethan fashion. Fashion design colleges. Fashion trends. Fashion of the 80s. Fashion design. 1950s fashion jeans. Fashion.... Renaissance fashion….

Plus size fashion. Elizabethan fashion. Fashion design colleges. Fashion trends. Fashion of the 80s. Fashion design. 1950s fashion jeans. Fashion….

]]> By: Brandon http://brandonlive.com/2008/04/26/getting-the-shell-to-run-an-application-for-you-part-1-why/comment-page-1/#comment-110831 Brandon Sun, 27 Apr 2008 23:25:02 +0000 http://brandonlive.com/2008/04/26/getting-the-shell-to-run-an-application-for-you-part-1-why/#comment-110831 Hi Andrei - There is no way to know what other window threads will pump messages while you have the hook installed. The fact is that the hook will almost always be loaded into other processes. Since you know which window you're targetting, you should always restrict the hook to the thread that owns that window. There is no reason *not* to as a call to GetWindowThreadProcessId is cheap and easy as cake. Passing NULL for the fourth parameter to SetWindowsHookEx is meant for the rare case when you actually want to hook every window's message loop. Hi Andrei -

There is no way to know what other window threads will pump messages while you have the hook installed. The fact is that the hook will almost always be loaded into other processes.

Since you know which window you’re targetting, you should always restrict the hook to the thread that owns that window. There is no reason *not* to as a call to GetWindowThreadProcessId is cheap and easy as cake. Passing NULL for the fourth parameter to SetWindowsHookEx is meant for the rare case when you actually want to hook every window’s message loop.

]]> By: Andrei Belogortseff http://brandonlive.com/2008/04/26/getting-the-shell-to-run-an-application-for-you-part-1-why/comment-page-1/#comment-110828 Andrei Belogortseff Sun, 27 Apr 2008 23:08:12 +0000 http://brandonlive.com/2008/04/26/getting-the-shell-to-run-an-application-for-you-part-1-why/#comment-110828 Your claim that "...this hook code is immediately going to be loaded by every process on the desktop with a window" is incorrect. The hook code gets loaded into a process only when the conditions for the hook to execute for that process occur, not immediately. Since the CodeProject article you mentioned installs the hook for a very short time (just enough to send a message to the shell), and then removes the hook, it means that the hook code will not be loaded into every process or thread, it will only be loaded into the shell process, as it was intended to. Your claim that “…this hook code is immediately going to be loaded by every process on the desktop with a window” is incorrect. The hook code gets loaded into a process only when the conditions for the hook to execute for that process occur, not immediately. Since the CodeProject article you mentioned installs the hook for a very short time (just enough to send a message to the shell), and then removes the hook, it means that the hook code will not be loaded into every process or thread, it will only be loaded into the shell process, as it was intended to.

]]>