Welcome Guest.   Make a donation to an author on the site October 26, 2014, 02:46:30 AM  *

Please login or register.
Or did you miss your validation email?


Login with username and password (forgot your password?)
Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.


You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.
 
Free DonationCoder.com Member Kit: Submit Request.
   
   Forum Home   Thread Marks Chat! Downloads Search Login Register  
Pages: [1] 2 Next   Go Down
  Reply  |  New Topic  |  Print  
Author Topic: UAC Issues - Vista/Windows 7, 32 & 64-bit  (Read 9285 times)
Markham
Honorary Member
**
Posts: 404


see users location on a map View Profile WWW Give some DonationCredits to this forum member
« on: February 23, 2010, 04:41:27 AM »

It seems that a number of users are experiencing problems with Circle Dock which we have identified as being allied to the use of User-Access Control ("UAC") protection in these two operating systems. As you probably know, Microsoft reacted to pressure to make its operating systems more secure, particularly from malware, by introducing us to the joys of UAC with the launch of Windows Vista.

UAC comes into play whenever you install a program into "C:\Program Files" or "C:\Program Files (x86)" and that program (attempts to) modify its own configuration files which, say Microsoft, should ideally be placed in the %APPDATA% folder which Circle Dock does. If Circle Dock is not run by a user with full administrator privileges, it will either crash or a UAC warning dialog will appear - depending on the operating system and UAC level you've selected.

There are several ways we can overcome this:
  • 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.
  • We could instruct users not to install Circle Dock in either "C:\Program Files" or "C:\Program Files (x86)". Whilst that undoubtedly works, it does cause problems for the Installer and (fact of life) users rarely read documentation!
  • We could do what Microsoft themselves do when they need elevated privileges which is to test the current privilege level and if the user is not an administrator, restart the program using a particular keyword in the start-up information block; TaskManager is an example of such a program which works in this way. The problem with that is that it will likely interfere with the multiple-instance and command-line handling.
  • The fourth way is, in effect, an automated version of the first which is achieved by "marking" the executable with a special manifest that tells Windows that it is a trusted application and is to be run as administrator.


In future releases we will be using the fourth option (trusted application manifest) and this should ensure that Circle Dock runs unhindered and can update its configuration files without triggering a UAC exception.



Mark

« Last Edit: February 23, 2010, 04:48:43 AM by Markham » Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #1 on: February 23, 2010, 08:56:38 AM »

...or you could track down why your code require elevation while it really shouldn't?
Logged

- carpe noctem
sgtevmckay
Moderator
*****
Posts: 836


Magis Esse

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #2 on: February 23, 2010, 09:08:33 AM »

f0dder

we are open for ideas  tellme
Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #3 on: February 23, 2010, 09:12:48 AM »

Btw, sorry if that remark came off wrong - I'm not saying it's necessarily going to be an easy task!

Can you reproduce the problem on your own machines? Do you have a crash location, or even an idea what exactly is triggering? Tried tracing with sysinternals' Process Monitor (not to be confused with their Process Explorer) and seeing which file paths, and possibly registry keys, are being attempted accessed? There's a slight chance it could be keyboard-hook related as well; they do normally work from non-elevated apps, though, but then the keys just don't work when an elevated app has focus.
Logged

- carpe noctem
Dormouse
Supporting Member
**
Posts: 996

View Profile Give some DonationCredits to this forum member
« Reply #4 on: February 23, 2010, 03:36:34 PM »

UAC comes into play whenever you install a program into "C:\Program Files" or "C:\Program Files (x86)" and that program (attempts to) modify its own configuration files

Does that mean a portable version would be unaffected?
Logged
sgtevmckay
Moderator
*****
Posts: 836


Magis Esse

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #5 on: February 23, 2010, 05:08:49 PM »

????


It you place a self contained or "Portable Application" of any kind in to Program Files or Program Files (x86), and there is any type of I/O or R/W operation. It will be stopped by the Windows UAC.

This is common knowledge.

That being the case: I do not understand your questions
Logged
Dormouse
Supporting Member
**
Posts: 996

View Profile Give some DonationCredits to this forum member
« Reply #6 on: February 23, 2010, 05:19:02 PM »

