franz.reitner
8th July 2010 15:02 UTC
Shared Dlls
Hi all,
I wrote an installer from scratch, which is able to do an admin and a normal user install. Admin places the files in program files and user in roaming area. So far so good.
Now I need to place a shared dll into my installation. The problem now is, that the key for those shared dlls resides inside HKLM, which is no longer accessible under Vista/W7. In case there are two different installations (one admin and one user), it is not possible to determine, whether to remove the shared dll or not, since the user installation has no access to the shared dlls key in HKLM.
Is there a workaround? Any ideas?
Franz
MSG
8th July 2010 17:59 UTC
Hmmm, I think more information is required. I understand you are talking about the situation where both an admin and user level installation have been performed. Then, I take it that you're talking about the uninstallation process of one of the two, is that correct? And you want to access this HKLM key, but why exactly? What information do you want to obtain? And once you have that info, what do you want to use it for?
Animaether
9th July 2010 06:27 UTC
I'm confused also. I suspect you're referring to the oft-abused (in terms of not being used at all, and in terms of applications storing non-shared non-library files in there) registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs
But a User application should still be able to read from that location just fine.
( Note that there's no such key under HKCU, so any crossover problems should be moot: user-space installations should simply not install/uninstall shared DLLs )
franz.reitner
9th July 2010 08:26 UTC
Abused SharedDlls? Where else should we place informations about shared dlls. This is the standard place to do this. However I would like to do it the HKLM...SharedDlls way.
And yes, I'm talking about two installations. One executed by an admin and a second one by a user. Both installation have different targets and files, but share one dll.
In case the admin installs an entry in SharedDlls is generated. The entry contains the path of the dll as entry name and a current number. In case it is the first installation this number will show 1 after the installer finished.
Now the user installs its package in his user area. There is only read access to the mentioned key and thus the user installation process is not able to increment the value of the shareddlls number. It will remain at 1.
After this the admin uninstalls his previously installed package. The uninstall recognizes a 1, decrements and is now advised to remove the shared dll, since the sharing count is at zero. This breaks the user installation.
The user should be able to increment the sharing count to 2, doing by a write access to the key. The admin uninstall would decrement the sharing count from 2 to 1. This would show the admin uninstaller to leave the shared dll in place and not to remove it.
Hope this is more clear than my last post...
MSG
9th July 2010 09:48 UTC
Hmm this is an interesting question. I'll forward it to Anders.
Edit: Assuming I still remember when he comes online, that is. >__>
Animaether
9th July 2010 12:40 UTC
Originally posted by franz.reitner
Abused SharedDlls?
Oh I wasn't referring to you specifically.
Basically one of the problems with SharedDLLs - not so much if you own all the DLLs yourself, but moreso if you're sharing DLLs with 3rd party applications not under your control - is that not every app actually uses SharedDLLs. In other words, if the DLL in question is not 100% yours (i.e. you're installing some open source component), you can't really rely on SharedDLLs.
On the flip side, there are companies that abuse SharedDLLs. For example, my SharedDLLs registry key is filled with entries from several companies that list for a single application their "readme.txt" - which is neither a library, nor is it shared across applications (let alone applications from different parties).
Again, it -is- the correct place to do this for truely shared DLLs.. I was just commenting on the general state of it in the wild :)
Similarly, DLLs shared not globally, but within a single vendor, should more appropiately use a private key, rather than SharedDLLs.
To summarize:
If you're installing files that aren't shared at all, you shouldn't have to do anything special.
If you're installing files that are shared only among your own applications, then you should preferably write to a private key, but SharedDLLs is commonly accepted, with files written to your $COMMONFILES vendor location.
If you're installing files that are, or conceivably could be, shared not just by your own applications but also others, you should use SharedDLLs, with the files typically written to e.g. $SYSDIR . ( Conversely, if you write a library to $SYSDIR, odds are you should be checking SharedDLLs for its refcount entry. )
Originally posted by franz.reitner
In case the admin installs an entry in SharedDlls is generated. The entry contains the path of the dll as entry name and a current number. In case it is the first installation this number will show 1 after the installer finished.
Correct
Originally posted by franz.reitner
Now the user installs its package in his user area. There is only read access to the mentioned key and thus the user installation process is not able to increment the value of the shareddlls number. It will remain at 1.
This is also correct - the user installs the package in -his- (or her) user area. So where does the shared library go? Not to a proper shared location, but to that user's location. At that point it ceases to be a shared library.
I do understand what you're saying, and as far as I can figure out, you would have to get HKLM write access (which tends to mean you'll have to elevate to Admin) for that to work correctly as users can't see other users' registry hive either. But it's looking for a solution for a problem that shouldn't exist :)
Elevating to admin is pretty easy, of course - made a bit more powerful if you use the UAC plugin to do it.
An alternative -might- (never tried it) be in the ACL plugin (
http://nsis.sourceforge.net/AccessControl_plug-in ), if your installer - in its Admin portion - sets the access for the key (this should be a private key, of course, not SharedDLLs) so that all Users can write to it.
franz.reitner
9th July 2010 13:22 UTC
Similarly, DLLs shared not globally, but within a single vendor, should more appropiately use a private key, rather than SharedDLLs.
...yep, that's it! I did it the ini way. Since NSIS is that power- and featureful it was an easy task to put that info in an ini file:).
Thanks to all for discussing with me and placing answers.
..hhmm. I've got a silly newbie question: How to place a quote with 'Originally Posted by <name>'? Sorry, did not find it here in the editor...
MSG
9th July 2010 17:02 UTC
Originally posted by franz.reitner
Sorry, did not find it here in the editor...
Try the tiny 'quote' button at the bottom right of every post.