XYplorer Beta Club

I know it's been touched upon here, but I find myself having more and more apps that I interact with by context menu, that I have to load Windows Explorer for because XY can't do it.

I'm not used to having to shelve XY in favor of Windows Explorer, and I'm having to do that more and more often.

So, please fix this, because XY - at least for 64 bit systems - is starting to get left behind due to an inability to keep up.

Demset wrote:I know it's been touched upon here,

Yes, such as in http://www.xyplorer.com/xyfc/viewtopic.php?f=3&t=4248 -- have you looked at that thread?

Demset wrote:So, please fix this, because XY - at least for 64 bit systems - is starting to get left behind due to an inability to keep up.

I believe Don would like to fix it but is limited due to compiler restrictions according to a post in that thread and in some other places.

j_c_hallgren wrote:
Yes, such as in http://www.xyplorer.com/xyfc/viewtopic.php?f=3&t=4248 -- have you looked at that thread?

I did, but suggesting a workaround of installing the 32 bit version of an app, instead of the 64 bit version is - forgive me - laughable. Imagine Microsoft telling people that they need to install the Windows 98 version of an app on XP, instead of running an XP native version. They'd be crucified. It's a *very* temporary break-fix patch at best. But if that's what XY is relying upon for new customers, they're going to lose them.

j_c_hallgren wrote:
I believe Don would like to fix it but is limited due to compiler restrictions according to a post in that thread and in some other places.

Well, that's just it. Customers (particularly, but not exclusively, new ones) are primarily concerned with results. If another file manager is programmed in Python, or C, or VB.NET and has already been ported to 64 bit - that's going to be a *very* strong point in their favor and against XY.

Whatever the reasons are, 64 bit operating systems are now quickly becoming mainstream. If XY is to stay competitive, it needs to adapt. If it doesn't, it's going to fall by the wayside. File operations might not matter between 32 and 64 bit, but system navigation and context menu items are a HUGE deal.

If the programming language Don is using can't handle 64 bit compiling, then he needs to change programming languages. I know, it's a nightmare. But I'm not aware of any other way he's going to end up with a 64 bit application. And that's going to sink him - especially if his competitors specifically target this point, and XY's lack.

You can convert context menu items to PFA (Portable File Associations). I don't use context menu at all, since I did so and it gives you much more control. I don't have 64-bit system, but it should work (and it may stay working even after reinstalling the system or switching to another installed system).

And file manager in Python or VB.Net? Come on :-) While I'm not a fan of Visual Basic, XYplorer is at least quick and lightweight, which is more than I can say about any VB.NET application I encountered (even the simplest ones) or about any interpreted language in general. But unfortunately I agree that Don may need to change programming language at some point in the future (if there is no 64-bit version of Visual Basic - and there is no sign, that there ever will be; unless he would write one of course).

xman wrote:
You can convert context menu items to PFA (Portable File Associations). I don't use context menu at all, since I did so and it gives you much more control. I don't have 64-bit system, but it should work (and it may stay working even after reinstalling the system or switching to another installed system).

That won't work, as many context menu items are processed via DLLs, not EXEs.

xman wrote:
And file manager in Python or VB.Net? Come on :-) While I'm not a fan of Visual Basic, XYplorer is at least quick and lightweight, which is more than I can say about any VB.NET application I encountered (even the simplest ones) or about any interpreted language in general. But unfortunately I agree that Don may need to change programming language at some point in the future (if there is no 64-bit version of Visual Basic - and there is no sign, that there ever will be; unless he would write one of course).

Well, I was trying to stay with a higher level language, for the sake of the example. Obviously, a move to C++ would keep the speed beautifully, but it's tough to move from VB to C++ unless you have a grounding in low level languages, and I was trying not to assume.

That won't work, as many context menu items are processed via DLLs, not EXEs.

While that's true, that some applications use DLLs as context menu handlers (and not only on 64 bits), you can often call application directly with parameter(s). Two such examples I know of are PSPad and 010 Editor. There are some special applications, that can even create image previews in context menu and other stuff, but that's another story. Maybe making it possible to call handler in those DLLs from XYplorer would be solution (I'm not sure, how exactly is it implemented), but I don't personally need this functionality.

xman wrote:
While that's true, that some applications use DLLs as context menu handlers (and not only on 64 bits), you can often call application directly with parameter(s).

Only sometimes, and often with a loss in either speed or functionality. That makes this an unacceptable workaround. Oh, in a pinch, someone can get a temporary band-aid for their issue (maybe), but in general, it's not an equal solution. And to new customers, they're not going to accept it.

That's like trying to pitch linux at a lifetime Windows user by saying "well, it doesn't work the way you need it to - but, hey, you can just grab the source code and program it yourself!" The next words out of your mouth would be "Wait, where are you going?"