HWiNFO v7.17-4655 Beta released

Martin

HWiNFO Author
Staff member
HWiNFO v7.17-4655 Beta available.

Changes:
  • HWiNFO64 ported to UNICODE.
  • Enhanced Intel XMP 3.0 Revision 1.2 support.
  • Enhanced sensor monitoring on some ASRock B660 and H610 series.
  • Enhanced support of future AMD AM5 platforms.
  • Enhanced sensor monitoring on ASUS B660, H670 and H610 series.
  • Starting localization into 24 languages.
For further information and questions about the new Localization check here:
 
Last edited:

RobertR

Active Member
Well, what do you mean by "UNICODE"? For instance, all of the device/sensor labels that had the wonderful - and correct - UTF-8 encoding on the temps are now broken (i.e., no longer using UTF-8, which should presumably be the goal here?).

And while the UTF-8 breakage is presumably fallout from the "Localization" changes, I assume it wasn't an intended result.

Just saw this now, as I was offline for 24 hours (what a nightmarish experience;)) - and if this isn't the correct place to post BETA feedback, please let me know.
 

Martin

HWiNFO Author
Staff member
Well, what do you mean by "UNICODE"? For instance, all of the device/sensor labels that had the wonderful - and correct - UTF-8 encoding on the temps are now broken (i.e., no longer using UTF-8, which should presumably be the goal here?).

And while the UTF-8 breakage is presumably fallout from the "Localization" changes, I assume it wasn't an intended result.

Just saw this now, as I was offline for 24 hours (what a nightmarish experience;)) - and if this isn't the correct place to post BETA feedback, please let me know.

UNICODE (or UTF-16) is the encoding to be used on Windows since WinNT. Until now, HWiNFO was using ANSI and the characters shown were depending on current locale used for Non-UNICODE applications, which also wasn't portable between systems with different locales.
Can you please provide more details - what exact labels have you used in the past and what is your current locale? Assuming you had UTF-8 (Beta) set for non-UNICODE applications.
 

RobertR

Active Member
Actually, I don't even think Microsoft any longer recommends you use their version of UTF-16, as UTF-16 (any version) doesn't have nearly the range of characters that can be encoded as does UTF-8... in other words, UTF-8 won. :)

So, until this BETA, HWiNFO was putting out this (for example):

[12324] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|System1 °C
[12324] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|PCH °C
[12324] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|CPU °C
[12324] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|PCIEX16 °C
[12324] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|VRM MOS °C

... where the "degrees" symbol was properly encoded in UTF-8 as "c2 b0". As a detail, this trace was produced using OutputDebugStringA - which works great with UTF-8.

Now what I see with the BETA is the sequence "ef bf bd" - which is used for illegal characters.

And yes, as you suspect, I am using the Windows "beta" feature of "Use Unicode UTF-8 for worldwide language support" - with the underlying locale set to "English (United States)".

To be clear, these are the label strings supplied by HWiNFO for the sensors in the shared memory segment.

I actually fell victim to this same thing about 3 years ago, when I thought I would be all correct and cool etc by re-writing my Windows apps to use the Microsoft version of UTF-16... but it turned out I was years late, and UTF-8 won out: it is way more complete, has amazing levels of compatibility with older code, etc.

To be [more] technical, neither UTF-8 nor UTF-16 is "Unicode" - both are merely external encodings meant for the exchange of data - actual "Unicode characters" are 32 bits.

You could get into philosophical discussions of whether the shared memory interface is an "external" encoding or not, as there is no longer even an argument to be made for UTF-16 when exchanging data - it is an historical artifact that a large number of the system calls use UTF-16 internally for sure, but that untidy detail should be left internal to an app, and any newer development should not be based on it.
 

Martin

HWiNFO Author
Staff member
Thanks for the additional data, so the only problem is the degree sign and only what's passed via Shared Memory? In the sensors screen it's shown properly? What is you actual locale/language used in Windows?

Actually the new language data HWiNFO uses internally is encoded in UTF-8 (as I too believe this is much more universal). This is then converted it into UNICODE for GUI output because that's the 'universal' way in Windows. Sure, UTF-8 would also work but only for Win10 users which have UTF-8 also selected for non-UNICODE applications, for others it would not and this is the majority. Maybe one day UTF-8 becomes standard here and if that happens it will be easy to adjust HWiNFO for this.
 
