XYplorer Beta Club

It occurs to me that it's been a while since I saw this discussed, so I wanted to ask how the 64 bit version of XY was coming along?

Are things moving smoothly, or has it become a bit of a bear to work with?

Actually, this week I got the impression from some thread that XY is coded in Visual Basic 6. If that is the case, I'm not sure how Don is going to do a x64 version short of a rewrite because VB6 doesn't compile to 64 bits...

XYplorer is compiled using VB6 compiler, it's not coded in it. I believe Don's eggs are currently in kernel copy basket. There is still plenty of time left in 2011. And there is a possibility that things may slip, as much as it pains me to say so.

zer0 wrote:XYplorer is compiled using VB6 compiler, it's not coded in it.

Sorry but I don't get the meaning of this.
AFAIK XY is coded in VB6 and then compiled by a VB6 compiler into machine code and the only real problem with 64bit is, that there aren't any compilers out there creating 64bit machine code out of VB6.
Pls correct if I'm wrong.

My bad. You are correct -- XYplorer is written in VB6 and is compiled to native code. So yes, either a 64-bit compiler will surface or the app will need to be re-written in another language such as C++.

Basically, it's either waiting for a 64-bit VB6 compiler or a complete rewrite. As regards the former, the only VB compiler currently available seems to be PureBasic, with Real Software planning to have something in Q1 2012.

Non-VB options with their disadvantages are:
- C++: huge learning curve and the need to do much more plumbing at the expense of RAD;
- .NET (either VB.NET or C#): less performance and hindered access to the Windows API;
- Embracadero currently has a 64-bit compiler in closed beta but without ETA. Delphi is rumoured to have easy access to the Windows API, however.

The one big advantage of changing programming language would be gaining *working* multi-threading in addition to 64-bit support, but the cost in time, effort and stalled XYplorer development is probably huge.

Without wanting to start a discussion, just a short note: Yes, it all comes down to waiting for the compiler to appear. I know that several groups are working on one, and once a good one is there I'll buy it.

Tip: In case you have time and talent and need money: A working 64-bit compiler for VB6 will make you rich quickly for sure!

admin wrote:Without wanting to start a discussion, just a short note: Yes, it all comes down to waiting for the compiler to appear. I know that several groups are working on one, and once a good one is there I'll buy it.

Pure curiosity: do you know of others besides PureBasic and RealBasic?

Tip: In case you have time and talent and need money: A working 64-bit compiler for VB6 will make you rich quickly for sure!

Would that be feasible in VBA?

nas8e9 wrote:

admin wrote:Without wanting to start a discussion, just a short note: Yes, it all comes down to waiting for the compiler to appear. I know that several groups are working on one, and once a good one is there I'll buy it.

Pure curiosity: do you know of others besides PureBasic and RealBasic?

Tip: In case you have time and talent and need money: A working 64-bit compiler for VB6 will make you rich quickly for sure!

Would that be feasible in VBA?

Yes.
No.

admin wrote:Without wanting to start a discussion, just a short note: Yes, it all comes down to waiting for the compiler to appear. I know that several groups are working on one, and once a good one is there I'll buy it.

Interesting. So it may not come out in 2011 after all, as it is subject to another party doing their magic first.

I am also curious: how do you propose to handle the VB VM runtime requirement? The virtual machine DLL is only included up to Windows 7. In Windows 8 -- or whatever the nick they give it -- non-.NET VB stuff won't run.

zer0 wrote:

admin wrote:Without wanting to start a discussion, just a short note: Yes, it all comes down to waiting for the compiler to appear. I know that several groups are working on one, and once a good one is there I'll buy it.

Interesting. So it may not come out in 2011 after all, as it is subject to another party doing their magic first.

I am also curious: how do you propose to handle the VB VM runtime requirement? The virtual machine DLL is only included up to Windows 7. In Windows 8 -- or whatever the nick they give it -- non-.NET VB stuff won't run.

I'm not scared by this. There is always a solution. Nature finds a way.

admin wrote:Without wanting to start a discussion, just a short note: Yes, it all comes down to waiting for the compiler to appear. I know that several groups are working on one, and once a good one is there I'll buy it.

You decided that PureBasic was insufficient?

nas8e9 wrote: Pure curiosity: do you know of others besides PureBasic and RealBasic?

Since, as far as I know, BASIC was never standardised as language (and even if it had been Visual Basic would have extended it greatly) I seriously doubt PureBasic or RealBasic will compile current the current XY codebase without a fair amount of rewriting.

I coded in VB6 professionally for 8 years. It's a great language to get things up and running really fast, but a real b*tch past a certain point when you want more structure in your code (it's OO "support" is atrocious). Don't miss it a bit.

Miguel Melo wrote:

nas8e9 wrote: Pure curiosity: do you know of others besides PureBasic and RealBasic?

Since, as far as I know, BASIC was never standardised as language (and even if it had been Visual Basic would have extended it greatly) I seriously doubt PureBasic or RealBasic will compile current the current XY codebase without a fair amount of rewriting.

I coded in VB6 professionally for 8 years. It's a great language to get things up and running really fast, but a real b*tch past a certain point when you want more structure in your code (it's OO "support" is atrocious). Don't miss it a bit.

I'm not a programmer myself, but I saw mention of (possibly limited) importers/converters for both PureBasic and RealBasic. I don't doubt that some serious clean-up would be necessary after that, but that would still be a lot less effort than a full rewrite and that's before considering the time and effort necessary to fully learn a different programming language.

I can't speak for Don, but based on some of his posts, both the RAD aspect you mention for which VB was explicitly designed, as well as direct access to the Windows API is very important to him. The other choices for 64-bit programming, would detract from one or both to varying degrees.

In the end, none of this is directly relevant to anyone but Don. It's just that 64-bit is growing fast, especially among XYplorer's intended market segment. The other big advantage of moving away from Basic would be gaining working multi-threading, which would help with several things (thumbnail creation, handling in-process third-party code, file operations, hashing, etc.). It's amazing how far he has taken XYplorer with nothing more than VB6 plus a huge amount of Windows API use; I hope an external Basic solution enables him to take it even further.

nas8e9 wrote: In the end, none of this is directly relevant to anyone but Don.

It's amazing how far he has taken XYplorer with nothing more than VB6 plus a huge amount of Windows API use

Agree on both counts!