Screenshots & sketches RSS feed

A brand new version of the copying speed-time estimator is in. It is far more sensitive to the changes in copying conditions while also producing estimates that are far less jittery.

New version also has a visually distinct mode when the program is correcting its estimate due to changes in the copying speed.

Significant copying speed-ups are not uncommon, but the slow-downs are even more routine. They happen few seconds into the copying, when the write cache fills in and the writing speed drops to the device's native value: When this happens, the completion time gets pushed back and the UI reacts to this by highlighting the estimate in red. It also increases its rate of refresh to make changes more obvious.

The GIF at the top captures this in action with a backup that goes from an NVMe drive to an HDD.

The copying speed first spikes to 1600MB/s as the write cache is getting filled, but quickly drops to 100 MB/s, which is the native write speed of the HDD.

When a change in speed like this happens, the estimator enters a correcting state and starts to gradually adjust the ETA.

Once the copying speed stabilizes, the estimator switches to the stable state and sticks to its most recent prediction. That is, it fixes the ETA and keeps it constant until further notice.

As the copying speed fluctuates, the effective ETA may go a bit up or down, but the estimator will ignore this jitter in favour of keeping the countdown steady.

This ensures that the countdown behaves like a clock, without sudden stalls and accelerations like this: The estimator also keeps monitoring effective ETA to make sure it doesn't drift too far away from the fixed estimate. If it does, then the estimator initiates a new correction and the process repeats itself.

So there you have it - our new and shiny stabilized estimator. Coming up in Release 80.9.

*  A broader context here is that even the fastest storage devices will complete the IO unevenly. As a result the raw measurements that go into an estimator will always be noisy and feeding them into an estimator, as-is, will produce noisy estimates.

For example, here is (an otherwise truly excellent) Far Manager running a bulk copy and using an overly simplistic estimator: This is more distracting than it is helpful.

A better, human-friendly estimator needs to de-noise the data and to smooth out the estimates. It also needs to make use of heuristics to further align the result with what a human would expect, e.g. to not re-adjust the ETA every chance it gets.

Long story short, calculating ETA is one of those things that look trivial on the surface, but in practice it fronts quite a bit of depth and complexity. Just something to keep in mind.

If we are to open an existing file, append some data to it and keep it open, then the dir command will keep returning file's original size until we close the file:

The same will also happen to the last-modified timestamp. Even though we "touch" the file, everyone else will be seeing its old timestamp until we release the file reference.

This looks odd, doesn't it?

The explanation to this behavior can be found here and it has to do with the fact that modern file systems such as NTFS and ReFS store file meta data alongside the file itself rather than with its folder entry.

This allows attaching arbitrary meta data to the files (i.e. not just attributes and timestamps), but it also means that a simple directory listing requires combing through each and every file to collect respective bits of meta.

Obviously, this doesn't scale well.

This issue is resolved by caching parts of file's meta in its folder's entry. This speeds up directory listings, but it also comes at a cost of meta being replicated lazily.

For example, if we are to add data to a file, then its new file size will not get propagated to its folder record immediately. Instead, it will done at some point later on.

Depending on the Windows version, this may happen when we flush file buffers, query file size via a handle or close its handle.

All this means that there's no reliable way of detecting actively modified files based on their directory listing alone.

So if we want to identify and back up such live files, we need a workaround.

One workaround is to just forcibly update them on every run, regardless of whether they have actually changed or not. It's crude and wasteful, but in a pinch it works.

A better option, supported by the new preview release, is to double-check directory listing data by re-querying file size and timestamps directly from the files themselves.

The queries aren't cheap, so they are not issued for all files.

Instead, this option works similarly to the forced updates - we specify one or more files of interest and the program rechecks their meta if it runs into them during a scan.

None of this is too complicated, but it takes time to understand why things work they way they do and how to work around that.

*  Kudos to James Kindon for raising the issue and providing original traces to identify it.

Update channels were first introduced back in 2016 and they got formally documented earlier this year.

However the selection of channels remained limited to newest, stable and, the everyone's favourite, symantec. There was no need for making channels easily configurable. Not until now.

A brand new update channel called preview will go live shortly after the 80.6 release and it will host development builds of upcoming major releases, starting with R81.

A chance for you to see what's coming and a chance for us to crash on machines other than ours. Win-win.

* Update channel configuration is an advanced option, so it will not be visible unless Help menu is opened with Ctrl being held.

When run, every backup job goes through 3 main phases:

• Scanning
• Planning
• Executing

Scanning creates file indexes of the source and backup locations.

Planning compares resulting two indexes, finds the differences and compiles a list of basic steps - create folder, copy file, move this, delete that, update third - that, when executed in order, bring the backup in sync with the source.

Executing merely goes through the plan and diligently executes each step.

Having a formal planning phase comes with one very important benefit - it allows extending core backup logic with a minimum amount of changes, making it a very simple, fast and predictable process.

In case of offline files, the opportunistic backup is implemented by simply disabling scheduled file update if the source file has a Recall-On attribute set.

Simple, which is why the change can be rolled out as a part of a smaller update rather than needing to wait for the next major release.

* The same mechanism is already used by the option that disables file updates when the backup copy is newer than the source.

It works the same way - an update is scheduled using regular file comparison logic, and then an additional check is made to compare file times and to disable the planned action if needed.

As you probably know, files stored in the OneDrive folder may or may not actually have their data cached locally.

When there's no local copy available, the file is said to be offline and its contents will be retrieved from the cloud storage when the file is accessed. An offline file like this will have either Recall-On-Open or Recall-On-Data-Access attribute set, allowing it to be identified as such.

The Pinned attribute will be set on files that were marked for permanent local storage using "Always keep on this device" - These files will show up with the solid green icon in the Explorer. Conversely, the Unpinned attribute will be set on files that were explicitly purged from the computer using "Free up space" - Finally, there's also an Offline attribute that is set on offline files by older versions of OneDrive.

With release 80.5 it becomes possible to define rules based on these four attributes.

For example, we can exclude all unpinned files from the backup. Once in place, a rule like this will cause Bvckup 2 to remove file's backup when its OneDrive copy is discarded with Free up space.

While not dramatically useful by itself, this change paves the way for another improvement - an option for suppressing file updates if the source file is offline.

See Part 2 for details.

7 years ago

The original company name - Pipemetrics - was picked in 2012, when the company was formed.

The plan back then was to make a distributed network profiling and monitoring system, tentatively called Notwerk. As quirky as it was, the name quite accurately predicted what happened next - the project did not werk out.

So not few months later we ended up switching to another idea - a proper, production rewrite of the original Bvckup. It was a file backup program that I wrote over a weekend few years prior and that was getting an unexpected amount of traction despite all my efforts to ignore it.

The company name remained though and according to it we were still knee-deep in the pipe measurement business. Even had a logo to match - That's an undersea network cable cross-section... or at least an artist's impression of the same.

In any case, all this was around 7 years ago.

4 years ago

The discrepancy between the product and the company name was one concern. Another concern surfaced a bit later on, when Windows 10 with its pervasive telemetry was released and more people started paying closer attention to the tracking and privacy matters.

And there we were, making an offline software for handling one's private data, and yet we were called ...metrics. What was it that we were merticsing exactly?

Neither of these concerns required an immediate name change, but they lingered. And so about 3 years in we started looking for a better name.

Naming

Now, that is just factually wrong.

Naming things is not hard. It is an utterly frustrating and painful, painful process that drains all fun from life and creative juices even from those who didn't have them to begin with.

Sometimes you can stumble upon a great name in a matter of seconds, but more often you don't. Or you just google it up and realize that you are the N-th heir to the throne, ten years too late.

Say, you want to name something that deals with data. Dat should not be hard. Ding - "dat" is taken, and you haven't even considered it yet.

DataWorks?
DataScape?
ProData?

Pfft, lol. Are you kidding? Taken.

How about Datto?

Quirky, weird. No way anyone else would think it up.

You'd think. Taken.

In fact, taken so long ago that people now complain how much better it was in the good old days, whenever that was.

Datrium?

You know - uranium, unobtanium, pinacoladium. No-pe, taken.

Days go by and all that you can come up with are just OK-ayish bland names, each flawed in more ways than one, and most of them even without a matching dot-com domain.

Inevitably, you start looking for a way to make the process more formal, structured, predictable. To keep track of the "progress" and not to cover the same ground twice.

The good news is that it is doable. The bad news is that genuinely great names are still a matter of luck and random insipiration.

Part 1 - Keywords and associations

The name needs to be unique and memorable, obviously.

The shorter the better. There are exceptions, of course, but the rule of thumb is that it should be 3-4 syllables max.

It needs to be pronounceable and it should not have any negative connotations. Yes, I know, there's an irony in here somewhere.

In fact, looking back this is probably the most important property of a good name - it needs to roll off the tongue and leave a good impression behind.

That impression should be strong and memorable, even more so than the name itself. While people tend to forget specific names, the concepts and feelings stick around for much longer.

To that end good names often have an unusual, but an otherwise obvious association with whatever they are attached to.

An excellent example of this is a distributed database called...

    Ready?...

    Voldemort!

Distributed storage indeed. How ridiculously good.

Naturally, there are great names that don't have any explicit associations.

For example, Akamai does have a very good explanation behind it, but it's not obvious. However the name is simple and it sounds nice, so it is easy to remember just because of that.

Same goes for Skype, originally standing for Sky Peer-to-Peer.

Kodak is yet another example, except that it's a completely made up word. George Eastman, the founder of the company, liked the impression the sound of the letter K made, so he went on to find a name that was "short, easy to pronounce, and not resemble any other name."

The year was 1888.

Finding a good association is a matter of certain luck, but the chances can be improved by formalizing the process.

By brute-forcing it basically.

Start by defining what it is that the company (product, gadget, whatever) does and what it is about. Compile a list of relevant keywords. Then for each keyword add several more - synonyms, related concepts, ideas, references.

