3 ms·

PowerShell exposes the hives as a directory structure, and has for a decade or more. just type "HKLM:" or whatever hive you want and start using "cd" and "dir"

PowerShell exposes the hives as a directory structure, and has for a decade or more. just type "HKLM:" or whatever hive you want and start using "cd" and "dir" all you want. https://docs.microsoft.com/en-us/powershell/scripting/samples/working-with-registry-keys?view=powershell-7.1 https://docs.microsoft.com/en-us/powershell/scripting/sample...

rwmj 5y ago
Sure, but it's still converting to and from the weird hive format.
13of40 5y ago
The guy who implemented that really did a disservice to the filesystem metaphor, though. Instead of making values analogous to files, they're properties of registry keys, so instead of Get/Set-Content, Get-ChildItem, etc. you need to do some gymnastics with Get/Set-ItemProperty to work with them. For example, if you want to find a registry value with a particular name, you can't just do 'dir -rec SomeValueName' to find it like you can on the filesystem provider.
- naikrovek 5y ago
  well, the registry has types. files are raw binary data that is almost entirely untyped. how could they possibly enforce typed data without diverging from the filesystem metaphor?
  - 13of40 5y ago
    Cmdlets can have provider-specific parameters, so in this case I would add a registry-provider-specific data type parameter with sensible default behavior to New-Item and Set-Content. For example... Set-Content hklm:\software\xyz\abc -value 1 ...could create a DWORD value by default based on the type of the value argument, while adding '-DataType String' would enable creating a string value.
  - jaclaz 5y ago
    Files are raw binary data, but a (BTW unreliable) method to understand what they contain has been in use since years: file extensions. I can see no reason why in a filesystem-like representation of the Registry you cannot have a value.dwd (which is a DWORD), a value.bin (which is a BINary), value.esz, etc., or at least that is what I would use.

rwmj 5y ago

Sure, but it's still converting to and from the weird hive format.

13of40 5y ago

The guy who implemented that really did a disservice to the filesystem metaphor, though. Instead of making values analogous to files, they're properties of registry keys, so instead of Get/Set-Content, Get-ChildItem, etc. you need to do some gymnastics with Get/Set-ItemProperty to work with them. For example, if you want to find a registry value with a particular name, you can't just do 'dir -rec SomeValueName' to find it like you can on the filesystem provider.

naikrovek 5y ago
well, the registry has types. files are raw binary data that is almost entirely untyped. how could they possibly enforce typed data without diverging from the filesystem metaphor?
- 13of40 5y ago
  Cmdlets can have provider-specific parameters, so in this case I would add a registry-provider-specific data type parameter with sensible default behavior to New-Item and Set-Content. For example... Set-Content hklm:\software\xyz\abc -value 1 ...could create a DWORD value by default based on the type of the value argument, while adding '-DataType String' would enable creating a string value.
- jaclaz 5y ago
  Files are raw binary data, but a (BTW unreliable) method to understand what they contain has been in use since years: file extensions. I can see no reason why in a filesystem-like representation of the Registry you cannot have a value.dwd (which is a DWORD), a value.bin (which is a BINary), value.esz, etc., or at least that is what I would use.