XYplorer Beta Club

hey I wonder if these problems wouldn't be easier to solve if there was just an x64-compiled build of XY, instead of trying to patch and work around them. I can't remember the reason that it wasn't possible, but I think there will probably continue to be little problems here and there until such a build exists. I had a dialog running with the developer several weeks ago about a related bug which had to do with sending files to the recycle bin from redirected folders (e.g, %windir%\system32) with WOW64 redirection disabled. The bug goes something like this:

XY is unable to send items from WOW64 redirected folders to the recycle bin without generating a dialog box stating that the Recycle Bin is "corrupted". The beta version performs as follows:

• a) start with WOW64 redirection OFF, and a text file named "file.txt" in C:\Windows\System32
• b) right-click "file.txt" in \Windows\System32 directory and attempt to delete from within XY
• c) dialog appears from XY stating 'WOW64 redirection Enabled'
• d) dismiss dialog with 'OK' button
• e) 'Item Not Found' dialog appears (not sure who owns this dialog- XY or explorer.exe but my hunch is XY). Dialog says 'This is no longer located in C:\Windows\System32\file.txt verify the item's location and try again' - with 2 buttons "Try again" or "Cancel"
• f) I click 'Try Again'.
• g) dialog now appears from XY stating that 'WOW64 redirection Disabled'
• h) nothing happens
• i) check, and file.txt is still there, both inside XY as well as explorer.exe, nothing in Recycle Bin.
• j) repeat steps b-e above, but instead I click "Cancel".
• k) steps g-i repeat

The developer suggested that I make a post to the forums to ask for ideas on how to solve it. I cynically admit that in my opinion the only true solution would be a native x64 build. I hope that someday it would be possible.

luckman212 wrote:confirmed that bug here too:

Thinking about it, it might be simply caused by the fact that the app to be opened has no 32bit version in WOW64. In that case I would not call it a bug but a logical consequence from disabling WOW64 redirection.

But surely disabling WOW64 redirection (DWR) should be implemented differently. The question is: What exactly do you want to achieve by this feature? Depending on the answer I might find a better way to do it.

luckman212 wrote:hey I wonder if these problems wouldn't be easier to solve if there was just an x64-compiled build of XY, instead of trying to patch and work around them.

i couldn't agree more , if admin doesnt want to install 64bit windows on his main pc he could use a program like Virtual Box (its free and open source, made by Sun) runs just as fast as a normal pc, i actually really like the program , small doesnt need all the junk that vmware needs, its really fast (you can play videos and opengl/directx apps even at 100% full speed)

you can run 64bit windows under a 32bit os.

http://www.virtualbox.org/

i actually throw it on my second monitor its just like having a second os on at the same time

this could also help him test the wow64 errors if needed.

Actually I don't think it's possible to run a 64-bit virtual environment when the "host" is in 32-bit mode.

luckman212 wrote:Actually I don't think it's possible to run a 64-bit virtual environment when the "host" is in 32-bit mode.

I don't know if it's possible on VirtualBox, but VMware does support 64-bit guests on a 32-bit host *if you have the right CPU*. They have a utility that will tell you if the CPU would support 64-bit guests.

Note that Microsoft's Virtual PC does not support 64-bits guests at all.

However, I think that the bigger problem is that XY is developed with tools that do not support creating 64-bit executables.

mwb1100 wrote:However, I think that the bigger problem is that XY is developed with tools that do not support creating 64-bit executables.

The developer has told me the same thing, yes I think that this is the main problem.

luckman212 wrote:

mwb1100 wrote:However, I think that the bigger problem is that XY is developed with tools that do not support creating 64-bit executables.

The developer has told me the same thing, yes I think that this is the main problem.

Well, what I do is write source code (plain TXT format), and then use a 32-bit compiler to compile it. The day a 64-bit compiler for VB6 source code comes out is the day when there's 64-bit XYplorer. I cannot see a reason why this should not be possible, and I'm quite sure some people are working on this right now because you could make a lot of money with a 64-bit compiler for VB6.

The day a 64-bit compiler for VB6 source code comes out is the day when there's 64-bit XYplorer

Have you had a chance to look at this page:
http://zabkat.com/blog/26Oct08-x64-deve ... d-ATL3.htm

I think it may be possible after all ! Please have a look.

luckman212 wrote:

The day a 64-bit compiler for VB6 source code comes out is the day when there's 64-bit XYplorer

Have you had a chance to look at this page:
http://zabkat.com/blog/26Oct08-x64-deve ... d-ATL3.htm

I think it may be possible after all ! Please have a look.

Yeah, interesting. However, this is about VS6, not VB6.

My mistake. I guess the wait for a VB6 x64 compiler continues...