Program Files are only for installed programs. I've never heard of anyone placing a portable program in there.
And even if someone did, they could simply move it elsewhere when they realised it was causing a problem.
Logged
sgtevmckay
Moderator
*****
Posts: 836


Magis Esse

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #7 on: February 23, 2010, 05:27:12 PM »

If you are trying to insinuate that to move a portable into the Program Files is not an install... stop there! As it seems you are splitting hairs and making more issue than is required here.

It seems you are trying to tell me you place a screw in an engine, you do not install it !?!!
Regardless of HOW the program ends up in UAC monitored Folders' It is inferred that it was installed

If you have something useful to contribute fine....I see you are a long time member here, but if you are just trying to be funny, you are far from the mark, and are creating more issues, and a more confusing situation than what already exists.

Understand:
We who use Portable or Self Contained programs are actually in the minority, the average person wants an install and run program, and this is what we are attempting to create. Not everyone is Linux Distro savvy and understand the impact and the lack of complexity that self contained programs present, and it is not our intention to educate along those lines.

As it stands: Circle Dock can be installed to almost any folder directory, and made portable in a simple manner, beyond the Zip Packaging that was designed as a corporate and back up solution.
The settings to make Circle Dock a self contained program is there in the settings, after install
« Last Edit: February 23, 2010, 05:34:35 PM by sgtevmckay » Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #8 on: February 23, 2010, 05:52:04 PM »

If you are trying to insinuate that to move a portable into the Program Files is not an install... stop there! As it seems you are splitting hairs and making more issue than is required here.
Sorry for splitting hairs smiley, but that wouldn't be an install - no registry keys affected, no add/remove program entry added, no start menu item added, etc.

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.
Logged

- carpe noctem
sgtevmckay
Moderator
*****
Posts: 836


Magis Esse

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #9 on: February 23, 2010, 06:10:22 PM »

As far as I know, Circle Dock does not write anything to the Registry.
The problem actually lies in the integration of the Standalone stacks 2
Apparently Standalone Stack 2 will be reluctantly removed as an integrated program in Circle Dock, but for two very large issues.
1.) SS2 requires that it R/W to itself...This automatically sets off the UAC
2.) the SS2 libraries are compiled in 32bit, so although SS2 works (somewhat) in the 64 bit version, its assimilation is not a complete one.

Bottom line is that Standalone stack 2 is old and busted, and we will move on to the new hotness  Thmbsup
This is no reflection on Christian (Chris "n" Soft), he is simply working with the tools he received from Montagno at Aqua-Soft


Something to consider for the long time "experienced" members here: Did any one consider, but no one asked, If we already knew what the issues are???
I appreciate the help, when it appears there is help to be had, but several assumptions have been made without understanding all the facts.
Several conclusions have been drawn, and many were just, well.....let's say I am not a happy camper  mad
Logged
rssapphire
Supporting Member
**
Posts: 58


View Profile Give some DonationCredits to this forum member
« Reply #10 on: February 23, 2010, 09:22:09 PM »

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.

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. Sad
Logged

RetroRoleplaying -- Tabletop Roleplaying Games Before D20
Software Gadgets Blog -- Interesting Software, Mostly Free
sgtevmckay
Moderator
*****
Posts: 836


Magis Esse

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #11 on: February 23, 2010, 09:33:53 PM »

agreed
I do not want this, and it is exaCTLY WHAT WE WANT TO AVOID....(oops caps) embarassed
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

Logged
Markham
Honorary Member
**
Posts: 404


see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #12 on: February 23, 2010, 11:30:17 PM »

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.
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 smiley



Mark

Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #13 on: February 24, 2010, 02:04:55 AM »

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.
Logged

- carpe noctem
EĆ³in
Charter Member
***
Posts: 1,400


O'Callaghan

see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #14 on: February 24, 2010, 09:13:18 AM »

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.
Logged

Interviewer: Is there anything you don't like?
Bjarne Stroustrup: Marketing hype as a substitute for technical argument. Thoughtless adherence to dogma. Pride in ignorance.
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #15 on: February 24, 2010, 12:48:37 PM »

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.
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.
Not just to you, that's by definition smiley
Logged

- carpe noctem
sgtevmckay
Moderator
*****
Posts: 836


