I noted down the following display glitches/inconveniences when performing Disk Resize/Move operations that had to be performed in Exclusive (for the older Generation: DOS) Mode. The Move Partition Bar and the Overall Progress Bar go to 99.9% within the first 2 minutes, and stay there for the remaining 5 hours of the move/resize operation. Better: Change the way those Bar positions are being calculated so that Move Partition Bar and Overall Progress Bar correlate better with the actual progress of the operation The Suboperation Bar stays blank for the whole time of the operation. Better: Utilize the Suboperation Bar for Progress of the various different types of actions that can be witnessed in the Log Window, like pre-scanning of the filesystem, error checking, resizing, editing mft, moving, post-scanning, etc The estimated time to finish starts at 0:00 and from there, goes up continuously for about 95% of the time of the operation, staying between 70% and 150% of the continuously increasing Work Time, not allowing any useful estimation of the time left for the operation. Better: Start estimation at 23:59:59, then gradually decrease the number as more information about the speed of the operation allows a better estimation Work Time Display froze at 02:59:04, resumed at 04:xx:xx. When the Read/Write/Total MB/s drops from xx.x MB/s to 0.0 MB/s due to a bug that appears on all three of them after some time (a few hours) independently, the Time to finish Counter starts continuously counting down (or in very high modulo values, up), for example 23:59:01, 23:04:05, 22:11:26, ..., down to 00:12:53, then flips over to 23:25:42, and so on, over and over. The issue in this case isn't the estimated time (although it might want to be adjusted to prevent the overflow by allowing higher values for hours, or adding a days column), but the Bug that causes the display of MB/s to drop to 0.0MB/s without the actual read/write speed going down at all. In contrast to the frozen Work Time Display, once occured, the 0.0MB/s Display will stay for the rest of the operation and not reset itself eventually. For the Display of the Read/Write/Total GB, a bug is removing leading zeroes from the floating point value after the decimal point. This results in the following values being displayed in a wrong way, for example: Actual Value_____Displayed Value 10,973__________10,97 10,996__________10,99 11,019__________11,19 11,042__________11,42 11,065__________11,65 11,088__________11,88 11,111__________11,11 11,134__________11,13 That's it for now, hope it helps improving the product.