I've spent some time on this today -- in fact the past 2 hours -- deep in IDA. This is absolutely a bug in Defraggler, specifically the text strings referenced/compiled into the program.
Let's start with the string that's shown on a drive when clicking "Analyze" -- the string should show "Analyzing (xx%)", but instead shows the left paren as being messed up on XP. Defraggler uses (mostly, but not entirely) Unicode strings. That's important to note.
For whatever reason, the program splits up the string into two portions: "Analyzing" and " (xx%)" (note the preceding space). I've hyphened-out the bytes that don't matter.
The "Analyzing" string is at the following file offset, and is a Pascal-style Unicode (UTF-16) string, meaning the string length is stored first (16-bit value; 0x09 = 9 bytes long), followed by the string itself. It's not a C-style string (zero-terminated).
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00274D30 – – – – – – – – – – – – – – 09 00 …
00274D40 41 00 6E 00 61 00 6C 00 79 00 7A 00 69 00 6E 00 A.n.a.l.y.z.i.n.
00274D50 67 00 – – – – – – – – – – – – – – g…
As for the " (xx%)" string, it's quite different: it's Unicode (UTF-16), C-style (zero-terminated), and printf()-formatted:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
001DAD00 – – – – – – – – 20 00 0E 20 28 00 25 00 … … (.%.
001DAD10 2E 00 30 00 66 00 25 00 25 00 29 00 – – – – …0.f.%.%.)…
Notice how I didn't hyphen out the first 4 bytes.
Defraggler's code actually considers all those bytes to be the start of the string. See my IDA screenshot for proof (the "DATA XREF: sub_579750+C1" part). So let's decode these bytes a pair (UTF-16) at a time:
0x20 00 = Unicode 0x0020 = Space
0x0E 20 = Unicode 0x200E = Left-to-right (LRM) character
0x28 00 = Unicode 0x0028 = Open parenthesis
0x25 00 = Unicode 0x0025 = Percent symbol
Left-to-right (LRM) character -- http://en.wikipedia....t-to-right_mark
For sake of comparison, if you were to change the first 4 bytes to 0x21 0x22 0x23 0x24, you would get this:
0x21 22 = Unicode 0x2221 = Measured angle character
0x23 24 = Unicode 0x2423 = Open box character
0x28 00 = Unicode 0x0028 = Open parenthesis
0x25 00 = Unicode 0x0025 = Percent symbol
Measured angle character -- http://www.fileforma.../2221/index.htm
Open box character -- http://www.fileforma.../2423/index.htm
So what happens if we hex edit the Defraggler binary and use those bytes? Take a look at the screenshot. The measured angle character gets rendered correctly, but open box just shows an empty square/box. But if you look on the web, it'll show up as what looks like the bottom half of a box... So what gives?
This is where fonts and how the OS tries to correlate Unicode characters with specific glyphs in fonts comes into play. Windows 7 does a better job of this (no argument), while XP does a so-so job. On XP, its basically referring to the font Microsoft Sans Serif and looking for Unicode character 0x2423 in that font -- there is no such glyph. For unknown characters, XP tends to print an empty square/box like you see in the screenshot. Windows 7 does a better job of truly trying to find something that has the open box character.
So what's all this mean? It means that the LRM character, when shown in Microsoft Sans Serif, for whatever reason ends up drawing something that ends up affecting the subsequent left parenthesis being drawn.
You can complain/bitch about XP not doing decent Unicode-to-glyph mapping and sometimes showing weird stuff -- that's fine. But it doesn't change the fact that Defraggler obviously has a bug in its data/text tables.
So is there any way to temporarily fix this nonsense and ensure it'll work fine on XP and 7? Absolutely, but it's extremely tricky. The simplest and safest way, without risking breaking the entire text printing/concatenation/lookup routine is to changing the two bytes 0E 20 to 20 00. That would turn the LRM character into a whitespace. The downside is that the text routine still points to the previous 2 bytes, so you get 20 20 20 20, which is two whitespace characters. And sure enough that's how it displays. See my 3rd screenshot for proof.
One might think "well couldn't you modify the code to instead start 2 bytes ahead of where it's told to start?" Yes, but that could have dire repercussions; I imagine this routine is used by other areas in the program, referring to text strings which are actually correct.
Thus, the only real solution is to have Piriform actually fix the bug properly. And if they fix it, it'll work fine on XP as well as 7.
The other strings, such as the one for "Fragmented FIles (xx.x GB)" have the exact same problem, thus they need to be fixed too. I'm not going to go into details on how to fix those because the bug has been analysed at this point.
Snarky footnote comment: so the next time you consider telling an engineer/programmer "it's a bug in XP", reconsider. I shouldn't have to spend this amount of time reverse-engineering something (do you know how long its been since I've done x86 assembly?) just to show that the bug is in fact within Defraggler.
And furthermore, just because something doesn't happen within a different OS doesn't mean there isn't a bug. Windows 7 just does a better job of hiding it. Fix the bug. :-)
![post-46924-0-52539200-1341623340_thumb.png]()
![post-46924-0-97550600-1341626028_thumb.png]()
![post-46924-0-12762600-1341626034_thumb.png]()