Last edited:

RobertR

Active Member
Perhaps I wasn't clear above: with the underlying locale set to "English (United States)" - at least, that is what I think you are asking with "actual locale/language used in Windows?".

Rats - I was afraid you would consider the shared memory segment as "GUI output"... and no, I have no idea what it looks like now - unless the "ef bf bd" is really what is in the sensor label by the time my app sees it.

What happens for my app "RxMDocklet" is that I save the full path representation of each sensor the user has selected for display, and then I match those up with what HWiNFO (and the other sensor apps) says are the available sensors each time the docklet is started. So, since the strings with a proper UTF-8 "degree" symbol no longer match, my app fails the match, and I just get a "missing" indication for that sensor.

So, unless you are willing to make this [unneeded from my perspective] extra translation to "UTF-16" optional, then I will do what I did when you first changed to putting out UTF-8: I will do a one-time hand editing of my saved config files to whatever magic string I need to so that it matches the next time the docklet is started - an ugly hack, and a step backwards as I see it.

But I do see your problem, in that Windows is the last holdout in the general shift to UTF-8... perhaps you will rethink this and have more options if Microsoft ever gets away from calling this feature in Windows "BETA" - sadly, Windows 11 is still that way.

Thanks , Martin.
 

Martin

HWiNFO Author
Staff member
Well, I run several tests but couldn't replicate this issue. The degree sign copied into SHM was always either 0xb0 or 0xc2 0xb0 depending on the Non-Unicode preferences (unless you're using Chinese), so I have no idea how "ef bf bd" could appear there. The language selected in HWiNFO is also "English"? Have you perhaps renamed the temperature units in HWiNFO in the past which could result in some encoding mismatch? You could export your preferences (reg file) and check what Units are set there.
 

RobertR

Active Member
So, to recap: with 7.16.4650, my scheme as described above works, in that I see the expected UTF-8 encodings for the degrees symbol.

With 7.17.4655 - AND NO OTHER CHANGES ANYWHERE - I don't. What I actually get is slightly painful to discover (without attaching a debugger, for instance) since my tracing which I copied into an earlier post is filtered through the Win32 call OutputDebugStringA... so the fact that we see the "bad encoding" indicator "ef bf bd" is likely just an indication that what is being seen is NOT a legal UTF-8 code point (not all sequences are valid, and in particular, the allowed ranges of the first and subsequent bytes are well-defined and limited).

I will hack in a "show me the actual hex codes in this string" just to get this value. ;)

Finally, it occurs to me that I should perhaps check for a newer (or replaced) "hwisenssm2.h" file... if you are really switching to a UTF-16 encoding for "GUI output" (and count the shared memory segment as such), then the declarations for szLabelOrig and szUnit are likely changed from "char" arrays to ?

EDIT:
[the magical place for discussing shared memory layout]
... seems to be no longer accessible?
 
Last edited:

RobertR

Active Member
Possibly bad news... when I dump the hex representation of "szUnit" with the BETA, the "bad UTF-8 sequence (ef bf bd)" looks to be already there:

[17640] RxTRACE> szUnit[as HEX]=efbfbd43
[17640] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|System1 �C
[17640] RxTRACE> szUnit[as HEX]=efbfbd43
[17640] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|PCH �C
[17640] RxTRACE> szUnit[as HEX]=efbfbd43
[17640] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|CPU �C
[17640] RxTRACE> szUnit[as HEX]=efbfbd43
[17640] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|PCIEX16 �C
[17640] RxTRACE> szUnit[as HEX]=efbfbd43
[17640] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|VRM MOS �C

if I set the encoding in my editor to EITHER UTF-8 or UTF-16 before copying the above strings:

[17640] RxTRACE> szUnit[as HEX]=efbfbd43
[17640] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|System1 �C
[17640] RxTRACE> szUnit[as HEX]=efbfbd43
[17640] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|PCH �C
[17640] RxTRACE> szUnit[as HEX]=efbfbd43
[17640] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|CPU �C
[17640] RxTRACE> szUnit[as HEX]=efbfbd43
[17640] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|PCIEX16 �C
[17640] RxTRACE> szUnit[as HEX]=efbfbd43
[17640] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|VRM MOS �C