Magis Esse

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #16 on: February 24, 2010, 03:49:27 PM »

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.

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.
Logged
Ltan
Supporting Member
**
Posts: 24

View Profile Give some DonationCredits to this forum member
« Reply #17 on: February 24, 2010, 04:06:38 PM »

Markham: interesting that some people get the UAC trouble and others don't...

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...   
Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #18 on: February 24, 2010, 04:31:58 PM »

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...
Logged

- carpe noctem
Markham
Honorary Member
**
Posts: 404


see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #19 on: February 24, 2010, 11:20:09 PM »

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
Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #20 on: February 25, 2010, 03:29:30 AM »

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!
Technically, it does set the right ACLs - from the design philosophy that %ProgramFiles% and %ProgramFiles(x86)% are protected paths. I know a lot of developers don't agree with this, but it's been kinda official since the NT4 days (and probably earlier) - damn Microsoft for delaying "default user is non-admin" until Vista, and for continuing the Win9x series for so long smiley

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!
Perhaps do it like mouser? EXEs that are basically self-extracting (and thus can be extracted manually without running) archives, with an embedded setup/fixup executable? That should cater to both camps.

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).
That sounds pretty strange - I've used it on XP-64/2gig, XP-64/8gig, Win7-64/8gig without problems. I know there's some problems with VS2008 if you install IE7 or later, but afaik it doesn't lead to memory errors, and I've only heard it in relation to MFC (since the MFC designers use html+js :-s).

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
It definitely depends on the type of application; x86-64 instruction has relatively efficient encodings so code doesn't necessarily bloat super much - and MS was smart enough to have .NET datatypes be size-specified, so your integers etc don't double in size, only pointers (there might be some data alignment size-bloat as well, too, though - haven't checked what happens with .NET in this respect).

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).
Interesting, I wonder what causes that - CircleDock doesn't strike me as an application that would benefit from it. Perhaps it's not because of compiling for x64, but because x64 doesn't include SS2 and SS2 causing the slowdowns?

Then again, the one 32bit application I've seen perform abysmally on x64, Foxit Reader, did so apparently because of drawing operations - iirc it uses GDI+. So there might be certain graphics components that suffer from WoW64 translation overhead (regular GDI, DirectX and OpenGL don't seem to be affected, though).

Ah well, this is drifting slightly off-topic from the original post, even if it's related to CircleDoc and IMHO is stuff of interest smiley
Logged

- carpe noctem
Stoic Joker
Honorary Member
**
Posts: 5,334



View Profile WWW Give some DonationCredits to this forum member
« Reply #21 on: February 25, 2010, 07:12:20 AM »

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.
That is odd, as I'm still heavily using VS 2005 on Win7 x64 on a daily basis and it's never blinked. Both T-Clock32 & x64 were developed with VS 2005 on Vista x64 (back when), using two different project files that pointed at the same source pool.

