A bit of history: in r71528, I tried to fix our explorer often
crashing while browsing directories. It was linked to the fact
that a notification result may arrive while the notification
structure had already been deleted.
The fix for this was actually broken and was leading to a double
leak: the notification structure was leaked. But also the handle
to the directory that had been browsed!
This means that the directory couldn't be modified anymore as
a leaked handle to it was still open.
Actually, when notifications are cancel, the kernel properly
calls the notification routine, but with a specific error code.
So the correct fix is to stop handling that notification when
we receive this error code. This is the correct fix with no leaks.
This commit is a complete r71528 revert with the appropriate fix.
CORE-10941
CORE-12843
- Make sure the DWLP_* values are correct on _WIN64
- Don't use the DWL_* constants, they are not portable. Enforce this by removing them entirely from winuser.h
- Make sure Get/SetWindowLong*Ptr* is used and pointers are not truncated to LONG
- Use a new work_available event to allow ProcessPlayingNotes to sleep when no
notes are to be played.
- Get rid of the pointless thread_termination_complete event, wait on the
thread handle instead.
- Don't leak thread_handle.
- Set some last errors.
- Fix error code returned by ScLookupServiceByServiceName().
- Check the validity of the handler proc in RegisterServiceCtrlHandler(Ex)W().
- Improve some traces; comment some code.
services\database.c:
- Refactor ScmControlService() so that it can be used to send the dispatcher loop stop command.
- Separate the code to decrement the image run counter from the service image cleanup code.
services\rpcserver.c:
- RSetServiceStatus(): Stop the dispatcher loop when the image run counter is zero and remove the service image after that.
advapi32\service\sctrl.c:
- Do not terminate the service dispatcher loop when the last service is being stopped. Wait for an explicit dispatcher stop command (empty service name).
CORE-12413
The two methods were completely broken because they passed a full pidl to the parent folder (and not desktop folder).
Compile SHGetNameFromIDList to use it in CShellItem but don't export it.
on 32bit builds CSIDL_PROGRAM_FILESX86 is treated as CSIDL_PROGRAM_FILES and on wow64 builds CSIDL_PROGRAM_FILES gets treated as CSIDL_PROGRAM_FILESX86
Set the view object as the site of the drop target.
Implement GetItemPosition, SelectAndPositionItems, IsDropOnSource, GetDragPoint.
Use DROPEFFECT_COPY only when the item supports it.
This patch reduces failures of SHGetFileInfo function. CORE-7159
* improve WideByteToWideChar calls
* fix bugs related to file attributes and SHGFI_EXETYPE
* SHGFI_USEFILEATTRIBUTES and SHGFI_ICON fix
* s/sizeof(temppsfi)/0/
CDefView: Make GetItemObject return an IContectMenu after setting itself as the site.
CDefViewBckgrndMenu: Make the inner context menu use the same site. Implement handling CMDSTR_VIEWLISTA and CMDSTR_VIEWDETAILSA.
CDefaultContextMenu: CMDSTR_VIEWLISTA and CMDSTR_VIEWDETAILSA shouldn't be handled in this class.
Fixes CORE-14327 and the two buttons that change the view mode
It shouldn't be necessary for QueryContextMenu to be called before InvokeCommand.
Move retrieving the IContextMenu of the folder to the initialization of the class.
CORE-12866
[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.
Wine's comctl32 somehow fails to load an 24bpp image with ImageList_LoadImageW
when crMask is CLR_NONE so use a color that doesn't exist in the bitmaps until
comctl32 gets fixed.
I prefer to add this silly hack in a non critical dll than make a hasty change in the
critical comctl32 until some proper tests are written for this absurd failure.
Such a manifest is meant to be activated by the caller of the exports of the dll.
This means that the user of syssetup which is setup.exe is the one that should do the proper handling of the manifests.
Since setup.exe is the one that needs to do the right thing, add a CREATEPROCESS_MANIFEST_RESOURCE_ID to it and avoid
dealing with ISOLATIONAWARE_MANIFEST_RESOURCE_ID altogether (which is supposed to be used by activating the activation context
before calling the exports of the dll that has it). We don't really use ISOLATIONAWARE_MANIFEST_RESOURCE_ID correctly in any
place in the tree so let's rely on CREATEPROCESS_MANIFEST_RESOURCE_ID for now.
This fixes one part of CORE-14228 where no image was shown in the theme selector buttons. This happened because comctl32 was
statically linked and calling ImageList_LoadImage ended up creating an image list with comctl32 v5. Then we passed this image
list to a button created with comctl32 v6 and as a result the image list was unusable. This is yet another issue that needs
to be addressed in the future. Namely, it seems that in windows comctl32 v6 can use image lists created by comctl32 v5 whereas
we cannot.
This fix is not a hack but cleverly works around these two bugs that need to be addressed some time in the future.
CORE-14228
- Introduce the TRAYNOTIFYDATAW structure, as documented by Geoff
Chappell in "WM_COPYDATA for Taskbar Interface", at
http://www.geoffchappell.com/studies/windows/shell/shell32/api/shlnot/copydata.htm
that is the data structure passed between shell32 and explorer for
communicating shell notify icon information.
- In Shell_NotifyIcon(), correctly capture the (ANSI and) UNICODE
structures provided by the caller, properly taking into account for
the different NOTIFYICONDATA structure sizes existing out there.
The different strings are now properly null-terminated (especially
szTip if it needs to be truncated out), and the flags validated.
- Remove the now unneeded "SHELL_NotifyIcon()" helper function.
[EXPLORER] Use TRAYNOTIFYDATAW and adjust the callers.
- Add missing error code to DDK/NDIS
- Fix error code in IP driver
- Patch MSAFD to reply correct WSA error code
- Fix IcmpSendEcho function
- Fix returning error code in ICMP_ECHO_REPLY (see MSDN)
- Fix returning host address (using GetBestInterface and GetIpAddrTable functions)
- Fix GetBestRoute function (it is used by GetBestInterface)
Relates to #318 and CORE-14241
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.
