4 ms·

You can do similar on windows. However, the registry was turned into trying to solve a slightly different issue of roaming users, and centrally managed setting

You can do similar on windows. However, the registry was turned into trying to solve a slightly different issue of roaming users, and centrally managed settings, split by machine and user, and using what became active directory. They started off with OLE and its central store of holding name value pairs in a tree. Basically making the registry do at least 4 different things. Only one of them it does 'ok' (COM/OLE lookups). In practice it became a huge mess because thousands of applications now keep their settings in there and poor cleanup practices like you see. When like 99% of the use cases out there would be perfectly well suited to just using the forever deprecated win32 INI API to manage settings and MS just saying 'put your config files in these places for different effects'. Instead they said 'put it all in the registry'. Looking back at it, it is now 100% clear it was a bad design decision.

int_19h 4y ago
It should be noted that putting configuration into files rather than registry has been the standing recommendation on Windows for a very long time now. For example, .NET 2.0 (2005) added a standard facility for application settings, and it was implemented on top of XML .config files.
- nikau 4y ago
  Good to see MS practising what they preach on newly written applications: https://docs.microsoft.com/en-us/deployedge/configure-microsoft-edge https://docs.microsoft.com/en-us/deployedge/configure-micros... > You can also use REGEDIT.exe on a target computer to view the registry settings that store group policy settings. These policy settings are located at this registry path: HKLM\SOFTWARE\Policies\Microsoft\Edge.
  - int_19h 4y ago
    This is a group policy, not a setting. That makes a big difference in the right context - policies are meant for things that are typically centrally managed in enterprise environments, so the ability for the admin to remotely control every setting individually is important, and requires some kind of central system registry for OS tooling to work with.
    - nikau 4y ago
      Yep, but it still sucks if you are a user trying to figure out how a setting is applied, first delve into some seemingly proprietary config db for edge, and then realise its actually configured via a registry gpo.

int_19h 4y ago

It should be noted that putting configuration into files rather than registry has been the standing recommendation on Windows for a very long time now. For example, .NET 2.0 (2005) added a standard facility for application settings, and it was implemented on top of XML .config files.

nikau 4y ago
Good to see MS practising what they preach on newly written applications: https://docs.microsoft.com/en-us/deployedge/configure-microsoft-edge https://docs.microsoft.com/en-us/deployedge/configure-micros... > You can also use REGEDIT.exe on a target computer to view the registry settings that store group policy settings. These policy settings are located at this registry path: HKLM\SOFTWARE\Policies\Microsoft\Edge.
- int_19h 4y ago
  This is a group policy, not a setting. That makes a big difference in the right context - policies are meant for things that are typically centrally managed in enterprise environments, so the ability for the admin to remotely control every setting individually is important, and requires some kind of central system registry for OS tooling to work with.
  - nikau 4y ago
    Yep, but it still sucks if you are a user trying to figure out how a setting is applied, first delve into some seemingly proprietary config db for edge, and then realise its actually configured via a registry gpo.