hex conversion

[memoryoverflow]

When trying to convert a REG-DWORD into a signed decimal, Hex() behaves differently depending on OS version.

Dec(Hex($RegDWordVariable)) yields the expected signed decimal under w2k sp4, while it fails under xp sp3 for negative values (Hex() outputs 0x8000000 instead of 0xfff.....).

I've searched help and forum search for quite some time to no avail.

Every tip that helps understanding the behaviour is highly appreciated.

[Inverted]

I'm confused,too. If I do this :

MsgBox (0,"",Hex(4294967295))

it returns FFFFFFFF, which is correct.

If I create a reg_dword key with the value 4294967295 and do this :

MsgBox (0,"",RegRead ("HKEY_CURRENT_USER\blah\blah","test"))

I get 4294967295, which is correct.

But if I do this :

MsgBox (0,"",Hex(RegRead ("HKEY_CURRENT_USER\blah\blah","test")))

I get 80000000

Although this expression is true :

RegRead ("HKEY_CURRENT_USER\blah\blah","test")=4294967295

Edited October 7, 2009 by Inverted

[memoryoverflow]

Tanks 'inverted', but I understand this better than my example, where the same code produces different results depending on the machine, where it's running.

Your example, Hex(4294967295), yields "FFFFFFFF" on w2k and "80000000" on xp.

While: Your last example works on the w2k machine, too!

I didn't implement it like that, because I check for errors between RegRead and conversion.

Edited October 7, 2009 by memoryoverflow

[Inverted]

I'm still confuzzled : did you come to a conclusion ?

[SmOke_N]

I'm still confuzzled : did you come to a conclusion ?

Although this expression is true :

RegRead ("HKEY_CURRENT_USER\blah\blah","test")=4294967295

^ That isn't accurate. You're stating that comparing the string value "4294967295" is equal to the integer value 4294967295 essentially.

Here's your example it seems you are suggesting should be true:

MsgBox(64, "Info", _
    "Using Hex on a ""String"" = " & Hex("4294967295") & @CRLF & _
    "Using Hex on an ""Integer"" = " & Hex(4294967295))

This is more what I think you're looking for, notice how the string is cast as an integer before I do the hex on the string:

MsgBox(64, "Info", _
    "Using Hex on a ""String that is cast as an integer"" = " & Hex(Int("4294967295")) & @CRLF & _
    "Using Hex on an ""Integer"" = " & Hex(4294967295))

Edited October 8, 2009 by SmOke_N

[memoryoverflow]

I can't solve it. And you see the number of answers here.

What I can do is to bloat the scripts with a workaround. Which wouldn't exactly build trust that the rest will work reliably on other machines. Let alone the still-to-be-done, bigger rest.

-oops- there came an answer while I was typing, have to look into that one first.

Edited October 8, 2009 by memoryoverflow

[memoryoverflow]

^ That isn't accurate. You're stating that comparing the string value "4294967295" is equal to the integer value 4294967295 essentially.

Here's your example it seems you are suggesting should be true:

MsgBox(64, "Info", _
    "Using Hex on a ""String"" = " & Hex("4294967295") & @CRLF & _
    "Using Hex on an ""Integer"" = " & Hex(4294967295))

This is more what I think you're looking for, notice how the string is cast as an integer before I do the hex on the string:

MsgBox(64, "Info", _
    "Using Hex on a ""String that is cast as an integer"" = " & Hex(Int("4294967295")) & @CRLF & _
    "Using Hex on an ""Integer"" = " & Hex(4294967295))

Thanks for the reply 'SmOke_N', but how does this explain the different behaviour on different machines?

[Inverted]

^ That isn't accurate. You're stating that comparing the string value "4294967295" is equal to the integer value 4294967295 essentially.

Why would RegRead return a string and not a number ? It's a reg_dword value, so it's a number.

Anyway, if I do this, then I get the MsgBoz :

If RegRead ("HKEY_CURRENT_USER\blah\blah","test")=4294967295 Then MsgBox(0,"","expression true")

[SmOke_N]

Why would RegRead return a string and not a number ? It's a reg_dword value, so it's a number.

Anyway, if I do this, then I get the MsgBoz :

If RegRead ("HKEY_CURRENT_USER\blah\blah","test")=4294967295 Then MsgBox(0,"","expression true")

I didn't see dword, that's what I get for skimming through the post.

Speculation:

The return type from Dword is a double, you're (@Inverted) using an Int64 value, so it may cause issues there being converted to a double.

Testing that theory myself by creating a key and key value it did show that to be the case:

; ** You have to create the folder hierarchy before you run RegRead
Global $s_reg_key = "HKLM\TestValues"
Global $s_reg_read = RegRead($s_reg_key, "TestingDword")
ConsoleWrite($s_reg_read & @TAB & @TAB & "Registry value returned" & @CRLF)
ConsoleWrite(VarGetType($s_reg_read) & @TAB & @TAB & "Return type" & @CRLF)
ConsoleWrite(Hex($s_reg_read) & @TAB & "Hex value " & VarGetType($s_reg_read) & @CRLF)
ConsoleWrite(Hex(Int($s_reg_read)) & @TAB & "Hex value Integer" & @CRLF)

@OP

Maybe you can provide the exact reg values you're doing your research on.

[PsaltyDS]

Why would RegRead return a string and not a number ? It's a reg_dword value, so it's a number.

Anyway, if I do this, then I get the MsgBoz :

If RegRead ("HKEY_CURRENT_USER\blah\blah","test")=4294967295 Then MsgBox(0,"","expression true")

It's a number but not INT32 type (in XP), which is signed. RegRead() returns a DOUBLE so as not to get screwed up with the sign. Try this on XP and Win2K to see if they are different:

Global $sKey = "HKLM\SOFTWARE\AutoIt v3"
RegWrite($sKey, "Test_DWORD", "REG_DWORD", 4294967295)

$vRead = RegRead($sKey, "Test_DWORD") ; Type = Double
ConsoleWrite("$vRead = " & $vRead & "; Type = " & VarGetType($vRead) & @LF)

$vTest = 0xFFFFFFFF ; Type = INT32
ConsoleWrite("$vTest = " & $vTest & "; Type = " & VarGetType($vTest) & @LF)

[SmOke_N]

It's a number but not INT32 type (in XP), which is signed. RegRead() returns a DOUBLE so as not to get screwed up with the sign. Try this on XP and Win2K to see if they are different:

Global $sKey = "HKLM\SOFTWARE\AutoIt v3"
RegWrite($sKey, "Test_DWORD", "REG_DWORD", 4294967295)

$vRead = RegRead($sKey, "Test_DWORD") ; Type = Double
ConsoleWrite("$vRead = " & $vRead & "; Type = " & VarGetType($vRead) & @LF)

$vTest = 0xFFFFFFFF ; Type = INT32
ConsoleWrite("$vTest = " & $vTest & "; Type = " & VarGetType($vTest) & @LF)

Echo?

[PsaltyDS]

Echo?

ECHO... Echo... Echo... Echo... Echo... Echo... Echo... Echo...

Yep, echo test positive.

[memoryoverflow]

... (in XP), ... RegRead() returns a DOUBLE so as not to get screwed up with the sign.

Same here (w2k), so that seems not to explain the different behaviour. Will get to the xp computer where it fails in ~16 hours and check if that shows a difference.

But - I don't really expect it, since the conversion works here on w2k, showing the same type as your (? or 'Inverted's xp, where it fails.

[Inverted]

You guys are right.

The reg value is a dword, RegRead returns a double (and @extended=$REG_DWORD)

And no remark about it on the help !

I didn't know about VarGetType by the way, very useful, I knew I was missing something.

[SmOke_N]

Same here (w2k), so that seems not to explain the different behaviour. Will get to the xp computer where it fails in ~16 hours and check if that shows a difference.

But - I don't really expect it, since the conversion works here on w2k, showing the same type as your (? or 'Inverted's xp, where it fails.

You certainly have not provided any information to even begin to help you if mine/PsaltyDS's comments do not help you.

1. What is the actual dword value in the registry that is giving you issue?

2. What type of processor does each machine have?

3. Is one OS 32 bit and the other 64 bit?

4. If one is 64 bit, are you compiling either of them as 64 bit?

[memoryoverflow]

It's not depending on the actual value, just fails on one machine while it works on the other, as soon as it's going negative. It's not even dependent on reading the reg value. Same thing with arbitrary numbers typed in for testing.

Here is an Athlon, don't know the other one by heart. But since it shows the same behaviour as on that other machine for 'Inverted', I wouldn't expect it to be crucial. Having that said for this specific case, I appreciate the tip, which commonly should need clarification.

Both OSs where I tried it, are 32 bit.

I don't compile as 64 bit and it shows up in the interpreter already.

[memoryoverflow]

Further tests on the xp, where it fails have been foiled for today by an accident on the way to that other office. Having spent the rest of the workday in hospital forced me to postpone further testing to Monday. (and is forcing me to type one-handed for the next weeks.)

[Inverted]

Further tests on the xp, where it fails have been foiled for today by an accident on the way to that other office. Having spent the rest of the workday in hospital forced me to postpone further testing to Monday. (and is forcing me to type one-handed for the next weeks.)

You crashed ?

Dude, be more careful,lol. And get better

At least, that's what Cpt Obvious would suggest !

Edited October 9, 2009 by Inverted

[PsaltyDS]

You crashed ?

At least he didn't BSOD!

[herewasplato]

At least he didn't BSOD!

:-)

:-)