What are the benefits of TC in 64-bit?
Moderators: white, Hacker, petermad, Stefan2
- sergeycentral
- Junior Member
- Posts: 34
- Joined: 2003-07-24, 02:48 UTC
- Location: USA
What are the benefits of TC in 64-bit?
What are the benefits of having total commander in 64-bit?
Specifically to the application, not just general 64-bit benefits (extended memory, etc).
Which functions should we expect to see a performance enhancement in?
internal zip packer?
encoding / decoding files?
creating / verifying checksums?
Specifically to the application, not just general 64-bit benefits (extended memory, etc).
Which functions should we expect to see a performance enhancement in?
internal zip packer?
encoding / decoding files?
creating / verifying checksums?
Ghisler wrote here
So, don't expect big difference between TC 32x and TC 64x.ghisler(Author) wrote: The 64-bit bit version is mainly for ignorant people who think that 64-bit is "better", and for some very specific usage cases (e.g. only 64-bit extension available, or 64-bit Windows PE with no 32-bit support).
- sergeycentral
- Junior Member
- Posts: 34
- Joined: 2003-07-24, 02:48 UTC
- Location: USA
- sergeycentral
- Junior Member
- Posts: 34
- Joined: 2003-07-24, 02:48 UTC
- Location: USA
Privet, kak dela? I forgot TC was a file manager... some file operations like zip packing can be greatly improved. esp. if the algorithm is as complex as 7zip...
-edit-
but i dont see why the time had been spent on 64-bit support when things such as automatic hot fix update could have been worth investigating...
-edit-
but i dont see why the time had been spent on 64-bit support when things such as automatic hot fix update could have been worth investigating...
- ghisler(Author)
- Site Admin
- Posts: 48012
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
There are no big benefits, but you can now compare really big files (several GBytes), e.g. large log files or so.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
- ghisler(Author)
- Site Admin
- Posts: 48012
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
32-bit is NOT virtualized on 64-bit Windows! That's the great thing about AMD64 (which was later adapted by Intel): It can run 32-bit and 64-bit programs natively in parallel, something which other 64-bit processors like Intel Itanium can't do.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Not virtualized in the usual meaning of this word, but still 32-bit application are running via some layer provided by OS for virtualizing file system and registry — its the term Microsoft itself uses.ghisler(Author) wrote:32-bit is NOT virtualized on 64-bit Windows!
So, 32-bit code is executed natively in terms of processor instructions, but is virtualized in terms of operating system libraries and interfaces.
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 10.52 / Win10 x64
Using TC 10.52 / Win10 x64
- ghisler(Author)
- Site Admin
- Posts: 48012
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
Hmm, are you sure? The libraries are there in both 32-bit and 64-bit form. I assume that the user level code is handled entirely in these 32-bit libraries, while the calls to kernel mode of course call to the 64-bit drivers.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
ghisler(Author)
I don't know the internal details of this mechanism, did not read much about them yet, but undoubtedly the system calls are performed in 64-bit mode since the kernel is 64-bit only, so this transformation has to be performed in user-mode level. As far as I can see, all 32-bit processes have several 64-bit DLLs loaded into their address space, including ntdll.dll and wow64.dll; judging from the name, the latter should be responsible for substituting different file system and registry paths.
But, actually, it's all just a matter of terms. I suppose this mechanism (whatever its internal implementation might be) can be treated as a layer between the application and operation system which performs all necessary substitutions, even if there is no such layer from the point of view of code organization. Besides, Microsoft chose the term "file system and registry virtualization" and now uses it across the MSDN and other technical resources, so I think we can stick to the same term without fear of being not understood.
I don't know the internal details of this mechanism, did not read much about them yet, but undoubtedly the system calls are performed in 64-bit mode since the kernel is 64-bit only, so this transformation has to be performed in user-mode level. As far as I can see, all 32-bit processes have several 64-bit DLLs loaded into their address space, including ntdll.dll and wow64.dll; judging from the name, the latter should be responsible for substituting different file system and registry paths.
But, actually, it's all just a matter of terms. I suppose this mechanism (whatever its internal implementation might be) can be treated as a layer between the application and operation system which performs all necessary substitutions, even if there is no such layer from the point of view of code organization. Besides, Microsoft chose the term "file system and registry virtualization" and now uses it across the MSDN and other technical resources, so I think we can stick to the same term without fear of being not understood.
Flint's Homepage: Full TC Russification Package, VirtualDisk, NTFS Links, NoClose Replacer, and other stuff!
Using TC 10.52 / Win10 x64
Using TC 10.52 / Win10 x64
-
- Junior Member
- Posts: 18
- Joined: 2009-05-07, 11:46 UTC
You should read:
http://msdn.microsoft.com/en-us/library/aa384249%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/aa384249%28v=VS.85%29.aspx
The system isolates 32-bit applications from 64-bit applications, which includes preventing file and registry collisions. Console, GUI, and service applications are supported. The system provides interoperability across the 32/64 boundary for scenarios such as cut and paste and COM. However, 32-bit processes cannot load 64-bit DLLs for execution, and 64-bit processes cannot load 32-bit DLLs for execution. This restriction does not apply to DLLs loaded as data files or image resource files; for more information, see LoadLibraryEx.