[This article also serves as announcement of DSiWin32 1.26.]

[Update: Reported as QC #47559. Vote for it!]

You're probably asking yourself - what's that AllocateHwnd anyway?

And why must it be thread-safe?

As the Google is guick to tell (BTW, Steve, thanks for the search filter!),

AllocateHwnd is used to create a hidden window which you can use to receive messages in non-windowed components.

Of course, you can use it outside of any component to set up simple and easy messaging subsystem anywhere in your application.

If you need more communication channels, just call AllocateHwnd many times.

I won't bother you with the usage pattern - if you want to use AllocateHwnd and don't know how, use the search link above.

You'll find many examples, including this one from DelphiDabbler, which Steve's searcher lists on the first place.

An example of a very popular component using AllocateHwnd internally is Delphi's TTimer.

That should answer the first question, but what about thread-safety?

Well, many programmers use AllocateHwnd in threaded code to create hidden windows where messages are processed.

Many are also using TTimer inside threads without knowing the first thing about AllocateHwnd.

But almost nobody knows that this is totally unsafe and may lead to rare and obscure crashes.

AllocateHwnd was written with single-threaded VCL applications in mind and you can use it from a thread only if you take special precaution.

Why is AllocateHwnd dangerous

Let's see how the AllocateHwnd is implemented. Following code was copied from D2007's Classes.pas

(in very old Delphis, AllocateHwnd was implemented in Forms.pas):

var

  UtilWindowClass: TWndClass = (

    style: ;

    lpfnWndProc: @DefWindowProc;

    cbClsExtra: ;

    cbWndExtra: ;

    hInstance: ;

    hIcon: ;

    hCursor: ;

    hbrBackground: ;

    lpszMenuName: nil;

    lpszClassName: 'TPUtilWindow');

function AllocateHWnd(Method: TWndMethod): HWND;

var

  TempClass: TWndClass;

  ClassRegistered: Boolean;

begin

  UtilWindowClass.hInstance := HInstance;

{$IFDEF PIC}

  UtilWindowClass.lpfnWndProc := @DefWindowProc;

{$ENDIF}

  ClassRegistered := GetClassInfo(HInstance, UtilWindowClass.lpszClassName,

    TempClass);

  if not ClassRegistered or (TempClass.lpfnWndProc <> @DefWindowProc) then

  begin

    if ClassRegistered then

      Windows.UnregisterClass(UtilWindowClass.lpszClassName, HInstance);

    Windows.RegisterClass(UtilWindowClass);

  end;

  Result := CreateWindowEx(WS_EX_TOOLWINDOW, UtilWindowClass.lpszClassName,

    '', WS_POPUP {+ 0}, , , , , , , HInstance, nil);

  if Assigned(Method) then

    SetWindowLong(Result, GWL_WNDPROC, Longint(MakeObjectInstance(Method)));

end;

Basically, the code registers window class if necessary, creates a new window of that class,

and sets window procedur for that window to MakeObjectInstance(Method).

Nothing special, except this last step. Can you tell why it is necessary at all?

The reason lies in the discrepancy between Delphi's object model and Win32 API, which is not object oriented.

The TWndMethod parameter passed to the AllocateHwnd is not just an address of code,

but contains also the address of the object this method belongs to.

On the other hand, Win32 API wants to call a simple method anytime it has to deliver a message to a window.

MakeObjectInstance bridges this gap.

It manages a linked list of methods together with a dynamically generated code preamble

(address of which is returned from the MakeObjectInstance function).

When Windows calls this code preamble, it makes sure that correct method is called on the correct object.

MakeObjectInstance is complicated, but it works.

That is, until you call it from two threads at the same time.

You see, MakeObjectInstance does nothing to lock its internal list while it is being manipulated.

If you do this from two threads running on two CPUs, or even if you have only one CPU and context switch occurs at a bad time,

internal instance list can get corrupted.

Later, this may lead to crashes, bad program behaviour, you name it. And you'll never find the true culprit.

Admittedly, there is only a small window - few instructions - which are problematic.

In most applications such problems will never occur.

But if you're running 24/7 server which calls AllocateHwnd/DeallocateHwnd constantly from multiple threads,

you can be sure that sooner or later it will crash.

Solution

There are two possible solutions to the problem

- one is to wrap all AllocateHwnd and DeallocateHwnd in some sort of critical section,

spinlock or mutex that will allow only one instance to be called at the same time

and other is to write a better and thread-safe AllocateHwnd.

First solution is somewhat clumsy to implement in production code while the second can be hard to write.

Actually, I search the net wide and deep and found only two alternative AllocateHwnd implementations (references below).

I'm sure there are more. I just couldn't find them.

None of them was really suitable for my needs so I created a third one using ideas from both of them.

My version — DSiAllocateHwnd, DSiDeallocateHwnd and TDSiTimer — has been published as a part of the DSiWin32 library.

This is the current version of my AllocateHwnd alternative:

const

  GWL_METHODCODE = SizeOf(pointer) * ;

  GWL_METHODDATA = SizeOf(pointer) * ;

  CDSiHiddenWindowName = 'DSiUtilWindow';

var

  GDSiWndHandlerCritSect: TRTLCriticalSection;

  GDSiWndHandlerCount: integer;

  function DSiClassWndProc(Window: HWND; Message, WParam, LParam: longint): longint; stdcall;

  var

    instanceWndProc: TMethod;

    msg            : TMessage;

  begin

    instanceWndProc.Code := Pointer(GetWindowLong(Window, GWL_METHODCODE));

    instanceWndProc.Data := Pointer(GetWindowLong(Window, GWL_METHODDATA));

    if Assigned(TWndMethod(instanceWndProc)) then

    begin

      msg.msg := Message;

      msg.wParam := WParam;

      msg.lParam := LParam;

      TWndMethod(instanceWndProc)(msg);

      Result := msg.Result

    end

    else

      Result := DefWindowProc(Window, Message, WParam,LParam);

  end; { DSiClassWndProc }

  function DSiAllocateHWnd(wndProcMethod: TWndMethod): HWND;

  var

    alreadyRegistered: boolean;

    tempClass        : TWndClass;

    utilWindowClass  : TWndClass;

  begin

    Result := ;

    FillChar(utilWindowClass, SizeOf(utilWindowClass), );

    EnterCriticalSection(GDSiWndHandlerCritSect);

    try

      alreadyRegistered := GetClassInfo(HInstance, CDSiHiddenWindowName, tempClass);

      if (not alreadyRegistered) or (tempClass.lpfnWndProc <> @DSiClassWndProc) then begin

        if alreadyRegistered then

          Windows.UnregisterClass(CDSiHiddenWindowName, HInstance);

        utilWindowClass.lpszClassName := CDSiHiddenWindowName;

        utilWindowClass.hInstance := HInstance;

        utilWindowClass.lpfnWndProc := @DSiClassWndProc;

        utilWindowClass.cbWndExtra := SizeOf(TMethod);

        if Windows.RegisterClass(utilWindowClass) =  then

          raise Exception.CreateFmt('Unable to register DSiWin32 hidden window class. %s',

            [SysErrorMessage(GetLastError)]);

      end;

      Result := CreateWindowEx(WS_EX_TOOLWINDOW, CDSiHiddenWindowName, '', WS_POPUP,

        , , , , , , HInstance, nil);

      if Result =  then

        raise Exception.CreateFmt('Unable to create DSiWin32 hidden window. %s',

                [SysErrorMessage(GetLastError)]);

      SetWindowLong(Result, GWL_METHODDATA, Longint(TMethod(wndProcMethod).Data));

      SetWindowLong(Result, GWL_METHODCODE, Longint(TMethod(wndProcMethod).Code));

      Inc(GDSiWndHandlerCount);

    finally LeaveCriticalSection(GDSiWndHandlerCritSect); end;

  end; { DSiAllocateHWnd }

  procedure DSiDeallocateHWnd(wnd: HWND);

  begin

    DestroyWindow(wnd);

    EnterCriticalSection(GDSiWndHandlerCritSect);

    try

      Dec(GDSiWndHandlerCount);

      if GDSiWndHandlerCount <=  then

        Windows.UnregisterClass(CDSiHiddenWindowName, HInstance);

    finally LeaveCriticalSection(GDSiWndHandlerCritSect); end;

  end; { DSiDeallocateHWnd }

There are many differences between this code and Delphi version.

• My code uses custom DefWindowProc method - DSiClassWndProc.
• It reserves four extra bytes in each window of the DSiUtilWindow class (utilWindowClass.cbWndExtra setting).
• It writes both parts of TMethod (code and data) directly into those four bytes of the hidden window's user data.
• DSiClassWndProc retrieves those four bytes, reconstructs TMethod and calls it directly.
• When all hidden windows are closed, window class gets unregistered (in DSiDeallocateHwnd).

I admit that this approach to message dispatching is slower than the Delphi's version,

but usually that is not a problem - custom windows are usually created to process some small subset of messages only.

Acknowledgments

The AllocateHwnd problem is not something I have found by myself.

It has been documented for years, but is not well known.

I'd like to thank to:

• Arno Garrels on the ICS mailing list, who described the problem to me.
• Francois Piette for providing ICS source code with custom AllocateHwnd solution. My approach is partially based on the Francois' code.
• Alexander Grischenko, who wrote this solution from which I stole the idea of storing TMethod directly in window's extra data.