Introduce new configuration system

[nefarius]

Using properties to store and fetch configuration properties has reached its limits. I've thought about a better way to fetch configuration within the driver. Primarily it needs to work in good ol' pure C and shouldn't be too much of a hassle to also write to from C# (as DSHMC is a .NET application). It boiled down to two technologies to use: the registry or the filesystem.

Registry access if very limited, almost unusable in UMDF and that's on purpose, the hosting process of an user-mode driver runs under very low privileges for security reasons and I don't want to change that. There are ways to create registry keys and alter their permissions to allow the LocalService account read and write permissions but it didn't feel quite right.

Another way that is "easy" in an UMDF driver is to read from the filesystem, since we're running in user-mode, the common file primitives to open and read files work out of the box. At first I thought about using an INI parser, but to my delight I found a lightweight JSON parser so I settled on using JSON. It's an established standard, simple syntax for humans and it has native support in .NET, so it ticks all the boxes!

The driver will attempt to read the file C:\ProgramData\DsHidMini\DsHidMini.json and fallback to default values, if not found or parsing errors occur. This path has been chosen as the driver can read it without any modifications and any user can alter the file if they'd like to tinker with it outside of DSHMC. This will also allow for DSHMC to only require administrative elevation to restart the device, but no longer to simply store settings!

Related issues

These could be addressed and potentially fixed in entirety with this new feature:

• [x] #196
• [x] #87
• [x] #81
• [x] #53
• [x] #52
• [x] #51
• [x] #35
• [x] #31
• [x] #30
• [x] #202
• [x] #260
• [x] #261

JSON Schema

See example config file (work in progress).

[DJm00n]

Hi! Can you give some more insights why you don't like the official "Unified Device Property Model" approach? Maybe you can store your json in a string. I understand that it is not comfortable for user but anyways..

[nefarius]

Hi @DJm00n

As the project evolved we collected more and more feature requests and it became obvious that the approach "one property per setting", or a "key-value-pair" approach would soon lead to a massive overhead and not suitable for what we got planned.

I am not a fan of doing something "outside" of the official design by UMDF (reading files directly from disk is possible due to how UMDF works, but I agree it should not be done just because it's possible 😉 ) so your remark is perfectly valid.

Since we plan to provide an updated config UI anyway, the JSON config being fetched from file is not a strict necessity so yes, I could just pull it from a property as binary value. For now it's just an incredible convenience in debug builds to test changes quickly by editing a file. Plus having a file system watcher for automatic reload is also incredibly convenient.

I hope I could shed some light on the decisions made 😇

[DJm00n]

Thank you for clarification!

Then Dmf_File could be your friend.

File watcher is a great idea! Maybe you can extend DMF and write a module with this feature - it will be nice!

[nefarius]

Then Dmf_File could be your friend.

Brilliant! Haven't seen this one yet.

File watcher is a great idea! Maybe you can extend DMF and write a module with this feature - it will be nice!

Sounds like a rewarding challenge, I'll sure try once I pick up work on this project again!

[nefarius]

This is pretty much done and working well. All future related changes can be tracked by new individual issues or straight away in PRs 🎉