Open/left parenthesis appears wrong

[koitsu]

Preface: this requires folks with a good eye. Many developers and users alike often miss things like this, but I tend to notice them. Call it OCD if you wish, but it's still an issue/bug. :-)

 

It appears that the open parenthesis character ("(") being used in the Status area after doing an Analysis is either using a different font than the rest of the user interface, is using a very unique/strange point size, or there's some kind of GDI drawing error happening.

 

Look at the text under the Status section, under Analysis Complete. Specifically the text "Fragmented Files (31.6 GB)". See defraggler_open_paren_01.png.

 

Notice how the open-paren appears corrupted in some way; very strange, but consistently happens and only in this area of Defraggler. Furthermore, the issue is not specific to fonts on my system (e.g. corrupted filesystem, disk issues, etc.); see fonts.png for what different fonts look like and different point sizes.

 

The same oddity happens when clicking Analyze on a drive, where there's a progress indicator in the Status window which says "Analyzing (%u%%)" (programmers will know what this printf formatter is). See defraggler_open_paren_02.png for validation. The problem is also visible in the upper-right of the application under the Drive area when doing Analyze; meaning there is a consistent string with this problem that is being used universally.

 

The problem does not happen with strings like "Quick Defrag (%u%%)"; the left paren appears fine there.

 

From what I can tell based on looking at the underlying dialog and string resources within Defraggler.exe, MS Shell Dlg is used as the font in most dialogs (if you aren't familiar with this, here you go), and I can assure you that works fine on my system. MS Shell Dlg should correlate with Microsoft Sans Serif on my system. However, it is quite obvious that the font being used for string output for "Fragmented Files (%3.1f GB)" is Tahoma, so that would be something within your code that's forcing that. But again: Tahoma also looks fine on my system.

 

I'm still scratching my head over what's going on here. I would have to disassemble the program and reverse engineer it to figure out what was going on; a lot easier to just ask here. :-)

 

Happy to work with you in any way/shape/form to figure this one out. Thanks.

[koitsu]

One other thing: while reviewing the dialog resources -- as well as some bitmap and menu resources) -- in ResEdit, it appears that the language attribute associated with these resources varies from Polish to English (US) to English (Canada), despite everything being in English. What's up with that? These should really be consistent. See attached screenshots for proof.

[kroozer]

This has been discussed — the glitched bracket issue is with XP. Piriform may not repair this due to XP's age (11 years next month).

[koitsu]

Can you point me to where this was discussed?

 

This can't be an XP problem even though it may not exist on 7 -- I provided proof that font-wise things are perfectly fine, and that the open paren also works fine in Defraggler in other areas. It seems to be a bug in Defraggler and what it's doing with its generation of the string used for percentages for specific uses (Analyzing percentage and Files fragmented percentage). As stated, Quick Defrag percentage does not have the problem. Other Piriform products (CCleaner, etc.) also do not have this issue.

 

I myself am a programmer and I'd be happy to assist in debugging this problem, but from my perspective it really does look like a bug in the Defraggler code. A build of Defraggler that includes debugging symbols would help me greatly, assuming I'm to do the work in tracking down the bug.

[kroozer]

Can you point me to where this was discussed?

 

clamp error

[koitsu]

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. :-)

[hazelnut]

koitsu the Piriform devs read all bug reports so please don't feel your efforts have been in vain.

 

Thanks for the research and welcome to the forum

[Super Fast]

Koi, I have long been irked by this bug as well.

 

This has been discussed — the glitched bracket issue is with XP. Piriform may not repair this due to XP's age (11 years next month).

 

@Kroozer -> http://windows.micro...elp/end-support

_____

 

This should not be a reason NOT to fix a bug in Defraggler.

 

Vista -> Dead since July 12, 2011.

XP -> Still supported till April 8, 2014.

 

Vista is a newer OS than XP & is already dead. Been dead 1 yr. XP is still supported for 2 more years. Shouldn't a supported OS get bugs fixed?

 

If XP is not going to be supported because of its age, shouldn't Vista support also be dropped since Microsoft support for it is dead?

[hazelnut]

Super Fast I have edited out a vast portion of your post above which was nothing to do with the bug report which is about......

 

Open/left parenthesis appears wrong

 

Please try to stay on topic.

[Super Fast]

@Hazel, thanks!

 

What I posted earlier made no sense to you because it was a partial posting that I was still editing.

It would not have made much sense till I posted the rest of it, but it's no biggie.

 

The point I was attempting to make with the earlier post, before it was edited, is that although XP is older, it still has greater market share, & is still supported.

It is seemingly a bit harsh to judge everything about an OS based on it's age. After all, Vista is newer & dead...

 

But I do thank you! No hard feelings

[hazelnut]

Please do not be insulting, I was not confused.

 

I read the huge amount you wrote about all the different operating systems etc.

 

Don't add anything else to this thread, just leave it for the devs to sort out.