XYplorer is dead

[w64bit]

XYplorer is dead.

Explanation:
The present and the future is 64 bit.
XYplorer will never be a 64 bit app because will never be a 64bit VB compiler and a complet rewrite in another language will never be done in the next years.

Bye.
Quinn

PS: Please answer only if you have the info that will surely be an x64 version of XYplorer.
I am not interested in your oppinion that existing 32 bit is soo good for an 64 bit OS.

[calude]

hahaha 1st april

soo funny

Cal

[Stefan]

Luckily just today Mircosoft announced an 64 bit VB compiler for the end of the year: > Read more on bbc.co.uk ...

[jjk]

Stefan, who is Mircosoft ?

By the way I see that "when the cat is away, the mice dance".
Don should not have got holidays on 1 april !!

[iycgtptyarvg]

Actually, the OP does have a point.

The problems we're having with WOW64 and context menu items not showing up is only going to get worse in the (near) future.

Therefore, I'm also tentatively looking around for other apps.
It's really a shame because after years we finally have the recycle bin and mode-less (even queued!) copying.

[zer0]

Actually, the OP does have a point.

The problems we're having with WOW64 and context menu items not showing up is only going to get worse in the (near) future.

Therefore, I'm also tentatively looking around for other apps.
It's really a shame because after years we finally have the recycle bin and mode-less (even queued!) copying.

OP has a point in as much as 32-bit limitations are inconvenient, but there are 2 sides to every coin...

The WOW64 issue is to do with the differences in software architecture. Actually, we should be appreciative -- for the lack of a better word -- that we are able to run 32-bit applications at all in a 64-bit OS. Wouldn't it be much worse if you/I/others couldn't run XYplorer at all -- as it currently is -- in a 64-bit OS?

Regarding context menus, it's again a two-way road. On some occasions, you are able to install 32-bit and 64-bit versions side-by-side, as a workaround. In situations when you cannot do so, you should -- at the very least -- notify the developer of software that doesn't register 32-bit extensions. It is quite likely that a 32-bit version of the same software also exists, so it's a matter of including a few more DLLs and calling regsvr32 on them during the installation process. Trust me, I have been bitten by the lack of a particular context menu and I will be contacting the maker of that software to see what can be done -- but at least it shows that I'm in a similar boat to yours.

OK, maybe you already knew what I've just wrote above. Maybe. Or maybe not. But what options does Don have? There is no 64-bit VB compiler. Will there be one? I don't know, but I'm sceptical. Could Don write his own 64-bit compiler? I don't know that either, but I'm sure it's no small task and would take him away from developing XYplorer. An alternative is to re-write XYplorer in a language that has a 64-bit compiler. How easy would that be for Don? Once again -- no idea. What if -- hypothetically -- a feature that works at the moment won't work if written in a new language through some incompatibility? I'm sure certain users won't be best pleased about that either.

Speaking metaphorically, the above combines to put XYplorer between a rock and a hard place. It's a difficult job for Don, but I trust him to make decisions that are best for business and users

[Mesh]

But what options does Don have? There is no 64-bit VB compiler.

Actually, while Microsoft may not be releasing a 64 bit compiler, someone suggested a third party Basic compiler which was 64 bit (I think it was PureBasic). I wonder if Don ever looked into that, and what the results were of his evaluation.

Even if that doesn't work out, there might be other third party Basic compilers which are 64 bit.

[admin]

But what options does Don have? There is no 64-bit VB compiler.

Actually, while Microsoft may not be releasing a 64 bit compiler, someone suggested a third party Basic compiler which was 64 bit (I think it was PureBasic). I wonder if Don ever looked into that, and what the results were of his evaluation.

Even if that doesn't work out, there might be other third party Basic compilers which are 64 bit.

PureBasic looks certainly like one of the better options. However I'd like to see a professional app written in PureBasic -- did not find any.

Generally, however, the 64 bit topic has no priority for me at the moment. And, sorry, I won't take the time to discuss why. Broadly speaking I see my time much better invested in improving the program (there are a lot of great things to come!). XYplorer is anything but dead.

[Mesh]

PureBasic looks certainly like one of the better options. However I'd like to see a professional app written in PureBasic -- did not find any.

Generally, however, the 64 bit topic has no priority for me at the moment. And, sorry, I won't take the time to discuss why. Broadly speaking I see my time much better invested in improving the program (there are a lot of great things to come!). XYplorer is anything but dead.

I understand. But for what it's worth, I'm not sure it's wise to dismiss the 64 bit issue.

