diff --git a/Source/Settings/ConfigurationFileStore.cs b/Source/Settings/ConfigurationFileStore.cs
index 0586185..ab027b1 100644
--- a/Source/Settings/ConfigurationFileStore.cs
+++ b/Source/Settings/ConfigurationFileStore.cs
@@ -28,8 +28,67 @@ namespace Nuclex.Support.Settings {
/// Represents an ini- or cfg-like configuration file
///
- /// This class tries its best to preserve the formatting of configuration files.
- /// Changing a value will keep the line it appears in intact.
+ ///
+ /// This class tries its best to preserve the formatting of configuration files.
+ /// Changing a value will keep the line it appears in intact. The parser also takes
+ /// as much data from a line as it can - anything to the left of an equals sign
+ /// becomes the name, anything to the right (excluding comments) becomes the value.
+ ///
+ ///
+ /// To access the contents of a configuration file, simply parse it and use it like
+ /// you would any other settings store:
+ ///
+ ///
+ ///
+ /// // # Settings.ini
+ /// // message = hello world ; the usual...
+ /// // show message = true
+ /// ISettingsStore settings;
+ /// using(var reader = new StreamReader("settings.ini")) {
+ /// settings = ConfigurationFile.Parse(reader);
+ /// }
+ ///
+ /// if(settings.Get<bool>(null, "show message")) {
+ /// Console.WriteLine(settings.Get<string>(null, "message"));
+ /// }
+ ///
+ ///
+ ///
+ /// It's usually a good idea to keep an application and all of its required files
+ /// together, whether it's code or data, but platforms often have their own conventions:
+ ///
+ ///
+ ///
+ /// Operating System
+ /// Convention
+ ///
+ /// -
+ /// Linux
+ ///
+ /// System-wide configuration goes into /etc/<appname>/, user-specific
+ /// configuration goes into ~/.<appname>/ while static configuration that is
+ /// known at build time resides with the application in /opt/<appname>/
+ ///
+ ///
+ /// -
+ /// Windows
+ ///
+ /// System-wide configuration goes into %ProgramData%, user-specific configuration
+ /// has no real place (try %AppData%/<appname>/ if you want to hide it from
+ /// the user, %UserProfile%/Documents/<appname> if the user should see it)
+ /// and static configuration resides with your application
+ /// in %ProgramFiles%/<appname>/.
+ ///
+ ///
+ /// -
+ /// MacOS
+ ///
+ /// System-wide configuration goes into /etc/<appname>/, user-specific
+ /// configuration goes into /Users/<username>/.<appname>/ while static
+ /// configuration resides with the application in /Applications/<appname>/
+ ///
+ ///
+ ///
///
public partial class ConfigurationFileStore : ISettingsStore {
diff --git a/Source/Settings/WindowsRegistryStore.cs b/Source/Settings/WindowsRegistryStore.cs
index dff2609..bc64c13 100644
--- a/Source/Settings/WindowsRegistryStore.cs
+++ b/Source/Settings/WindowsRegistryStore.cs
@@ -29,6 +29,24 @@ using Microsoft.Win32;
namespace Nuclex.Support.Settings {
/// Stores settings in the registry on Windows operating systems
+ ///
+ ///
+ /// For the cases when you must use the Windows registry, the windows registry store
+ /// lets you map a registry key as a settings store. Its direct subkeys will become
+ /// categories and all registry values are made available as options.
+ ///
+ ///
+ /// Use of the registry is strongly discouraged. It binds you to Microsoft's silly
+ /// technology stack and fragments your application by storing some of its data in
+ /// the file system while storing other data in an opaque, globally-shared settings
+ /// manager that is filled with megabytes on unrelated things. Xcopy deployment
+ /// and portability will be out of the question when relying on the registry.
+ ///
+ ///
+ /// Instead of using this, consider querying for the platform's appropriate location
+ /// to store settings in.
+ ///
+ ///
public class WindowsRegistryStore : ISettingsStore, IDisposable {
/// Initializes a new settings store on the specified registry path