> RegEdit merges the contents of the .reg text file into the registration database.
— HKEY_CLASSES_ROOT is the lowest defined numerical constant, maybe it was the first one.
— RegSetValue() only handles REG_SZ (string) values.
— REG_SZ is the default format for new and empty registry keys.
— System data about components stored in {CLSID} branches all use short REG_SZ values for everything: numbers, lists ("8,PBrush"). This is in line with handling such values in INI files, short string “verbs” and class names in ShellExecuteEx() (notice that the registry key can be used to define an object class — was it initially supposed that any registry key corresponded to some class in some hierarchy?), text messages in DDE, etc.
— Finally, Wikipedia (ooh) says that the registry started as component registration database. So maybe the point of lpClass was tagging the branches that belonged to this or that class, or preventing components from messing with each other's data…
I believe that some team created a nice, compact, and simple enough storage solution to hold a predictable amount of text values under first and third party CLSID keys to be used in system COM libraries operation. It was way better than some potentially enormous OLE.INI which would regularly fail to be written completely in case of power loss, among other problems. Then it was found to be so nice that upper management decided to use it for everything, and the team cursed, and tore their hair, but it was too late.
It is possible that articles in computer journals introducing COM/OLE in Windows 3 have more information on first approach to registry and its goals back then.
> lpClass most likely is a class name in COM/OLE sense.
I don't think that is true. In the original Windows 3.1 registry, lpClass did not exist. You only had the RegCreateKey() function which had no lpClass parameter, that parameter was added in RegCreateKeyEx() which was only in NT (and later Windows 95 too).
COM/OLE never used lpClass. Out-of-the-box, very few Windows registry keys have lpClass set, and those that do it is mostly some meaningless value like "Shell" or "Setup", which COM/OLE completely ignores. The one place (that I know of) which it is (or was) actually used, is to store the syskey encryption key [0]. I think using lpClass for that is just abusing it for a bit of security-by-obscurity, it is a way to store data in the registry but hide it from most registry tools (which provide no access to lpClass because almost nobody uses it.) Possibly other people are doing the same thing (to store license keys, detect expiration of trial periods, malware hiding stuff, etc.)
— A lot of WIN32.HLP articles from the 3.x to 9x transition era talk about “registration database”, which seems to be the original name for registry.
https://www.betaarchive.com/wiki/index.php/Microsoft_KB_Arch...
https://docs.microsoft.com/en-us/cpp/mfc/registration?view=m...
> RegEdit merges the contents of the .reg text file into the registration database.
— HKEY_CLASSES_ROOT is the lowest defined numerical constant, maybe it was the first one.
— RegSetValue() only handles REG_SZ (string) values.
— REG_SZ is the default format for new and empty registry keys.
— System data about components stored in {CLSID} branches all use short REG_SZ values for everything: numbers, lists ("8,PBrush"). This is in line with handling such values in INI files, short string “verbs” and class names in ShellExecuteEx() (notice that the registry key can be used to define an object class — was it initially supposed that any registry key corresponded to some class in some hierarchy?), text messages in DDE, etc.
— Finally, Wikipedia (ooh) says that the registry started as component registration database. So maybe the point of lpClass was tagging the branches that belonged to this or that class, or preventing components from messing with each other's data…
I believe that some team created a nice, compact, and simple enough storage solution to hold a predictable amount of text values under first and third party CLSID keys to be used in system COM libraries operation. It was way better than some potentially enormous OLE.INI which would regularly fail to be written completely in case of power loss, among other problems. Then it was found to be so nice that upper management decided to use it for everything, and the team cursed, and tore their hair, but it was too late.
It is possible that articles in computer journals introducing COM/OLE in Windows 3 have more information on first approach to registry and its goals back then.