I posted on your blog about this, but I thought I should post here too.
Many thanks for taking the time to reply and look into these problems.
I'll post a link to your response at the top of our blog post.
Firstly these forums are NOT the right place to send bug reports like the above. They should always go to support@stardock.com so that they can be tracked and forwarded on internally.
I assumed this wasn't needed since, as I understood it, some of our mutual customers had already contacted Stardock support over the issue and Stardock support had already posted in this thread (after my June postings), and alerted you to the thread, and you'd replied to the thread and seemed to agree that the check should be removed. So it looked to me like the right people were already aware but that nothing had been done.
I also assumed that, since the WindowBlinds forum doesn't have a high amount of traffic, threads and posts in it were unlikely to be overlooked or buried before anyone had a chance to see them.
I fully understand that the forum isn't the official support channel (we have the same deal with Opus), but as far as I was aware the issue had already been reported through the official channel (although not by me), and it seemed a safe assumption that posts made here would be difficult to overlook.
As you can imagine, it looked to me like the issue was reported and confirmed back in June, and then nothing at all had happened, except an update which made things even worse.
Additionally if you did want to post on the forums it would have been better to post a new thread so it would have been more visible and posting just before Christmas is not ideal either!
There were already two threads (this one and "WB not correct on dopus 10") about Opus, both mentioning having to hex-edit the WindowBlinds DLLs, near the top of the forum. It didn't seem right to create a third thread with two existing ones still near the top of the list, especially when it was a follow-up to one of them.
Given that the post wouldn't be buried under lots of other posts/threads, it seemed safe to assume that it would be read (if the forum itself was read, which it seemed to be from my previous experience of the forum).
Indeed, although my most recent post (until today) was from just before Christmas, it was still one of the most recent posts in the WindowBlinds forum for the two weeks up until today.
But that most recent issue, and the lack of response to my post about it, were just the straws that broke the camel's back. The unfixed, six-month-old issue was the underlying problem.
WindowBlinds still caused the same problems it did six months ago. It still had DOPUS.EXE in the DLLs, still caused the same problems if anything else was renamed to dopus.exe, and still stopped causing all problems if hex-edited to remove dopus.exe. There was no mention of any (attempted) fix in any of the change-logs (that I found, at least; maybe they were incomplete), and no follow-up posts here, while people were still posting here about hex-editing the DLLs without anyone saying "hey, you shouldn't have to do that any more..."
So my post to the Opus blog was not because nobody had replied to my pre-Christmas post here after two weeks. That was a part of it but only a very small part. The main issue was that WindowBlinds was still breaking Opus, even worse than before, and it looked like nothing was being done or would ever be done. Without telling our users what was up, and proving to them that we weren't just trying to pass the blame, they would assume that Opus was at fault.
There was a report of issues back in May and we modified WB for the next update to remove the DOPUS.EXE line from the source code. Unfortunately the search missed the fact there was a second reference to it in a header file and for some reason QA did not actually test this - I will be finding out why this is.
Thank you.
There was only ever one instance of DOPUS.EXE in the DLLs, which is still there now, but string-pooling might account for that, so it makes sense that a second check could have been missed. I can accept that.
I hope you can also see how we could assume that nothing had been done when the DOPUS.EXE string was still in the DLL and when the six-month old problems (plus the new, more recent one) could still be solved by removing it, as per the instructions in several posts on this forum. There was no indication that anything had been, and now Opus was being broken even more than before.
I don't really understand how the change could have been done and then not even smoke-tested before handing it to QA. When I make a code-change to address compatibility issues with another application, I install that application in a VM and test with it to ensure the change is correct and that there aren't any other compatibility issues that were being hidden by the previous check's failure.
I mean, that's quite a chain of failures:
- Not doing the change correctly.
- Passing the change to QA without doing a smoke-test.
- QA failing to test the change themselves.
- No mention of the (attempted) fix anywhere in public (that I can find, at least), so nobody else knew the fix had been attempted and that you should be alerted to the fact that it didn't work and/or made things worse.
- Nobody noticing that the forum was still getting new posts telling people to hex-edit the DLLs, which should no longer have been required.
- Nobody noticing, (in an existing thread or not, and Christmas or not), a post near the top of the WB forum for two weeks making a serious complaint.
Anyway I apologise for the problem and I have modified the code and removed the second reference to dopus from the code. The next update should resolve this, but obviously if you encounter any more issues please do contact support in the manner I describe above.
Many thanks!
Regarding the other issues, the resizing from the top corner issue is pretty minor and I can live with that right now as fiddling with that code could cause other more serious issues.
Fair enough; I don't have to live with it.
I could send you a list of a bunch of other issues I noticed with the Windows desktop (Windows Explorer, the taskbar, Aero Peek; all unrelated to Opus) if you want them. (I didn't bother including them in my videos as it didn't seem necessary.)
The problem with the explorer selection when using the keyboard is interesting. I have not heard of that before, but I imagine not many people use the keyboard in explorer in that way.
Some people are keyboard die-hards.
I was surprised that it wasn't noticed by someone, and that combined with some cosmetic issues (with Aero Peek, in particular) made it look to me like the styles hadn't been very well tested with Windows 7.
By the way, if you missed the focus rects, you may also have missed the highlights that Explorer draws over matching parts of filenames when you do a search. (I didn't think to check for this when I have WB in a VM, but I think it's part of the same theme that Explorer uses for the focus rects.)
It also looks like the theme used in most of my videos causes inconsistent window sizes to be reported to applications. I got some really weird things going on that didn't happen with any other theme, like maybe the reported window metrics don't match up with reality. (Or the perceived reality; I know that with Aero itself the window metrics aren't 'real', but the OS tells a consistent set of lies to applications so that it doesn't matter except for apps that try to take screenshots of window-birders or similar. This is different to that.)
"Directory OPUS assumes things about theme handles, so its excluded at this level"
I suspect it did not handle the case of a theme handle returning NULL which was entirely possible and permitted on Windows XP (the docs even warned developers about it)
I wasn't working on Opus back then so I can't say anything authoritative, but from the way the code is now it handles OpenThemeData returning NULL in every case that i've seen. It would have to, at least in general, else it would never work with themes disabled.
Perhaps there was an assumption somewhere that if one theme component was available then another related component would also be available, which didn't always hold, but I'm only guessing.
I did find and fix, a while ago, an assumption in Opus that the tab-control background texture would be a bitmap, not some other type of element, so maybe it was that. Just a guess, though.
Anyway, if there are any issues then we can fix them, assuming they are reported to us one way or another.
(Edit: Fix some spelling mistakes.)
