BUG: PackDDElParam for WM_DDE_ACK/WM_DDE_EXECUTE on Windows 95

• Microsoft Win32 Software Development Kit (SDK), version 4.0

SYMPTOMS

When a DDE server receives a WM_DDE_EXECUTE message, the server should call PackDDElParam with WM_DDE_ACK as the first parameter, a DDEACK structure as the second parameter, and the handle of the command string received in the third parameter. The return value from PackDDElParam is then posted as the lParam with the WM_DDE_ACK message. On Windows 95, the return value from PackDDElParam, in this case, does not contain the proper information. The WM_DDE_EXECUTE sequence will succeed but when the client that posted the WM_DDE_EXECUTE message receives the WM_DDE_ACK in response to the execute, it will not be able to retrieve the command handle using UnpackDDElParam. Because the handle cannot be retrieved, it cannot be freed.

CAUSE

On Windows 95, PackDDElParam does not function properly and will not identify the third parameter as a memory handle. It mistakenly identifies it as an ATOM. Because of this, the return value from PackDDElParam will contain the DDEACK structure in the low WORD and an ATOM in the high WORD. The result of this behavior is that the client that posted the WM_DDE_EXECUTE will not be able to free that handle when it receives the WM_DDE_ACK message.

RESOLUTION

If you are creating the client application, then you will need to store the command handle in static storage before posting the WM_DDE_EXECUTE message. When the client receives the WM_DDE_ACK message in response to the WM_DDE_EXECUTE, it will need to free the command handle stored in static storage rather than free the handle that is included with the WM_DDE_ACK message.

STATUS

Microsoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article. We are researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.