Page 1 of 1
64-bit version
Posted: 19 Feb 2014 16:39
by Signum
Welcome everybody ;-)
Will there be 64-bit version of XYplorer? The most irritating thing about 32-bit version of this app on 64-bit OS is context menu... It needs separate process to bring the context menus. Sometimes it takes about several seconds to appear, in 64bit TotalCommander it works perfect. Any plans for releasing x64?
Re: 64-bit version
Posted: 20 Feb 2014 04:28
by RalphM
Welcome to the forum.
If you search the forum you'll find more than enough threads about this already, so there's not really a need for yet another one.
Current state of affairs is AFAIK that a 64bit XY will evolve as soon as there's a 64bit compiler available for VB6.
Re: 64-bit version
Posted: 22 Feb 2014 22:09
by 40k
Long story short? No.
Microsoft needs to develop a 64 bit compiler for VB6 for this to happen. They're never going to revive VB6. This is most likely a political decision made by management rather than by actual developers.
Re: 64-bit version
Posted: 28 Nov 2016 01:38
by n37
Too bad. Good program but no future, numerous inconveniences create situations where opening an explorer window is easier than working within xyplorer. Such a shame.
Re: 64-bit version
Posted: 29 Nov 2016 16:09
by Jerry
What other issues in XYplorer (besides the context menu) do you find with the 32-bit version that would be improved with 64-bit? In my experience, the biggest payoff of 64 bit is it's larger memory allocation. But I've never run up against the 32-bit per-process memory limit in XYplorer. Whereas say, Firefox, is awful at 32-bit since I typically have multiple windows and multiple tabs and it's constantly page-faulting, even though I have 64GB of total RAM in my system.
Re: 64-bit version
Posted: 29 Nov 2016 17:51
by eil
actually the main plus of x64 XY could be the threads. limited multitasking due to no-threads feels sometimes hard.but that would be the only real benefit.
Re: 64-bit version
Posted: 29 Nov 2016 18:13
by Jerry
Nothing normally inhibits the use of threads in 32-bit applications, but for XY there may be VB constraints, I don't know. But even here, I don't see a big issue. The one place in XY that should be threaded is clearly, searching. Otherwise, the I/O bound nature of most XY operations isn't going to be helped by multiple threads; background processing and queuing is what you want here most and XY has that.