This forum is why VB6 is still usable today

[xiaoyao]

Interesting times for VB6 developers. Lots of potential VB6 alternatives being put forward.

twinBasic has had over 250 downloads of its Developer Preview

RAD Basic is on Kickstarter

IndicSoftware have an IDE with a VB-like language

and possibly Visual Free Basic

What is the use of downloading by 250 people?

In the early days, there were three million users of a software for sending and receiving mail in China.

[VB6 Programming]

Olaf has shown his vbRichClient working with twinBASIC

vbRichClient on twinBASIC

Lots of interesting things happening in the VB6 world at the moment.

[yereverluvinuncleber]

I thank the mods for their part in keeping this forum usable.

[Episcopal]

Olaf has shown his vbRichClient working with twinBASIC

Lots of interesting things happening in the VB6 world at the moment.

Each one who tests his son ... I am waiting for the GUI part to test my components ...

[VB6 Programming]

VB6 'compatibles' update...

twinBASIC has updates to the Preview version

twinBASIC Twitter account

twinBASIC weekly status updates

twinBASIC say...
Once we have finalized and fixed up any bugs in the first release of twinBASIC, we will be focusing on three key areas over the coming weeks and months:

• Forms / GUI support, including full backwards compatibility with existing VB6 forms.
• Native compilation.
• Cross-platform compilation.

RAD Basic has moved to Patreon for funding. Hopefully there will be a Preview/Beta edition.

RAD Basic website

RAD Basic



MixLangz are promising a release shortly, though it isn't really clear just how VB6 compatible it will be.

Mixlang

[yereverluvinuncleber]

I am going to contribute to RADBasic's Patreon request and I will keep an eye out on TwinBasic. Mixlangz is interesting but I feel they miss the point if they don't hone down the VB6 compatibility.

The point is that many such as the Mixlangz crowd are missing is that there are a surfeit of choices that any of us could take, Lazarus/Delphi, C++, C# &c but we (simply?) want a compatible VB6 on Windows that is supported, compiles to 64bit and has the potential in the future for cross platform operation. I'll take all the rest but whatever else comes is just a bonus.

[VB6 Programming]

we (simply?) want a compatible VB6 on Windows that is supported, compiles to 64bit and has the potential in the future for cross platform operation. I'll take all the rest but whatever else comes is just a bonus.

Exactly that. All the other offerings, from VB.Net onwards have failed to offer VB6 backward compatibility. That has to be the starting position for any VB6 replacement.

[VB6 Programming]

Lots of progress with twinBASIC. The language is largely VB6 compatible and twinBASIC have released a 12 month roadmap for twinBASIC...

https://github.com/WaynePhillipsEA/twinbasic/issues/335

Expected release dates of major features:

• FILE I/O SUPPORT (September 2021)
• 64-BIT COMPILER SUPPORT (October 2021)
• OPTIMIZED COMPILATIONS (November 2021)
• FORMS GUI SUPPORT
  - form designer and cross-platform forms engine (November 2021)
  - VB6-compatible Forms engine (February 2022)
  - Reimplementation of all remaining VB6 shipped controls (August 2022)
• MULTI-THREADING LANGUAGE SUPPORT (December 2021)
• INHERITANCE LANGUAGE SUPPORT (December 2021)
• EDIT & CONTINUE SUPPORT (March 2022)
• CROSS PLATFORM SUPPORT
  - Initial support for x86 and x64 builds on Linux and Mac OS (May 2022)
  - Support for ARM CPU architectures, and Android OS (August 2022)
• VBWATCHDOG SUPPORT (December 2021)
• and many other features

These are all expected release dates, and are subject to change. Beta versions will be available sooner.

https://www.vbforums.com/showthread....0181-TwinBasic

[DataMiser]

hmm hard to say it is largely compatible if it contains no form support and no file i/o. I can't think of many VB programs I have ever written that do not include both of these.

It will be nice if they pull it off and get something that can open an existing VB6 project and compile it to run as a 64 bit and/or on other OS besides windows.

[wqweto]

It will be nice if they pull it off and get something that can open an existing VB6 project and compile it to run as a 64 bit and/or on other OS besides windows.

This is *never* going to happen. At least there is no prior art -- no Windows GUI framewrk is able to work on Linux without client code modification unless it's written with cross-platform support in mind since get go e.g. Qt

In this regard any UI based on RC6 should be already TB compatible on Windows. If Olaf ports this to Linux then the promise of cross-platform support in RC6 will come to live. First of course there is the x64 Windows port that might be quite some effort -- I have no idea of his plans.

cheers,
</wqw>

[VB6 Programming]

This is *never* going to happen. At least there is no prior art -- no Windows GUI framewrk is able to work on Linux without client code modification unless it's written with cross-platform support in mind since get go e.g. Qt

In this regard any UI based on RC6 should be already TB compatible on Windows. If Olaf ports this to Linux then the promise of cross-platform support in RC6 will come to live. First of course there is the x64 Windows port that might be quite some effort -- I have no idea of his plans.

cheers,
</wqw>

twinBASIC haven't said that you can take an existing (forms based) VB6 app and run it on Linux (unless you use WINE) or other OS's.

That's why they are starting with a simple cross-platform forms designer and then adding a VB6 compatible forms engine later.
You'll be able to use twinBASIC to develop for Linux, Mac OS or Android but not, of course, be able to use Windows calls or OCX's.

There is a bit more info here https://github.com/WaynePhillipsEA/t...iscussions/270

[Elroy]

Hmmm, I'd say that the main reason VB6 is still used today is because Microsoft was so dumb when they wrote .NET and didn't make the language perfectly backward compatible with VB6. In fact, IMHO, they could still do that, but they don't think there's enough money to be made in our community to put the effort into it. At least they haven't cut us off at the knees and done something to Windows that wouldn't allow VB6 programs to execute.

