Other Software > Found Deals and Discounts
XYplorer lifetime license PRO 50% off
AbteriX:
With the information that 64-bit shell extensions are supported with a config option, I can't think of a reason that the main program needs to be 64-bit.
Other than to say that it's 64-bit. I don't think there's any functional reason for it. Or am I missing something?
-mwb1100 (June 06, 2014, 11:05 PM)
--- End quote ---
There are only minimal, for most user not relevant reasons, like:
- you can't browse to folder "sysnative" (the 64-bit-"system32" folder from the view of a 32-bit program on 64-bit OS)
- you can't allocated more than 3,5GB RAM for processes launched from a 32-bit program (as in starting a program from within the 32-bit app, which in turns needs many RAM for processing)
- every app started from an 32-bit app will only see the 32-bit environment (as in launching Regedit and you will not see "Syswow6432node")
For such tasks you will have to utilize WinExplorer.
Most user this may not affect, it could only led to confusions if you would look for something above mentioned from within a 32-bit app.
All in all no real reason from standing back from a 32-bit app on 64-bit OS. Most user will never see any differences.
.
mwb1100:
Other than to say that it's 64-bit. I don't think there's any functional reason for it. Or am I missing something?
-mwb1100 (June 06, 2014, 11:05 PM)
--- End quote ---
There are only minimal, for most user not relevant reasons, like:
- you can't browse to folder "sysnative" (the 64-bit-"system32" folder from the view of a 32-bit program on 64-bit OS)
- you can't allocated more than 3,5GB RAM for processes launched from a 32-bit program (as in starting a program from within the 32-bit app, which in turns needs many RAM for processing)
- every app started from an 32-bit app will only see the 32-bit environment (as in launching Regedit and you will not see "Syswow6432node")
For such tasks you will have to utilize WinExplorer.
Most user this may not affect, it could only led to confusions if you would look for something above mentioned from within a 32-bit app.
All in all no real reason from standing back from a 32-bit app on 64-bit OS. Most user will never see any differences.
-AbteriX (June 07, 2014, 05:23 AM)
--- End quote ---
These issues either have been solved by XY or they just don't apply to XY in the first place:
- Even though it's a 32-bit application, XY will show the 'real' System32 directory without having to use the sysnative alias hack (there are APIs a 32-bit application can use to tell Windows to stop the redirection). There's a configuration option to turn this behavior on/off ("Show the real System32 directory"), but it's on by default, I think. So when you navigate to the System32 directory, you will see the same files that are actually in the System32 directory just as if a 64-bit file manager were browsing that directory.
- being limited to 3.5GB of virtual memory is unlikely to be a limitation to XY. In fact, I'm sure most users would be up in arms if they noticed it using more than a few hundred MB (mine is using around 70MB at the moment). The virtual memory limitation of a 32-bit process has no bearing on the virtual memory available to processes launched - they get their own allocation of virtual memory that is completely separate from the launching process.
- again, an app launched from XY has it's own virtual memory allocation and the WOW64 redirection that the OS imposes on 32-bit process has nothing to do with the process that launches an app. If the newly launched process is 32-bit, then it will get the WOW64 redirections whether or not it is launched from a 64-bit or 32-bit app. Similarly, a 64-bit app launched from a 32-app will *not* have those redirections applied, and will have the full terabytes-large virtual address space available to it.
So the bottom line is that with XY configured to show 64-bit shell extensions, it's functionally equivalent to a 64-bit file manager as far as I know. Doing a ton of work to make it a true 64-bit application would be a compete waste of effort for no gain other than to be able to say "XY is a 64-bit app".
And to waste Don's efforts on that would be a shame.
Jibz:
So the bottom line is that with XY configured to show 64-bit shell extensions, it's functionally equivalent to a 64-bit file manager as far as I know. Doing a ton of work to make it a true 64-bit application would be a compete waste of effort for no gain other than to be able to say "XY is a 64-bit app".
And to waste Don's efforts on that would be a shame.
-mwb1100 (June 07, 2014, 05:13 PM)
--- End quote ---
As far as I know XY is written in VB6, which means it won't be 64-bit or multi-threaded. But as long as it works for people, and Microsoft continues to support running VB6 apps (which they do at least for the lifetime of Windows 8 ), there should be little problems.
At some point WoW64 will probably be phased out (when we are all on 128-bit processors), just like WOW was removed from 64-bit Windows, but that's further into the future, so as long as you don't need a file manager on something like WinPE 64-bit, that's not a real concern right now either.
Personally, I think the lack of multi-threading is a lot worse than being 32-bit, if you want to worry about something.
tomos:
Personally, I think the lack of multi-threading is a lot worse than being 32-bit, if you want to worry about something.
-Jibz (June 07, 2014, 05:33 PM)
--- End quote ---
^this
(I actually thought 64bit and multi-threading were synonymous :-[)
Innuendo:
Personally, I think the lack of multi-threading is a lot worse than being 32-bit, if you want to worry about something.
-Jibz (June 07, 2014, 05:33 PM)
--- End quote ---
Multi-threading was the next thing I was going to ask about. I simply can't live without that.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version