XYplorer Beta Club

I'd like to add some thoughts on the oft-discussed possibility of a 64-bit version of the world's best file explorer, XYplorer.

To restate the core issue: XYplorer is a Visual Basic 6 app, and there is no x64 compiler for VB6. It looks like no one is building a 64-bit compiler for VB6. Donald tried to use VB.NET and found it less than appealing. So the official status is published in his well-written piece on VB6, which can be read here.

Please note that I work in software development. I'm familiar with the challenges herein from a technical standpoint. I fully recognize that the process of creating an XYplorer codebase that can be compiled to a 64-bit app is not a trivial thing. I'm sure Don sees another "64-bit" topic pop up and his eyebrows go afluff in a scowl because (a) why another annoying post?! and (b) he knows that the project could be vast and hard.

But maybe it doesn't have to be so vast and hard. I'd like to discuss the obvious options and provide some additional thoughts I haven't seen in previous posts on this topic. I don't particularly care to argue the need for a 64-bit version vs. not, because the fact is that people will continue to demand a 64-bit version despite whatever valid reasons are given for sticking with 32-bit only. (We can discuss "performance of an app like XYplorer is fine in 32-bit"; "just grab 32-bit shell extensions"; etc. all day long but people will keep clamoring for 64-bit.) There's marketing value to just being able to offer a "64-bit app" even if it's marginally more functional than a 32-bit version, because some people out there simply won't buy unless it's 64-bit. So I propose that this thread not be focused on whether we need a 64-bit version or not (a valid question, but for another thread) and instead discuss the possible ways forward to a 64-bit version.

Disclaimer: I assume that Donald is already well aware of all these possibilities and has mulled them over. I'm just stating them here for discussion; I don't think Don would have missed any of this.

The obvious possible ways forward to 64-bit, as I see them, are:

1. Use one of the modern VB6 migration tools to convert to a language of Donald's choice.
2. Use the services of a VB6 migration company.
3. Choose a language and development environment + framework(s) and rewrite the app from scratch.
4. With any of the above, perhaps do a Kickstarter-like campaign for the large effort any of these options will require.

I'd love to hear of any additional possible routes I haven't mentioned. To expand on the ones I have mentioned:

------------------------------------------------------------------------------------------------------------------

1. Use one of the modern VB6 migration tools to convert to a language of Donald's choice.

I've been through code migration projects before and, as everyone involved in such a project knows, there is always refactoring and rewriting involved. That said, as long as XYplorer isn't spaghetti code in VB6, a good migration utility could realistically save 50-60% of redevelopment time. (In some cases, it could be as high as 80-90%, but it depends on the migration utility and how XYplorer was originally architected.) The only way to find out is to try it.

Some options:
Mobilize VB Upgrade Companion - https://www.mobilize.net/solution/vb-upgrade-companion
Converts VB6 to C# or VB.NET, so Don would want to get used to new versions of Visual Studio and the .NET framework (more on that below). Endorsed by Microsoft and generates native code - all symbol names and comments preserved - without third party runtimes or dependencies. They provide consulting services to support use of their software.

VBto Converter - http://www.vbto.net >>> Last updated February 2, 2018!
Can convert VB6 to MS VC++ MFC; VC++.NET CLR; VB.NET; C#; J#; even Delphi and Borland C++ Builder. Converts VB6 projects (including source code) to resource and source files. Is kept surprisingly up-to-date for an application targeting VB6 conversion.

Code Architects VB Migration Partner - http://www.vbmigration.com
Converts VB6 to .NET. This page describes the process, which actually looks like a lot of fun! Francesco Balena and team tested this tool on hundreds of randomly chosen open source applications and VB Migration Partner correctly converted 999 out of 1,000 statements.

Avotova - https://www.avotova.net
Converts VB6 to VB.NET only. They provide consulting services to support use of their software.

Additional notes for consideration:

• There is a pure Microsoft option, but it isn't pretty. Modern versions of Visual Studio do not provide tools for upgrading applications and projects from Visual Basic 6.0. There are upgrade tools provided with versions of Visual Studio prior to Visual Studio 2012, and you could upgrade the project again in Visual Studio 2012. The main problem is that the Visual Studio upgrade tools didn't work very well. That said, there are some interesting thoughts here and here.
• One article mentions the growing lack of parity between VB and C# support from Microsoft. ""VB 15 comes with a subset of C# 7.0's features.... we are leading with C#." From everything I'm seeing in my work, all else being equal, C# isthe way to go between the two.
• There are some good thoughts on VB6 upgrades here.

------------------------------------------------------------------------------------------------------------------

2. Use the services of a VB6 migration company.

