在hello world中，我始终找不到谁在调用它，没有任何痕迹。
// hello world.cpp : Defines the entry point for the application.
//
#include "stdafx.h"
#include "hello world.h"
#include <commctrl.h>
#define MAX_LOADSTRING 100
// Global Variables:
HINSTANCE hInst; // The current instance
HWND hwndCB; // The command bar handle
// Forward declarations of functions included in this code module:
ATOM MyRegisterClass (HINSTANCE, LPTSTR);
BOOL InitInstance (HINSTANCE, int);
LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM);
LRESULT CALLBACK About (HWND, UINT, WPARAM, LPARAM);
int WINAPI WinMain( HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
MSG msg;
HACCEL hAccelTable;
// Perform application initialization:
if (!InitInstance (hInstance, nCmdShow))
{
return FALSE;
}
hAccelTable = LoadAccelerators(hInstance, (LPCTSTR)IDC_HELLOWORLD);
// Main message loop:
while (GetMessage(&msg, NULL, 0, 0))
{
if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
return msg.wParam;
}
//
// FUNCTION: MyRegisterClass()
//
// PURPOSE: Registers the window class.
//
// COMMENTS:
//
// It is important to call this function so that the application
// will get 'well formed' small icons associated with it.
//
ATOM MyRegisterClass(HINSTANCE hInstance, LPTSTR szWindowClass)
{
WNDCLASS wc;
wc.style = CS_HREDRAW | CS_VREDRAW;
wc.lpfnWndProc = (WNDPROC) WndProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_HELLOWORLD));
wc.hCursor = 0;
wc.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH);
wc.lpszMenuName = 0;
wc.lpszClassName = szWindowClass;
return RegisterClass(&wc);
}
//
// FUNCTION: InitInstance(HANDLE, int)
//
// PURPOSE: Saves instance handle and creates main window
//
// COMMENTS:
//
// In this function, we save the instance handle in a global variable and
// create and display the main program window.
//
BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
{
HWND hWnd;
TCHAR szTitle[MAX_LOADSTRING]; // The title bar text
TCHAR szWindowClass[MAX_LOADSTRING]; // The window class name
hInst = hInstance; // Store instance handle in our global variable
// Initialize global strings
LoadString(hInstance, IDC_HELLOWORLD, szWindowClass, MAX_LOADSTRING);
MyRegisterClass(hInstance, szWindowClass);
LoadString(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);
hWnd = CreateWindow(szWindowClass, szTitle, WS_VISIBLE,
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL);
if (!hWnd)
{
return FALSE;
}
ShowWindow(hWnd, nCmdShow);
UpdateWindow(hWnd);
if (hwndCB)
CommandBar_Show(hwndCB, TRUE);
return TRUE;
}
//
// FUNCTION: WndProc(HWND, unsigned, WORD, LONG)
//
// PURPOSE: Processes messages for the main window.
//
// WM_COMMAND - process the application menu
// WM_PAINT - Paint the main window
// WM_DESTROY - post a quit message and return
//
//
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
HDC hdc;
int wmId, wmEvent;
PAINTSTRUCT ps;
TCHAR szHello[MAX_LOADSTRING];
switch (message)
{
case WM_COMMAND:
wmId = LOWORD(wParam);
wmEvent = HIWORD(wParam);
// Parse the menu selections:
switch (wmId)
{
case IDM_HELP_ABOUT:
DialogBox(hInst, (LPCTSTR)IDD_ABOUTBOX, hWnd, (DLGPROC)About);
break;
case IDM_FILE_EXIT:
DestroyWindow(hWnd);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
break;
case WM_CREATE:
hwndCB = CommandBar_Create(hInst, hWnd, 1);
CommandBar_InsertMenubar(hwndCB, hInst, IDM_MENU, 0);
CommandBar_AddAdornments(hwndCB, 0, 0);
break;
case WM_PAINT:
RECT rt;
hdc = BeginPaint(hWnd, &ps);
GetClientRect(hWnd, &rt);
LoadString(hInst, IDS_HELLO, szHello, MAX_LOADSTRING);
DrawText(hdc, szHello, _tcslen(szHello), &rt,
DT_SINGLELINE | DT_VCENTER | DT_CENTER);
EndPaint(hWnd, &ps);
break;
case WM_DESTROY:
CommandBar_Destroy(hwndCB);
PostQuitMessage(0);
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}
// Mesage handler for the About box.
LRESULT CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
RECT rt, rt1;
int DlgWidth, DlgHeight; // dialog width and height in pixel units
int NewPosX, NewPosY;
switch (message)
{
case WM_INITDIALOG:
// trying to center the About dialog
if (GetWindowRect(hDlg, &rt1)) {
GetClientRect(GetParent(hDlg), &rt);
DlgWidth = rt1.right - rt1.left;
DlgHeight = rt1.bottom - rt1.top ;
NewPosX = (rt.right - rt.left - DlgWidth)/2;
NewPosY = (rt.bottom - rt.top - DlgHeight)/2;
// if the About box is larger than the physical screen
if (NewPosX < 0) NewPosX = 0;
if (NewPosY < 0) NewPosY = 0;
SetWindowPos(hDlg, 0, NewPosX, NewPosY,
0, 0, SWP_NOZORDER | SWP_NOSIZE);
}
return TRUE;
case WM_COMMAND:
if ((LOWORD(wParam) == IDOK) || (LOWORD(wParam) == IDCANCEL))
{
EndDialog(hDlg, LOWORD(wParam));
return TRUE;
}
break;
}
return FALSE;
}
14 个解决方案
#1
回调函数是由操作系统进行调用，一般由两种方式，一种是对于非队列化消息，由操作系统直接调用WndProc，另一种是队列化消息，消息放入消息队列，当用GetMessage取得消息时由DispatchMessage(&msg); 化配对窗口，再由操作系统调用WndProc
#2
您得看看windows的消息机制。
#3
（转）
在Windows应用程序开发中，有很多地方使用了回调函数。一般的开发并不关心谁来调用这些函数，但如果开发复杂的多线程协作处理程序，或者研究操作系统中程序的“操作权限”问题，您就需要知道您写的这段代码是由谁来调用的，在哪个线程或进程中执行的。
最常见的就是Windows消息响应函数。一般的书本并不讨论这些函数是如何被调用的，只是说消息产生时，这些函数将会执行。初学者也许会以为，如果两个消息一起发出，那么它们的响应函数会同时执行。事实并不是这样。这些函数是串行执行的，也就是说只有执行完一个之后，另一个才有机会被调用。不仅如此，这些函数也不是由什么系统调用的，而是由一个确定的线程中统一管理，这个线程正是你的程序自己的主线程。
您可能自己并没有写这样的代码，但您使用的基础库中有。无论是MFC还是ATL，您都可以在它们的源代码中找到类似下面这样的内容：
MSG msg;
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
这个是消息循环，也称消息泵。它像个抽水机似的，把消息从一个地方抽出来，然后洒给各个消息响应函数处理。因此也可以说，消息响应函数是从线程的消息泵开始调用的。
还有一种作为参数传进去的回调函数。这些回调函数类似于Java中的那些接口，当调用某个函数时，把它当成参数传进去。在适当的时候，这些被函数会被调用。很多窗口枚举函数就是这样的，比如：EnumChildWindows、EnumDesktopWindows、EnumWindows等。这些函数其实并不是异步函数，在函数返回时，相应的功能已经完成，被传进去的回调函数也已经被调用过了。这种情况下，回调函数可看作是被相应的功能函数调用的。
钩子（HOOK）处理函数也是一种回调函数。我曾一度以为它是由操作系统的某个线程调用的，但事实并非如此。我在钩子函数里使用GetCurrentThreadId测试了一下，发现调用钩子函数的线程竟然是安装钩子的那个线程。那么这个调用是从哪发起的呢？原来还是消息泵！当调用GetMessage或PeekMessage函数时，并不只是把消息从队列中取出来这么简单，而是做了更复杂的工作。具体这些API是如何实现的我们不得而知，但有一个我进行了验证：不启动消息泵，钩子啥也钩不到。所以归根结底，钩子处理函数还是由线程的消息泵开始调用的。
Windows使用消息和回调函数来调度程序的执行，同一线程设置的回调函数，无论是消息响应还是钩子，最后仍在这一线程内执行，消息泵负责调度。
了解这一点，我们就可以在这些回调函数中放心地使用任何资源了，不用担心互斥、死锁。但是要担心另外一些问题：比如消息响应的嵌套冲突导致的数据变化、消息的循环发送等。一般这些问题都易于重现，所以还算容易发现和处理。
在Windows应用程序开发中，有很多地方使用了回调函数。一般的开发并不关心谁来调用这些函数，但如果开发复杂的多线程协作处理程序，或者研究操作系统中程序的“操作权限”问题，您就需要知道您写的这段代码是由谁来调用的，在哪个线程或进程中执行的。
最常见的就是Windows消息响应函数。一般的书本并不讨论这些函数是如何被调用的，只是说消息产生时，这些函数将会执行。初学者也许会以为，如果两个消息一起发出，那么它们的响应函数会同时执行。事实并不是这样。这些函数是串行执行的，也就是说只有执行完一个之后，另一个才有机会被调用。不仅如此，这些函数也不是由什么系统调用的，而是由一个确定的线程中统一管理，这个线程正是你的程序自己的主线程。
您可能自己并没有写这样的代码，但您使用的基础库中有。无论是MFC还是ATL，您都可以在它们的源代码中找到类似下面这样的内容：
MSG msg;
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
这个是消息循环，也称消息泵。它像个抽水机似的，把消息从一个地方抽出来，然后洒给各个消息响应函数处理。因此也可以说，消息响应函数是从线程的消息泵开始调用的。
还有一种作为参数传进去的回调函数。这些回调函数类似于Java中的那些接口，当调用某个函数时，把它当成参数传进去。在适当的时候，这些被函数会被调用。很多窗口枚举函数就是这样的，比如：EnumChildWindows、EnumDesktopWindows、EnumWindows等。这些函数其实并不是异步函数，在函数返回时，相应的功能已经完成，被传进去的回调函数也已经被调用过了。这种情况下，回调函数可看作是被相应的功能函数调用的。
钩子（HOOK）处理函数也是一种回调函数。我曾一度以为它是由操作系统的某个线程调用的，但事实并非如此。我在钩子函数里使用GetCurrentThreadId测试了一下，发现调用钩子函数的线程竟然是安装钩子的那个线程。那么这个调用是从哪发起的呢？原来还是消息泵！当调用GetMessage或PeekMessage函数时，并不只是把消息从队列中取出来这么简单，而是做了更复杂的工作。具体这些API是如何实现的我们不得而知，但有一个我进行了验证：不启动消息泵，钩子啥也钩不到。所以归根结底，钩子处理函数还是由线程的消息泵开始调用的。
Windows使用消息和回调函数来调度程序的执行，同一线程设置的回调函数，无论是消息响应还是钩子，最后仍在这一线程内执行，消息泵负责调度。
了解这一点，我们就可以在这些回调函数中放心地使用任何资源了，不用担心互斥、死锁。但是要担心另外一些问题：比如消息响应的嵌套冲突导致的数据变化、消息的循环发送等。一般这些问题都易于重现，所以还算容易发现和处理。
#5
窗口处理函数是由消息映射机制决定的。
#6
回调函数都是由操作系统调用的，他的实现需要我们自己写
#7
可以去研究一下回调函数
#8
当系统接受到发送给此窗口的消息或者再次窗口内发生的事件时,就会调用此窗口的窗口过程.
#9
你都说了有系统来调用的嘛,当然没痕迹了,除非你跟到系统里
#10
就是给系统调用的，具体实现可以自己写，也可以默认实现
#11
所谓的回调函数，就是一些已经封装好的库（如API）提供给程序员的扩展接口
回调函数都是注册到程序进程里的（程序自己注册的，如调用EnumWindow，或系统注册的，如SetWindowsHookEx）
无论同步还是异步调用 回调函数 的都是程序本身的某线程
系统只是负责调度和通知（系统并不执行 回调函数）
如 WndProc回调函数
RegisterClass后将WndProc注册到程序进程里，
DispatchMessage负责回调 WndProc，
所以谁（某线程）执行DispatchMessage，就相当于谁来执行WndProc
最好自己去搞清楚，别被误导
回调函数都是注册到程序进程里的（程序自己注册的，如调用EnumWindow，或系统注册的，如SetWindowsHookEx）
无论同步还是异步调用 回调函数 的都是程序本身的某线程
系统只是负责调度和通知（系统并不执行 回调函数）
如 WndProc回调函数
RegisterClass后将WndProc注册到程序进程里，
DispatchMessage负责回调 WndProc，
所以谁（某线程）执行DispatchMessage，就相当于谁来执行WndProc
最好自己去搞清楚，别被误导
#12
用LRESULT CallWindowProc(
WNDPROC lpPrevWndFunc,
HWND hWnd,
UINT Msg,
WPARAM wParam,
LPARAM lParam
);
也可以自己调啊
WNDPROC lpPrevWndFunc,
HWND hWnd,
UINT Msg,
WPARAM wParam,
LPARAM lParam
);
也可以自己调啊
#13
如果回调函数是由系统调用的，
那是不是很容易就进入到系统内核？
或者直接调用系统底层的东东？
这不太可能吧.....
那是不是很容易就进入到系统内核？
或者直接调用系统底层的东东？
这不太可能吧.....
#14
还是不懂……
#1
回调函数是由操作系统进行调用，一般由两种方式，一种是对于非队列化消息，由操作系统直接调用WndProc，另一种是队列化消息，消息放入消息队列，当用GetMessage取得消息时由DispatchMessage(&msg); 化配对窗口，再由操作系统调用WndProc
#2
您得看看windows的消息机制。
#3
（转）
在Windows应用程序开发中，有很多地方使用了回调函数。一般的开发并不关心谁来调用这些函数，但如果开发复杂的多线程协作处理程序，或者研究操作系统中程序的“操作权限”问题，您就需要知道您写的这段代码是由谁来调用的，在哪个线程或进程中执行的。
最常见的就是Windows消息响应函数。一般的书本并不讨论这些函数是如何被调用的，只是说消息产生时，这些函数将会执行。初学者也许会以为，如果两个消息一起发出，那么它们的响应函数会同时执行。事实并不是这样。这些函数是串行执行的，也就是说只有执行完一个之后，另一个才有机会被调用。不仅如此，这些函数也不是由什么系统调用的，而是由一个确定的线程中统一管理，这个线程正是你的程序自己的主线程。
您可能自己并没有写这样的代码，但您使用的基础库中有。无论是MFC还是ATL，您都可以在它们的源代码中找到类似下面这样的内容：
MSG msg;
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
这个是消息循环，也称消息泵。它像个抽水机似的，把消息从一个地方抽出来，然后洒给各个消息响应函数处理。因此也可以说，消息响应函数是从线程的消息泵开始调用的。
还有一种作为参数传进去的回调函数。这些回调函数类似于Java中的那些接口，当调用某个函数时，把它当成参数传进去。在适当的时候，这些被函数会被调用。很多窗口枚举函数就是这样的，比如：EnumChildWindows、EnumDesktopWindows、EnumWindows等。这些函数其实并不是异步函数，在函数返回时，相应的功能已经完成，被传进去的回调函数也已经被调用过了。这种情况下，回调函数可看作是被相应的功能函数调用的。
钩子（HOOK）处理函数也是一种回调函数。我曾一度以为它是由操作系统的某个线程调用的，但事实并非如此。我在钩子函数里使用GetCurrentThreadId测试了一下，发现调用钩子函数的线程竟然是安装钩子的那个线程。那么这个调用是从哪发起的呢？原来还是消息泵！当调用GetMessage或PeekMessage函数时，并不只是把消息从队列中取出来这么简单，而是做了更复杂的工作。具体这些API是如何实现的我们不得而知，但有一个我进行了验证：不启动消息泵，钩子啥也钩不到。所以归根结底，钩子处理函数还是由线程的消息泵开始调用的。
Windows使用消息和回调函数来调度程序的执行，同一线程设置的回调函数，无论是消息响应还是钩子，最后仍在这一线程内执行，消息泵负责调度。
了解这一点，我们就可以在这些回调函数中放心地使用任何资源了，不用担心互斥、死锁。但是要担心另外一些问题：比如消息响应的嵌套冲突导致的数据变化、消息的循环发送等。一般这些问题都易于重现，所以还算容易发现和处理。
在Windows应用程序开发中，有很多地方使用了回调函数。一般的开发并不关心谁来调用这些函数，但如果开发复杂的多线程协作处理程序，或者研究操作系统中程序的“操作权限”问题，您就需要知道您写的这段代码是由谁来调用的，在哪个线程或进程中执行的。
最常见的就是Windows消息响应函数。一般的书本并不讨论这些函数是如何被调用的，只是说消息产生时，这些函数将会执行。初学者也许会以为，如果两个消息一起发出，那么它们的响应函数会同时执行。事实并不是这样。这些函数是串行执行的，也就是说只有执行完一个之后，另一个才有机会被调用。不仅如此，这些函数也不是由什么系统调用的，而是由一个确定的线程中统一管理，这个线程正是你的程序自己的主线程。
您可能自己并没有写这样的代码，但您使用的基础库中有。无论是MFC还是ATL，您都可以在它们的源代码中找到类似下面这样的内容：
MSG msg;
while(GetMessage(&msg, NULL, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
这个是消息循环，也称消息泵。它像个抽水机似的，把消息从一个地方抽出来，然后洒给各个消息响应函数处理。因此也可以说，消息响应函数是从线程的消息泵开始调用的。
还有一种作为参数传进去的回调函数。这些回调函数类似于Java中的那些接口，当调用某个函数时，把它当成参数传进去。在适当的时候，这些被函数会被调用。很多窗口枚举函数就是这样的，比如：EnumChildWindows、EnumDesktopWindows、EnumWindows等。这些函数其实并不是异步函数，在函数返回时，相应的功能已经完成，被传进去的回调函数也已经被调用过了。这种情况下，回调函数可看作是被相应的功能函数调用的。
钩子（HOOK）处理函数也是一种回调函数。我曾一度以为它是由操作系统的某个线程调用的，但事实并非如此。我在钩子函数里使用GetCurrentThreadId测试了一下，发现调用钩子函数的线程竟然是安装钩子的那个线程。那么这个调用是从哪发起的呢？原来还是消息泵！当调用GetMessage或PeekMessage函数时，并不只是把消息从队列中取出来这么简单，而是做了更复杂的工作。具体这些API是如何实现的我们不得而知，但有一个我进行了验证：不启动消息泵，钩子啥也钩不到。所以归根结底，钩子处理函数还是由线程的消息泵开始调用的。
Windows使用消息和回调函数来调度程序的执行，同一线程设置的回调函数，无论是消息响应还是钩子，最后仍在这一线程内执行，消息泵负责调度。
了解这一点，我们就可以在这些回调函数中放心地使用任何资源了，不用担心互斥、死锁。但是要担心另外一些问题：比如消息响应的嵌套冲突导致的数据变化、消息的循环发送等。一般这些问题都易于重现，所以还算容易发现和处理。
#4
#5
窗口处理函数是由消息映射机制决定的。
#6
回调函数都是由操作系统调用的，他的实现需要我们自己写
#7
可以去研究一下回调函数
#8
当系统接受到发送给此窗口的消息或者再次窗口内发生的事件时,就会调用此窗口的窗口过程.
#9
你都说了有系统来调用的嘛,当然没痕迹了,除非你跟到系统里
#10
就是给系统调用的，具体实现可以自己写，也可以默认实现
#11
所谓的回调函数，就是一些已经封装好的库（如API）提供给程序员的扩展接口
回调函数都是注册到程序进程里的（程序自己注册的，如调用EnumWindow，或系统注册的，如SetWindowsHookEx）
无论同步还是异步调用 回调函数 的都是程序本身的某线程
系统只是负责调度和通知（系统并不执行 回调函数）
如 WndProc回调函数
RegisterClass后将WndProc注册到程序进程里，
DispatchMessage负责回调 WndProc，
所以谁（某线程）执行DispatchMessage，就相当于谁来执行WndProc
最好自己去搞清楚，别被误导
回调函数都是注册到程序进程里的（程序自己注册的，如调用EnumWindow，或系统注册的，如SetWindowsHookEx）
无论同步还是异步调用 回调函数 的都是程序本身的某线程
系统只是负责调度和通知（系统并不执行 回调函数）
如 WndProc回调函数
RegisterClass后将WndProc注册到程序进程里，
DispatchMessage负责回调 WndProc，
所以谁（某线程）执行DispatchMessage，就相当于谁来执行WndProc
最好自己去搞清楚，别被误导
#12
用LRESULT CallWindowProc(
WNDPROC lpPrevWndFunc,
HWND hWnd,
UINT Msg,
WPARAM wParam,
LPARAM lParam
);
也可以自己调啊
WNDPROC lpPrevWndFunc,
HWND hWnd,
UINT Msg,
WPARAM wParam,
LPARAM lParam
);
也可以自己调啊
#13
如果回调函数是由系统调用的，
那是不是很容易就进入到系统内核？
或者直接调用系统底层的东东？
这不太可能吧.....
那是不是很容易就进入到系统内核？
或者直接调用系统底层的东东？
这不太可能吧.....
#14
还是不懂……