Will function advapi32.dll.RegOpenUserClassesRoot will be implemented?
Hi, Is there a chance, that function advapi32.dll.RegOpenUserClassesRoot will be implemented? As I can see, most up 2 date software of Micro$oft (Explorer etc.) is using this function and can not run on a W2K environment. Any suggestions? Regards Signer: Eddy Nigg Company: StartCom Group at http://www.startcom.org MediaHostT at http://www.mediahost.org --- StartCom Ltd. http://www.startcom.org Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/10/2004
On Wed, Jan 14, 2004 at 11:09:15AM +0200, MediaHost (TM) wrote:
Hi,
Is there a chance, that function advapi32.dll.RegOpenUserClassesRoot will be implemented?
If someone implements it, yes.
As I can see, most up 2 date software of Micro$oft (Explorer etc.) is using this function and can not run on a W2K environment.
Any suggestions?
Feel free to send a patch, even with a function just printing a FIXME() message. Ciao, Marcus
Well, I guess, that there are people actively developing...It might be easier for them to get a fix done... Until I get into the source and understand, what you guys did.....win2000 will have finished end of life :-) Anyone knows where to insert this piece of code? Can be found here: http://msdn.microsoft.com/msdnmag/issues/1100/Registry/default.aspx the following: Registry API Flavors and New Functions There are basically three ways to program the registry: the Win32 API functions (advapi32.dll), the more recent Shell Lightweight API (shlwapi.dll), and various object models accessible mostly from Visual Basic® and Windows Script Host. If Visual Basic is your favorite development tool, I recommend taking a look at the RegObj library available from http://msdn.microsoft.com/vbasic/downloads. It is an object model that emulates the full Win32 API for working with the registry. The original set of registry functions provides you with the greatest flexibility. It requires you to open a key, to read or write to it, and then close it; the three basic operations for reading or writing an individual entry. The Shell Lightweight library-also available with Windows 98, Windows 95, and Windows NT 4.0 plus Internet Explorer 5.0 or higher-comes with some new functions that internally open and close the specified key when asked to read or write values. You just call SHGetValue or SHSetValue and let the function deal with the registry. In addition, the new API provides a SHDeleteKey function that recursively deletes non-empty keys. As explained earlier, this is the standard behavior in Windows 9x, but not in Windows NT or Windows 2000. The Windows 2000 SDK introduces three new functions that work with the registry: RegOpenUserClassesRoot, RegOpenCurrentUser, and RegDisablePredefinedCache. RegOpenUserClassesRoot returns a handle to HKCR for the specified user. You identify the user through an access token. The token can be returned by functions like LogonUser, and allows you to log onto the system as if you were another user. RegOpenCurrentUser retrieves a handle to HKCU. Notice that by default all the values stored in HKCU are cached for all threads in a process. To disable this practice and force the API to read and write from disk, remember to call RegDisablePredefinedCache. IQueryAssociations is another tool for working with the registry. It simplifies the information retrieval from HKCR and HKCU. You obtain a reference to the interface through IShellFolder's GetUIObjectOf or a new API function called AssocCreate. The IQueryAssociations methods allow you to set the root key and query for data, as shown in the following code: ----- Original Message ----- From: "Marcus Meissner" <meissner(a)suse.de> To: "MediaHost (TM)" <webmaster(a)startcom.org> Cc: <wine-devel(a)winehq.org> Sent: Wednesday, January 14, 2004 12:08 PM Subject: Re: Will function advapi32.dll.RegOpenUserClassesRoot will be implemented? --- StartCom Ltd. http://www.startcom.org Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004
On Wed, 14 Jan 2004 14:51:13 +0200, MediaHost (TM) wrote:
Well, I guess, that there are people actively developing...It might be easier for them to get a fix done...
It wouldn't be too hard to stub it. Wine doesn't really have any of the multi-user APIs implemented, there seems little point when you we can just pretend we're a single user system and let the underlying OS deal with multi-user capabilities. If I were you I'd just make this function return HKEY_LOCAL_USER and ignore which user was requested, assuming that would satisfy the spec
participants (3)
-
Marcus Meissner -
MediaHost (TM) -
Mike Hearn