James Hawkins truiken@gmail.com writes:
This implementation passes the registry tests. A new server function is added, mount_key. mount_key is similar to load_registry except that mount_key can only load a key under HKLM or HKU and the key is created inside mount_key. To use load_registry, the subkey has to be created and then passed in as a parameter. load_registry is no longer used by anything, so if it should be remove, let me know.
What you should have done is modify load_registry, there's no reason to create a new request that does the same thing.
On 24 Mar 2005 13:35:35 +0100, Alexandre Julliard julliard@winehq.org wrote:
James Hawkins truiken@gmail.com writes:
This implementation passes the registry tests. A new server function is added, mount_key. mount_key is similar to load_registry except that mount_key can only load a key under HKLM or HKU and the key is created inside mount_key. To use load_registry, the subkey has to be created and then passed in as a parameter. load_registry is no longer used by anything, so if it should be remove, let me know.
What you should have done is modify load_registry, there's no reason to create a new request that does the same thing.
There are a couple reasons why I chose to add a new request instead of use load_registry. mount_key was written with the restriction that a key can only be loaded under HKLM or HKU, while load_registry (internally) loads a key anywhere. While load_registry wouldn't be called anymore, I thought that it still might be needed...but I agree this isn't a very strong reason to make a new request. load_registry requires that the requested key be created and sent in as a parameter. I think requiring NtLoadKey to create the key is mislocating functionality. NtLoadKey's job is to make the server request with the information provided, and mount_key should create the key. The only way I can think of modifying load_registry to fit the functionality of RegLoadKey/NtLoadKey is to add a char *subkey param to load_registry and then put the tests and create_key in load_registry, but by then we've just renamed mount_key to load_registry and gotten rid of the old load_registry. Let me know what is the best route to take for this circumstance.
James Hawkins truiken@gmail.com writes:
There are a couple reasons why I chose to add a new request instead of use load_registry. mount_key was written with the restriction that a key can only be loaded under HKLM or HKU, while load_registry (internally) loads a key anywhere. While load_registry wouldn't be called anymore, I thought that it still might be needed...but I agree this isn't a very strong reason to make a new request. load_registry requires that the requested key be created and sent in as a parameter. I think requiring NtLoadKey to create the key is mislocating functionality. NtLoadKey's job is to make the server request with the information provided, and mount_key should create the key. The only way I can think of modifying load_registry to fit the functionality of RegLoadKey/NtLoadKey is to add a char *subkey param to load_registry and then put the tests and create_key in load_registry, but by then we've just renamed mount_key to load_registry and gotten rid of the old load_registry. Let me know what is the best route to take for this circumstance.
load_registry already has the subkey name. The fact that the key is also created on the client side is just a temporary hack that can be removed.
On 24 Mar 2005 19:39:59 +0100, Alexandre Julliard julliard@winehq.org wrote:
load_registry already has the subkey name. The fact that the key is also created on the client side is just a temporary hack that can be removed.
Ah, excellent. A slight overlook on my part, but now the puzzle pieces are falling into place. I will write up the changes and send them in.
-
Alexandre Julliard -
James Hawkins