Printable View
Hi,
this might be a fairly stupid question, but advice would be welcome.
We've produced a simple VB6 app that talks to a Silabs UART->USB device via a virtual comport. We've pacaged it with the satndard deployment wizard to result in a silabs DLL being placed in the target installation directory (silabs says this required.
When installed on a new machine it works fine for administrator accounts but generates DLL errors (can't open port) for user accounts.
Any advice?
Many thanks,
Mark.
Welcome to the Forums.
Thats because Limited Accounts in XP have permission restrictions to the Windows and System32 directory which is necessary to install dependancy files for apps. Also, to register the dlls and ocxs they need permissions to read/write to the registry.
many thanks for the prompt welcome & reply.....
Thats because Limited Accounts in XP have permission restrictions to the Windows and System32 directory which is necessary to install dependancy files for apps. Also, to register the dlls and ocxs they need permissions to read/write to the registry.[/color][/QUOTE]
Just to be sure I'm clear, I'm not having problems with installing from a limited account, but rather running from one once I've installed from an administrator one. In fact I even made a new, second, administrator one after installing & it runs fine from there as well.
I got the impression that you were discussing installing rather than running: am I correct (& if so can you still help!)?
Thanks,
Yes, but if your app access certain protected areas they will fail unless they are admins. I dont know all that your app does so I can only generalize. ;)
hi,
thanks for further reply. After some time on the web yesterday (UK) evening I concluded the same. In fact the Silabs DLL we use queries the registry to get COM ports associated with USB PID's (for a virtual COM port). I guess this is where the issue lies. I'll contact the Silabs tech support people. Ultimately it's not a problem - I just wanted to be good and let (research) end user run program without admin privileges.
(however, on Tuesday it might get demoed on a Vista machine.......I don't want to think about that now......!)
I really appreciate your taking the trouble to reply.
Mark.
Since you are using a third party component its very unlikely that you will be able to code around it. You may have to recreate the functions and features of the dll as a workaround so you can elevate the HKLM registry reads and what nots.
The problem is that when the component tries to read/write to the registry in areas other then the HKCU, Vista will use Registry Virtualization where it will "redirect" the write from HKLM (for example) to a different safe authorized location under the HKCU.