VB6-Programming

The twinBASIC programming language is a modern VB6 - and it can import VB6 source code and forms.

The new twinBASIC programming language gives you the simplicity of VB6 with modern powerful features.

The twinBASIC programming language is a modern successor to VB6 - and it can import existing VB6 source code and forms.

You can import VB6 source code and forms into the twinBASIC programming language (with a good expectation it will run first time). And then you can add modern features and upgrade to 64-bit. And it is all familiar to VB6 coders :)

Take a look at the twinBASIC programming language. VB6 compatible and can import VB6 source code and forms and adds modern features too.

Yes, the twinBASIC programming language is a genuine successor to VB6 (and VBA). twinBASIC can import VB6 source code and forms.

And XYplorer will be even faster when it has been upgraded to the VB6 compatible 64-bit twinBASIC programming language with its optimising compiler.

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.

Very true!

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.

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.

twinBASIC programming has a free Community Edition.

twinBASIC programming is VB6 compatible and can import VB6 source code and forms.

The 64 bit version of XYplorer is written in the twinBASIC programming language (actually an import of the VB6 source code and forms).

>Looks like you need to call InitCommonControls(Ex), in addtion to the manifest.

Often all you need is the manifest. If the app won't run at all after you have added the manifest, then add a call to InitCommonControls(Ex)

>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.

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.

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.