While it's true that 32 vs 64 bit doesn't matter much to file operations, context menu support is *not* a trivial matter. Unless you can find a way around this and let XY have full access to all 64-bit context menu items (which also assumes that it's not a problem for a 32 bit app to call a 64 bit dll/app), this problem is going to grow.

It's not reasonable to tell users to talk to the other developers and ask them to make their apps compatible with a 32 bit file manager. To be frank, it's simply not going to happen. As more and more users switch to 64 bit O/S's, and as both existing and new users start using more and more 64 bit apps, the dependency on context menu support is only going to grow.

Users might be willing to switch to Explorer for the rare occasion that they need access to the 64 bit System directories. But context menu deviation means that they are constantly going to have to switch back and forth between XY and Explorer (something that I have had to do as well). And that is going to end up being a deal breaker.

Respectfully, I think you need to address the context menu functionality, if nothing else - either by finding a way to compile a 64 bit app, or by finding a way around the current default limitations. Otherwise, you're going to lose no small amount of new business once users realize the extent that XY cannot replace Explorer on a 64 bit O/S.

[admin]

PureBasic looks certainly like one of the better options. However I'd like to see a professional app written in PureBasic -- did not find any.

Generally, however, the 64 bit topic has no priority for me at the moment. And, sorry, I won't take the time to discuss why. Broadly speaking I see my time much better invested in improving the program (there are a lot of great things to come!). XYplorer is anything but dead.

I understand. But for what it's worth, I'm not sure it's wise to dismiss the 64 bit issue.

While it's true that 32 vs 64 bit doesn't matter much to file operations, context menu support is *not* a trivial matter. Unless you can find a way around this and let XY have full access to all 64-bit context menu items (which also assumes that it's not a problem for a 32 bit app to call a 64 bit dll/app), this problem is going to grow.

It's not reasonable to tell users to talk to the other developers and ask them to make their apps compatible with a 32 bit file manager. To be frank, it's simply not going to happen. As more and more users switch to 64 bit O/S's, and as both existing and new users start using more and more 64 bit apps, the dependency on context menu support is only going to grow.

Users might be willing to switch to Explorer for the rare occasion that they need access to the 64 bit System directories. But context menu deviation means that they are constantly going to have to switch back and forth between XY and Explorer (something that I have had to do as well). And that is going to end up being a deal breaker.

Respectfully, I think you need to address the context menu functionality, if nothing else - either by finding a way to compile a 64 bit app, or by finding a way around the current default limitations. Otherwise, you're going to lose no small amount of new business once users realize the extent that XY cannot replace Explorer on a 64 bit O/S.

Yes, it will have to be done and it will be done (sounding like a politician... ). But I have to set priorities.

[zer0]

It's not reasonable to tell users to talk to the other developers and ask them to make their apps compatible with a 32 bit file manager. To be frank, it's simply not going to happen.

Actually, I have just sent an email to developers of a program whose extension I cannot see in XYplorer. This wasn't done to call you out -- I did it because it's an honest bit of feedback. You don't ask, you don't get. I don't expect anyone to follow suit, but I don't agree that it is unreasonable to engage in a conversation regarding compatibility.

[Mesh]

Yes, it will have to be done and it will be done (sounding like a politician... ). But I have to set priorities.

I understand, and I agree with you. I just don't think the priority for this one should be too low, that's all.

[Mesh]

Actually, I have just sent an email to developers of a program whose extension I cannot see in XYplorer. This wasn't done to call you out -- I did it because it's an honest bit of feedback. You don't ask, you don't get. I don't expect anyone to follow suit, but I don't agree that it is unreasonable to engage in a conversation regarding compatibility.

My comment was meant two fold - that for over 90% of the problem apps, *either* users weren't going to bother pestering the developers, *or* they would ask and the developers would say no. You're going to end up with only a tiny percentage of cases where a user asks, and the developer pulls it off. That's what makes the issue moot.

[zer0]

My comment was meant two fold - that for over 90% of the problem apps, *either* users weren't going to bother pestering the developers, *or* they would ask and the developers would say no. You're going to end up with only a tiny percentage of cases where a user asks, and the developer pulls it off. That's what makes the issue moot.

I know what you mean. To a certain extent, users are reasonable to expect things to work out-of-the-box. However, I am sceptical as to what you're basing you metrics on Concerned users can contact developers to ask them to include registration of 32-bit extensions. Users can also ask them which DLL(s) are the ones containing such extensions. Knowing which DLLs allows users to get more hands-on as described here: http://www.xyplorer.com/xyfc/viewtopic. ... 035#p40035

There is a lot that users can (whether they should is another debate ) do themselves to try to mitigate the impact of missing extensions. Said lot doesn't even involve Don doing anything to XYplorer

[Mesh]

I know what you mean. To a certain extent, users are reasonable to expect things to work out-of-the-box. However, I am sceptical as to what you're basing you metrics on Concerned users can contact developers to ask them to include registration of 32-bit extensions. Users can also ask them which DLL(s) are the ones containing such extensions. Knowing which DLLs allows users to get more hands-on as described here: http://www.xyplorer.com/xyfc/viewtopic. ... 035#p40035

There is a lot that users can (whether they should is another debate ) do themselves to try to mitigate the impact of missing extensions. Said lot doesn't even involve Don doing anything to XYplorer

I work in IT, so I deal with developers and clients contacting developers all the time. Don is very much the exception insofar as respecting user requests. For that matter, respecting users period. 99% of the time, worst case scenario is that you don't even hear back from the developers that they received your request, best case is that they'll say they'll think about it - but end up doing nothing.

I've contacted no small number of them in regards to this issue. Of the ones that bothered to respond, the typical answer was along the lines of "We're developing for a 64 bit OS, we're not interested in developing for a 32 bit third party file manager on a 64 bit OS."

I was able to get UltraEdit to work simply because its developers happened to leave the 32-bit handler DLL in the install directory, instead of deleting it during install. But that's the very rare exception.

If you try to get twenty developers to accomodate XY's issue, you'll be lucky to get one that does it. It's not impossible, but it's close enough that telling XY users to contact other developers to fix this is, for the most part, sending them on a wild goose chase.