When the project was still under Bernhard’s rule, he was always going to release only versions that had passed his test plan. I hope to break this tradition soon and release more often and release earlier. My goal is to put all of the code-base under a testing harness that will allow me to verify and validate much of the functionality without too much manual interaction required. This means you will see unstable versions tagged as “alpha”, “beta” or “RC” (release candidate) as well as stable releases. It is on you to decide whether you want to contribute to the development by testing any of the unstable versions, or whether you want to stick with the stable releases only.
Please note that I will follow these guidelines:
- alpha (may become a weekly or nightly build) is a very early version of a future release. Neither is it guaranteed to work properly, nor at all on your machine. Also, new features in such a version may be unstable. As an example, a saved scan may not be loadable in a “beta” or a stable release of this version.
- beta means that the version is reasonably stable. Features available in a beta may disappear in the stable release, or change considerably.
- release candidate (RC) is a version of the software that has the full set of features (“feature-frozen”) of the anticipated next stable release. One of the RCs will eventually become the actual stable release if no bugs/issues have been reported within a certain time frame.
- stable releases are what you already know from WinDirStat.
PS: Once I am done with the migration of the translations to XML (see previous post), I will release a first alpha version that has the multi-selection feature activated. It will also have an optional online update-check. Before a beta I want to include an improved mouse-navigation as well as a save/load feature to save time and not having to re-scan a directory structure every time. I personally also liked the proposed ignore feature.
just wanted to let everyone know that I am currently working out a format for what’s now the resource scripts in XML. You can find a first draft version in revision 174 in the Subversion repository. As you can see, you will have the translations “side-by-side”, which should also make the job of translators easier. Since the encoding of the XML files will be UTF-8, all languages should be just fine, as all natural languages and several artificial languages (such as Klingon) are covered by the Unicode standard of which UTF-8 is one incarnation.
If any of you has ideas for how to improve the current XML format (more additions will follow throughout the next few days), please let me know here in the comment section, via our contact form on the website or in a tracker or the discussion forum at SF.net.
Rationale: it has been increasingly difficult to manage the translations (be it new translations, edits of existing ones by native speakers or changes in the GUI by me). Therefore I was for a while now looking into moving to a more manageable solution that will not require the translator to contact the developer, let alone have the developer “compile” the translation. Of course even with the new system it will be necessary that I include a new language in a future release, but there will be more flexible means of updating languages via the internet and translators will be able to contribute in a very flexible fashion as well.
PS: The XML parser (TinyXML with TinyXPath) will also be used to save/load a scan.
The migration to Subversion apparently did have some cost attached to it. Just found out that for whatever reason the resource scripts have been garbled. Hmpf …
Actually the culprit must have been one of the editors used two/three years back, according to the history. It only affected those languages with real diacritic characters (e.g. Polish) and completely different alphabet (Cyrillic/Russian) that could not be fit into the 1252 ANSI code page (the default on my system). This website from Microsoft really helped to find the correct matched for each code page. Hoefully the UTF8 version of the resource scripts is now correct. Parsing the strings inside string tables was pretty straightforward, but the PITA will be the controls in dialogs (which also need to be extracted). Just to explain briefly what I am going to do: all the resource DLLs will be replaced by a text file (most likely XML, as the saving of reports is another good reason to use an XML library already). This will allow anyone with basic understanding of computers to contribute translations (or pieces thereof) without having to know the (slightly convoluted) syntax of resource scripts (
Just recently Bernhard received fan art, from a WinDirStat fan and forwarded it to me. We got the permission to put it up on the website by the author, so I am doing this now and here. The image (thumbnail below) shows the patterns of a cushion tree map, nicely shaded so it will work well as a wallpaper. And guess what, that’s what it’s meant for. It fits perfectly to a dual-monitor setup with a resolution of 1280×1024 on both screens. Seems like to appreciate its full beauty you’ll have to grab your copy 😉
Go ahead, right-click and choose “Save target as”:
Thanks to Mathias for sharing it with us.
Good news first. Development on WinDirStat has officially resumed.
Now the question. I know as a matter of fact that there is demand for a 64bit version of WinDirStat. However, since 64bit implies Unicode, there is no need to handle this specifically as long as the compatibility requirements ar Windows 2000 and above. Nevertheless, as you know we actually do have an ANSI version. My proposal would be the following:
- I’ll try to keep compatibility as much as possible, even for Windows 9x/ME.
- Emphasis will be put on Windows 2000 and above – meaning it will be native Unicode.
- The versions offered will stretch 32bit (x86) and 64bit (x64) with Unicode. ANSI may be made available separately.
- New features will only be available in the Unicode versions, but bugs will be fixed in the old one and selected features may be migrated back.
I’ll add a poll soon at this place (possibly as a new post, so people who subscribe to the RSS feed get to see it).
PS: Feel free to comment on this post.
The company behind STOPzilla doesn’t seem to deem it necessary to react on a false positive report from someone who hasn’t bought their software. This means it could be that their software still detects WinDirStat and since I am not able and/or willing to check it on a regular basis, I can only recommend that none of our users use this software for their protection.
Should something get moving, I’ll keep you updated here on the blog.
STOPzilla, an antispyware is catching the most current WDS installation package as Zlob.YU. While one should never take this too light-hearted, the first reaction of the user who contacted me was of course rather in the direction of an accusation. Nothing wrong with that, if it would have turned out to be true. Not at last I am an AV researcher and developer. Although probably SF.net would be to blame if something like this happened, because all downloads run via them, this would be horrible for my reputation as well.
So, what now? First of all I want to reassure everyone, that the two download samples from different SF.net mirrors that I have taken are not infected, but still reported as Zlob.YU by STOPzilla. Since all mirrors are supposed to be in sync and I got the first report two days back, all mirrors should have the infected file version by now – if there ever was any threat. Instead the fact that only STOPzilla finds it, points to a false positive and I am going to contact the vendor about it.
Second, you need not trust me on that, instead I suggest to visit Jotti and VirusTotal, although these are also not 100% reliable in the end, the heuristics and signatures of different AV scanners are used to examine your file, which gives you a fairly good hint as to whether the file is infected or not.
I re-released version 1.1.2 with two additional languages earlier today.
Please note that I aim for a release with functional updates between around end of this year and beginning of the next year.
The short answer is: yes.
The long one is: there is no reason why WDS wouldn’t be Vista compatible. However, depending on how you start it (elevated or not) you will not be able to see certain parts of the file system (which is just the point with the elevation model). Naturally WDS, running under your credentials will have the very same problem, so you should expect to find a – potentially large – chunk called
in the root of the drive you are scanning.
Please search this blog for further information on the
I have to confess, I fell in love recently. Sounds weird? Right, it gets even more weird if I tell you that I fell in love with a file manager. The file manager is called Speed Commander (SC) and I am truly sorry to not have found it years ago. The respective project exists already for more than a decade.
So what’s so cool with it you ask? SC is shareware. This means you can try before you decide whether to buy it. Although I am developer of more than one OpenSource (and therefore also free – as in “free beer”) software, I usually try to balance between the effort required to write it myself and the time it would spare me to use such a program instead of the one I am using at the moment. The predecessor of SC on my machine was Turbo Navigator. Since it was written in Delphi or Borland C++ Builder, its Unicode support was non-existent. However, it was free (as in “free beer”) but not OpenSource. Neither is SC, in fact SC is commercial and ClosedSource. Nevertheless it rocks. This file manager is a joy to use. The only things that really distract me at the moment are the new program icons, the rest is better and some stuff I have to get used to.
Give it a try. In fact I think about porting the treemap code into an ActiveX and write a plugin for SC to show treemaps directly there. Of course such an ActiveX (COM) control would be accessible from any other application as well. The idea is to make WDS more modular and allow to share the code-base for the treemap between WDS and this ActiveX.
Several users had contacted us and claimed that WDS caused their systems to show the dreaded BSOD. As a driver developer I know that this is impossible since no user mode program can crash the system with BSOD unless some driver or other kernel mode component fails to check its parameters or whatever else.
Anyhow, one of the users sent me a minidump. This is the only way to find out who’s the culprit after a BSOD. In fact a full dump does as well, but a full dump has the size of the RAM on the user’s machine which is not usually practical (given sizes of 1 GiB and more).
The minidump showed that the fault had occured in a component of the Novell Client software. Although this justifies a strong suspicion, it is not a guarantee, since the respective bugcheck code occurs if some kernel mode component has corrupted the memory of the driver shown as faulty. My only recipe was to update the client software, if possible. There is no other way than this or uninstalling it completely (which usually isn’t an option at all ;)).
As before, the
item keeps us busy. Last week a user contacted us through the blog and later through email and chat as suggested.
As you know, the
item just shows the discrepancies between the used disk space reported by Windows and the size of the sizes of files and folders found by WinDirStat. The biggest problem is that WinDirStat has to have access to the files and that these files have to be enumerated. So if the files are hidden from normal Windows file functions, there is no way for WinDirStat to detect them. This and the way some backup software seems to function was the problem on the machine of the user who contacted me.
Thanks to the ever-increasing amount and frequency of spam-comments, I removed the option for comments for now. However, I’ll attempt to work out a fix (possibly similar to the fix I use in the UVNC forum) and then enable it again.
Sorry for the annoyance :-[
A user sent us the following registry script via the feedback mailing list. Thanks!
Copy and paste it into a text file and save the text file with the file extension “
.reg“. Make sure to modify the path in case you have a non-english system or in case you installed WDS into a different folder. Also make sure to use double-backslashes within the double-quotes.
Windows Registry Editor Version 5.00
@="WinDirStat here ..."
@="\"C:\\Program Files\\WinDirStat\\windirstat.exe\" \"%L\""
fixed version of the same script by Adnan Zafar.
Regarding the topic that is being asked for most often. Use the following approaches:
- Run a file system check on the file system (read: drive/partition) in question. E.g.
chkdsk /f X:. You’ll have to have admin privileges and if this is the system partition you will have to reboot.
- Check whether you have System Restore Points (SRPs) enabled. If so, check whether the size reported for
is below or equal to the amount you allowed for SRPs. If it is bigger and you skipped step 1, go back and perform step 1!
- If you have any special software installed that manages its own recycle bin or allows to restore old states of the system this software could use the same facility as the SRPs. Therefore the data may just be hidden/inaccessible to WDS. Nothing to worry if the previous steps didn’t give a reson to worry.
PS: I am about to create a Wiki where users can maintain a FAQ and so on (and possibly translate the help).