And the VB6 compatible twinBASIC programming language supports unicode and 64 bit compilation - and has a modern IDE.
And it can import VB6 source code and forms.
PhotoDemon has now been updated to 64 bit using the twinBASIC programming language.
twinBASIC is backwards compatible with VB6 (and VBA) and can import VB6 source code and forms.
It seems that can buy a perpetual license for GBP £5000 / developer, which is equal to 16 years of monthly subscription (quite optimistic for a 3yo project).
it seems pretty reasonable to charge $30-50 a month for somebody doing the hero's work of reimplementing and building on top of a 30 year old programming environment. also there's a free one! spray money the people who do crazy niche work! that's what makes the world beautiful!
twinBASIC programming is backwards compatible with VB6 (it intends to be 100% and is very close to that now). Existing VB6 source code and forms can be imported and run (at least as 32 bit apps.). twinBASIC can compile to 64 bit and has many modern features. There is also an optimising compiler.
There is a free Community Edition.
VBA can also be replaced with twinBASIC programming.
Future plans include Linux, MacOS and Android versions.
I've been using/evaluating twinBASIC for a few months now (other than that I have no connection with the twinBASIC developers).
I've been very impressed with everything about twinBASIC so far.
There is a free (including commercial use and royalty free distribution) community edition (Windows only, 32bit and 64bit - though the 64bit has a nag screen).
The paid editions add optimised compilation, and (planned) support for Linux, Mac and Android (and possibly Web).
Compared against other products such as Gambas, Xojo (realbasic) or VB.Net it has the advantage of being able to import existing VB6 apps and run them as Windows 32bit apps (much of this is available now, but there is still some way to go for 100% compatibility). RAD Basic may offer compatibility too, but it seems difficult to find an up to date evaluation download.
twinBASIC also goes beyond what VB6 offered - 64bit compilation, multithreading, creating DLLs etc. (some of which could be done with hacks in VB6).
As for a potential market, that is difficult to say. There are still huge numbers of VB6 applications in use, having the ability to move easily to a new language may be attractive for whoever still supports those applications.
There is certainly interest, a thread about twinBASIC on VBForums has had almost 400,000 views.
It's an interesting question. It looks like TwinBASIC embraces the OLE/COM/ActiveX model as its native model. VARIANTS and BSTRs. This means advanced patterns like ObjPtr and StrPtr can work, assuming other compatibility is high.
I'm unsure about RAD Basic here, but a contentious thread of VBForums suggests it differs here.
Now, arguably ObjPtr and StrPtr aren't part of the semantics of VB6. Nonetheless, if you want compatibility with some real world code, it needs to work.
(I too have no connection with twinBASIC, except I'm a VB6 fan who is technologically impressed by it.)
This would be huge. Last time I was out field deploying a camera system, customer wanted a custom PVM (Public Viewing Monitor) with a few tweaks, I spun up VB, added the VLC component that gets installed anytime you put VLC on windows. Wrote a few lines of code and cleaned up my tools and left.
At some point Microsoft (who no longer support the IDE) will also stop supporting the VB runtime, and companies will have no choice but to convert those old apps.
I doubt if there will ever be a VB6 revival.
I think they should focus on 100% compatibility, and 64bit code generation.
Perhaps allow the new Apps to connect to modern cloud services instead of MS access, or on premises SQL, preferably without anyone having to touch any code.
Also some kind of project analysis and auto-documentation so the new developers can understand what the project does, would be useful.
>I think they should focus on 100% compatibility, and 64bit code generation.
100% compatibility seems to be the main focus of the twinBASIC developers.
64bit code is already available. One big issue is ActiveXs - they are supported, but there are few 64bit third-party ActiveXs. So the support of 32bit ActiveXs in 64bit twinBASIC apps is planned but not yet available.
The migration tool was next to useless. Even if, after a lot of effort, you migrated your app it would typically run a lot slower than on VB6.
The only practical way to "migrate" was a complete re-write, that way you could have something comparable in performance to the original app.
And that is why there are still so many VB6 applications around today, the cost of migrating (to an app that was no better than the original) was rarely justified.
Now that Microsoft support VB6 until at least 2025 while VB.Net is falling in popularity (only 12% of .Net developers use Vb.Net now) it looks like those staying with VB6 made the right decision.
«Now that Microsoft support VB6 until at least 2025»
Microsoft only supports the VB6 runtime. The VB6 IDE and editing tools are no longer supported. Building new projects or new builds of VB6 applications is dangerous and unsupported.
«VB.Net is falling in popularity (only 12% of .Net developers»
So what? C# and F# are both good languages, and it makes sense if VB.NET is a good stepping stone to one or the other. VB.NET isn't going anywhere, it's also a good language for those that want to use it.
«those staying with VB6 made the right decision»
Hah. I'm not sure I agree with "right" from your analysis. Those who have stuck with VB6 in spite of all that has happened in language design and platform changes since VB6 was discontinued have certainly decided to be their generation's COBOL programmers. Certainly there will be money to be made there in ridiculous contracting fees for companies that don't know any better, and that's a possible definition of "right decision", I suppose.
