Здравствуйте, Рек, Вы писали:

Рек>Правильно ли я понял,
Рек>что SM-сообщения обрабатываются внутри GetMessage (прямым колом)
Рек>и никогда не попадают в DispatchMessagе?
Рек>В том числе и тогда когда сообщение пришло из другого потока.
Рек>Так?

Извини — наверное где то неправильно выразился
GetMessage — забирает следующее сообщение из очереди. И ничего более... Оно не вызывает оконную процедуру.

вот DispatchMessagе — уже вызывает оконную процедуру, исходя из параметров полученых из GetMessage, по пути обработав таймер.

SendMessage напрямую вызывает оконную процу (с синхронизацией, естественно).

Т.е., грубо говоря, содержимое DispatchMessagе можно представить как:

LRESULT 
DispatchMessage
  ( CONST MSG *lpmsg )
{
// ***********************
//  Обработка каллбека таймера, если обрабатываем сообщение WM_TIMER, если такой имееться
// ***********************
//  Возможно что то еще: проверки на валидность оконного хендла, етс.
// ***********************

  return SendMessage
    ( lpmsg->hwnd,
    , lpmsg->message
    , lpmsg->wParam
    , lpmsg->lParam );
}

Грубая реализация SendMessage:

LRESULT SendMessage
  ( HWND hWnd
  , UINT Msg
  , WPARAM wParam
  , LPARAM lParam)
{
// ***********************
//  Что то тут есть: проверка на валидность оконного хендла, синхранизация многопоточности етс.
// ***********************

  return CallWindowProc
    ( (WNDPROC) GetWindowLong (lpmsg->hwnd, GWL_WNDPROC)
    , lpmsg->message
    , lpmsg->wParam
    , lpmsg->lParam );
}

Я не знаю досконально внутренний механизм этих функций, но судя по всему, оно где то рядом...
Теоретически можно поробовать реализовать стандартный оконный луп через CallWindowProc или
SendMessage — и посмотреть что получиться...

з.ы. кстати — сейчас попробую, и напишу