Import/Export configuration

[himselfv]

Original report by me.

Viper already can generate .reg-file export for service triggers. It needs the ability to export full service configuration, preferably maximally identical to the actual registry key for this service.

It will then provide the ability to export one or more services in this way.

Services exported in this way can be imported by simply importing the .reg files and rebooting.

But it would also be nice to have an UI for that. There are several typical tasks that should be handled:

1. Import .reg file, create missing services, rewrite existing services.
2. Choose whether to only update existing services/also create missing ones. In the former case, gray out the services which are missing.
3. Choose which services to import from a given .reg file.
4. Choose which configuration elements to import from a given .reg file.

Note:
Services may have additional configuration options and keys under their own key. We may recreate the base key structure with information gathered from SC API, but not these additional keys.
We need to look into actual registry to export these keys. And we'll need to write them back too. This puts additional privilege requirements (SC API may sometimes require less rights that directly editing the key).

1. We should make these keys a separate configuration element which can be skipped on import, and then we should require less privileges.
2. We should somehow study the entire service key and figure which parts of it are "non-standard" (should be exported in addition to standard export generated from SC API).
   Or maybe we should just export the entire key from the registry? Including the stuff we might have retrieved via SC API?

Note 2:
Currently Viper has an ability to save/restore autostart configuration for the services in the .svcconf format. I'd like to keep it because this plain text format is easier for comparisons. Or maybe even extend it to table format, or simple line-by-line format, so that multiple properties can be included.

[himselfv]

Summarizing the above:

1. SC API provides no way to export additional configuration data. Additional data might be located anywhere in the service key. Thus most of the data must be exported from the registry.

2. But if we want to be versatile, we have to skip the known keys: the keys we can recreate from the SC API info.

3. On import, we should first import the known keys with SC API, then create additional keys directly in the registry.

4. All additional keys together should be a separate option when exporting/importing as they may require additional permissions.

There might be a need to mark key permissions in reg files somehow. I don't think reg file format normally supports this.

[himselfv]

I think I had some kind of reg format writer in ManifestEnum

[himselfv]

Wrote straightforward export for service's entire registry key.

[himselfv]

The default mode for importing vague things like "additional data" should be "update/extend": Add anything that's missing, Update anything that's present but do not Delete.

Why? Because if you want to "delete and recreated" you can quite literally delete the service beforehand. Meanwhile if we make the "delete/recreate" the default mode, there's no way to do update/extend. Letting the user choose might be okay but it complicates the UI, so by default let's just do update/extend. If we later wish we may add a choice.

[himselfv]

Same with services. There's hardly any use for "automatically deleting services which don't appear in the imported list". If you have any additional services you do not want you can just kill them beforehand.

There is maybe a use case for "completely restoring the service configuration from the export". This requires deleting all services with all their additional data and restoring them to clean slate. But I think I should set this aside for now as it's different from most other uses.