Jump to content

koitsu

Members
  • Posts

    6
  • Joined

Reputation

0 Neutral

About koitsu

  • Birthday 24/01/1977

Profile Information

  • Gender
    Male
  • Location
    Mountain View, CA
  1. There are numerous UI-related mistakes pertaining to colour (particularly background colour) of texts when using Windows XP, particularly under Windows Classic with a different theme (ex. Rainy Day). The existing UI seems to make assumptions in a lot of places (but not everywhere!) that "the background colour is white", which is simply untrue. It's been like this for years now. Attached are some screenshots showing the problem (and one screenshot showing where things are done right (the Search tab)). This is 100% reproducible on stock Windows XP Pro SP3 (no weird "themeing" or third-party crap like WindowBlinds installed), and can be reproduced inside of a VM as well, so Piriform should have no problem fixing all this. ss00.png -- "Status" and "Properties" text is black-on-white; should be black-on-whatever-theme-bg-is ss01.png -- "Search" tab -- an example where its done correctly. Use this as a reference! ss02.png -- "Color" has issue ss03.png -- Self-explanitory (lots to fix here) ss04.png -- Self-explanitory (lots to fix here) These shouldn't be time-consuming to fix, despite Microsoft's support for Windows XP ending (I know, I know...). If you need to know what exactly to change in Windows XP to reproduce this (theme-wise) let me know and I can provide exact instructions.
  2. 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. :-)
  3. 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.
  4. 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.
  5. 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.
  6. Something I deal with fairly often: the XP icon cache reaching its maximum size or becoming corrupt in some way. The only way to deal with this is to delete the file and log off/log on (or reboot). In XP, this file lives at %USERPROFILE%\Local Settings\Application Data\IconCache.db. The file is hidden (ATTRIB +H), but otherwise is deletable/manageable by user applications. I have no idea where it lives in Vista or 7. I think it'd be useful to have this capability listed under the main CCleaner -> Windows -> Advanced section, labelled "Delete Icon Cache" or "Clear Icon Cache". And before anyone comments on it: yes, I'm using HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\"Max Cached Icons"="4096" already. That just limits the size of the cache, and has a maximum permitted value of 4096.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.