Repeat several times.

The end result will be a list comprising both very specific and very abstract things that can be used as latches for an association.

For us, being in a data preservation domain, it went something like this: The list was over 50 entries long, stretching as far as "bastion", "marmalade" and "formaldehyde".

The problem, of course, is that a keyword alone usually doesn't make for an unique name.

Part 2 - Prefixes and suffixes

Lots and lots of names follow certain patterns. These patterns can be identified, distilled and formalized.

One such pattern is adding a trailer qualifier:

• ... technologies
• ... software
• ... systems
• ... project
• ... group
• ... labs
• ... associates

Similar, but with more "edge":

• ... initiative
• ... innovations
• ... engineering
• ... committee
• ... society
• ... masters
• ... theory
• ... method
• ... logic
• ... works
• ... matters

Alternatively, the keyword itself can be equipped with a suffix:

• -com
• -sys
• -ware
• -soft
• -tec
• -tech
• -tronic
• -mark
• -craft

This tends to result in a rather pompous and boring enterprise-y names, which sometimes may actually be desirable:

Infocom, Unisys, Commware, Microsoft, Symantec, Datamark, Netcraft, etc.

Prepending prefix to the word is yet another option:

• Para-...
• Meta-...
• Vari-...
• Poly-...
• Inter-...
• Super-...
• Hyper-...

InterPlay (of the Descent game fame), ParaData, HyperLoop, etc.

One other option I feel I must mention is that mixing Maxwell into any technical name tends to make it dramatically better.

The association here is that with Maxwell's equations that carry an incredible mix of mathematical elegance and complexity.

"Maxwell" also sounds nice, and it is just 2 syllables long.

As a result, we had Maxwell Storent on the short list. In the end it lost to other options, but I still think it was a great name, full of technical competence and credibility at no extra charge :)

Part 3 - Word mangling

Mangling a keyword is yet another way of turning it into an unique name.

If we were back in the .com era, prepending an e to everything would've sounded like an excellent idea. Still have fond memories working in a place called eTunnels.

Dropping a vowel was an equally acceptable option with a great following - Flickr, Tumblr, etc.

Duplicating letters also worked, e.g. Dribbble or FFFFound.

In fact, there was also Forrst, which boldly went where nobody dared, both dropping and duplicating like there's no tomorrow.

Replacing c's with k's and dropping trailing vowels tends to make words sound vaguely Scandinavian.

Objective becomes Objektiv, which can pass for a noun.
Accurate - Akkurat, etc.

Technik can help adding some German flavor to the name. We would've gone this route except that we are in a French-speaking canton and it didn't seem like the right thing to do.

Replacing trailing -e with an -a tends to create Latin-sounding words, e.g. Apertura, Machina, Textura, etc.

Similarly, tweaking the word to end with -ium or -eum results in a Latin-scientific feel.

The yield

Fast forward 4 years of episodic search spurts and we had a list of names with quite a few candidates on it. Here it is, with just few entries trimmed:

• Data Mechanics - really liked this one, actually, a good pun
• Data Matters - similar, also double-meaning
• Data Associates - only if in hopes of being acquired by CA
• Data Committee - implied that we don't get any real work done

• Swiss Data Works
• Swiss Data Reserve - implied that we are a storage provider

• Datori
• Datamata
• Datamation
• DataTechnik
• SuperData
• Redata

• Storewell
• Storent
• Prestor
• ByteMasters
• MetaByters
• Keepwell

• Keep Systems
• Parity Works
• Zeroloss Systems
• Data & Loss - the barristers

• Stray neutrino
  * As per the theory that the bitrot is caused by neutrinos

• Ashwell
• Waltron
• Corelion - as in Coreli-on, not Core-lion
• Hyper - with "Hyper Abc" as product names
• Variance
• Wellmade
• Struktura - also liked this one a lot, but the .com is squatted

And the winner is...

It's reasonably short.

It rhymes when pronounced.

It's generic enough to cover more than just backup software.

The iobureau.com and @iobureau were available.

It also can be made to look both like IO and 10 when rasterized down to a small size. Not terribly important, but having a simple symbol to go with the name is always a plus. So, ladies and gentlemen, until we decide to rename ourselves again we shall be known as the IO Bureau.

Bonus material

In case you want to try your hand at finding a good sounding, but otherwise random name, here are some pointers:

1. Reverse dictionary
To search for words with specific ending.

2. List of last names
To make your own Bang & Olufsen.

3. Lists of gods
Quite a few solid leads there.

4. List of Intel project codenames
Skylake, Ice Lake, etc. Mostly geographical landmarks.

5. List of Microsoft project codenames
Not as consistent as Intel's, but still worth a read.

6. List of Solar System objects
Including a handy list of moons.

7. List of planets in science fiction
Examples of names made up by other people.

8. List of fantasy worlds
Same here.

Samples

• Brand new
  Long-running series on re/branding by UnderConsideration,
  including longer reviews, quick mentions and smaller bits.
  
  
• Origins of well-known company names
  3M = Minnesota Mining and Manufacturing Company, etc.
  
  
• YC list
  A list of Y-Combinator funded startups, if only to see how
  hard it really is to come up with a truly memorable name.

Longer reads

The Weird Science of Naming New Products
An NYT article that follows the naming of a very high-profile project. Perhaps with no directly actionable insight, but really interesting nonetheless.

Brand Names
This is a really really deep dive into scientific aspects behind naming and name perception. Fantastic resource... though a bit like trying to learn how to fry a steak by studying metallurgy and proteins :) Be warned that you may end up being even more confused than before.

Feeds  -  RSS  /  Twitter  /  Reddit

In particular, the UI will now make a clear distinction between upgrade releases and maintenance patches.

For maintenance releases it will also put more stress on the importance of an update if it happens to resolve a high-impact issue. See "Critical patch" screenshot above.

Additionally, the release notes are now displayed off the main view, giving them a bit more space if and when it's needed:

Starting with R80 all explicit folder exclusions will be final.

In plain English it means that excluding a folder by clicking on it in the middle pane of the Backup What window will now prevent any further rules from being applied to its contents: For example, if there were an include *.dll rule defined further below, it will now no longer pick up basebrd.dll from Basebrd subfolder.

It is, of course, still possible to re-include any items from an excluded folder just like so:

Prior to this change excluding a folder wasn't "final", meaning that it merely set the default action for all sub-items to exclude, and this action could still be overridden by other rules.

New behavior will be enabled for all backup jobs created with R80 and newer releases. All existing jobs will continue to use their original filtering logic and work exactly as they did before.

There is also a way to tell if a job uses the new or the old logic. Here's an older job: And here's one with the new logic:

Alte Haas Grotesk has been replaced by a considerably more expressive Brutal Type, slightly customized and re-kerned.

The symbol has also been redrawn from a bastardized V to a proper and better balanced geometrical construction.

The symbol now comes in three versions. One is shaded suitable for larger sizes, where the gradients do not get lost: Second is the monochrome, which is a reduction of the first version to just black and white: The last one is simple, which is just the shape without any embellishments as used for program icons and such.

While we are at it, it's probably worth sharing several other options that didn't make the cut.

An alternative weave: An alternative shading style: Something with color: Truth be told, the one of the left was my absolute favorite, but it ended up looking like a royal mess at smaller sizes. And smaller sizes are important, because, you know... Windows.

When reading a file, the program does that by requesting blocks of data, back to back: Then, as nears the end of a file two things can happen. If the file size is not a multiple of block size, the program will receive back an incomplete block: And if the file is perfectly aligned to the block size, the program will see either a zero-sized block or an explicit "end of file" notification or EOF for short. Upon seeing either of these lovely events, the program will know that it reached the end of the file and there's nothing else left to copy.

There is however a nuance.

In theory, the program may receive a partial block back even if it's not at the end of a file.

It is declared, that if this happens, it indicates a busy device or some other intermittent issue. The program is then welcome to retry the request or to read the remainder with a separate query.

In practice, this means a faulty storage device or a severely stressed system.

Further to that, very few program implement retrying on partial reads and OS vendors fully realize that.

So the overwhelmingly common practice is for the OS to just fail such requests, automatically meaning that a partial read = EOF.

Think different

However "overwhelmingly common" is not 100%.

As it turns out there do exist storage devices that will return partial blocks mid-file if ... the file is corrupted: Technically, it makes some sense - this allows salvaging at least some data from a corrupted block. Practically however this is completely useless unless you are in a data recovery business.

Partial mid-file reads

The first edge case that is now being explicitly handled by Bvckup 2 is that of reading a partial block mid-file.

More specifically, the program will now check that a partial block is the exact tail end of a file and it will raise an alarm if it's not.

Past-EOF reads

As you probably know Bvckup 2 uses async IO and it normally has several read/write requests "in flight".

With the new release, if it detects an EOF of the source file, it will then check any read requests for blocks beyond this EOF location and ensure that they too show the same EOF.

Rapidly growing files

There are cases when being able past EOF marker is actually OK.

If the source file is being actively modified and it is growing very quickly, the program may see an EOF followed by a actual data block, because the latter gets added exactly between the EOF and the second requests.

This is now also detected and reported accordingly.

Rapidly shrinking files

There's also an inverse case - the source file being very quickly shrunk down.

When this happens, Bvckup 2 will see an EOF first. It will realize that EOF is for a smaller file size than it saw when the copying started. So it will re-check the size and the current file size will now be even less than the recorded EOF.

Clearly, this is a mess and it is too now detected and logged.

Will be in release 79.26.

Changes

1.  The program can now automatically recover from any issues stemming from being foricibly closed/killed midway through the mode switch process.

This is different from before where any such recovery, while still always possible, needed to be done manually.

2.  Switching back to the desktop mode now displays a % done for the slow part of the process ( see below ).

3.  The slow part itself was reworked for speed and it was also fully parallelized. The more CPU cores you have, the faster it goes. It can still be slow, mind you, but it is less so now.

