It’s this time of the week again where I have to sit down and try to remember everything I have been doing over the week.
I began the week by looking at some older pending bugs. First, I looked at an issue where using the branch with the vmware audio driver installed would crash stobject.dll and because it’s loaded into explorer-new, the rest of the desktop and taskbar. I couldn’t reproduce this issue, so I moved on.
Then I went back to our “friends” the object leaks. I tried to fix my win2003 VM so that I could use the leak detection tool, but it turns out the filebrowser program wasn’t actually working anymore, since the recent IPC fixes, and neither would running explorer with the /SEPARATE flag.
So I fixed the code to properly support loading a folder window in a separate process, and when I went to try getting some info about the leaks, I realized it wasn’t returning anything. It turns out, the method I was certain would work for debugging leaks in windows doesn’t actually work, and the only part of our shell32.dll that’s loaded are the resources. The code itself is still using the windows DLL. So again, I put the leaks back into the waiting queue, and moved on to the next issue.
I then looked at the toolbar, which has the View popup where you can change the listview mode between details, large icons and such. I looked at what the code was doing to make it work in windows, and where this code was failing in ReactOS, and I learned that our shell32 was missing two things. First, the shell view should call SetCommandTarget on the toolbar, in order to teach it how to notify the shell of the popup request, and second, the shell view should handle receiving commands from the toolbar, and show the popup appropriately.
I wrote the code, and when I went to test it, I realized I couldn’t click on it. Somehow, the menu was unresponsive. I spent some time debugging the issue, and finally I worked around it by making a copy of the popup menu instead of using the one loaded from the resources directly. Fixing the actual bug would be nice, but I think everyone will agree that it can be done later.
At Victor’s insistence, my next task became the implementation of SHFileOperation. I have spent the last few days writing new tests for this one very complicated function (since it does a lot of things in one single call), trying to find where it goes wrong, and when.
Huw is also providing some ideas for SHFileOperation, in case we decide to rewrite the functionality completely instead of trying to patch up the current (and very messy) implementation from WINE.
This is it for now, until next week!