DonationCoder.com Software > Circle Dock
UAC Issues - Vista/Windows 7, 32 & 64-bit
f0dder:
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!-Markham (February 24, 2010, 11:20 PM)
--- End quote ---
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 :)
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!-Markham (February 24, 2010, 11:20 PM)
--- End quote ---
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).-Markham (February 24, 2010, 11:20 PM)
--- End 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).
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-Markham (February 24, 2010, 11:20 PM)
--- End 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).
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).-Markham (February 24, 2010, 11:20 PM)
--- End 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?
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 :)
Stoic Joker:
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.-Markham (February 24, 2010, 11:20 PM)
--- End quote ---
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.
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).
--- End quote ---
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).
f0dder:
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.-Stoic Joker (February 25, 2010, 07:12 AM)
--- End quote ---
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 :)
Markham:
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 :)-f0dder (February 25, 2010, 03:29 AM)
--- End quote ---
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.
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).
--- End quote ---
Unfortunately with Windows 7 you automatically get IE7 which immediately nags you to upgrade to IE8.
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).
--- End quote ---
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.
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?
--- End quote ---
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
sgtevmckay:
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?
--- End quote ---
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:
https://www.donationcoder.com/forum/index.php?topic=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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version