One company with a core focus on VB6 migration is Fecher. (Fecher's based in Germany, by the way.) Several of the companies listed above providing converter software also provide migration consulting services.

Obviously, Don has serious talent and none of us would want to see the project "outsourced." But if Don could push the bulk majority of the "grunt work" of upgrading to an external team - and if the external team has a stated focus on VB6 like these companies - it could prove to make the work almost fun. When you get the right people on such a project, it can be a fantastic time.

------------------------------------------------------------------------------------------------------------------

3. Choose a language and development environment + framework(s) and rewrite the app from scratch.

This one would probably be any coder's least favorite. You might kick open an IDE and start out, and quickly realize that the magnitude of the task at hand - to port an advanced app like XYplorer - just doesnt sound appealing.

That said, with enough looking, Don may find a certain flavor of language and work environment that suits him. One that a lot of VB6 coders have jumped to is Xojo because it feels familiar while providing all the amenities of a modern setup. In Xojo, you can:

• Code once then deploy on macOS, Windows, Linux, the web, iOS and Raspberry Pi.
• Drag & drop elements to design a native user interface
• Remain abstracted from platform details and focus time and energy on just building the app (one thing many developers prefer about VB6)

There is a plethora of options available to Don for a full rewrite. The main question is whether he'd want to do that at all.

------------------------------------------------------------------------------------------------------------------

4. With any of the above, perhaps do a Kickstarter-like campaign for the large effort any of these options will require.

So, Don might feel like all of the above options are difficult. Even if he could get a converter to work decently well, and/or even if he could get help and/or rewrite XYplorer from the ground up, it's going to be a serious investment of time and/or money (probably both). It becomes a question of profitability: Will the current rate of sales be increased significantly enough by the mere fact of a 64-bit release to justify all the effort and cost? Up to now, Don's evaluation has been resoundingly, "No."

But part of that evaluation is likely an assumption that it would be up to Don to figure the whole thing out - the code and the finances. Well, Don's really good at the code side, so that's a good assumption. But what if we rallied around Don and gave him the financial incentive to move forward into 64-bit deployment?

What if:

• Pre-sales model: Donald provides a link to pre-buy a license for "XYplorer 64". The language is clear, and everyone knows: Users are putting their money into an account for Donald to deliver a 64-bit version of XYplorer which might never happen. Users put the money in anyway. Once we reach a figure pre-determined by Don (maybe 2,500 licenses?), Don has over $100,000 to work with to reach his goal. That would probably be enough to complete the project. A couple years later, Don releases the 64-bit version.
• Kickstarter: Launch a "XYplorer 64" Kickstarter campaign and invite all existing users. Set a target amount to reach, and maybe even include fun bonuses like a special edition license that tweaks the interface to display the fact of investor support; credits in the app help section; etc. Get the money to go 64-bit quickly and then go for it.

------------------------------------------------------------------------------------------------------------------

Some additional thoughts:

I get it. Don is extremely fast and proficient in VB6. He cracked open a newer version Visual Studio, looked at the complication of all the object-oriented fun, and hit the X button.

I've also known quite a few developers who've made the jump from VB6 to VB.NET, C#, or other options. I can tell you that they consistently say that, once they get used to the new workflow, (a) it took a lot more work to code in VB6 than it does now; (b) it's now downright painful for them to go back into VB6 code; and (c) they didn't enjoy the transition at all, but now they'd never go back to VB6 if coding their own app (vs. client work).

For those out there who aren't familiar: Compared to VB6, the .NET environment provides a way to interconnect managed code with unmanaged code bidirectionally. In VB6, some entities behave like objects and some don't. But in VB.NET, for example, everything is an object. So for someone like Don, who's used to the quirks of VB6 and who's able to do things very quickly and simply in VB6, the .NET approach can be extremely frustrating at first. But by all accounts from the developers I work with, it's worth it.

Don, not sure about when was the last time you tried Visual Studio, but: It's often acknowledged that Visual Basic 7 was pretty terrible. VB8 was OK, and version 9 and beyond are really pretty excellent to work with. I think you'd be blown away (in a good way) by VB15. You might consider taking another look.

Discussing the transition from VB6 to VB.NET specifically (since that's one option): .NET uses objects and variable types that VB6 doesn't have, but overall most aspects transfer well. The interop layer can be leveraged to use OCXs in VB.NET, but if the OCXs are from VB6, you may or may not run into problems with this approach. You can try using regular ADO on VB7 and beyond, which can help in certain apps.

My understanding is that XYplorer is in the ≈200,000 lines of code range. I'm aware of one instance where a company migrated 1,800,000 lines of VB6 to VB.NET in under two years. The codebase dropped to about 1,400,000 lines through efficiency of the language, and of course the app gained all of the multi-threading and UI advantages.

If you're a VB6 expert, and if you have some knowledge of object-oriented programming, you could literally learn VB.NET in an evening, maybe a week. Picking up object-oriented programming if you've never done it before is a bigger challenge, but certainly achievable - and then the skills translate directly into other modern languages.

Don, not to speak for everyone else, but: We're behind you and would love to help support you if you decide to go for a 64-bit endeavor. For that matter, you might consider the Kickstarter/pre-sales approach for any number of larger-scale ideas you've put on hold because they're too big.

Do I win the award for longest-winded post on XBC? At least in 2018 (so far)?

Wow, thank you for the longest post so far! I'm aware that the future of XY is somewhere along those lines. And I'm not afraid of it. Nothing could possibly be harder than doing a commercially successful app in VB6 in 2018. But yes, it needs some good thinking and checking to decide WHICH is the way to go. I certainly don't want to do this twice. So thanks a lot for outlining some of the current possibilities!

@xyplorerköln: outstanding analysis and elaboration of options!

xyplorerköln wrote: Don, not to speak for everyone else, but: We're behind you and would love to help support you if you decide to go for a 64-bit endeavor.

As a 'lifetime license' holder I would certainly be willing to contribute to either of your suggested options (Kickstarter, 'pre-sales model', or...).
If only to help ensure the long-term XYplorer utility, and license sales to maintain viability.

@xyplorerköln Thank you for thinking that through, and posting.

That's it! So: +1

Great post.

One thing I wanted to add to the pool of thinking: not to argue for the need for a 64-bit version, but to show the advantage of moving to another language.
When Don will grow tired of developing/maintaining XYplorer, what will the software become? I'm convinced today there are almost no bug (or they're minor), thus XYplorer could live several years without being maintained. But maybe Don will want to open-source the code so that the community could continue improving the software. In that case, having moved to a language with a better future than VB6 might attract many more developers.

Leito wrote:But maybe Don will want to open-source the code so that the community could continue improving the software. In that case, having moved to a language with a better future than VB6 might attract many more developers.

Generally a good thought, but... just a quick comment on that: VB6 was THE language (most popular, most used, most sold, most commercial applications) when MS decided to drop it. So unfortunately one can forget about speculating which language has the best future. Actually a source code in BASIC is not so bad future-wise, a child could read it.

If the code is clean VB6 can auto convert VS2008 VB.NET, the from there to VS2017 VB.NET.

And as Don has stated before, VB .NET is NOT an option...

highend wrote:And as Don has stated before, VB .NET is NOT an option...

..
Thanks for the constructive adult feedback.

highend,

My guess is you haven't successfully converted any language of 250,000 plus lines of code into another language and have it working correctly utilizing the language of your choice to it's potential. Even under the best of cases this is a significant undertaking which takes thousands of hours with someone who cares deeply about the end results rather than just a paycheck. Outsourcing to some consulting firm will just burn bank and in almost all cases will result in a product that will have a slow death. I know. Seen many go this way. Have you or anyone had person experience with the list of conversion tools listed herein? If not I wouldn't count much on what can be achieved with them on real production high-quality products. Typically, the clean up on these products is significant, I'm not talking about refactoring, I'm talking about functionality and behavior as expected, including the visual aspects. I've used them, not all list, but several. Don't think that 32-bit software is going to being operational on serviced, non-sunset versions of Windows indefinitely, MS is working hard to lock down future versions of Windows, pushing UWP and their authentication. They killed 16-bit app support next is 32-bit. As a guess (a guess) 32-bit support will be removed in 5-years. That's about a 3-year window to figure out the direction, 2-years to rewrite. Whatever you do keep the development team down to 1 or 2 who have a love for what they do and want to see a stellar end product.

I sure hope XY doesn't die a slow death and is able to move the the next step. I'd love to be a part of that process forward...

highend, My advice to you is don't assuming anything. VB3 is very different than VB6 (beyond 16/32-bit) and many developers where hammered when moving out of VB3 at the time. VB.NET is not the VB.NET when it came out, it is extremely different on a significant level variance much greater than VB3 to VB4. Should XY be moved into VB.NET? Don't know. I haven't seen the code. It would depend on what the VB6 (Add-In) .NET Code Advisor Kit reported. If the core business logic is well isolated it might just take a few months to rewrite the presentation-- then I'd go with some of the options discussed for multi-platform in the 64-bit version myself. However, that will take much time.

I don't assume anything. I was just posting what Don stated about it.
Nothing more, nothing less

Hello everybody

A question (maybe naive ?) : as a user, technical debates x86 vs x64, VB6 vs VB.Net does not interest me at all.
I let it to specialists.

But, on the other hand, I would like to clearly know:

- when will it be possible to access portable devices without having to go back to W7 nor run Windows Explorer ?
- when will it be the possible to have one tree for each panel without using others FM like (e.g QDir, Dopus ...)

These 2 features are realy basic for a file manager worthy of the name.

Thanks for enlightening me if I missed something ...

@don -- how many lines of code is there in XY?

If Spock had read this discourse he would surely have uttered, "Fascinating!"

Am also a Lifetime License holder for a decade and would be willing to help finance a new path should Don so choose.

aurumdigitus wrote: Am also a Lifetime License holder for a decade and would be willing to help finance a new path should Don so choose.

Me too. Of course!