[13of40]

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]

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]

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]

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.