4.  Finally, it's now possible to cancel the switch if desired.

The slow part

Under the hood Bvckup 2 is essentially a pair of programs sharing a single executable.

One is the backup engine, which is a module that handles scheduling and execution of backup jobs, tracking of storage devices, dispatching of email alerts, etc.

Another is the user interface module - it talks to the engine, retrieves and displays a list of jobs and allows controlling and configuring them by sending requests to the engine.

Both modules operate independently from each other and communicate through a formal messaging protocol. Similarly their configuration data is also not mixed, with each module using their own directory to store all its data.

When the program is switched to the service mode, the engine module is simply shut down and re-launched as a system service.

Switching back to the desktop mode reverses that - it stops the service and starts the engine inside the UI process. Easy.

But there is one nuance. There always is...

When running as a service, the engine runs under a dedicated user account. This account is a member of the Local Admins group, so it has no problem accessing engine's config files even though they were created under a desktop user account.

However, any files it creates are owned by the Local Admins and they are not fully accessible by the original (desktop) process. So, going back to the desktop mode requires another step - we need to reset the owner on all engine config files.

This issue is further compounded by the fact that the number of files in the engine config can be really quite large.

This is because the engine config is where settings for all backup jobs are kept, and this includes the blockhash data of files copied using the delta copier.

The more files are delta-copied, the larger the engine config will be and the longer it will take for the owner reset to complete. So that is the slow part.

Previously, both manual and scheduled (automated) checks for new versions were treated the same, so it wasn't possible for an installation to retrieve a freshly released update until its IP address was included in the newest channel coverage.

With this change, gradual roll-out provisions now apply to automated checks only. Manual checks will now always be served through the newest channel. They will also override Symantec-specific processing if one applies.

For detailed description of gradual roll-outs, update channels, Symantec-specific handling and available configuration options see this post.

In earlier releases volume information was queried in an ad-hoc fashion, when it was needed or when it became stale.

This release gathers all this functionality in a single place, adds support for tracking device information and improves detection of changes to network drives.

It also reworks processing of Windows device notifications, which are the "pings" sent by the OS when devices arrive or depart, volumes get mounted, locked, formatted, renamed, etc.

The program is now capable of sourcing these notifications from more than one place, which gives it a fallback option should the default notification source stop working ... at least until you get to reboot that WS2012 instance.

TrueCrypt

Storage tracking module includes explicit support for TrueCrypt volumes. This is notable because TrueCrypt does not implement all required volume notifications, making it impossible to track volume activity via standard means.

For example, a system service will never receive any alerts for TC volumes being mounted or unmounted.

These quirks are transparently accommodated. It all just works as expected.

Under the hood

New code comes from Diskovery, a storage inspection tool that we first released back in 2016 and have been steadily improving ever since.

In fact, the plan has always been to use Diskovery as a testbed for all things storage-related and then fold them into Bvckup 2.

And so we are now at exactly that point - all hard-earned Diskovery smarts are now being merged into Bvckup 2.

Staged merge

First, with this release the program gets access to raw device information, which is vastly more detailed and accurate than what's available through conventional Windows APIs.

Next, we'll be enabling the monitoring of device SMART status and tracking of SMART attributes. The code that supports this is ready to go, it's now only a matter of pacing the merge through its stages.

We are also on track for adding previously announced UI support for the storage monitor to the next major release, R80.

Stay tuned for updates.

The way the delta copying works is that it relies on block hashes saved from the last file update to detect which parts of the file changed since then and copy over only these modified blocks.

This means that the actual delta part of the copying kicks in only on the second update, because when we are copying file for the first time, we don't have the block hashes yet. Once the file is copied, we have the hashes and all set to do the delta updating.

This inability to detect block changes on the first run is not a big deal. Most of the times we are adding new files to a backup and these need to be copied in full anyway, so we do just that and initialize their delta state at the same time.

However, when taking over existing backups, it presents a slight problem.

Consider the case when you spent a day copying a very large file over a slow link to an off-site storage. Then, you created a backup job to handle all further updates.

If you are to touch the file now and run the backup, there'll be no block hashes yet, so the file will be re-copied in full. If only we could somehow initialize the delta copying state without copying a file...

Enter delta state pre-comp

Release 79.13 adds support for pre-computing block hashes for all files in the backup that qualify for delta copying but not yet have the delta state.

That is, if you put an existing backup under Bvckup's control, you can now flip a switch, do a quick run and then have all files ready for delta copying on their first update.

† Quick here assumes that your source is local, reads are cheap and writes are expensive, which is how the setup should be for making full use of delta copying benefits.

The screencap above shows taking over a Debian VM backup that is initially created by just copy-pasting VM folder in Windows Explorer.

Running a backup executes delta pre-comp for .vmdk files and patches up "created" times on backup items - all without writing a single byte to destination.

There's now Check for updates option next to the version info, which is automatically displayed as Newer version is available notice if there was one seen at some point earlier on: The window also got a separate Validity field, which is used for displaying remaining trial time and also for confirming that all production licenses are in fact perpetual.

If you want to have a day worth of hourly backups, you'd just point them at ...\%HOUR%, and just as if by magic backups will go into ...\00, ...\01, etc. depending on the current hour.

For a year worth of weekly snapshots just use %WEEK%.

%DAY_OF_YEAR% will give you a year of dailies.

%DAY_OF_WEEK% - a week of dailies, and so forth and so on.

One caveat is that when the backup destination switches to a new folder, it will invalidate destination snapshot and require a full destination rescan.

Similarly, it will also invalidate delta copying state, so actively modified files will end up being recopied in full on their next update.

Finally, since no good feature is truly complete without a way to shoot oneself in a foot, be advised that the same set of variables can be used in ther source path as well.

Internally, this is done very simply.

When enabled, this option will cause the backup engine to use a much smaller count of memory buffers to move data from A to B.

* It is also perfectly possible to throttle disk load dynamically by looking at the actual disk performance and by yielding IO capacity to other programs when required. This is planned and it will be coming with later releases.

The change itself is that we will continue providing maintenance updates for free, while the access to new features will be free for one year and an optional paid extension after that. The one year starts from the moment of licensing an installation. All major releases within one year window are included, each of which coming with a lifetime of maintenance updates. The paid-for option will extend the access to feature releases for another year and will be priced as a smaller percentage of the original license cost.

Basically, the bugfixes are on us. The new features, should you need them, are at small cost after the first year. If you don't find any new features useful, you will be able to keep on using your existing release that will remain fully functional and supported.

Finally, all legacy licenses (of Personal and Professional types) will continue receiving all feature releases free of charge, just as they do now.

Questions or comments? Post them here or send them privately.

†  Some conditions apply

First, this is enabled only for files that are delta-copied, because all resume-related data is saved with the file's delta state.

Second, the source file must remain unchanged between the attempts (as witnessed by its size and timestamps). Because if the source changes, we don't know where the change was, so we must start from the beginning.

Third, the destination file is, obviously, expected to also stay the same, but that's a more general requirement for the delta copying as a whole. Touching target file between the runs will automatically invalidate its delta state and trigger a re-copying.

* For people lacking certain excitement in their lives it is possible to suppress the last check. Inquire within for details.

In addition to recording how far it went in the source file, the ultra copier also remembers the reason for aborting a copy. Three main reasons are the read errors, write errors and user cancellations.

In case of read errors and user cancellations the copier gets a chance to shut down the copying process in an orderly fashion. This ensures a consistent state of the backup copy, so in these cases the copying is always resumable.

In case of write errors it depends.

Recovering from write errors

If we are to yank out an USB drive while it is writing data, the state of the backup copy will be somewhat uncertain. Ditto for the network copies when the router decides it had enough for the day and dies.

