如何在不使用 CreateWindow(Ex) 的情况下创建窗口 (HWND)？
我正在使用代理 DLL 拦截对 的调用CreateWindowExA/CreateWindowExW。除了某些应用程序（尤其是一些 Visual Basic 6 应用程序）似乎能够创建窗口而无需通过这两个函数中的任何一个之外，此方法运行得很好。 Spy++ 等工具能够显示窗口，但我的挂钩函数没有注意到它们。
我的第一个怀疑是这些（旧）应用程序可能使用 CreateWindowA/CreateWindowW 用于创建窗口，但至少对于我的编译器（MSVC6 到 MSVC10）来说，CreateWindow 只是一个#define；文档的备注部分证实了这一点。
我的第二个想法是我可以安装 <使用 SetWindowsHookEx 检测窗口的创建。然而，结果是相同的：这个挂钩注意到与我挂钩的 API 函数相同的窗口，但它没有注意到 Spy++ 中可见的所有窗口。
所以我的问题是：是否可能有一段时间 CreateWindowA/CreateWindowW 不是一个#define，而是一个真正的函数？也许出于兼容性原因，此函数是否仍然由 user32.dll 导出？我怎样才能获得这个函数的句柄来挂钩它？
或者是否有其他一些可能未记录的函数可用于创建函数，例如 NtCreateProcess 可以用来代替 CreateProcess？
I'm using a proxy DLL to intercept calls to CreateWindowExA/CreateWindowExW. This works quit nicely, except that some applications (most notably some Visual Basic 6 applications) seem to be able to create windows without going through either of the two functions. Tools like Spy++ are able to show the Window, but my hooked functions didn't notice them.
My first suspicion was that maybe these (old) applications use CreateWindowA/CreateWindowW for creating windows, but at least with my compilers (MSVC6 up to MSVC10), CreateWindow is just a #define; the remarks section of the documentation confirms this.
My second idea was that I could maybe install a CBT hook using SetWindowsHookEx to detect creations of windows. However, the result is the same: this hook notices the same windows as my hooked API functions, but it doesn't notice all the windows which are visible in Spy++.
So my question is: was there maybe a time when CreateWindowA/CreateWindowW was not a #define, but a real function? Is this function still exported by user32.dll, maybe for compatibility reasons? How can I get a handle on this function to hook it?
Or is there maybe some other, possibly undocumented, function which can be used to create functions, much like e.g. NtCreateProcess can be used instead of CreateProcess?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
三个简单的猜测：
1) VB 应用程序是否可能真的在幕后调用“DialogBox”API（例如DialogBoxParam、CreateDialogIndirect 等...）？
2) 您正在运行 64 位操作系统并正在挂接 64 位 user32.dll。因此，32 位应用程序不会上瘾。 c:\windows\syswow64 中有 user32.dll 的 32 位副本
3) 您没有挂钩应用程序正在使用的 user32.dll。许多较旧的应用程序可能会进行一些 DLL 重定向。在命令提示符下，从 c:\windows\winsxs 目录执行“dir /s user32.dll”。您将在此处看到至少一份 user32.dll 的其他副本。忘记什么时候发生这种情况，但您可以 Bing 搜索“winsxs”并获得一些页面讨论并排目录如何解决较新的 Windows 操作系统版本上的兼容性问题。
我怀疑#3 是您问题的原因。
Three simple guesses:
1) Is it possible that VB apps are really calling a "DialogBox" API (e.g. DialogBoxParam, CreateDialogIndirect, etc...) underneath the hood?
2) You are running a 64-bit OS and are hooking the 64-bit user32.dll. 32-bit apps aren't getting hooked as a result. There's a 32-bit copy of user32.dll in c:\windows\syswow64
3) You aren't hooking the user32.dll that the apps are using. Many older apps may be getting some DLL redirection. From a command prompt, do "dir /s user32.dll" from the c:\windows\winsxs directory. You'll see at least one other copy of user32.dll here. Forget when this happens, but you can Bing for "winsxs" and get some pages discussion how the side by side directory solves compat issues on newer windows OS releases.
I suspect #3 is the reason for your issue.
我认为你的问题可能是 VB 应用程序正在使用 GetProcAddress() 调用 CreateWindow**() 函数。如果你挂接 GetProcAddress 你应该能够确认这一点。
I think your issue might be that the VB app is using GetProcAddress() to call the CreateWindow**() function. If you hook GetProcAddress you should be able to confirm this.