Quote
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).
I keep reading this (assuming I'm missing something) wondering how you're getting CD64 to run on a 32-bit platform - That's not supposed to be possible.

Side note: The only reason I had to create T-Clock x64 (which does use quite a bit more memory) was because of the Clock Window Shell Hook (injecting 32-bit hook into 64-bit process no worky), other then that it could have stayed 32-bit and been fine. (...Well except for the 9x era hardware access code that had to be stripped out for Vista).
Logged
f0dder
Charter Honorary Member
***
Posts: 8,774



[Well, THAT escalated quickly!]

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #22 on: February 25, 2010, 07:51:50 AM »

I keep reading this (assuming I'm missing something) wondering how you're getting CD64 to run on a 32-bit platform - That's not supposed to be possible.
I'm reading that as "the 64-bit version works better [on 64-bit OS] than the 32-bit version [whether it's run on 32- or 64-bit OS]" - anything else wouldn't make sense smiley
Logged

- carpe noctem
Markham
Honorary Member
**
Posts: 404


see users location on a map View Profile WWW Give some DonationCredits to this forum member
« Reply #23 on: February 25, 2010, 09:24:34 AM »

Technically, it does set the right ACLs - from the design philosophy that %ProgramFiles% and %ProgramFiles(x86)% are protected paths. I know a lot of developers don't agree with this, but it's been kinda official since the NT4 days (and probably earlier) - damn Microsoft for delaying "default user is non-admin" until Vista, and for continuing the Win9x series for so long smiley
Until I took over the development, Circle Dock's configuration files were stored in its own path and one of the changes I made quite early on is to move them away to AppData if Circle Dock is being run from Program Files/Program Files (x86). Either not many people were using Circle Dock under Vista or Windows 7 or they put up with the UAC dialogs, I guess the former as the download statistics, for the month to date, show that 97% of downloads are onto XP machines.

Quote
That sounds pretty strange - I've used it on XP-64/2gig, XP-64/8gig, Win7-64/8gig without problems. I know there's some problems with VS2008 if you install IE7 or later, but afaik it doesn't lead to memory errors, and I've only heard it in relation to MFC (since the MFC designers use html+js :-s).
Unfortunately with Windows 7 you automatically get IE7 which immediately nags you to upgrade to IE8.

Quote
It definitely depends on the type of application; x86-64 instruction has relatively efficient encodings so code doesn't necessarily bloat super much - and MS was smart enough to have .NET datatypes be size-specified, so your integers etc don't double in size, only pointers (there might be some data alignment size-bloat as well, too, though - haven't checked what happens with .NET in this respect).
Interestingly the core executable is about 50KB smaller when compiled as 64-bit that it is compiled as 32-bit. However, after binding-in the support DLLs, the 32-bit version is about 3KB smaller.

Quote
Interesting, I wonder what causes that - CircleDock doesn't strike me as an application that would benefit from it. Perhaps it's not because of compiling for x64, but because x64 doesn't include SS2 and SS2 causing the slowdowns?
SS2 is included in the 64-bit version - the Sarge would kill me if I removed it! SS2 does run but there's a noticeable delay, amounting to several seconds, before it displays the Stack (oh well, not my problem!). In general though - and ignoring SS2 - Circle Dock does appear to run faster and smoother as a 64-bit app than the 32-bit version under either 32-bit or 64-bit OSes.


Mark
Logged
sgtevmckay
Moderator
*****
Posts: 836


Magis Esse

see users location on a map View Profile WWW Read user's biography. Give some DonationCredits to this forum member
« Reply #24 on: February 25, 2010, 10:24:33 AM »

Quote
Interesting, I wonder what causes that - CircleDock doesn't strike me as an application that would benefit from it. Perhaps it's not because of compiling for x64, but because x64 doesn't include SS2 and SS2 causing the slowdowns?
SS2 is included in the 64-bit version - the Sarge would kill me if I removed it! SS2 does run but there's a noticeable delay, amounting to several seconds, before it displays the Stack (oh well, not my problem!). In general though - and ignoring SS2 - Circle Dock does appear to run faster and smoother as a 64-bit app than the 32-bit version under either 32-bit or 64-bit OSes.


Mark
[/quote]

No no...I am a proponent of removing SS2, as I have said, I can live with utilizing as an addon.
This can be relegated to the addon list, and a tutorial can be made.
This is the logical way to go, especially considering that we can not adjust the ini path to the appropriate AppData file.
teh slowness experienced in SS2 in a 64bit environment is well discussed and documented at Aqua-Soft...The only reasonable conclusion is teh 32 bit libraries in use, combined with the additional advancements of SS2 over the original Standalone Stack...needless to say: SS2 is a far advanced program over the original.

I must confirm that Circle Dock (64bit) renders faster and is more responsive in the Windows 7 64bit enviro.
I have been deeply considering the "why" of this, and I am starting to think of an old post that was created here:
http://www.donationcoder....18019.msg161278#msg161278
The bottom line would be: 64bit handles graphics better (period)
Personal experience.
So if the graphics issue, initially diagnosed my Dormouse, remain from the Alpha builds, then this could account for the slower response and rendering of Circle Dock in a 32 bit enviro.
I could be way off, But I figure this is something that may need to be explored, then confirmed or ruled out.
Logged
Pages: [1] 2 Next   Go Up
  Reply  |  New Topic  |  Print  
 
Jump to:  
   Forum Home   Thread Marks Chat! Downloads Search Login Register  

DonationCoder.com | About Us
DonationCoder.com Forum | Powered by SMF
[ Page time: 0.057s | Server load: 0.06 ]