So when we are resuming after a write failure, we need a way to ensure that the state of the destination file is consistent with our (or rather delta copier's) view of it.

Ultra does that by keeping track of file ranges that it successfully updated on the last run in a form of a write log. However since we are resuming after a write failure, some of these writes may actually have never hit the storage media even though they were reported as "completed". This is due to all the caching, lazy-writing and outright lying that modern drives do to improve their performance.

For this reason when resuming after a write failure the ultra will go through the write log, read respective parts of the backup copy and check their hashes against those stored in the delta state. If there's a match, we are in clear. Otherwise, it's a block we need to re-copy.

The earliest non-matching block from the write log gives us an adjusted resume point. Simple... with a hint of elegance.

So there you have it...

1.   Faster bulk copying  #
2.   Faster delta copying  #
3.   Resuming support and error recovery

All courtesy of the new ultra copier. Coming to an update server near you in a few days...

Quick recap

Delta copying is a way of updating files whereby only blocks that changed since the last update are copied over. When files change, more often than not they change only here and there, in an isolated manner. This makes delta copying a godsend for backing up all sorts of large, slowly changing files from large RAW photos, to database files, to VM images and encrypted file containers.

If you are familiar with rsync, it is based on the same idea to derive the same speed benefits. However where Bvckup 2 differs from rsync is how it does change detection.

Detecting changes

The recipe is simple - split the file in large-ish blocks, compute block hashes and then see if the hash changed from the last time we looked at the file. If it did, we got a modified block, so we copy it over.

We still end up reading a file in full, but we save time on being selective with writing, which is usually an expensive thing to do.

Bvckup 2 works by saving block hashes between the runs and then using these as a reference point on the next update.


This requires only basic IO access to source/backup copies and some local space to store the block hashes. That is, the delta copying works with any storage devices that are accessible for reading/writing.

*  In comparison, rsync requires a copy of itself to be running on receiving end (that's when copying over the network). It doesn't require any interim storage, but it ends up reading both source and target files in full. This makes rsync poorly suited for local copying and it also explains the r in its name.

False negatives

It is possible that two different blocks of data will have the same hash. This is a so-called hash collision.

With delta copying if we ever run into a hash collision, we will end up skipping a modified block ... which is something we most certainly don't want to be doing.

Avoiding false negatives comes down to reducing the chances of running into them on a real-world data. This is done by using cryptographic hashing for its avalanche effect - a property that causes a hash to change drastically in response to small changes to the input.

Using longer hashes is another option.

And using multiple hashes computed with different algorithms is yet another one.

Old delta setup

From its very first public release and up to Release 79 the program used the following delta copying setup:

Block size	32KB
Block hashes	MD5 + a variant of CRC32
Full-file hash	SHA-1

This yields 20 bytes of hash per block, meaning that the delta state of a file is about 0.06% of its size.

Full-file hash

In addition to hashing individual blocks, delta copier was also computing a SHA-1 hash of the whole file and storing it with the delta state.

The purpose of this hash was to catch cases when no modified blocks were detected but the full-file hash changed.

That was *not* a very good idea. It added very little in terms of the false negative protection and it created a bottleneck.

See, SHA-1 can't be parallelized. In fact, very few cryptographic hash functions can be and they all expect to be fed blocks in sequence, one by one.

This means that performance of the delta copier was effectively bounded by the speed of SHA-1 on a single CPU core.

For mechanical drives it's usually not an issue, because they are quite slow. But SSDs and NVMe drives can be read faster than we can hash what we get from them:

HDD	Seagate ST9500325AS	70.5 MB/s
HDD	WDC WD5000LPVX	118.8 MB/s
SHA-1	Intel i3 @ 2.53GHz	332.4 MB/s
SHA-1	Xeon E5 v4 @ 2.10GHz	380.1 MB/s
SSD	Samsung T3, USB 3.0	429.7 MB/s
SHA-1	Intel i5 @ 2.70GHz	520.9 MB/s
SSD	Samsung 860 Pro	534.8 MB/s
NVMe	Samsung MZVPV512HDGL	2157.9 MB/s

*  These are read rates for the drives and bulk rates for SHA-1 using a well-optimized implementation.

So the full-file hash is a bottleneck and it should be eliminated, which is exactly what the ultra copier in delta mode does.

New delta setup

Starting with Release 79 the delta copying uses a larger block size, replaces MD5 with Blake2b and compliments it with two weaker, but very fast hashes called xxHash and spooky.

Block size	64KB
Block hashes	Blake2b + xxHash + Spooky
Full-file hash	-

Per-block hash size is now 32 bytes - 16 from Blake2b, 8 from xxHash and 8 from Spooky, but the blocks are twice as large, so the ratio of delta-state / file-size is actually lower, ~ 0.05%.

Impact on performance

Block hashing is now noticeably faster:

MD5	595.4 MB/s
SHA-1	561.9 MB/s
SHA-256	247.4 MB/s
SHA-512	391.4 MB/s
Blake2b	762.3 MB/s

Non-crypto hashes, xxHash and Spooky, are running at 10.8 GB/s and 11.7 GB/s respectively. That's gigabytes per second, so these hashes effectively come free of charge.

But more importantly, we are no longer constricted by the full-file hash, so we can push these 762 MB/s per core.

*  Numbers are obviously specific to our test machine, but they give a good idea of relative performance of the algorithms.

The net effect of these changes is that the delta copier now can fully saturate an IO of a very fast drive while using just a small handful of hashing threads.

This in turn means that delta copying now comes with virtually no performance impact even when it ends up copying files in full. It basically goes as fast as a regular bulk copier.

An example

Copying a 16 GB file from an NVMe to an SSD drive using the old delta copier vs the new one:

	Release 78	Release 79
Creating	262.8 MB/s	547.2 MB/s
Updating	272.5 MB/s	2026.6 MB/s

Copying file afresh now runs at the write speed of the target drive and updating it afterwards (with little to no changes) runs at the read speed of the source drive.

Needless to say, that's a huge improvement.

Next up is the part 3 of the ultra copier series. It covers resuming of interrupted copies and fast error recovery.

Prior to this release the engine already maintained a list of so-called fatal errors that causes a backup to be aborted if any of them is encountered.

These are errors like Disk corrupted or IO device error and they signal an unrecoverable condition that will cause all remaining backup steps to fail the same way.

Network-related failures were also on the list, but now they've been moved on a separate list of retryable errors, for which the engine is, basically, "trying harder".

The UI will still show a total error count in the job's summary, but it will render it in black if all errors were recovered from by retrying. See the In action screengrab for details.

The retry count and the pause interval are configurable, but the 20 x 15 sec default should work well in most cases.

It's also possible to add/remove error codes to both fatal and retryable lists, so if you ever need to retry on, say, Disk full, you can certainly do that too.

Smaller files

Copying lots of small files quickly is a challenge.

The per-file overhead of prep/post work is often comparable to the time needed for the actual copying. This fixed cost is split between program's own overhead and the time spent actually opening and closing files, copying meta info, etc.

With older drives this was not an area worthy of optimization, because the cost of merely opening/creating a file dwarfed that of any prep work that the app itself was doing.

However with newer drives and faster machines it's no longer the case. All that trivial activity like allocating buffers, writing to the log, pre-configuring the IO - it all suddenly adds up and starts to matter.

For this reason the ultra copier now aggressively pre-allocates, caches, recycles and otherwise streamlines the prep/post phases to keep its per-file overhead to an absolute minimum.

The effect of this obviously varies, but it can be as eye-popping as a threefold speed-up, for example, when cloning C:\Windows on an NVMe drive.

Faster drives

Bvckup 2 has been using multi-buffer async IO from its very first release.

The core of the technique is that the program doesn't wait for read/write requests to complete, but it rather just queues them with Windows and later checks if they are done.

That last bit - check if it's done - is where the new code does things differently.

Ultra's IO pipeline is built around IO completion ports (IOCP) which it uses to track, well, the completion of IO requests.

The program issues read/write requests as before, but it also asks Windows to queue a "done" notification once a request is completed.

This queue is called an "IO completion... port", which tends to muddy the waters somewhat, but it is one of more elegant and useful mechanisms of the Windows kernel.

The key point of IOCP is in the last line: With IOCP we no longer need to drag the full list of pending requests across the userspace boundary just to learn which of them might've been completed.

This makes IOCP really quite fast.

But wait, there's more.

IOCP can also accommodate async non-IO operations.

The ultra copier makes a full use of this when delta-copying a file. It feeds a stream of block hashing requests to a pool of worker threads and then receives their completions events via the same port that it uses for IO requests. This allows for uniform handling of all async operations in the IO code. Reading, hashing and writing now become equal parts of the IO pipeline, leading to a simpler code.

Synchronous IO

There are documented cases when async IO requests may complete synchronously. In fact, Microsoft also says that your code should be prepared for this to happen at all times.

We care about synchronous completion, because it makes the pipeline stutter, so it's not good for performance.

When this happens, Windows still queues an IOCP notification, so the simplest thing to do is to ignore how request completes and just wait for an IOCP ping.

This however adds a small delay to the IO flow, because we end up completing a request later than we could've.

You probably see where this is headed and you are correct - the ultra copier suppresses IOCP pings for sync reads/writes and processes them immediately.

If you ever wondered what SetFileCompletionNotificationModes is for - here you go, now you know :)

Locked IO buffers

Among smaller performance tweaks, the ultra copier defaults to using unbuffered IO when reading larger files. Larger files aren't likely to be cached in full, so bypassing the cache has a small, but noticeable effect on the reading speed.

There also happens to be a way to further improve performance by locking IO buffers with SetFileIoOverlappedRange.

    * Some conditions apply

In particular, this requires holding a rather exotic privilege and it just may lead to memory starvation for the rest of the system. Ask me how I know.

But when used with care it does appear to improve bulk IO rate on faster drives.

Next up, the delta copying improvements.

May 2013: Jun 2013: Sep 2013: Nov 2013: Nov 2013: Feb 2014: Aug 2015: Dec 2017: The original plan was to switch to the last style, but after testing it on live data it proved to animate very poorly. When IO buffers are large (which is common) that nice right-to-left sliding animation turns into a jumpy-jerky movement which is plain confusing.

In any case, here's a version that made it into R79... ...though that's certainly not the final word in the progress bar saga. Far from it.

To that end, it spreads each sample across several horizontal bands, each displaying a count of full GBs, MBs and KBs, plus "leftover" bytes in each sample.

If we want to display, say, 12345678, then it's 11 MB + 792 KB + 445 bytes, so the band closest to the zero line shows a bar filled to 445/1024, the next band - 792/1024 and the 3rd - 11/1024.

This is basically a mod-1024 factorization of a sample value.

It is also a discrete (rather than continuous) variation of a log scale, which is very commonly used for "squeezing" large values into more manageable ranges.

In practical terms this allows us to quickly see how different any two samples are, even if they are very large.

For example - These two samples are both in the MB range, very close to each other, but looking at the KB band it's immediately obvious which one is larger and approximately by how much.

This sort of analysis is often needed when trying to spot jitter that is order of magnitude smaller than absolute sample values.

In our case, this need surfaces when analyzing the effects of OS file caching on bulk IO performance.

Here's a 16 GB file being copied using Windows Explorer: Here's the same file being copied with a custom, somewhat better optimized code: * Both tests are run with the file cache purged.

Windows Explorer makes uses synchronous IO that goes through the Windows File Cache. This delays writes and it also adds jitter to read operations.

In comparison, the second graph is for the code that uses asynchronous IOCP-based copying engine that bypasses the OS cache. The resulting data flow is far more stable and predictable. It's also substantially faster.

Download

Here's a dev build if you feel like seeing this thing in action:

io-monitor.exe
~ 72KB, no dependencies, signed. Just save somewhere and run.

It defaults to monitoring of the C: drive, but another drive can be selected by clicking on "Disk C:". The sampling rate is 500 ms and it is fixed for now.

The Purge cache option will clear the so-called Windows Standby List, which effectively empties the OS file cache. Use with care, obviously.

Happy graphing :)