... which is just saying it doesn't like the encoding of the "degrees" symbol.

Of course, when I run with the previous version of HWiNFO (7.16.4650) and UTF-8:

[16972] RxTRACE> szUnit[as HEX]=c2b043
[16972] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|System1 °C
[16972] RxTRACE> szUnit[as HEX]=c2b043
[16972] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|PCH °C
[16972] RxTRACE> szUnit[as HEX]=c2b043
[16972] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|CPU °C
[16972] RxTRACE> szUnit[as HEX]=c2b043
[16972] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|PCIEX16 °C
[16972] RxTRACE> szUnit[as HEX]=c2b043
[16972] RxTRACE> HWIM|GIGABYTE Z690 AORUS MASTER (ITE IT8689E)|VRM MOS °C

... so maybe the BETA - or its new output translation - doesn't like my running with the Windows BETA UTF-8 support?
 

Martin

HWiNFO Author
Staff member
Try to do a "Backup User Settings" or export the HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\Sensors registry key and post here. You'll need to compress it using something first to attach.
I want to check whether there are perhaps some custom setting causing this.
 

RobertR

Active Member
Here it is - actually, pretty small even before compressing, since I don't make any changes or "customizations" - it would be a pretty bad idea to do that, since I expect people to just be able to run a [presumably licensed] copy of HWiNFO without making any changes and have RxMDocklet work without trouble. ;)

Could you tell me what you think the szUnit bits should look like for me? Remembering that my Windows 11 is "US English" but with the UTF-8 BETA flag set?

Also, not to be impatient or anything, but you haven't answered my question about possible changes to the shared memory layout? :)
 

Attachments

  • 4MartinSensors.zip
    1.4 KB · Views: 1

Martin

HWiNFO Author
Staff member
Thanks for the file, I haven't found any issue there :( Can you try this Shared Memory Viewer how does it show the degrees symbol: https://www.hwinfo.com/beta/HWiNFOSharedMemoryViewer.exe.7z

The Shared Memory layout remains same for now and encoding is still ANSI and depending on locale set for Non-Unicode applications. I will explore adding/extending it with an additional field for different encoding (most probably UTF-8) if there will be such a need.
 

RobertR

Active Member
Cool little viewer! :)

Here it is with the BETA of HWiNFO: �C (copied straight from the viewer field with its "Copy")... of course, with the 7.16.4650 version, we have °C (also from your viewer).

I am sorry this is causing so much trouble for you... way back when you changed HWiNFO to the way it was working with units (right up until your new BETA) you actually made me go and start to get a better understanding of what Unicode, encodings, and code points actually mean. ;)

One of the biggest things I took away from my reading (and subsequent coding) on these subjects is that it isn't really that complicated, but it is key that you get the right mindset - and try not to let Windows historical weirdness in this area complicate your code too much.

From what you say, I think you are trying to follow this approach - but things get broken somewhere.

Not to reference my own code too much, but just to be reminded how easy these concepts and transformations can be, you might take a look at my Github project RxMDocklet, file RXMDocklet.cpp, starting with the definition of the function sizeOfUTF8CodeUnits().
 

Martin

HWiNFO Author
Staff member
OK, I think I have a fix for this :) Works now with and without localization, with and without UTF-8 enabled and even for Chinese that uses a different sequence :)
 

RobertR

Active Member
Sweet! Congratulations, it sounds like you have things well in hand.

Glad to be of assistance, even if it was mostly just being annoying. ;)

BTW, I may be able to help look at some fairly new stuff, since I finally updated my "Kaby Lake" system to an Intel Core i7-12700K CPU, Z690 mobo, and XMP-speeds G.Skill DDR5.
 

wawans1975

Well-Known Member
Hi Martin,
I have problem that summary windows can't be drag.
Also i notice hwinfo use high cpu usage.
I attached debug file and Task Manager screenshot for you to look at.
 

Attachments

  • debug.zip
    2.7 MB · Views: 1
Top