Еще раз об утечке атомов и баге VCL

Код хука тривиален

Если так все тривиально, то наверно следовало бы привести хоть ссылки на этот код, а то одни слова…

Замечательная бага. Правда «пофикшена» в XE5 по крайней мере точно:
RM_GetObjectInstance := RegisterWindowMessage(PChar('DelphiRM_GetObjectInstance'));
Удивительно, что по факту RM_GetObjectInstance вообще не нужен. Эта переменная лежит в имплементации юнита Control.pas и используется только в одном месте:

function ObjectFromHWnd(Handle: HWnd): TWinControl;
var
  OwningProcess: DWORD;
  ProcessId: DWORD;
begin
  ProcessId := GetCurrentProcessId;
  if (GetWindowThreadProcessId(Handle, OwningProcess) <> 0) and
     (OwningProcess = ProcessId) then
    Result := Pointer(SendMessage(Handle, RM_GetObjectInstance, ProcessId, 0))
  else
    Result := nil;
end;

ObjectFromHWnd так же только в implementation, и ниоткуда снаружи не вызывается. В самом Controls.pas он вызывается дважды:

function FindControl(Handle: HWnd): TWinControl;
var
  OwningProcess: DWORD;
begin
  Result := nil;
  if (Handle <> 0) and (GetWindowThreadProcessID(Handle, OwningProcess) <> 0) and
     (OwningProcess = GetCurrentProcessId) then
  begin
    if GlobalFindAtom(PChar(ControlAtomString)) = ControlAtom then
      Result := Pointer(GetProp(Handle, MakeIntAtom(ControlAtom)))
    else
      Result := ObjectFromHWnd(Handle);
  end;
end;

function IsDelphiHandle(Handle: HWND): Boolean;
var
  OwningProcess: DWORD;
begin
  Result := False;
  if (Handle <> 0) and (GetWindowThreadProcessID(Handle, OwningProcess) <> 0) and
     (OwningProcess = GetCurrentProcessId) then
  begin
{$IF DEFINED(CLR)}
    Result := FindControl(Handle) <> nil;
{$ELSE}
    if GlobalFindAtom(PChar(WindowAtomString)) = WindowAtom then
      Result := GetProp(Handle, MakeIntAtom(WindowAtom)) <> 0
    else
      Result := ObjectFromHWnd(Handle) <> nil;
{$ENDIF}
  end;
end;

В обоих случаях он вызывается после проверок:
GlobalFindAtom(PChar(ControlAtomString)) = ControlAtom
GlobalFindAtom(PChar(WindowAtomString)) = WindowAtom
И обе эти проверки всегда возвращают TRUE. Следовательно до вызова ObjectFromHWnd вообще никогда не доходит, а следовательно RM_GetObjectInstance вообще не нужен. Так что можете даже ничего не менять в хуке, а просто забивать болт если там есть 'ControlOfs'

Кстати в MSDN не сказано что винда не чистит атомы от RegisterWindowMessage. Я проверил на WIN7 со всеми обновлениями. Сожрал атомы и прибил процесс. Через некоторое время винда очистила хендлы, но очистила их далеко не сразу после регистрации. Так что возможно в WIN7 такая ситуация с утечкой от RegisterWindowMessage не возникает вообще. Если конечно не запускать 16К приложений делфи одновременно. :) А поскольку RM_GetObjectInstance не используется — то приложению от того что оно не смогло регнуть себе мессагу для RM_GetObjectInstance — должно быть не холодно не жарко. Должно бы быть, но это не так. Какого-то лешего разработчики Windows решили, что в принципе достаточно использовать один скоуп для RegisterClipboardFormat и RegisterWindowMessage. Соответственно если вдруг закончится эта таблица — ни одно приложение не сможет регнуть свой формат буфера обмена. Да и потом, неудача с RM_GetObjectInstance VCL не огорчит, а вот все остальные приложения в ОС будут вести себя нестабильно. Ситуацию спасает лишь то, что винда периодически (и неизвестно при каких обстоятельствах) чистит эти атомы.

Да, именно. Используется только в одном месте, поэтому можно использовать тупо константу.

Кстати в MSDN не сказано что винда не чистит атомы от RegisterWindowMessage

В MSDN сказано, как я цитировал в посте:

The message remains registered until the session ends.

Я проверил на WIN7 со всеми обновлениями. Сожрал атомы и прибил процесс. Через некоторое время винда очистила хендлы, но очистила их далеко не сразу после регистрации

Атомы вообще или именно RWMовские?
На WS2008 нет очистки, мы именно на 2008м увидели это впервые. И атомы накапливались там не один день.

Какого-то лешего разработчики Windows решили, что в принципе достаточно использовать один скоуп для RegisterClipboardFormat и RegisterWindowMessage

Это тянется, наверняка, чуть не с 1.0. В третьей версии атомы такие же, насколько я помню из обсуждения этой проблемы. Так что тогда они экономили ресурсы

Да и потом, неудача с RM_GetObjectInstance VCL не огорчит

Ну, как вам сказать — сообщение-то это VCL не нужно, но вот приложение не запустится. Вообще.

Ситуацию спасает лишь то, что винда периодически (и неизвестно при каких обстоятельствах) чистит эти атомы.

Я, к сожалению, не могу этого подтвердить. MSDN утверждает, что RWM атомы живут до конца сессии, и именно это я наблюдаю.