The storage stack scanner is adapted from another project of ours called Diskovery and the IO profiling logic is based on the data gathered through CCSIO Benchmark.

While the scanner part is anything but trivial, the most time-consuming part, as per usual, was the UI.

There's a lot of information to be displayed - both the properties of volumes and devices, and how they relate to each other.

As you likely know, a device may host multiple volumes and a volume may span multiple devices. So in a most general case it's a full-mesh, which is the reason why we can't display volumes and devices as a simple hierarchy.

So, after going... ... through ... ... some ... ... options ... ... it became obvious that having two lines per entry was a way to go and that volumes and devices should be on separate lists, both visible simultaneously.

After a bit more sketching the lists arranged themselves into two columns and the scroll bar of the left list went to the left of it: * I must say that the idea of placing that damn scroll bar on the left took waaay too long to converge to. For whatever reason it's just a strangely un-obvious thing to do...

In any case, the result is a layout where we can display relations between volumes and devices with literal, drawn links.

After that just needed to take care of smaller details like scrolling slits... out-of-view arrows... and connector points... and, voilà, we now have something that is both usable and reasonably good-looking. Still to be added is a separate pane for displaying further details - device hardware info, SMART data, etc. This pane will sit at the bottom of the window and will switch between showing volume and device details depending on what's selected above.

Stay tuned for the updates :)

This is a new and improved progress bar that is making its way into R79. The idea is to use the vacant space on the right-hand side (the "todo" part) to show the sub-progress.

In comparision, here's a lively version we have now: _† This is a GIF, trust me.

In Bvckup's case a progress bar also needs to accommodate the delta copying. In particular, the bar should be able to display processed file blocks that were copied in full, copied in part or not copied at all.

So here's a short list of options to achieve just that: Will probably go either with the 2nd from the top or the 5th from the bottom. Maybe both.

It's an older API that doesn't correctly handle inheritable ACLs and its use is not recommended. Not by the API documentation, mind you, but by a random blog post from one of many Microsoft development teams, which you still need to find first. What they recommend instead is Get/SetSecurityInfo.

And you'd still naively think it's the one.

Nope, it's not.

The problem is that SetSecurityInfo will fail with "access denied" if you are trying to set DACL and the file is not opened with READ_CONTROL.

You may wonder why the heck it needs read control... excellent question. That's because it wants to look up the name of the file and then *feed that name into SetNamedSecurityInfo function*. The latter will then re-open the file and start spraying kernel with requests, which is the last thing you need when you are already quite busy with copying a million of files from A to B.

Looking at the trace of SetSecurityInfo with Procmon shows that it generates over a dozen of kernel calls... whereas only one is really needed.

The name of that one call that we want is NtSetSecurityObject, but it's a part of so-called Native API and as such it is officially off-limits for any application use.

However, if we are to comb several pagefuls of relevant APIs, we may spot something called SetKernelObjectSecurity, which looks suspiciously like NtSetSecurityObject.

Long story short, you want to copy security attributes - use Get / SetKernelObjectSecurity. So now you know. Congratulations :)

The answer is that alt. streams is as a generic and more flexible replacement for an older "extended attributes" mechanism. It is meant for the cases when you may want to pin an extra bit of info to a file (or a folder), the info that is application-specific, but that doesn't belong in a file itself.

The book example is a small tag that browsers add to executable files downloaded from the Internet. This tag is used by Windows Explorer to show its "Ugh-oh, something from the Internets" warning when you are trying to run such files. The tag is stored as an alternate stream called Zone.Identifier. You delete this stream - you won't get the warning.

Long story short, Bvckup 2 now can replicate these secondary data streams. This option is in Backup Settings > More Options > Copy Also section and it is Off by default.

•   File attributes are out.
•   Owner and Group are now a single multi-state option.
•   DACL is now called Security info.
•   SACL is now in, as Auditing info.
•   Alternate NTFS streams are in as well.

The rationale behind File attributes option removal is that it was the only one from the list that was familiar to non-professional users. That instilled a false sense of confidence when looking at other options, enticing to tick them all on.

From now on the list comprises exclusively... erm... alien-looking stuff, so hopefully this will deter people from randomly enabling options they should not really be enabling. This also lets those in need of a complete replication configure it now directly in the UI.

First, let's look at how this can be done conventionally. We'll just be verbose about it and list all the options as is: This is OK in terms of usability, but when taken as a part of the whole it makes window look cluttered: And *unnecessary* cluttered at that, because in a vast majority of cases Owner and Group will be either both checked or unchecked. Ditto for Security and Audit options.

So let's try something else.

Windows natively supports something called "3-state" checkboxes that can be in checked, unchecked or indeterminate states. "Indeterminate" is a rather strange term as if the program is not sure in which state the option is. However we can think of it as an in-between or partial state and do something like this: This is not bad, however we lose the overall meaning of the option when it is in a partial state: So let's put the context back: Better, but now we are back to things being too verbose and looking cluttered. Let's simplify it for two most common cases: Better, but now it's off visually: How about with chop the specifics and move them to the side: Almost there, just need to patch up visual hierarchy a bit to help telling principal parts from the secondary ones: And that's it. The result is an UI that looks clean and simple for two most common cases, fully supports marginal ones and packs 4 options in a space of two.

In pre-78 releases if you excluded a folder, you weren't able to then go and include some of its subfolders or files. Similarly, it wasn't possible to exclude some of the items in an explicitly included folder.

In fact, it wasn't possible to exclude anything at all if using the Start with an empty list mode or include any item when using the Include everything option.

While this approach mapped on a simpler code and sort of made sense when it was first coded, in retrospect it wasn't that good. So, R78 will come with a fundamental overhaul of the filtering module... and whatever new and exciting bugs that may come with it.

What the middle pane now does is it allows quickly setting the action (include or exclude) for folder and files by simply clicking on them. For files the action is final - if you exclude it, then it is excluded. End of story.

For folders however it also sets a default action for all its files and subfolders. This action may be overriden for any item by clicking on it, which simply reverses the default. So when bvckup2 looks at what to do with any given file or folder, it will first pass it through this set of filters, yielding a preliminary include or exclude action.

Next, the item will be passed through generic filters, from the bottom pane. First hit on any of these determines the outcome. If there are no hits, then the default action it is.

There are also new, finer controls over the filtering flow. In short - it's now possible to mark any generic filter as final, which will suppress generic filter matching for all folder contents.

Bonus material

If you are to think about all this for as looong as I have, you might realize that the Include everything / Start with an empty list selector at the top, this one - is actually no longer needed!

All it does is merely sets the default action for the top directory - and we may just allow doing that by simply clicking on it in the middle pane.

However I think having it a separate option helps making the UI a bit more approachable and easier to use, so it will stay.

1. Log files are created by the backup engine, but displayed by the UI module. In desktop mode this is easy enough to handle, but in service mode the engine runs in a process of its own and under a different user account, meaning the logs are simply inaccessible to the UI.

So what ends up happening is that the engine opens logs on behalf of the UI and passes open file handles back to it.

PS. Ever wondered what all those "process" handles are doing on the DuplicateHandle() argument list? Exactly to allow one process to do something privileged on behalf another process.

2. Log files are rotated, so what you see in the UI is actually a seamlessly glued together list of all log entries across all copies of a backup log.

This would've not been a big deal if it weren't for...

Finally, the UI needs to expand/collapse log parts and do it nearly instantaneously. This is a hard problem, especially considering that logs can grow very big.

As the engine writes out the logs, the UI scans them and creates an auxiliary index, which it then uses to quickly understand what should and should not be shown in any given state.

These ndecies cannot be kept in memory, not in full. Instead the UI stores them in a specialized on-disk database, which too needs to be very quick.

However, all this complexity had a nice little side-effect. It made adding the Error view very easy.

All the UI had to do is to build another index and include just the error entries and their immediate context. This way switching to/from the Error view is a simple matter of swapping one index file for another. That's it.

This might not be the most exciting thing ever, but still has some elegance to it, doesn't it?

Blinkety-blink. Here's a slo-mo in all its glory: So after killing several hours on trying to make it behave, it became clear that it's faster and simpler to just redo it from scratch.

Not the first time it happened and, sure as hell, not the last :-|

The account is called "Bvckup 2 Service". It is automatically added when the app is switched to the service mode and removed when the app is switched back to the desktop mode or uninstalled.

The account is made a member of Administrators and Backup Operators groups, which gives it the same set of privileges as provided by the LocalSystem account.

Ideally, it should've only needed Backup Operators membership, but in some cases this group lacks network access privileges, so the default is to add it to the Administrators group as well.

It is still possible to install the service under the LocalSystem account - click the More button at the bottom left of the Switch Mode dialog and flip the Run service under option.

This change has been long coming as it's an altogether better and tidier setup. It helps isolating Bvckup 2 from the rest of the services, eliminating effects of any custom LocalSystem policies that might be in place and it also allows for a fine-grained control over its permission set. So if another Windows update comes out and (again) breaks things, it should be much easier to hammer it all back in place.

In comparison, here's the existing version in all its one-page glory:

Please note that this feature is currently reserved for site license and larger resellers only, and it is enabled on a case-by-case basis.

In any case, the next maintenance release (76.5) will get ejection support, but without the UI part. It will be possible to set it up with a good old INI file edit only.

Then, next full release (R77) will get the UI support and above sketches are for that bit. The tricky part is that ejection settings are ultimately per-location preference, so they are needed for both source and destination drives and this takes 2x of screen estate to accommodate.

Secondly, ejection is available only for local drives and not network shares, so the Option 2 series aren't really good. They all allows enabling ejection for non-local drives, meaning that we have to do extra "sanity checks" and error messaging when validating backup settings. That's just... messy.

In comparison, Option 1 simply doesn't show ejection option for non-local drives, just like it doesn't show device tracking (the pushpin icon) in that case. So it's tidy and logical.

