4 ms·
That's a developer choice, not the registry in and of itself. You could just as easily have /etc filled files with GUIDs for file names. Generally, 3rd party d
by nullindividual 2y ago
That's a developer choice, not the registry in and of itself. You could just as easily have /etc filled files with GUIDs for file names.
Generally, 3rd party developers don't use a bunch of GUIDs for keys. Microsoft does for Windows components to map the internal object ID of whatever they're dealing with; my assumption is for ease of recognition/documentation on their side (and generally the assumption that the end user shouldn't be playing around in there).
- ruthmarx 2y ago> That's a developer choice, not the registry in and of itself. You could just as easily have /etc filled files with GUIDs for file names. For sure, that's why I said I have no issue with the concept but rather how it's used in practice. > Microsoft does for Windows components to map the internal object ID of whatever they're dealing with; my assumption is for ease of recognition/documentation on their side (and generally the assumption that the end user shouldn't be playing around in there). That's maybe fair, but most of that stuff isn't stuff the user even needs to access most of the time. Maybe separating it out from all the HKLM and HKCU software trees would have made sense.
- nullindividual 2y agoHKLM and HKCU have specific ACLs. It wouldn't make sense to have _two_ user-modifiable registry hives and ditto for machine.
- ruthmarx 2y agoI don't really understand your point here. It would make perfect sense to have two separate hives by sectioning off all the stuff users, even power users actually need access to. 'specific ACLs' have no bearing on that.
- nullindividual 2y agoThat already exists! It's the HKCU.
- ruthmarx 2y agoI really think you've missed my point and I don't understand how.