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.
The dotNET bytecode for 32- and 64-bit versions are probably going to be very similar - the runtime JIT'ed code is a different amtter, though
. If using the same assemblies, I would actually have thought the only difference was the manifest stating that machine type was x64 rather than x86 (or neutral).
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:
The bottom line would be: 64bit handles graphics better (period)
What graphics technology does CircleDock use, though?
As I've mentioned previously, the one slowdown I've seen was an app using GDI+... for DirectX, OpenGL and regular GDI I haven't been able to see a difference between 32- and 64-bit OSes (well, I don't have any intensive regular GDI apps, so perhaps regular GDI could be affected as well)
I could be way off, But I figure this is something that may need to be explored, then confirmed or ruled out.
Indeed - and perhaps an alternate graphics library should be tested? Might be considerable work, but if CD currently uses GDI/GDI+, it could probably get a nice speed boost from moving to something that leverages hardware acceleration properly?
What's the status of the StandaloneStack thing, btw? From my (very quick and superficial) look, it seems that there's no official site for it, only attachments in forum posts? Active development, closed source, ...?