• Top three vendors - Seagate (19%), WD (18%) and Samsung (12%)
• 219 HDDs and 58 SSDs - 79% and 21% respectively.
• The only SMART attribute present in all SMART reading was #12 - the power cycle count.
• All but one device also reported power on hours and reallocated sector count .
  
  This is good news, because the "reallocated" attribute (#5) is the principal predictor of an imminent drive failure. Once you see it starting to climb up, it's time to change the drive.
• The temperature attribute (#194) was reported by 71% of HDDs and 51% of SSDs. However some devices report temperature readings in different attributes, so these percentages may be off.
• Attributes in the 17 to 159 are unused (with an exception of one SSD that reports something #64).
• Lots and lots undocumented attributes. Some vendors have incomplete specs and others (e.g. Seagate) just don't release SMART specs at all. This means that we can't even label some of the attributes.
• Lots of inaccuracies in the specs too, meaning that it's hard to reliably interpret the attribute's raw values.
  
  Raw value is a 6-byte sequence of vendor-specific data, so you *must* have a spec to understand them. And you do want to understand them, because that's where the actually interesting data is.
  
  Regrettably some specs would say that it's just a 48-bit counter, whereby in reality it'll be a 16-bit something followed by a 32-bit counter. Furthermore, certain vendors (e.g. Kingston) tend to change the format not just between their product lines, but between sibling products that are just a model away from each other. It's really quite nuts.

New release is scheduled for the next week, so stay tuned.

After trying this and that, the design ended up converging to a simple More button at the bottom left corner of the dialog that, when pressed, injects additional settings into the dialog.

This is certainly not something new and revolutionary and it must've been done before, but it does feel a bit more natural compared to a more conventional approach of popping up a separate window with all the advanced extras.

Also, the initial iterations had the More button toggle between "More..." and "Less..." when clicked, but it looked a tad too busy, hence the current revision of a simple "sticky" background highlight when in the expanded state.

In a vast majority of cases native UI controls (widgets) work just fine. There's really no point in re-skinning, say, a button unless, of course, your goal is to make it stick out like a sore thumb.

There are however cases when the app needs to display information in a way that is not natively supported by the OS. In other cases, while it might be possible to render the data with a native control, it won't do it well or the result won't look good.

In these cases you have no option but to go with a custom UI, but, luckily, if you start with a need (rather than a quest for bells and whistles) the process is fairly predictable and logical.

Diskovery deals with displaying the bits and pieces of the computer storage stack - from physical drives, to parititions, to volumes, to logical drives and mount points.

These fall naturally into a hierarchy, with each level comprising a list of key-value(s) pairs.

So taking the first stab at the UI, we would quickly arrive at something like this: Primary list of drives and volumes on the left, with details of a selected item on the right, organized into a tree of "key:value" entries.

This is functional, but the right pane is not exactly easy to follow. So the first change will be to tabulate the key-value pairs:
Next, note that items in bold act like section headers, so they don't really need to be collapsible. So we do away with the buttons and connecting lines between top-level items:
This gets us a bit of extra horizontal space and trims a useless, but still actionable UI element.

Next, a couple of tweaks to how we render selected items.

There's no need for any items on the right to be selectable at all, so we won't render a selection highlight in the right pane.

The left pane can use a less jarring selection style, consistent with how Windows itself does it.
Next, we try and improve readability of the data on the right by helping to guide the eye from a key to its value.

The simplest option is the grid lines:
At this point, we take a sip of our cold coffee, squint an eye and assess if we like how it looks.

It's not bad, but we can try something else:
Now, that's not bad either and it has a nice visual consistency with the selection bar in the left pane.

However a minor nit here is that we now have bold items (section headers) paired randomly with row highlights. See how Storage space is on white and Partition table is on light gray?

Moreover, adding or expanding items will cause this pairing to flip-flop, e.g. we add an extra row about Partition table and it now sits on the white background:
That's not a disaster, but we can do better.

The idea is to recognize section headers as such and style them independently:
With this change in place we can just restart the row highlight sequence at the top of each section and all's good.

Next, we apply the same styling to the left pane as it happens to also comprise of sections:
Another sip of coffee, re-squint the eye and the whole thing now looks a bit cluttered and busy.

Easy enough to rectify by adding a bit of vertical padding:
Next, we remove vertical connecting lines leading from section headers to the top-level items.

However, we remove them on the right, but keep them on the left. This is because on the left we have a hierarchy of devices, so connection lines make sense. It also seems to look better this way.
Next, we move the expand/collapse buttons to the right.

In this particular app expandable items contain secondary details that 99% of users will not ever need. These items will also be collapsed by default (even though they are expanded here, but that's just because we are sketching through the details).

This change also helps decreasing the leading pad of top-level items and providing for a more compact horizontal packing of the data.
Alright, so that's about it as far as functional tweaks go. So now it's where it gets subjective. We are going to spruce it up a bit.

It's all about colors, padding and little nuances. If we were designing for the web, it would also involve texturing, but for a desktop app texturing is a sure way to ruin native look and feel.

In any case, moving on - invert the headers from dark-on-light to light-on-dark:
Add a bit of hue to the row highlights, tint their edges a bit and also flatten the look of expand/collapse buttons:
Splice in a scroll bar and make sure our precious design still looks reasonable:
Re-style the left pane to look more like an actual connected hierarchy of disks and volumes. The rationale here is to make it more obvious that items on the left are clickable.
Almost there. Take a final look and adjust vertical padding and spacing to de-clump items a bit more: And here it is. Compare to the starting point and you'd probably agree that there's at least some improvement.

Needless to say, one man's extra vertical padding is another man's complete waste of space, but any customization is always a combination of rational and subjective choices. The former is what gives an app the ease of use and the latter is what give it the personality. Can't have one without the other.

In particular, this happens when a custom domain is used with a managed (shared) mail service. You'd grab a domain, set its MX to mx.domain, add CNAME for mx.domain to point at mx.mail-service and - voilà! - you are served with mx.mail-service cert when connecting to mx.domain.

Ultimately, this is a mail server mis-configuration issue - your MX should really be pointing at mx.mail-service. In theory this shouldn't be happening, but in practice it does.

To address this, it's now possible to specify the exact domain the app should be looking for in an SSL certificate:


In the above example, you'd simply set this field to mx.mail-service and that's it.

To make things a bit easier that app now also helps you to pre-populate this field with the actual domain from the server's certificate.

It does that when you send out a test email and the field is left blank. As you can see from an opening screenshot, the app will recognize the certificate mismatch and re-run the test, accepting any and all certificates. It will then make note of the domain in the cert and copy it into the "SSL domain" field for you.

Finally, setting "SSL domain" to * will effectively disable all certificate checks and force the app to accept any certificate that the server sends, even if it's an expired or a self-signed one.

Earlier versions had general and alert-specific settings mixed up. For example, "From" doesn't really belong to the alert configuration, while "Include" from General Settings does.

This has been sorted out.

A larger picture here is that the app will be getting additional alert types - e.g. for S.M.A.R.T. diagnostics and backup verification - and this requires a proper structure to support these cleanly.

Also, while at it, the UI got a new framework for handling window transitions between different states.

For example, in the above screencap there's are 5 primary states and 2 intermediate ones. Prior to R75 moving window between these states required quite a bit of hand coding. This is no more, so we can now animate the hell out of any window. Consider yourselves warned :)

The year is 2015.

The age of cars trying to drive themselves and rockets trying to land on sea barges. Graphics cards are effortlessly churning photo-realistic images in real-time, mining crypto money and cracking passwords.

And here we have Windows still defiantly refusing to use any of that double-buffering nonsense when re-painting one of its basic common controls. Because who wouldn't want a bit of flickering?

Argh.

The idea is that the config window for specific alert type will give access to both the alert details and general email settings that are recycled between all alert types.

So here are several sketches for organizing page index of a multi-page configuration window. Nothing terribly novel here, it's more just a matter of getting styling details right - make sure it's obvious that it's an index and that its items are selectable.

Option Z (right-most) looks OK, but it's not obvious that index items are actionable as they look like static section headers.

Option Y is a bit better, but the arrow actually points at "From" field and you can bet some people will end up in a stupor because of that.

Option X uses standard Windows white-on-blue for selected item, so it's better in the actionability department. But it doesn't look nice.

Option B attempts to fix that.

Option A attempts the same but using app's own styling of selected items, which is already used in several places in the UI.

Thoughts or comments? There is a thread for that!

All fair points. Fear not, the UI got this covered:

The first iteration was the good old message box. You click on the "More on this..." and you get :


Nice, but looks like a hackjob, does't it? So, naturally, the next step was to spruce it up a bit - put text into a dedicated window, use RTF to add a bit of in-text formatting and a bit of animation to liven things up :


Nice again, looks better, but feels off. Too much going on. It looks like a conventional help window, but ... crippled. It's also not clear how to act when the user wants to resize the window - allow it, not allow it, restict minimum/maximum size, etc.

In short, what's lacking here is the cohesion. Luckily, the solution is right on the surface:


... whereby the text panel slides out on the "More info" click.

This is better, but now we have a window that sits lopsided on the desktop when the panel is open. It is also becoming wide, meaning that the app needs to mind the desktop edges, re-center the window, etc.

But if we just sleep on it, we might suddenly decide to make it an "either-or" window and then the UI magically becomes
(a) compact
(b) cohesive
(c) balanced
  and
(d) with unlimited text space!


So there you have it - a new mini-help subsystem coming to Bvckup 2 in the Release 71, deployed on as-needed basis across the app.

Don't know about you, but I think it's neat, tidy and pretty damn clever :)

VSS writers are the components of the shadow copying framework that are tasked with ensuring consistency of specific files in VSS snapshots. For example, when creating a snapshot, Windows would ask the MSSQL writer to flush any pending database changes in a way that would make on-disk copy of the database self-consistent.

Some of the writers are required and always participate in the snapshot creation process, but some are optional and they need to be explicitly enabled by the initiating app. Starting with R69 Bvckup will be enabling all optional writers and it will also provide a mechanism for excluding specific ones if needed.

Only a very small part of the log is now kept in memory, just enough to fill the log viewer panel in the UI. The rest is kept on the disk and read from there on as-needed basis.

However this is easier said than done.

Bvckup logs are hierarchical, meaning that they are generic trees with nodes that may have an arbitrary large number of children. Running a 1 million file backup would yield a "Processing..." entry with 1 million children, each with up to a dozen of descendants.

Displaying this tree would've not been a big deal if all log entries were always visible at all times. When the UI would've wanted to show entries 700,503 through 700,523 entries, it would've simply gone to a respective location in the log index file and plucked the data out. But...

The nodes can be collapsed and expanded. This hides and shows arbitrary chunks of the log tree and then the UI has this issue of finding 700,503-th *visible* item. And this is hard.

This implies quick look-ups in some sort of super-imposed binary search tree of visible items. A tree that changes every time a node is expanded or collapsed and that sits in a disk file, which restricts how you can walk and modify it without getting an I/O penalty.

This is fun. This is what cost me 3 weeks of shuffling through CS books and several complete rewrites of the tree indexing code. Believe it or not, but this is basically an original research and it seems that no one had to deal with this issue before. At least not publicly.

The solution is to use slightly customized version of an AVL tree to store the list of node's children (that's using tree within a tree), use it for the visible item look-ups and then optimize the hell out of the index I/O through aggressive write caching.

When all i's are dotted and t's crossed, this yields a logging system that can push up to 1 mil entries per second on a resonably equipped box. This might not be knock-your-socks-off impressive, but it's plenty enough for the task at hand.

At the moment Bvckup's UI keeps backup logs in memory. It puts an effort to trim them to a reasonable size, but this still eats quite a bit of RAM, especially with large backups.

It costs about 120 bytes plus the size of an entry to keep a single log line in memory, whereby these 120 bytes help weave entries into a hierarchy (a tree) and track their state.

If we want to reduce the memory usage, then the most obvious optimization would be to keep the actual entry text in a disk file and load it on demand, when it's actually visible in the log viewer.

This certainly helps, but as the log grows, the memory usage still climbs. A million file backup generates about 4 million log entries. At 120 bytes per entry that's 0.5 Gig in just supporting structures. This is unacceptable.

So it means that the entire tree structure of the log needs to sit in a disk file and to be read from there as needed.

Disk-based tree structures are routinely used in databases and file systems to store indecies of data sets, typically in a form of a B-Tree and its variations. The kicker is that these structures are meant for storing sorted data and they optimize for searching. Trying to adapt them for storing unsorted data would be nothing short of fitting a square peg in a round hole.

Long story short - there are no ready-made code for storing and manipulating generic data trees on a disk, leave alone fast code. This appears to be an esoteric problem that everyone solves on their own.

The screenshot above shows a part of a small "tree database" library that I ended up writing, together with its own caching module, predictive page loader and a pony.

Took almost two weeks.

On a bright side though, this code is perfectly reusable for storing disk snapshots as well and this paves way for making the planner module work almost entirely off the memory.

Once done, Bvckup memory usage will NOT depend on the particulars of a backup at all - this a very big deal and an incredibly improtant feature to have for any robust backup software.

So, stay tuned...

Then copy-paste the code, click on Verify, get this -

If this works (the server is accessible, the license code is valid, etc), then this is it. Thank you very much, click Ok, you are done -
Otherwise, it explains the failure and offers either to retry the activation or to use an alternative -
There are two alternatives, both are simple -
For offline boxes and locked-down setups there's the Copy To Clipboard option. Take the URL to a networked machine, open it in a browser, get a licensing file back and then drop it into the app's config folder.

The URL is exactly the same as the one used by the app's own licensing code and it comprises of the license code and installation ID and the fingerprint .

Prepare the email option creates a new email with default email client and puts the Installation ID, Fingerprint and License Code in the message along with some pleasantries. The license file will be attached to the reply and it will simply need to be dropped into %LocalAppData%\Bvckup2\engine.

When the app is started, it looks at several system properties including the CPU model, Windows' MachineGuid value and others, hashes them together to produce an "Installation ID". For example -


The ID stays the same under normal computer use, but it changes with hardware upgrades or when the OS is reinstalled.

The app also generates an "Installation fingerprint" by hashing each of the properties separately and stringing them together. This yields a longer hash -


Like ID, the fingerprint changes with hardware upgrades and OS reinstalls, but, unlike ID, it changes only in parts. This makes it suitable for detecting incremental changes to the user's computer.

Both ID and Fingerprint identify user's installation, the difference is that the ID is used on the app side and the Fingerprint - on the licensing server side.

Next, ID and fingerprint are submitted to the licensing server, either by the app itself or by a human through a website. When licensing for production use (as opposed to beta or evaluation), the request also includes a license code - a random token that is issued to the user in exchange for payment.

The server responds with a license, which is a short text file that binds together few pieces of information and seals them with an RSA signature of the licensing server.


For beta and evaluation licenses the "license code" is generated automatically by the licensing server. The large block of gibberish at the bottom of the license is the RSA signature.

When the app starts, it loads the license and verifies it using public key of the licensing server that is embedded in the app.

If the license is valid, the app works as normal. If the license is missing or expired or doesn't match the installation ID, the app disables certain features and periodically nags to do the right thing and what not.

Now, let say I upgraded my box. This screws up the Installation ID and invalidates the license. The app recomputes new ID and Fingerprint and sends them to the licensing server.

This is where Fingerprint comes into play. The server takes old and new fingerprints, chops them into individual hashes and does a "fuzzy" match. If enough hashes match, we can assume an incremental software or hardware change on user's end and re-issue the license for new Installation ID.

If fingerprints are wildly different, then we make fuss and require contacting human tech support.

In conclusion, needless to say that the whole scheme relies on the validation code in the app being trustworthy. If someone pries the app open and replaces selected IFs with NOPs, then obviously no licensing will work.

The answer to that is that the app should implement self-consistency checks and deploy counter-measures when these checks fail. This is a separate and very large and interesting subject ... which I have no plans on covering here :-) A good starting point here would be fravia.org archives and then follow from there.

This time the next/previous arrows are in the error entry itself.

I like the second option better, because it's contextual and I think it's more obvious. However, first option is superior in functionality because it allows jumping to next or previous error when there's currently no error visible in the pane.

Still deciding...

On program's end, the indicator translates into the "Update is recommended" line. It is one three options with "optional" and "critical" being the other two.

"Recommended" is a routine update that adds this and fixes that. It would better be installed, but it's not the end of the world if it's not.

"Critical" is critical - "you'd be sorry if you don't install it" kind of update.

An example of "optional" update is a new version that updates program's French translation when the user is running an English version, i.e. an update that can be ignored altogether.

There's now also the "View changes" button that expands the window and shows a neatly formatted (RTF) version of the change list.

The biggest deal, of course, is that it's a consolidated list of all changes between the installed and the latest version, rather than a laundry list of all changes since the dawn of time. It makes the list infinitely more useful compared to the raw version.

Significantly improved performance through multi-core, parallel hashing, asynchronous I/O and more aggressive caching of the state data.

Strengthened the change detection algorithm through addition of the whole file hash. When all individual block hashes come back unchanged, the algorithm now uses the file hash to confirm that the file has indeed remained unchanged.

Combined with the original use of two separate hashes per data block, this eliminates the need for a precautionary full-file sync every N copies.

Improved handling of cancelled and aborted delta copies by introducing support for partial updates .

The algorithm now remembers how far along the file it managed to proceed and stashes this information for the next run.

When the copying is cancelled partway through, the file is marked as out-of-sync, but the delta state is updated to capture what has been already done. This comes very handy and speeds things up when updating very large files.

Improved handling of large file counts.

Version 1 maintained an in-memory index of all delta copied files and, surprisingly, this didn't scale well. It also kept all delta state information in a single folder, which too led to some pain and suffering when the file count grew large.

New version eliminates both these problems.

Lastly, all copier parameters - block sizes, hash algorithms, cache buffer sizes, threading parameters, etc. - are now configurable on a per-job basis.

All in all - THIS IS IT.

This is how a simple and efficient delta copying should be done. Can't wait to release it to the real world.

There are two sets of icons on the sprite sheet. The first three columns is the XP style, which is a bit puffy and matches well older Windows styling. The last three columns is a flat version that goes better with native W7 tray icon style.

Each icon comes in 3 sizes - 16x16, 20x20, 24x24. This is needed to accommodate 3 common DPI levels, see this earlier entry for details.

When a program detects that it was just restarted with Admin privileges, it has a limited number of options for communicating this joyous news to its user.

#1 - A message box. Bluntly put - I hate them. They are always too sudden, they steal your attention and stuff whatever they want to say down your throat. They ... lack manners.

#2 - A system tray notification. This is less intrusive, but perhaps it's too out of the way. Also, the systray is a shared area so the program is always competing with other apps for the same screen real estate.

#3 - Something else that is right in your field of view if you are looking at the app, but that doesn't get in a way of whatever you are doing at the moment.

Cue in the message bar, now an integral part of the Bvckup UI. It is used for displaying various status notifications right after the launch, after switching the engine to/from the system service mode, when discovering software updates and few other things.

I have also tried the self-closing version of the bar that dismisses itself on a timeout. Like so -
and so -
but having lived with this for a couple of days, it now seems like a solution in a search of a problem. So I shelved it for now. If there's any a real need for this, it'd be very easy to add later on.

The most unconventional part of the setup is how it handles the configuration of the installation parameters.

The configuration page (see Page 3) is very bare and focuses on how the program is going to be used instead of being a mixed bag of the minute details of the setup.

The target location is made into a secondary setting with its value controlled by the usage preference. There's no field for the Start Menu group name. There's no ever popular "Run the program after the setup completes" option either. Instead, exiting the setup automatically runs the program (see Page 4), unless the installer window is closed through an (x) at the top.

This leads to a simpler and more intuitive setup flow... or at least that's the idea :)

The installer supports both privileged (administrative) and unprivileged (regular user) installations.

If you are logged in as a regular user and have no rights to modify C:\Program Files, there's no reason why you shouldn't still be able to install a software, just for yourself.

While other installers routinely ask if to install the software for everyone or just for one user, it's a superficial question. It merely controls if the Start Menu group is created under All Users or your personal profile. The program files still go into a system directory and this requires administrative privileges.

Bvckup implements true system- and user- deployment, which is akin to deploying the program in /usr/bin or ~/bin in Unix terms.

In fact, on a multi-user system it is perfectly possible to install one instance of Bvckup for each user and they will all happily co-exist with each other.

If the program is not running, then it's indeed a simple matter of replacing the program file with a newer version. The fun starts if the program is running.

On Windows, running a program locks its file, preventing any changes from being made to it. This is not required per se and there are operating systems that don't do this. There are also custom PE loaders for Windows that can take an executable and create a running process out of it without any locking fuss. For example, bo2k could do that back in 1999. See its source code for details if interested.

To complicate matters, there might be more than one process running off the same executable. For example, if several users are logged into a Windows box and each runs a copy of a program.


Therefore, the first order of business for any installer is to shut down all running instances of the program. A well-behaved installer should also restart all these instances after it's done with updating.

The shutting down part is not a big deal. There's more than one way to do this and all of them are fairly straight-forward.

It's the restarting that is contrived.

Not only program instances may be running under different user accounts, they may also be running with custom command-line arguments, as Administrators or system services. Restarting this cornucopia of awesomeness is not an envious task.

Here's how Bvckup works around this mess.

Every Bvckup executable has a corresponding named event in the Global namespace. The event is created by the first instance of the program when it's launched, and it is opened by all other instances.


The name of the event includes the file ID of the executable file. This groups running instances by the file they are using, because, after all, the installer is interested in a specific executable and nothing else.

For example, the following is an event name used by the Bvckup installation on my development box -

Global\Bvckup2.e65a96a8001f000000013cba.Update

With this in place, the installer starts off by signaling the event.

In response, a running program makes a temporary copy of its executable file and starts it in a special "relauncher" mode. And then it exits.

The "relauncher" process opens the "update" event and simply spins there, waiting for it to become unsignaled.

Meanwhile the installer waits for the program file to become unlocked. Once all running instances replace themselves with the relaunchers, the executable frees up and the installer proceeds with the update. It then clears the "update" event and exits.

This releases the relaunchers, they restart program instances and - ta-da - the update is completed.

Techincally, instead of adding a special "relauncher" mode to the program it's possible just to have a small standalone relauncher program. It comes down to a matter of taste. Some people don't like to spawn from temporary executables, and I like to keep my file count to a bare minimum. To each his own.

The header font, Alte Haas Grotesk, didn't display correctly after it was converted to the @font-face kit. Specifically, the lowercase 'o' looked like this:

The font's free, but I couldn't find a copy of its license, so I started tracking down font's author to ask a permission to edit the outlines.

While waiting for a reply, I found another workaround which involved generating the webfont kit from OTFs instead of TTFs. Not a big deal, but it still took over 3 hours to resolve.

The second issue was with the slide-out, fade-in animation. Sometimes the slide-out didn't extend all the way down and sometimes it overshot. This traced back to the fact that slide-out height was computed before the OpenSans was fully loaded and the script fused basic sans-serif to compute the height.

Again, not too complicated, but, again, cost an hour to work through.

:-|
Little bit of this, little bit of that - all unplanned and it all adds up.

Current design is almost two years old and it grew steadily disconnected from the simpler aesthetics I am pushing for now. So it needs to be redone.

I will probably simplify this even further. I've been wanting to do a true minimalist site for a software product for a long time now and this seems like a real chance to do just that. Yay.

Interestingly enough, the total size of individual images saved as 32bit PNGs is 63,127 bytes, while the size of this sprite sheet (without checkered backdrop) is 63,829. After factoring in the size of the code that is needed to parse the sprite sheet, it really becomes a no brainer to keep every image in its own file and embed them into .exe's resources that way.

1. The program now differentiates between three types of errors and handles them slightly differently.

First, there are unexpected operating system errors, i.e. when a core Windows function fails in a way that it shouldn't be failing. Classic example (that everyone is aware of) is TrackPopupMenu that is declared as returning boolean, but actually doesn't shy away from returning an integer under certain circuimstances.

Secondly, there are inconsistencies in app's own code, whereby one part assumes certain usage that is not observed by another part. These are so-called "assert" failures. The original version has three critical issues, all of this particular kind.

Lastly, there are straight-forward crashes. This is when a program is trying to operate with data that is no longer there or corrupted. This is the worst of them all as it typically indicates a major screw up on programmer's part, but in some cases it may also be an indication of failing hardware, like a faulty memory stick.

2. The program now generates a minidump - a small-ish file in a standard Windows format that captures the context of a failure. Minidump files dramatically simplify investigation of a problem on the developer's end.

3. Finally, the minidumps can now be uploaded to the support server right from the error notification window with one click. The transfer is based on WinInet API as this is supposed to improve the chances of getting the report through in proxied and otherwise "enterprised" environments.

For cases when the upload fails, the error dialog also offers an option of opening a link in a regular browser and reporting a problem that way.

Pro: a single executable to distribute
Con: the exe comes out weighing twice as much... or does it?

The size of a 32-bit executable can be easily reduced with the help of tools called executable packers . They work by turning the exe file into a self-extracting archive that also automatically launches the original exe after the extraction. It may sound simple but in reality it involves bundling a custom PE loader with the packed executable (as it might not be possible to extract the exe into a temporary file before running it).

In any case, exe packing is routinely used by developers who care about the size of their products, with uTorrent being one of most notable examples. Original Bvckup was also compressed, owning its tiny size in part to the magic of UPX .

The problem lies with 64-bit executables. For a variety of reasons there are presently no exe packers that support them.

However if we store 64bit binary inside of the 32bit executable and then pass latter through a compressor, we end up with both being compressed. Ta-da!

But there's more.

When an .exe is compressed, the compressor leaves the primary application icon intact. This is done so that the app would keep its original appearance in Windows Explorer and not sport a generic "program" icon.

Starting with Vista, the app is expected to support a variety of icon sizes that quickly add up. For example, bvckup's icon weighs in at about 110KB. That's almost half as big as the actual code, the code that does quite a few meaningful things on top of just looking great :)

