Is 64-bit nodejs required to access 64-bit software registry?

[vweevers]

Am I correct in assuming you need a 64-bit nodejs binary to access the 64-bit registry? Because when using a 32-bit nodejs binary, I'm guessing node-regedit will find the 32-bit version of cscript in PATH or else use the hardcoded c:\windows\system32\cscript.exe, which will be redirected by Windows to the SysWOW64 folder. And the 32-bit cscript can only access the 32-bit (wow64) registry, correct?

[vweevers]

Short answer: no. Bitness of nodejs makes no difference, it will use the 64-bits cscript. Furthermore, the 32-bit cscript can access the 64-bit registry too (reportedly).

[kessler]

Hi @vweevers

You have the arch API for handling 32/64bit access.

If you do:

regedit.list(...)

You will access the registry based on the architecture of the node process

If you do:

regedit.arch.list(...)

You will access the registry based on the architecture of the operating system (regardless of the process architecture)

If you do:

regedit.arch.list32(...)

You will access the registry explicitly in 32bit architecture

And finally If you do:

regedit.arch.list64(...)

You will access the registry explicitly in 64bit architecture

[vweevers]

My question only pertained to agnostic mode (running regedit.list()), I should have phrased it differently. Let me make sure I understand what's going on. Imagine I'm running 32-bit nodejs on a 64-bit machine. You're saying regedit.list() would access the 32-bit (wow64) registry. Is that A) because the 64-bits cscript is spawned but it somehow "inherits" the 32-bit environment of its parent process? Or B) because the 32-bits version of cscript is spawned, due to Windows' file system redirection?

[vweevers]

I've determined it's B (the 32-bit cscript is spawned, because in a 32-bit parent process, C:\Windows\System32\cscript.exe is redirected to C:\Windows\SysWOW64\cscript.exe). It might also be possible to spawn the 64-bit cscript from a 32-bits nodejs process by using the path C:\Windows\Sysnative\cscript.exe - and then access the 64-bit registry without having to use the slower ExecMethod calls.

But I'm sorry, I'm thinking out loud and this isn't relevant for node-regedit anymore (I've adapted some of your code for win-detect-browsers, with credits).

Thanks for your response, nonetheless.

[kessler]

Hey @vweevers

Thanks for the creds!

I'm fairly interested in this comment you made about speed here:
https://github.com/vweevers/win-detect-browsers/blob/master/lib/reg-stream/index.js#L14

Did you test this? how significant is the improvement? do you know why is it faster?

[vweevers]

I can't give you any hard numbers, but it was significant enough for me to notice. There must be some overhead in the ExecMethod calls, and because win-detect-browsers queries a lot of keys, it quickly adds up. I'll do a rough benchmark later, and get back to you.

[kessler]

Excellent! looking forward, thanks!

[vweevers]

See cscript-registry-benchmark and its output.

Calling registry.GetStringValue directly (eg, agnostic mode) is roughly 2x as fast as registry.ExecMethod_("GetStringValue", ..) with a "__ProviderArchitecture" flag / context.

The relevant bit of the output is (the third column is the difference to the agnostic duration):

Agnostic:                     2.219 sec  
64-bit:                       4.797 sec   +2.578 
64-bit (predefined method):   3.906 sec   +1.688 

As the third row shows, a small speed gain can be made by reusing the method object:

' Initialize
set method = registry.Methods_("GetStringValue")

' Then later ..
Set params = method.Inparameters
params.hDefKey = ..

Instead of doing registry.Methods_("GetStringValue").Inparameters each time.

PS. You might see "20000 sec" in the output, that's a formatting mistake, should be 2 seconds.

[kessler]

This is awesome! Thanks a lot.

I will check if there are additional ways to optimize ExecMethod()

Will update here