Just curious- how is file copying made better by a native 64-bit client?
-wraith808
It has features Explorer doesn't have(such as pause and resume copy.) But for the 32 vs 64 bit, if you run a 32 bit file copy or file manager program there is folder redirection due to 32 bit emulation provided by SysWow64. The 32 bit program can turn the redirection off but there are side effects. (In the world of meanings flipped to the opposite, on 64 bit systems the System32 folder has 64 bit modules. SysWow64 has 32 bit ones.)
This is an Explorer replacement. Otherwise it's not that big a deal to run say, FreeCommander 32 bit file manager. I assume there are Dlls hooked in to replace Explorer in the shell but I haven't looked into it in that much detail.
Just bypassing the emulation should give some improvement over the same application in 32 bit. Although memory allocation chunks can be larger. For file copy it likely sets up some memory buffer perhaps after doing some benchmark or just checking the amount of ram. TeraCopy used to have an .ini setting to let you specify the memory buffer size. Some let you have different buffer sizes for network, physical HD etc..
I'm not certain but I think replacing Explorer requires the same bitness. But it's no longer cut and dried. The Explorer in the SysWow64 emulation folder used to be 32 bits. You could bypass some incompatibilities for context menu handlers and the like on x64 by specifying the 32 bit Explorer(this is how my HalfShell utility worked.) But they changed it for some unspecified reason. It was Microsoft's own work-around too, which always struck me as bizarre.