So, if we do the 64-in-32bit packaging, we end up compressing 64bit version in its entirety, including its icon, and arriving at a greater size reduction if we were to compress the exes separately.

Win-win.

The message is a homage to NetPositive, the BeOS browser that pioneered the technique of using haiku in error reporting. In fact, the message in option B is from the NetPoisitive original list .

The icon is that of a Zen circle, which has a plenty of meanings, many of which applicable given the circumstances.

Fading animation dissolves a part of a window into background, in preparation for transitioning the window to another state, e.g. moving to the next page in a wizard or resizing the window into a more compact form.

As simple as it sounds, these sort of animation is fairly complex to implement on top of the Windows API.

Windows includes native support for window transparency in a form of layered windows, but it comes with a list of limitations that aren't exactly practical or easy to work, except for several specific cases.

The simplest working solution involves taking a screenshot of the window, creating an overlay window and then using it as a canvas to render the transition from an empty background to the screenshot. All the while making sure that Windows doesn't sneak in an unsolicited window refresh that would lead to a flicker, which in itself is a very "fun" thing to debug.

16, 32, 48, 256 are more or less expected. These are used in "small", "icon", "tile" and "extra-large " views in Windows Explorer.

20, 22 and 26 are possible sizes of an icon used in the window caption. The exact size depends on screen's DPI level.

