I decided to rewrite the tests in orderliness. Today I have done the tests on write-operations ( http://newtestbot.winehq.org/JobDetails.pl?Key=931 ) . And ome of my assumptions has been confirmed:
All the operations that change hkcr should prefer hkcu to hklm. That means if the _full_path_of_the_operation_ can be found in hkcu it act as mapping to hkcu, otherwise to hklm. _full_path_of_the_operation_ : for create_key and delete_key, it's the path of the handle plus the subkey path. for set_value and delete_value, it's the path of the handle. For example, set new value on 'val1 of hkcr/test1 affects hkcu when there are hkcu/software/classes/test1 and hklm/software/classes/test1, but affects hklm when there's only hklm/software/classes/test1. Another thing that I confirmed is that handle opened from hkcr is not the same as that from hkcu or hklm, even when there's only one such key in hkcu or hklm. Because further operations on the handle change the other when the 'path match' situation is meet. For example, make sure there is hkcu/software/classes/key1 but not hklm/software/classes/key1, after creating a new key subkey2 with the handle opened from hkcr/key1, it will be found as hklm/software/classes/key1/subkey2 rather than hkcu. Obviously operationg on a handle opened from hkcu/software/classes/key1 does not affect hklm, so there must be something necessary to do to tell the mapped key handle from oridinal one. My preliminary design: open_key for hkcr subkeys should return a new type handle - key_view, which have one field : key path relating to classes, all operations on the handle will be dynamic decided which branch to redirect to. As far as I know from my previous developing windows drivers, kernel and services run codes as system user, so the handle may be confused when using by different user, so I will test what happen when using a dumped key handle of hkcr subkeys across different users. To decide whether a more field 'owner uid' is needed. I'm going to test on read-operations soon, after this I'll start writing the test reports. -- Regards, Guo Jian