Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 280
  • Last Modified:

Find Window's Owning App -- Win32 API

I need to connect windows with their "owning" application (i.e. for all high level windows, find which application opened them). I have tried GetModuleFileName(), but under Windows 95 it only works for the process my app is current running under, which seems pretty useless. (Apparently it works fine under Win 3.1, but that is not the environment I care about.) I need to connect other application's to their windows, not my own.
0
parkerea
Asked:
parkerea
  • 5
  • 2
1 Solution
 
alexoCommented:
GetWindowThreadProcessId()
0
 
alexoCommented:
If that doesn't help, have you tried passing GetWindowLong(GWL_HINSTANCE) to GetModuleFileName()?
0
 
alexoCommented:
Also see KB article Q119163

0
What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

 
parkereaAuthor Commented:
Yes, I have tried the proper combination of GetWindowLong() and GetModuleFileName(), but as I mentioned, under Win 95 it only works for the current app, not other apps. (Win NT has the same limitation because both are Win32.) Apparently this is because other apps (i.e. other processes) run in a different address space under Win32.

Per Alexo's note, I checked knowledge base article Q119163, but it appears this approach only works for Windows NT, because it looks through the registry for what appears to be an NT specific key, "HKEY_PERFORMANCE_DATA", if I am reading it properly. The article says it applies to NT 3.1 & 3.5; it does not mention Win 95. I need a solution for any Win32 environment.

0
 
alexoCommented:
You need to use the tool help library (Win95) or PSAPI (NT) to get the filename of a process.

For Win95: check the CreateToolhelp32Snapshot() and Process32First() / Process32Next(), Module32First() / Module32Next() functions.

The process ID is available via GetWindowThreadProcessId().

0
 
parkereaAuthor Commented:
Thanks, that should do it, but I do still have a problem: where the heck do I get ToolHelp32.dll? My Win 95 PC has the 16 bit version, ToolHelp.dll, but that is it. According to the documentation I have, the ToolHelp32 functions are actually in Kernel32.dll, but they are not exported. Do I need to get the Win 95 SDK or something?
0
 
alexoCommented:
The tool help functions reside in the operating system kernel. The following example provides a platform-independent approach to accessing the tool help functions.

#include <tlhelp32.h> // needed for tool help declarations  
 
// Type definitions for pointers to call tool help functions.
typedef BOOL (WINAPI *MODULEWALK)(HANDLE hSnapshot,
    LPMODULEENTRY32 lpme);
typedef BOOL (WINAPI *THREADWALK)(HANDLE hSnapshot,
    LPTHREADENTRY32 lpte);
typedef BOOL (WINAPI *PROCESSWALK)(HANDLE hSnapshot,
    LPPROCESSENTRY32 lppe);
typedef HANDLE (WINAPI *CREATESNAPSHOT)(DWORD dwFlags,
    DWORD th32ProcessID);
 
// File scope globals. These pointers are declared because of the need
// to dynamically link to the functions.  They are exported only by
// the Windows 95 kernel. Explicitly linking to them will make this
// application unloadable in Microsoft(R) Windows NT(TM) and will
// produce an ugly system dialog box.
static CREATESNAPSHOT pCreateToolhelp32Snapshot = NULL;
static MODULEWALK  pModule32First  = NULL;
static MODULEWALK  pModule32Next   = NULL;
static PROCESSWALK pProcess32First = NULL;
static PROCESSWALK pProcess32Next  = NULL;
static THREADWALK  pThread32First  = NULL;
static THREADWALK  pThread32Next   = NULL;
 
// Function that initializes tool help functions.
BOOL InitToolhelp32 (void)
{
    BOOL   bRet  = FALSE;
    HANDLE hKernel = NULL;
 
    // Obtain the module handle of the kernel to retrieve addresses of
    // the tool helper functions.
    hKernel = GetModuleHandle("KERNEL32.DLL");
 
    if (hKernel){
        pCreateToolhelp32Snapshot =
            (CREATESNAPSHOT)GetProcAddress(hKernel,
            "CreateToolhelp32Snapshot");
 
        pModule32First  = (MODULEWALK)GetProcAddress(hKernel,
            "Module32First");
        pModule32Next   = (MODULEWALK)GetProcAddress(hKernel,
            "Module32Next");
 
        pProcess32First = (PROCESSWALK)GetProcAddress(hKernel,
            "Process32First");
        pProcess32Next  = (PROCESSWALK)GetProcAddress(hKernel,
            "Process32Next");
 
        pThread32First  = (THREADWALK)GetProcAddress(hKernel,
            "Thread32First");
        pThread32Next   = (THREADWALK)GetProcAddress(hKernel,
            "Thread32Next");
 
        // All addresses must be non-NULL to be successful.
        // If one of these addresses is NULL, one of
        // the needed lists cannot be walked.
        bRet =  pModule32First && pModule32Next  && pProcess32First && 
                pProcess32Next && pThread32First && pThread32Next && 
                pCreateToolhelp32Snapshot;
    }
    else
        bRet = FALSE; // could not even get the module handle of kernel
 
    return bRet;
}
 

0

Featured Post

Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now