23 Jun 2014



Spilling the Wine

After the frustration of last week, I decided to take one last look at Deleaker, and try to figure out why it crashes in ReactOS during COM registration.

The problem is, looking at the disassembly made it clear that the code is obfuscated. The functions start in one address, and then they jump all over the place, creating a mesh of small function chunks that even the best disassemblers seem unable to follow. It doesn’t help that the code has no stack frames, so there’s no way for me to get proper backtraces of the crash – all the info the debuggers show is completely bogus, due to EBP not being used for its intended purpose. I got some help from other developers, and even successfully ran the program in Wine, showing that there’s some incompatibility between the program and ReactOS that isn’t due to the Wine DLLs. But the obfuscation and potentially also copy-protection in the program, means that they implicitly made it very hard for me to learn where things go wrong, and although a leak detector is a very powerful tool, it’s not worth it if I’m spending more time trying to use the tool, than I would spend finding the leaks by hand.

Hoping to clear my head from this frustration, and wanting to make some progress for a change, I decided to look though the TODO list, and find something that should be easier, and as far away from the leaks as possible. This brought me to one of the issues mentioned by Giannis, where using the desktop with the keyboard seems to move the selection in the wrong direction (up/down move left/right instead, and vice-versa).

I traced this to LISTVIEW_GetNextItem from comctl32, which is a WINE-sync DLL. The function was a mess, and in my head, it seemed like rewriting it was more straightforward than trying to decode the existing logic. It took a bit longer than I would have thought (programming always does, for me), but I got the function working nicely in ReactOS, in all the available view modes. Then, it was time to apply the same changes to WINE.

I updated my Linux VM, and fetched the latest Wine source from their Git repository. I built the latest code, and ran the listview tests, and recorded the number of failed tests (it may be just me, but I can never get Wine to test cleanly in Linux). After saving the log of the test results, I applied the changes to Wine (not such an easy task when trying to apply an SVN patch from a different repository, into Git), rebuilt and re-tested, noticing the number of failed tests had grown by 4. Diff’ing the logs, I saw that the 4 new failures were really 2, and those 2 failures were in the same code, just with different keypresses.

Because I couldn’t think of any small app with an easy to use listview control, I decided to try running our filebrowser.exe with our rshell and browseui, in Wine. I had to fix a few small things in the Wine code before it ran successfully, but then I noticed the navigation wasn’t working (clicking on icons did nothing), so instead of trying to implement whatever may be missing from wine’s shell32, I chose to implement a simple commandline parser into filebrowser, so I was able to give it a path in the commandline, to use as the initial folder.

The default Icons mode seemed to work well, so I tried the other modes, and noticed that in the Details view, moving up/down would move by TWO items, instead of one! What the heck?! This was definitely not happening in ReactOS, so I was perplexed, and after a while of not finding a cause, even frustrated than when I started.

I chose this bug thinking it would let me get away from the previous frustration, but it turned out to add to it instead. At this point, threw the figurative towel against the screen, and went to play some Mario Kart 8 online.

Later, I came back and finished some local changes I had pending, and switched my brain into weekend mode.

Until next weekend.

P.S.: This is filebrowser running in Wine:


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

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