NTFS metafile (MFT) size handling, 2 fixes

Closer to 100% space accounting

NOTE: altWinDirStat will only try to query the MFT size if you open the root directory (e.g. C:\). altWinDirStat will only succeed in querying the MFT file size (and other NTFS metafiles) if run as an administrator.

In pursuit of 100% used-space-accounting-for (as NTFS "misreports" free space), altWinDirStat now displays the size of the NTFS Master File Table, and I've implemented experimental support for displaying the sizes of other NTFS metafiles.

I've also fixed the annoying issue (#9) where running altWinDirStat for the first time - only where the vanilla version of WinDirStat has also not been run - would display a garbled file tree & file type list. For more information, see Pull Request #10.

I also fixed issue #8, by eliminating the "special" case in CompareS.

This release does suffer one regression: working with very large folders (number of items) is a bit slower, sadly. I fixed an annoying bug where the last item in the list view would appear after the parent folder had been collapsed. I refer to it as a "zombie item". For more information, once again, see Pull Request #10.

As usual, they're statically linked. I recommend using the 64 bit builds wherever possible.

Minor changes - 32 bit build posted

No major changes here. I reverted back to the "classic" file picker dialog, because the more modern one uses a _crapton_ of ram.

There are plenty of back-end changes, since it's been a while since v0.9.3. I've been working on other projects, so I haven't devoted as much time to altWinDirStat.

I promised that if anybody wants a 32-bit build, I'll post one. Sure enough, someone did, and I'm happily complying.

I still encourage the use of 64-bit builds where possible - they're always faster.

As usual, they're statically linked. Thus, they're as big as MFC is. I really wish I understood ATL better!

Minor new feature added, fix to annoying issue in v0.9.2

Development has been a bit slow, and Git messages a bit terse, for the past two weeks or so. Sorry!

v0.9.2 had a small but idiotic issue in it, that was a stupid mistake of mine. I wasn't properly guarding a Windows-8-only API with IsWindows8OrGreater, but instead ASSERTing in debug builds. This meant that the release build would crash on calling the API, and the debug build would crash on the failed assertion. See windirstat.cpp:300 in 38470d2 for the fix. I develop on a Windows 8(.1) machine, so it didn't show up immediately. This is also a runtime check, so it didn't show up in static analysis.

I've added a (minor) feature, NTFS compression ratio, which displays the ratio of size-on-disk to size:

See 845a3f7 for the NTFS compression ratio changes.

I've also swapped out the dialog to select drives/folders with the native Windows shell dialog, which requires far less code complexity, and does a better job. The only down side is that it suffers from any of the performance issues that your local shell does (I'm looking at you, shell extensions! ahem TortoiseSvn). See 30a31f0 for the changes.

On the back end, I've implemented a new string allocation model for "children", which should reduce memory usage via a reduction in heap fragmentation. See e3ede6e for the changes

This new allocation model is also the framework for an even more efficient allocation model, that I'll introduce in the next release. This newer model will be more complex, easier to get wrong, and thus will require more dev/testing work. See eb2e4c1 for the prototyped idea.

I've implemented ScopeGuard, which was first introduced in Loki, as part of Andrei Alexandrescu's Modern C++ Design, now used at Facebook in folly, and presented in "Systematic Error Handling in C++". This will should tremendously simplify some complex code. See e557bfe for the changes.

In a number of places, particularly in drawing code, I've manually expanded/replaced MFC's code with code that does more error checking (see 3b4304b and eb2e4c1). Error checking is a good thing.

There are a few temporary hacks in ad00653 that I intend to remove immediately, but were holding this release up.

Known issues:

• Issue #2 NOT yet fixed - although I DO know what's going on, see 1837212
• The line-one-past-the-last-line isn't always properly redrawn as empty
• If you select an empty folder to scan, the treemap will be drawn as a single black square. This should probably just be an insulting error message.

I think that's everything. Hit up the links below for a binary. Let me know if anybody actually NEEDS a 32-bit build.

Pretty stable, functionality wise. Hopefully fixes issue #3.

There are too many commits to properly summarize here, but I'll try :)

I cleaned up some MFC warnings, and fixed a really subtle & annoying bug, that was only obvious by running the program ( the source looked fine! ), in commit 639fefc .

I removed some of the horrible global variables that are present from the original WDS (see 45b72d9 , b7f784e , and 113b38b ).

I also refactored tons of "arrow" code, code which was threatening my mental health (see 608a0da , 09e3df3 , 1992b56 , 85e3ac6 28acc8d , 2c0a187 , and 0fa4f19 ).

[...]If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.
Linus Torvalds

I believe that I fixed issue #3 in 85e3ac6 .

I also generalized some functions with template metaprogramming, of course with a generous use of static_asserts ( see 5c649d2 ), and cleaned up some code duplication that was the RESULT of inheritance (ha! take that, OOP!), ( see 632d73f ).

item.cpp was getting big, and the item.asm output that the compiler generated (I frequently inspect the generated code) actually got too big to open in Notepad++, so I moved the directory enumeration code into it's own file ( see 1a022cb ).

I've also turned on some security features that are newly present in Windows 8 (not supported on Win 7, Win Vista, etc...), so altWinDirStat will benefit from the newly "electrified" fences. Not that we're doing anything dangerous, like parsing untrusted data, but we still want to be as secure as possible. It's just the responsible thing to do. See d67a93d for the commit in question.

Lastly, one of my intentions in all this refactoring is

1. to enable a saneproper fix of issue #2 .
2. to add a new feature, display of NTFS compression efficiency, which I think would be quite useful, and absolutely within the scope of WDS's mission. I can't do this without a straightforward TreeListControl, and we're not there just quite yet.

(side note: do y'all really need a 32-bit build? 64-bit builds have access to twice as many registers, and are thus faster! It's 2015.)

A few issues fixed (hopefully!)

In response to issue #1 I've audited every single use of std::terminate( )/abort( ) (this is why
I keep the codebase small!), and ensured that at the very least, some
form of error message is displayed before any termination, no matter how
unexpected.

I furthermore disabled AVX codegen, now using SSE2 for compatibility.

I'm also providing the debug binaries, for the brave souls who'd like to track down issues, on computers without the Windows SDK. They're heavily instrumented with debugging output, and you can use a tool like DebugView from Sysinternals to view it.

See the summary in faa5e18 for the full description.

If you're not sure which version to download, then download the 64 bit release.

Approaching stability!

There's still a ton of work that I'd like to do, but it looks like everything is stabilizing. altWinDirStat is based on the 1.1.3 beta of WinDirStat.

altWinDirStat is many times faster than WinDirStat, is built using a modern toolchain, and features a modernized codebase.

I've rewritten large parts of the application, all with performance in mind, all while profiling relentlessly with vTune. I'm using vector new and placement syntax wherever possible, and do all string processing on the stack, for performance.

Lastly, I've ripped out all the gimmicky "features" ( including the ability to send email! ), which tremendously simplified the design.

The binaries are statically linked, and entirely standalone.
(source code may be a few commits behind binaries, oops. see 7de33be for the sourcecode)