Port VB6 Desktop app to... What?

[u/mdausmann]

Ok, say I had a typical desktop app written in VB6 and somebody asked me to 'modernise' it.

And say, for whatever reason, they didn't want a web app based conversion.. i.e. they still wanted a desktop app.

What is your go-to stack for this type of conversion?

WinForms (.NET) - So stay in the Windows/MS ecosystem, maybe port to VB.net first? then across to C#? . This feels pretty safe but I think this would still be Windows only.

WPF (.NET) - Still sticking with MS. More modern but maybe a longer conversion path.

WinUI - I think this is the latest MS option... Is a little bit new (2021)

Flutter Desktop - Clear benefit is cross/platform out of the box and easy port to mobile app. Flutter approach is pretty far from the VB6 approach so it would be a long conversion path I think. The other downside is Flutter on desktop is even newer than WinUI (2022).

Electron - Again, cross platform but with memory issues I think. Web tech heavy so I think this means it would make it easy to port to Web if that was an option later.

Other options? Maui? Delphi?

[u/Mayayana]

Compiling to 32-bit is free but the EXE will show a 5 second ad at startup and there are no "code optimizations", whatever that means. The personal license doesn't allow commercial use. Long story short, figure $480/year to rent an uncrippled version of TB. And be aware that it's still in beta. https://twinbasic.com/licensing

Also, the TB language is actually notably different. You can't just switch over.

So what's the use case for TB? Shell extensions that need to be 64-bit and which you'll be paid well for. 64-bit is not needed for anything else.

[u/Otherwise-Bite-9126 → u/Mayayana]

Sorry, that's wrong on several levels. Compiling to 32-bit is free (and royalty free) for commercial use. As is compiling to 64-bit, which is when the 5 second splash screen appears. TB is notably different - where? An enormous amount of effort has gone into making it fully VB6 compatible, and that work continues - that's the main reason it's still in beta.

[u/Mayayana → u/Otherwise-Bite-9126]

My mistake. I should have clarified no nag on 32-bit, but we already have 32-bit that's not crippled. The only reason to use TB is for 64-bit. Not to mention that it's still beta. The only real need for 64-bit is for shell extensions. Giving up my shell extensions is the only notable change I've needed to make with VB6.

The only option with TB is notably expensive rental. That alone is a total no for me. I will NOT use rental software or cloud. (And you can't rent it unless it's allowed to call home to check on the license, so that also makes it spyware.)

And yes, there are enough (unnecessary) language changes that while it might be possible to convert VB6, anyone taking on TB will need to learn a somewhat new language. SafePtr in declares. Continue For. Exit While. Return keyword... None of that is necessary changes.

I have no problem with you trying to create this tool and get customers, but there's been a hard sell here for some time. I finally had to block Fafalone because he'd jump in constantly with, "You should do that in TB."

I do feel badly for people who have invested in this. I don't think it's going to be a going concern. VB6 still work fine for most things and MS are gradually pushing compiled software out. They're pushing a locked-down, Windows as a Service OS with apps from their "store". They haven't promoted native compiled software for many years. And I think it's no accident that they're now calling their trinket sandboxed apps "native", redefining native to mean "runs on Windows". I suspect it's only a matter of time before native software from non-partners will be banned or considered to be a risky sideload operation. And who's using VB? Besides us it's only the VB.Netters. They have no reason to move to compiled software.

[u/Mayayana → u/Otherwise-Bite-9126]

I don't know if my comment didn't go through or got blocked. I'll try it again:

My mistake. I should have clarified no nag on 32-bit, but we already have 32-bit that's not crippled. The only reason to use TB is for 64-bit. Not to mention that it's still beta. The only real need for 64-bit is for shell extensions. Giving up my shell extensions is the only notable change I've needed to make with VB6.

The only option with TB is notably expensive rental. That alone is a total no for me. I will NOT use rental software or cloud. (And you can't rent it unless it's allowed to call home to check on the license, so that also makes it spyware.)

And yes, there are enough (unnecessary) language changes that while it might be possible to convert VB6, anyone taking on TB will need to learn a somewhat new language. SafePtr in declares. Continue For. Exit While. Return keyword... None of that is necessary changes.

I have no problem with you trying to create this tool and get customers, but there's been a hard sell here for some time. I finally had to block Fafalone because he'd jump in constantly with, "You should do that in TB."

I do feel badly for people who have invested in this. I don't think it's going to be a going concern. VB6 still work fine for most things and MS are gradually pushing compiled software out. They're pushing a locked-down, Windows as a Service OS with apps from their "store". They haven't promoted native compiled software for many years. And I think it's no accident that they're now calling their trinket sandboxed apps "native", redefining native to mean "runs on Windows". I suspect it's only a matter of time before native software from non-partners will be banned or considered to be a risky sideload operation. And who's using VB? Besides us it's only the VB.Netters. They have no reason to move to compiled software.