And yeah, this forum is definitely a nice resource ... but I didn't join until 2014 (15 years after the release of VB6). Sure, I occasionally explored the site, but far less frequently than you might think. I was just a lone programmer out there doing my thing, tapping the F1 key when I needed some help, or maybe pulling Dan Appleman's book off the shelf (or occasionally one or two other books I've got).

IMHO, to this day, VB6 is still a great language for rapid development and deployment of end-user applications, particularly for English speaking users. It just has a nice mix of complexity and simplicity.

(As I've stated elsewhere, I think Microsoft would be doing themselves a favor if they brushed off the VB6 IDE, stripped out ActiveX OCX support [but kept internal custom UC support], worked in the LongLong & LongPtr variables, and made it compile 64-bit p-code and binaries. Making the intrinsic controls all full Unicode would also be nice.)

[Shaggy Hiker]

Hmmm, I'd say that the main reason VB6 is still used today is because Microsoft was so dumb when they wrote .NET and didn't make the language perfectly backward compatible with VB6.

They started out with that intent, but found a reason why they couldn't do that. I'm related to the guy who called the meeting to present this to Gates and Balmer. He told me about the meeting and how it went, but I didn't get into the reason that pushed them in that direction. It wasn't a decision taken lightly. However, he agreed with you that this was the reason that VB6 is still around: That decision stranded a whole lot of people and a whole lot of working code.

[Eduardo-]

Hello Elroy,

stripped out ActiveX OCX support

could you explain that point?

[Elroy]

stripped out ActiveX OCX support

Hello Elroy,

could you explain that point?

Well, I'm just thinking about all that'd be involved in making the IDE 64-bit compatible.

When we think about the "entire" IDE, we typically include the ActiveX OCX files that get installed along with the "core" IDE. The list is rather long, but the ones we hear the most about are things like ComCtl32.ocx, ComCt232.ocx, ComDlg32.ocx, MsFlxGrd.ocx, TabCtl32.ocx, RichTx32.ocx, etc.

And that doesn't count any third-party OCX controls.

To create a "fully" 64-bit compatible VB6 (or VB6.5, or ever what you want to call it), they'd have to rewrite all of those OCXs for 64-bit. So, I'm just trying to reduce the workload.

I'm just thinking about the minimum that would really get me excited, and I could live without all of those. Krool (and others) have rewritten pretty much all that functionality in native VB6 code (which could hopefully be recompiled in any 64-bit VB6.5).

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

I know I'm tilting at windmills, but maybe, someday, they'll release the VB6 IDE to open source, and we could actually get there ourselves.

Take Care,
Elroy

[Episcopal]

I know I'm tilting at windmills, but maybe, someday, they'll release the VB6 IDE to open source, and we could actually get there ourselves.Elroy

I literally dreamed of this on 2016-08-01

https://vbmania.com.br/index.php?mod...65426&pagina=1

[Eduardo-]

Well, I'm just thinking about all that'd be involved in making the IDE 64-bit compatible.

When we think about the "entire" IDE, we typically include the ActiveX OCX files that get installed along with the "core" IDE. The list is rather long, but the ones we hear the most about are things like ComCtl32.ocx, ComCt232.ocx, ComDlg32.ocx, MsFlxGrd.ocx, TabCtl32.ocx, RichTx32.ocx, etc.

And that doesn't count any third-party OCX controls.

To create a "fully" 64-bit compatible VB6 (or VB6.5, or ever what you want to call it), they'd have to rewrite all of those OCXs for 64-bit. So, I'm just trying to reduce the workload.

I'm just thinking about the minimum that would really get me excited, and I could live without all of those. Krool (and others) have rewritten pretty much all that functionality in native VB6 code (which could hopefully be recompiled in any 64-bit VB6.5).

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

I know I'm tilting at windmills, but maybe, someday, they'll release the VB6 IDE to open source, and we could actually get there ourselves.

Take Care,
Elroy

VB6 without components would be like QuickBasic (with forms and just some enhancements) or something like that, going back many steps in technology.

Of course every component will have to be recompiled for 64 bits if you want them to be 64 bits (native). Is that the problem?

I think, on the other hand, that the issues regarding components should be addressed:
No more copying to Windows/System.
SxS installations should be the norm (and easy).
May be even the components packaged inside the exes, if possible.

I don't thnk that VB would have been the success it was without components.
In fact, you would not be even able to work with a database without components.

[yereverluvinuncleber]

Just a quick thread bounce but for a good reason. Every now and then I just receive this building feeling inside of me, one that says isn't this forum a great place. I see so many good minds helping others to do this or that and it always pleases me internally.

So, a just a shout-out to those that are always "ON" here, helping others and receiving nothing in return.

Really most impressed.

[Niya]

I don't thnk that VB would have been the success it was without components.

VB was successful because it was the first of it's kind. You have to remember that before VB, writing a UI was painful. I remember what it was like to write UI code all the way back in the 90s in something like QuickBasic. Writing a TextBox in QuickBasic was one of the most painful experiences I ever has as a teenager programming in QuickBasic. And don't even get me starting on writing UI code for Windows in C. It is painful as hell and very time consuming. Visual Basic was the first time we could just drag and drop a fully functional TextBox onto a Form without writing a single line of code.

But make no mistake, if the guys who were writing C development tools had thought of this at the time and beat Microsoft to it, Visual Basic would have died in obscurity a long time ago. RAD was what made Visual Basic a success, especially when it comes to UIs.

[Niya]

Just look at this console UI menu I wrote some years ago on the forum. Passel also posted a Calendar UI interface in the same thread written in this manner here. This was what UI code looked like before Visual Basic completely changed everything.