64 bit registry question

[GEOSoft]

Martin's code returned "False" here.

Thanks Jon

[GEOSoft]

I''m glad you like that function GEOSoft, but when I said "something like this" that was my way of saying I haven't tried it. Do you know if it returns true on a 64 bit OS?

Looks like it didn't work Martin. See Jons reply above.

[Emiel Wieldraaijer]

I think we need a true processorarch as well. Which tells if the chip is x64 or not regardless of OS type.

Yes off course but until it's there, a small modification in the documentation will explain it much better

[martin]

Looks like it didn't work Martin. See Jons reply above.

Yes, it's no.

I'm interested to know why it doesn't work, obviously there is something another thing I don't understand.

[Valik]

Since Jon already cleared up/confused the @ProcessorArch issue, I'll just mention one thing. Calling LoadLibrary and GetProcessAddress is about the silliest thing I've ever seen done with DllCall(). Why? Because DllCall() is little more (Jon will disagree) than a thin wrapper around that very same sequence of function calls. And to top it off, didn't even call FreeLibrary().

Edit: Thinking more on it, you may have re-implemented @ProcessorArch. As Jon mentioned, despite it's misleading name, it really just tells you if the OS is 64-bit or not.

Edited January 22, 2008 by Valik

[GEOSoft]

Since Jon already cleared up/confused the @ProcessorArch issue, I'll just mention one thing. Calling LoadLibrary and GetProcessAddress is about the silliest thing I've ever seen done with DllCall(). Why? Because DllCall() is little more (Jon will disagree) than a thin wrapper around that very same sequence of function calls. And to top it off, didn't even call FreeLibrary().

Edit: Thinking more on it, you may have re-implemented @ProcessorArch. As Jon mentioned, despite it's misleading name, it really just tells you if the OS is 64-bit or not.

I did re-implement @ProcessorArch. Although I too believe it is poorly named. Renaming it would likely break quite a bit of code but at this point a simple StringReplace() run against the scripts would fix it quickly. It's not like it's going to be called many times in a script. I would suspect that it has even been used in a few cases wher the user thought they were actually getting the processor architecture and had they known otherwise it would not have been used. This might be a good time to make the name change and then add the real ProcessorArch at a later date. That would give people a chance to get the name change out of the way and determine if they even needed it before another macro is added.

[Valik]

I think renaming a macro is the least of our concerns as far as breaking scripts.

[GEOSoft]

I think renaming a macro is the least of our concerns as far as breaking scripts.

Somehow I just knew that was going to come up. It's minor breakage, I agree. However my thinking is that the pain could be somewhat lessened by making the rename now and adding the new macro later.

Func FixMyDamnMacro($File)
   $oFile = FileRead($File)
   $oFile = StringReplace($oFile, "@ProcessorArch", "@OSArch")
   $nFile = FileOpen($File,2)
   FileWrite($nFile,$oFile)
   FileClose($nFile)
EndFunc

Would make it pretty simple right now.

[jvanegmond]

Just about the initial question, you don't have to convert it to write to 64-bit registry values. Windows handles the "wrong" regwrites and regreads from 32 bit programs automatically.

[GEOSoft]

Just about the initial question, you don't have to convert it to write to 64-bit registry values. Windows handles the "wrong" regwrites and regreads from 32 bit programs automatically.

Thanks for the info @Manadar. Like I said, I don't have a 64 bit Windows install to play with and I wanted to make sure it had the proper key before I ran RegEnumVal(). The current solution is working so I'll keep it in as a "Fail Safe".

[Jon]

Just about the initial question, you don't have to convert it to write to 64-bit registry values. Windows handles the "wrong" regwrites and regreads from 32 bit programs automatically.

That's only true for the 32bit version of AutoIt running on x64. If you run the native x64 version you are on your own

[martin]

Since Jon already cleared up/confused the @ProcessorArch issue, I'll just mention one thing. Calling LoadLibrary and GetProcessAddress is about the silliest thing I've ever seen done with DllCall(). Why? Because DllCall() is little more (Jon will disagree) than a thin wrapper around that very same sequence of function calls. And to top it off, didn't even call FreeLibrary().

Ah, thanks for the note about FreeLibrary Valik, I'll try to remember that next time.

But if what I did is silly then how should I find out if the function IsWow64Process exists in Kernel32.dll? Should I just call it and see if it fails or not?

[Valik]

Yes. Just check @error after DllCall().

[martin]

Yes. Just check @error after DllCall().

Thanks.