21 Sep



Shared memory messages


Another weekend, another report.

The week was slightly shorter for me due to having the project defense on Tuesday, so I spent most of Monday preparing for the presentation, and most of Tuesday afternoon recovering from it. If you are curious, I got a 9.5/10 on the project. ;P

In the context of the shell, this week I mostly continued my investigations on the IPC mechanism used by browseui to open new windows in the existing process.

I investigated the values used in the shared memory buffer, and discovered some matches with the input given to the function. I noticed some of the matched parameters, and then I saw that at the end of the buffer, the contents looked remarkably similar to the data I had seen while debugging ITEMIDLIST objects.

I confirmed that the buffer contains some sort of header or struct, followed by the data of three ITEMIDLIST objects, and finally the path string that would be the path of the folder to open, in case there was no ITEMIDLIST for it.

After finding these matches, I moved on to investigate the other end of the IPC: the message handlers for messages 1037 and 1035.

Message 1037 appears to be sent by browseui when looking for the root window in order to find the target for message 1035. I’m not fully certain of the contents of this message, other than it’s send through a call to EnumWindows (in the callback, I assume). I believe the contents of the message may involve the target ITEMIDLIST, but I haven’t verified that yet. There is a chance this message may also be used to find an existing window for the folder, so that it can activate the window instead of opening it.

Message 1035 is the one that uses the information I mentioned earlier, which I can guess means “open new window with this information”. Not all the details of the shared buffer are known yet, but it appears that WPARAM is set to 0/NULL, and LPARAM is set to the shared memory handle. This tells me that the shared memory may be obtained with the PID of the target instead of the PID of the caller. A previous call to GetWindowThreadProcessId (presumably with the HWND obtained by the results of the root window search) appears to confirm so.

So, for the short term, more investigation is needed before I can get a working implementation of the IPC mechanism, and finally make our explorer-new open new windows in existing processes. Then afterwards I will start looking at implementing the Shell DDE, which needs its own parser, and all the backing code for running the requested operations.

The mid- and long-term depend on which features are really wanted before explorer-new gets merged into trunk, but at the very least, there will have to be a lot of bugfixing and error-proofing before that happens. Some features, like explorer sidebars or taskbar icon grouping, will probably be implemented AFTER the merge, since they are not essential for the normal usage of explorer-new and the advantages already outweight the missing features, even including the bugs.

Discussion: https://reactos.org/forum/viewtopic.php?f=2&t=13653

This blog post represents the personal opinion of the author and is not representative of the position of the ReactOS Project.