🚀 go-pugleaf

In a previous article, bu254@cleveland.Freenet.Edu (Stephen Groundwater) says:
[Stuff deleted]
>This is the result of my dumping the hDrop memory that
>comes on the WM_DROPFILES message, and my understanding of it.
> 
>The hDrop memory is a global memory object.
>The drag-drop memory object consists of two parts, a header, and
>a trailing bit.
>The header is 8 bytes long in windows 3.1.
>The trailer is however long it needs to be.
> 
>The header:
> 
>typedef struct tagDragHeader {
>	UNIT wStructSize; /* Size of struct (8 bytes in this ver) */
>	UINT x; /* x co-ord on window that is dropped on. (Client DC) */
>	UINT y; /* y co-ord on window that is dropped on. (Client DC) */
>	WORD wReserved; /* no known purpose, should be 0 */
>	} DragHeader;
> 
>This is what I think the header structure is, the first three
>fields I am more or less sure of, the fourth field is a mystery
>to me, but in every drop I've seen it's been 0.
> 

Correction:
I have now found out what the fourth field is, thanks to hints from
blakeco@Microsoft.COM. The structure should be:

typedef struct tagDRAGHEADER {
  UINT wStructSize; // Same as before
  UINT x; // Same as before
  UINT y; // Same as before
  BOOL fInClient; // True if drop is on client area,
                  // false if anywhere else (title bar etc)
  } DRAGHEADER;

>The trailer:
> 
>The trailer is a series of null-terminated strings that contain
>the strings that DragQueryFile() will return. The number of the
>strings is not in any structure, so you don't need to worry about
>that.
>
[Stuff Deleted] 
>You should GlobalAlloc a block big enough for the header, and following
>file names, and use the flag GMEM_DDESHARE when allocating.
>
>