There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
[SHLWAPI] Refactor the SHCreateWorkerWindowW() prototype to match its ANSI SHCreateWorkerWindowA() counterpart.
The last parameter is really to be understood as an extra window data, and not a "message result" (as it would be the case for dialog window procedure).
That is why I also remove the mention of "DWLP_MSGRESULT" in the SetWindowLongPtrW() call.
SHCreateWorkerWindowA() had it OK but SHCreateWorkerWindowW() did not.
------------------
[SHLWAPI] Make SHCreateWorkerWindowA() and SHCreateWorkerWindowW() x64-compatible.
The first parameter of these functions is a pointer to a window procedure, having a definite prototype, so employ a correct typedef WNDPROC,
which ensures both correct pointer size and parameter type enforcement.
This also ensures that we use instead a correct pointer size, since otherwise LONG remains 32-bits for Windows compatibility on x64 platforms.
The wndProc parameter is thus casted to LONG_PTR to comply with the SetWindowLongPtrA/W calls.
In SHCreateWorkerWindowW(), the last "wnd_extra" parameter should also be LONG_PTR to be able to pass 64-bit data pointer on x64 platforms.
Therefore fix also setting the wc.cbWndExtra size. One should note that the ANSI SHCreateWorkerWindowA() function had everything OK already.
This Wine sync (that was not done against WineStaging) erased code
that had been submitted to WineStaging by the ReactOS team (clist.c
fixes, see r73565 a05881c and r73976 7b6b597) or added in r68042 9a78054.
To that aim I add explicit #if(n)def __REACTOS__ guards around the code.
