DonationCoder.com Software > Circle Dock

UAC Issues - Vista/Windows 7, 32 & 64-bit

<< < (3/6) > >>

rssapphire:
We could simply tell users to modify Circle Dock's properties so that it is run as if the user is an administrator; however inexperienced PC users may not be too comfortable with having to do that.-Markham (February 23, 2010, 04:41 AM)
--- End quote ---

I'm an experienced user and I would not to that with a program launcher as all the programs launched from it would also run with administrator rights. This is why I tried to use my old standby PowerPro with my new Win7 box and quickly decided not to. To get many PP features to work right, it had to be run as administrator -- but then all the programs it started were also running as admin. :(

sgtevmckay:
agreed
I do not want this, and it is exaCTLY WHAT WE WANT TO AVOID....(oops caps) :-[
We will make a working product then folks can addon from there.
But I do not wish to circumvent the UAC as most folks do utilize it.

Have faith and give us time folks we will make you proud  :Thmbsup:

Markham:
Now, I still firmly believe that UAC trouble = bug in the code somewhere, and the top priority should be chasing down the bugs. That said, if your proposed stop-gap solution is to make people run in elevated mode (ugh!), there's another radical (but far less radical) solution: setting the NTFS ACL permissions for the CircleDock install folder so that non-elevated users can write there. Assuming that the code bug involves trying to write to this folder, and not registry or something else, this will be a stopgap that's far better than running elevated.
-f0dder (February 23, 2010, 05:52 PM)
--- End quote ---
If we ignore, for the moment, StandaloneStacks, there are just two files that Circle Dock writes to in order to store configuration data and the placement of these files depends on where Circle Dock is installed. If it is installed to a UAC-protected area, then the configuration files are stored in %APPDATA% (ie: "C:\{username}\AppData\Local\CircleDock"); but if Circle Dock is not installed to a UAC-protected area - such as a USB memory stick - then those configuration files are stored in Circle Dock's "System\Settings" folder. All Circle Dock's configuration data file I/O is contained within two fairly small modules and I'm 100% confident they are working correctly.

Unfortunately, the same can not be said for the add-in program, StandaloneStacks. This insists on having its configuration data file in the same folder as itself and this will be a potential cause of UAC protection errors. To try to overcome this problem, there are three options:

* Do nothing and hope the problem goes away and/or doesn't affect too many people. I think you will agree that this is not really an option!
* Strip-out all internal support for StandaloneStacks. This option was favoured by both the Sarge and myself and, in fact, the Sarge has a tutorial almost completed which tells users how to add StandaloneStacks to Circle Dock as an add-in. Upon reflection, I don't really like this having spent the best part of a week adding support for SS in the first place.
* Move the add-in to a non UAC-protected location, for example "C:\CircleDock Add-ins".
The Sarge and I had a lengthy chat last night (my time) and it's quite clear to us that UAC-related issues don't affect all PCs running the self-same operating system in the same way. Some PCs are affected, others aren't. I have two Windows 7 machines, one has a 32-bit OS (with UAC disabled), the other has a 64-bit OS (with UAC fully-enabled); my wife uses a Windows 7 (32-bit) laptop (with UAC fully-enabled). I use the 32-bit machine to do most of the development of Circle Dock and have turned-off UAC as it has the potential of getting in the way. Circle Dock is tested on all three machines before anyone else sees it, including my testers. I don't expect to get any UAC-related issues on the development machine but I would expect to see them on the laptop and Win-64 machines. The problem is, I don't. At all. Ever. The Sarge, on the other hand, also running an Athlon-based 64-bit PC does see UAC type issues.

I welcome your further comments :)



Mark

f0dder:
Markham: interesting that some people get the UAC trouble and others don't... there's only one thing I can think of off top of my head, and that's whether UAC has been disabled at some point on some of the machines, especially when initially installing/running CircleDock? I recall something related to shadow storage not kicking in properly if UAC has been disabled while installing apps, and is later installed.

Which file(s) are StandaloneStacks messing with? Perhaps Sarge can try setting the NTFS ACLs of just the effected file(s) to give non-elevated users write access to those... again, it's a stop-gap, but if it works it's an OK stopgap - and will also tell you that it's just those files triggering the problem.

Eóin:
Out of sheer curiosity I looked into it and f0dders suggestion of adding read/write permission to the 'standalonestack.ini' does indeed work as a stopgap.

UAC file virtualisation compatibility doesn't kick in for native x64 applications, my guess is that's why not everyone see the issue, they may be running the 32bit version on a x64 OS.

P.S. the x64 installer is suffixed 'IA64'. To me thats the Itanium 64bit architecture, not AMD64.

Navigation

[0] Message Index

[#] Next page

[*] Previous page