And 40 (along with 32 and 48) is the size of an icon used in Alt-Tab view on W7, again depending on the screen's DPI.

If you don't provide an appropriately sized icon, the OS will grab one that is slightly bigger and shrink it down, ruining the pixel polish.

Lastly, each icon ideally must be saved in 32, 8 and 4 bits per pixel formats, so to be compatible... you know... with EGA cards

It would've not that big of a deal if it weren't for the size of a resulting .ico file. For example, the above icon ends up being ~ 120KB, whereas the actual .exe it is attached to and that does quite a few meaningful things sits at around 96KB.

DPI stands for dots-per-inch and it's a metric of a pixel density on the screen. The smaller the screen, the more pixels are packed into a square inch, assuming the resolution stays the same. The difference in DPI between a large LCD panel and a 12" notebook screen can easily be a factor of two or more.

This means that if a program renders 9px text on both screens, on one it will appear twice as small as on the other one, and might command a need for a good magnifying glass.

So naturally it's a good idea to make the OS aware of the actual DPI of the monitor in use. If it's too high, the OS can do few things to make things visible with a naked eye again. Like increase size of the default system font and make windows generally larger.

This can be done automatically by looking at the monitor .inf files or by letting the user configure the DPI manually.

XP defaults to 96 DPI and with some difficulty it can be changed to 120 DPI. Vista and newer versions are better. They come with four predefined levels - 96, 120, 144 and 192 - and they also support custom settings.

This brings us back to needing multiple versions of every graphic in the app.

Vista is the first Windows version to routinely use monitor-specific DPI values out of the box. As such 96 is no longer a dominant DPI level and the apps are now expected to take the DPI into an account when rendering their content.

The higher the DPI, the larger the graphics and the fonts the app should use. The penalty for not doing this is an automatic stretching of the app window that inevitably leads to a blurry appearance and a host of other lovely issues .

In other words - not complying with OS expectations is not really an option. Hence the need for 3+ differently sized copies of the same pixel art.