UPDATE: Neil from Stardock has posted a response in the comments below and also in the Stardock forums. I've copied my reply to both places as well. Looks like we're making progress, which is much appreciated.
UPDATE 2: From a support request I just handled and confirmed, we've also found that the current version of WindowBlinds breaks the Configuration Backup and Restore wizard in Opus, making it so that nothing happens when you click Next. There are probably other issues as well. As a general rule, if you're using WB with Opus right now and something doesn't work, try switching to Windows Aero.
UPDATE 3: List of related issues and their statuses: http://leo.dopus.com/dowb/index.html#summaries
UPDATE 4: Stardock have released WindowBlinds 7.30a Beta for registered WB users, with fixes to the Directory Opus issues (and a bunch more). Use it in conjunction with the 10.0.3.1 beta (or later) versions of Opus. I'll post about this separately as well, so more people see it.
This post is borne of frustration, and it's a shame it has come to this, but for months now (maybe longer), Stardock's WindowBlinds software has been breaking Directory Opus in ways that make it look like Opus is at fault when the problems are entirely caused by WindowBlinds.
As the videos below show in detail, these aren't just the kind of cosmetic issues which WindowBlinds causes with a lot of software (including standard tools like Windows Explorer).
WindowBlinds explicitly detects Opus by its executable name (dopus.exe) and, in its latest version, does something (we have no idea what or why) to Opus which completely breaks any standard file dialog which Opus tries to open. The dialogs simply do not appear and Opus looks broken.
(If you rename any other program to dopus.exe then WindowBlinds will break that program as well, so it cannot be anything wrong with Opus itself.)
Anyone who already had WindowBlinds installed and decided to try Opus would think Opus was faulty due to problems that do not exist without WindowBlinds.
Stardock have known that WindowBlinds causes problems with Opus for at least six months. We proved to them that various problems seen when WindowBlinds and Opus are used together are caused by WindowBlinds, and we even demonstrated how the WindowBlinds DLLs could be modified to solve most of the problems. Even though these issues are entirely due to WindowBlinds, we did all the investigation, provided the proof and explained how Stardock could fix their own code.
Despite giving them the solution on a plate, Stardock have done nothing. (Worse, in fact: They released an update which breaks Opus even more than it did before.)
Stardock do not seem to care. Their shoddy software is making our software look broken to anyone who doesn't know the details, but they do nothing. The barely-supported product that they sell is damaging our product's reputation, through no fault of our own. We have run out of patience and want everyone who has used the two programs together to know the full story.
I have made a series of four videos about this, embedded below. These explain the symptoms, prove where the fault is and show how Stardock could easily fix things. The last video, the most informal of the set, closes with a brief look at problems that WindowBlinds causes with other programs, like Windows Explorer.
A tool like WindowBlinds, which modifies the operating system and individual programs in this way, needs to be updated more proactively than Stardock are doing. A tool like that, and which hasn't really even been updated and tested to work properly with Windows 7 (see the last video), should not be given away for free, let alone sold for money.
(All videos are available in 720p resolution, with optional subtitles.)
19 comments:
This kind of software (company) should be flogged (as well as blogged) about the head and shoulders.
Short of legal, perhaps Opus should pop-up a box alerting the user that this !@#$ type of software is installed on their machine, and to beware of crazy results.
Might as well make a .class out of it to use with some of the other !@#$ out there.
That's my 2bits worth.
Kudos to you guys for finding these issues. Why anyone would install WindowBlinds is beyond me. Danger Will Robinson, Danger.
While I haven't installed WindowBlinds on my current install of Win7 x64, this explains a LOT of issues I have had in the past. In fact, I have been suspicious of WindowBlinds before this. I can see I won't be installing it and I won't be renewing with them in 3 months.
Thank you for this series of videos.
If IRC, I was one of the first to post this on stardock and log it with their support so I completely stand by this article. Stardock need to fix this and promptly!
I've been running Stardock products considerably longer than Opus (just 4 years on Opus) and the company has changed considerably over the past few years. It's mainly a gaming company now. That may explain why their old core products don't get updated as frequently, also why I had activation problems for so long. I turned off WindowBlinds several months ago because I couldn't find a theme that didn't have some problem or other with my apps. I don't miss it. The artistic gains on Windows 7 are minimal. I am however a big fan of ObjectDock Plus and Tiles. Nice post anyway, and if they fix this maybe I'll enable Blinds again :-)
This just shows the difference between a serious software company and a group of jokers posing as a software company.
No WindowBlinds for me or my company!
Well I don't have WindowBlinds but I indeed DO have problems with Dopus!
It simply either crashes or just stops responding to ANY mouse clicks without any warning and it does not relate to anything special I do, just normal folder browsing in Dopus. All other programs work normally.
To get it back to work, I first have to close Dopus (exit from taskbar icon won't do anything), THEN from task manager kill the dopusrt. After that I can start Dopus again and - if I'm lucky - to get it work properly for at least few minutes until the same happens again...
This started with Dopus 10 but I don't want to go back to 9 as in 10 there are finally some features I have been waiting.
Anyone else have similar problems?
@Anonymous:
Have a look in the "Other Troubleshooting" section of the Opus FAQs:
http://resource.dopus.com/viewtopic.php?f=11&t=4095
Also, try with the latest beta version:
http://blog.dopus.com/2011/12/directory-opus-version-10023-beta.html
A *lot* of people have seen crashes recently which turned out to be related to the Quallcomm/Atheros Bluetooth driver's shell extension, and the latest beta version blacklists that to avoid the problems.
If you still have problems, open a thread at the user-to-user forums or with GPSoftware Support:
http://resource.dopus.com/
http://gpsoft.com.au/support/support-request.html
Those are much better places to get technical support than the comments section on an unrelated blog post. :-)
Lead developer of WindowBlinds here.
I have looked into this and it appears there was a big miscommunication between us.
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.
After this we marked it as sorted and nobody has contacted the development team to let them know otherwise. We were not ignoring the issue we simply didn't know about it!
Did you send any mails to support@stardock.com identifying yourself as the author and explaining the fix did not work. Doing so should have resulted in the information getting to me eventually, but it seems for whatever reason this did not happen.
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.
I have searched and it seems you did post on the forums on Dec 22nd about this not being fixed, but the forums are not the best place for it and the week before Christmas is a mad time as Stardock shut until the new year that day. The fact nobody replied at all should show that nobody was reading the forums at that point.
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. 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. I will see about getting that fixed for the next update too.
BTW in case there was any doubt, the reason why dopus was in the 'bad app' list originally was because of how it worked on Windows XP in the past. I cannot recall exactly what the issue was, but the source code says :
"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)
As it happens the reason this fix is no longer working on 7 is because of a bug in the Windows 7 File Dialogs not handling NULL theme handles correctly.
Anyway we are always willing to work with other developers on issues encountered with WB and have in fact been working with the DisplayFusion guys recently in enhancing WB such as adding in specific custom sections for their needs. We are not fixing bugs in WB but actually adding things to they can render things identically to how WB does for the taskbar and start button.
If you did contact support@stardock.com regarding this please do provide me with the ticket IDs so I can investigate what went wrong so we can try to ensure it does not happen again.
@Neil: "the reason why dopus was in the 'bad app' list originally was because of how it worked on Windows XP in the past"
Did you send an email to support@gpsoft.com.au identifying yourself as the WindowBlinds author and explaining about this problem?
Let me know the ticket number and I'll try and work out why this issue was never addressed!
Oddly enough I have no idea as this as back in the early 2000s and it would have been handled by someone other than myself.
I know we opted to fix the problem our end as it sorted the issue and it made little difference visually as WB simply skinned it as a non themeaware app instead (as XP still does). It is also worth noting that we didn't take the easy option to simply exclude the app.
You would be surprised what we have discovered with some apps and their theme support. One high profile framework actually assumes theme handles can be allocated over and over again and never freed. You would think they might have wondered why there was a CloseThemeHandle api.
Others actually close the handle and then continue to use the thing!
However I have spotted that you do still have bugs in your theme code. Your menu code appears to always query state 1 for text colour. This is incorrect and you should be asking for state 2 for menu items in the selected (I.e. mouseover state). By not doing so you have made your app incompatible with any theme that has dark selections such as the sublime skin.
Additionally your tab code seems to be painting without proper support for transparency.
As I said before we are always willing to work with other companies, but do need them to approach us via the correct channels. Ideally companies will also supply us with a copy of the software in order to aid reproduction of the problem and we typically do this ourselves too.
I am guessing by your response that you didn't contact us via these channels regarding the issue this blog is about though.
In case there is any confusion, like you our forums are user - user not formal support.
I'm copying my reply to Neil here as well as in the Stardock forum, since we've got two threads going in parallel. (Neils two posts differ very slightly in a couple of places so the quoted text isn't an exact match to the post here, but there differences are minor. Just explaining them in case it looks like I've edited what I'm quoting.)
I've had to split this due to comment length limits.
Neil wrote:
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 burried 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 anymore..."
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.
However I have spotted that you do still have bugs in your theme code. Your menu code appears to always query state 1 for text colour.
I noticed that as well and mentioned it in the video, along with the lines above and below the icons when using the same theme.
We can fix that fairly easily in the code, although it can also be worked around by changing the Opus configuration, so it's not a big deal.
And that theme puts black text on a very-dark-gray background in parts of Windows Explorer anyway, so... :)
I've used Objectdock in its many versions for years despite minor problems but the "new" Stardock are only interested in games.
I removed Objectdock+ last year.
I used to subscribe to Stardocks Object Desktop, but I haven't seen a good reason to use it since Windows 7 came out. In addition, they are slow at updating their software with new features so I can't see no reason to give them my money for doing nothing. Well, it doesn't seem they aren't doing anything, they are breaking software. I am glad I did not renew my subscription to Object Dock and uninstalled Windows Blinds a while ago.
Post a Comment