Not 64-bit XY, but how about a 64-bit helper app?

[Mesh]

Okay, this is not a (direct) question about a 64 bit version of XY - so Don, you can put the Tylenol down.

As has been discussed before, most users don't care about a 64-bit version of XY, they just want access to the 64-bit context menus. Well, for several versions now, XY has had a helper app for dealing with file operations, and it's worked out well.

What about having a 64-bit helper app, rather than rewriting all of XY? It could just be a tiny 64-bit executable written in C (or any other fast, unmanaged language) whose sole purpose was to grab and handle the 64-bit context menus. I would think this could be a nice, easy to manage solution - very fast to code and implement without all the headaches of porting the entire application.


Is this feasable?

[Enternal]

Hahaha when I see 64Bit, I went uh oh. Anyway I think I had suggested something like this before but don't remember what the reply was again. Anyway it does seem like a good idea though and at the same time, I was thinking perhaps using a helper application could really alleviate some of the issues that the program has due to compiler issues. Perhaps using a helper to deal with 64Bit extensions, make a separate "thread" to process image thumbnails, and etc. Is it all possible Don? In case you get even more tired, here's some coffee and a breakfast sunny-side up egg . Also enjoy a nice soak in an onsen ♨.

[j_c_hallgren]

Here's the post in prior thread where 64-bit 'helper' was talked about by Don: http://www.xyplorer.com/xyfc/viewtopic. ... 688#p71688

[Mesh]

Here's the post in prior thread where 64-bit 'helper' was talked about by Don: http://www.xyplorer.com/xyfc/viewtopic. ... 688#p71688

Thank you for that. In that post, Don mentioned that this was a viable solution that would solve the problem quite neatly. I don't see any real discussion about it after that.

If this is an easy solution for what is clearly a legitimate problem, is there any reason why this can't happen soon?

[PeterH]

Here's the post in prior thread where 64-bit 'helper' was talked about by Don: http://www.xyplorer.com/xyfc/viewtopic. ... 688#p71688

Thank you for that. In that post, Don mentioned that this was a viable solution that would solve the problem quite neatly. I don't see any real discussion about it after that.

If this is an easy solution for what is clearly a legitimate problem, is there any reason why this can't happen soon?

Maybe there was no more discussion as people were so happy about this idea and possibility...

Several times later I asked myself: do we have a chance waiting for this?

At least I'd say: if this function is possible I'd give it a very high priority!

[admin]

Well, if anybody here is able to write a small helper in any language and compiled it as 64-bit, I'd be happy to integrate it into XY and deploy it.

Job Description:
Input: All selected files (with path).
Output: The shell context menu.

Remark:
Of course, XY's "Custom items in shell context menu" would not be present in that menu. The menu would be identical to the one shown in Explorer. No extras.

Who can do it?

Note: Somebody (http://www.gasanov.net/WOW64Menu.asp) wrote the opposite thing, and I asked him whether he would do the thing I need -- never got a reply...

[Mesh]

Of course, XY's "Custom items in shell context menu" would not be present in that menu. The menu would be identical to the one shown in Explorer. No extras.

I hope you mean that the helper wouldn't return anything extra, not that XY's final context menu would no longer be special. The output here can simply be a "64-bit Menu" flyout off of the current context menu.

[admin]

No, this "64-bit Menu" would be totally stand-alone, a separate process called by XY.

[Mesh]

No, this "64-bit Menu" would be totally stand-alone, a separate process called by XY.

That's what the helper app would return, but I hope that's not all you're going to show. There's no need to get rid of the Rename Special flyout or anything else that XY adds. As I said, it could just be a "64-bit Menu" flyout from what's currently shown. Aside from not losing all of XY's special additions, we also don't want the reverse of what we have now - where 64-bit extensions show up, but 32-bit only extensions don't.

[admin]

Forget it, totally impossible.

[Mesh]

Forget it, totally impossible.

If I'm not mistaken, Total Commander does something similar, so why would this not be feasable?

[admin]

Show me.

[Mesh]

Show me.

Here you go:

http://i.imgur.com/IkdxLce.png


On a seperate note, oh my god what a steaming pile of... compost. <shiver>
But it does serve to show this proof of concept.

[admin]

Wow, yeah, that kind of proves it. The remaining problem is: Show me how to code this. Totally beyond my skills.

[Mesh]

Wow, yeah, that kind of proves it. The remaining problem is: Show me how to code this. Totally beyond my skills.

I find that completely unbelievable.


Alright, rather than adding a custom item to the menu - how about having the 64-bit helper app simply bring up the standard 64-bit context menu when the right button is long pressed. That way, the current context menu can be completely left alone. XY simply detects if the right button is long pressed, and if so - passes the list to the 64-bit process for it to handle.

Would that be easier to implement?