DonationCoder.com Software > Circle Dock

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

<< < (4/6) > >>

f0dder:
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.-Eóin (February 24, 2010, 09:13 AM)
--- End quote ---
That was new to me, thanks for the info! Btw why make an x64 version of CircleDock, except for "because we can"? Doesn't strike me as an app that would benefit from it.

P.S. the x64 installer is suffixed 'IA64'. To me thats the Itanium 64bit architecture, not AMD64.-Eóin (February 24, 2010, 09:13 AM)
--- End quote ---
Not just to you, that's by definition :)

sgtevmckay:
Btw why make an x64 version of Circle Dock, except for "because we can"? Doesn't strike me as an app that would benefit from it.
-f0dder (February 24, 2010, 12:48 PM)
--- End quote ---

The most I can say is that a 64 bit version helps over come issues that have been discovered in the Windows 7 OS.
If I run the 32 bit Circle Dock from teh Program Files (x86), I run into a lot of issues where some settings and mouse controls do not operate reliably.
At this time: I will say that the 64 bit has corrected this.
I am unsure of all teh nuances that MS included into windows 7 64, but it seems to be more 64bit dependent. That being teh case, my personal experience to date with the CD 64 bit has been stable.

That being said:
I also have CD 32bit installed into an alternative folder...for the most part it works like a champ, but loses mouse communication.
Since this does not seem to widely affect XP or Vista....I am left with the conclusion that it is something that S changed to direct applications towards the 64bit future, or it may be something as simple as tighter UAC controls in Windows 7, or any number of things that I am unaware of.

Ultimately this is not the way we wished to go, but with out a ground up re-write of the entire code under a new language, we do not see an alternative. Understand this is going to bite us in teh rear for making CD compatible with the current Docklet set as all docklets are currently 32 bit, and will not be compatible with CD 64bit.
So we are stuck in an interesting dilemma.

Ultimately the removal of SS2 as being integrated is not a bad thing....The capability will be available, but will be listed as an addon.
As such I am making a tut to explain the what, why's and how to get it back, and the apparent limitations


But for stability, getting back on track, was to accommodate the 64bit environment. CD 64bit is faster and more reliable on my windows 7 64 than the CD 32bit.
As I mentioned, we are not thrilled with it, but at the moment it is what we got.

I am praying that I have spoken well, and not missed anything on this, but I would let Markham be the judge in all this, and comment further if needed.
Eóin hit it right on the nose with the ini file, the problem being faced is that SS2 is integrate, but we are not utilizing a source code, so we can not redirect the ini to an AppData file to handle the R/W that SS2 requires.

Ltan:
Markham: interesting that some people get the UAC trouble and others don't...
-f0dder (February 24, 2010, 02:04 AM)
--- End quote ---

I get the UAC alert, but then again I put it to run as admin.  I later went and modify the folder for Trusted Users Full Control, yeah I know.. I need to just mod the ini file, and CD works fine.

But, I do place myself in the "above average" user so...   

f0dder:
Sarge: your issues sound a bit weird - wish I had the time to help a bit with the CircleDock codebase, I'm sure most issues can be fixed there. I've been using 64bit versions of XP, Vista and Win7, and haven't run into major differences (excluding adding UAC from xp->vista, of course) - and the only noticeable performance impact on 32bit applications I've seen is Foxit Reader, where performance dropped abysmally on 64bit XP (haven't tested rendering of complex PDFs lately, so dunno if it's fixed on Vista/Win7 or in FR itself). For "normal" stuff, I haven't seen performance benefits, and memory requirements tend to go up a bit.

Anyway, if the only UAC-related problem is the SS2 ini file, I hope you'll take my recommendation and change the NTFS ACLs of that file, rather than adding a privilege request to the manifest file...

Markham:
F0dder,

Thank you for your helpful comments! The SS2 ini file is the only external file to be written to, both by CD and the SS2 program, and by default its permissions do not allow for this by normal users (CD's own config files are unaffected as they're not subject to UAC protection). What seems a bit strange to me is that ini files are normally created through OS calls (eg: WritePrivateProfileString()) and yet the OS doesn't automatically set the correct ACL flags on ini files it creates!

Fortunately the installer can set the correct permissions when it installs this file and this is the route I will take. And that, incidentally, is another good reason not to distribute CD in Zip files as some proponents of Portable Applications would have me do!

As for 64-bit OS's my experience is somewhat limited - to less than one week. What I can say is that I'm unable to use Visual Studio 2008 on that platform to actively develop CD as should I try to load the Main Settings dialog, Visual Studio crashes with an "out of memory" fault (and that's on a 4GiB machine). Instead I use a 2GiB 32-bit machine and that same dialog loads faultlessly (and with oodles of memory to spare). So, from my experience, running 32-bit applications on a 64-bit platform is not ideal hence my decision to release a 64-bit version of CD.

As for 64-bit applications requiring more memory, you're probably correct however the extra amount of memory CD-64 requires (over CD-32) is negligible but CD-64 does seem considerably more responsive than CD-32 on either a 32-bit or 64-bit platform (assuming the CPUs are of equivalent speed).


Mark

Navigation

[0] Message Index

[#] Next page

[*] Previous page