Visual Basic 6.0 replacement challenge
Having come from the old DOS days (Quick basic 4.5 and PDS 7.1), as well as the old Visual Basic (Classic) days (VB 1.0, 2.0 and 5.0 Pro), I think I have some experience with why Visual Basic was so popular, as well as some of its weaknesses. I understand why Visual Basic 6.0 is still popular today, even though it has seen an untimely demise.
Why so popular ?
I can’t speak for others, but there are a few reasons I liked it. When I made the transition from DOS to Windows, learning GUI programming simply put was not easy. Learning to write Windows programs in C back then was not for the faint of heart. Visual Basic made prototyping a GUI app and building it so easy and fast, no wonder it was a big hit back then. Simply put, it was all about the Visual Designer. The Visual Designer made working with C look embarrassing.
Second, it was all about the BASIC language. Yes, BASIC. Old time BASIC was not the beginners language many are told today. It’s first generation was very limited, but by the time Microsoft’s Quick Basic and Professional Basic came out, the language was highly professional and capable. I could even code modules for PDS 7.1 using assembler. BASIC borrowed many things from more powerful languages like Pascal, but kept its natural syntax and easy coding style. Visual Basic built upon a long history of BASIC’s improvements.
Now you put together an easy to read and code language like Basic with an actual GUI Visual Designer and you had an absolute success.
Lastly, the addition of the VBX and later OCX component model allowed Visual Basic to be enhanced by third parties using languages like C. The number of VBX’s when Visual Basic first came out bloomed so quickly that many were likely surprised at the support of the language.
Visual Basic’s downfall
So what happened to one of the most successful programming languages ever ? Probably many may find it hard to admit that Visual Basic had any weaknesses, but it did. One of its early weaknesses was that it was not a true native code compiler, but it was a PCode compiler. That really hurt Visual Basic’s image for the first four generations. When compared to the likes of C, it was always kept in the realm of a hobby language. Yet despite this is was still very successful. You couldn’t write a DLL library (a real stand alone one to be shared with other languages) in Visual Basic. C programmers could write DLL’s for Visual Basic, but not the other way around.
While it is true that eventually VB got a compiler in versions 5.0 and 6.0, that was simply a hack. From what I have read, it appears Microsoft used a C backend for the compiler rather than write one from scratch. It worked and it satisfied for awhile, but another danger to VB’s lifespan was coming and it was not what you think. Yes, dot.net spelled the end for VB 6.0, but I don’t believe it was simply that. The real end of Visual Basic was Object Oriented programming (aka. OOP). Why ?
I can only appreciate this from many years in hindsight. After spending a good 20 years or more learning to become a proficient WIN32 API programmer, only then would I see some of the real reasons for the end of Visual Basic.
Visual Basic was not an objected oriented language. Yes, it had objects of a sort, but VB was a mishmash between old time procedural coding styles and a version of Object Oriented Programming. The OOP stuff was one solution to the difficultly of writing GUI code in Windows. Just look at old time C GUI code using the WIN32 API and you quickly prefer using Visual Basic’s GUI objects. But remember that behind all those GUI objects, is still WIN32 code. Even when third parties created components for use in VB (VBX, OCX), likely most of them were written in C using low level WIN32 code rather than Visual Basic code.
So Visual basic was loved by many and likely one of the easiest to use programming languages ever, but it was relegated to second class citizenship to the likes of C, because its core engine, its components, etc. were being written in C, not BASIC.
It’s cry for a compiler for years by VB users was an indication that VB was obviously lacking. Also, until it had a real compiler there was also a cry for better performance. The compiler came too late in VB’s life. I think that hurt it.
Lastly, Visual Basic was not what most thought it to be. I got a rude awakening when in later years I read the following article about Alan Cooper the real creator of Visual Basic.
Read article here: https://www.cooper.com/alan/father_of_vb.html
Microsoft did not create Visual Basic ! They took someone else’s excellent work in a visual prototyping designer and converted it into Visual Basic. Simply put, it was a “hack”, a “mishmash”, a “hybrid”. Don’t get me wrong, it was amazing technology at the time, but it was not the building of a programming language from the ground up like most had been in the past. So likely this too may have contributed to the eventual downfall of VB. Microsoft was building upon something which originally was not intended to be a Windows programming language.
Why can’t Visual Basic 6.0 be recreated today ?
Well, it could, but it would not be Visual Basic as we know it. Why ? There are a number of reasons and some long time VB 6.0 users may not like the answers. First of all, to make a better VB 6.0 requires that many of the things done originally with it, not be done the second time around. Second, a decision has to be made about the coding style to support. VB was a hybrid language. The GUI stuff was all OOP based (or sort of), but much of the code one would write in events was actually procedural in nature. When VB programmers reached the limits of VB, they often resorted to the WIN32 API and a huge amount of advanced code in VB is actually old time WIn32 procedural code. So even when going low level a procedural style was used. It is this hybrid nature of VB which can cause problems in recreating it.
So does one simply go all out with OOP in VB 7.0 or do we fall back to the hybrid nature of classic VB ? If one goes all out with OOP, then hasn’t that already been done with Visual Basic dot.net ? So the real power and ease of use of classic VB really came from its procedural nature. But back in the day, Windows did not have an OOP based component model used in most programming languages, so one was created, the VBX and later changed to OCX (using OLE from WIN32). VB’ers became too dependent upon the component model used and when VB came to its end of life, so did all the third party developers of those components. VB’ers have been able to extend VBs life, but if they used any components, which third party developers don’t support anymore, then they have a big problem. You can solve some of the weaknesses of VB in VB or resort to the WIn32 API, but you can’t solve the problems with obsolete COM components.
VB’s biggest boon, the third party component market, later became a huge burden for supporting a programming language which came to an end of life.
It was some of the original designs of Visual Basic, which in my opinion, were its greatest weaknesses. So to recreate Visual Basic simply to create a modern day clone of it, simply isn’t viable. Sorry, but we can’t change now those original design decisions.
Visual Basic could be used as a template for a new language
I think this is the better route to take. Create a new language, like Visual Basic, but with a different design model. To do this requires asking oneself, what worked in VB and what didn’t ? From my own experience as a GUI framework developer, I find that there are 4 key issues in creating a new VB like language.
(1) Native code compiler
Any new VB language needs to be designed as a native code compiler from the ground up. Rather than write extensions to the language in other languages, the language needs to be able to be written in itself and all external components in this language. This requires a native code compiler.
So for any project to build a VB 6.0 replacement, it needs to start from building a core language with a simple text based IDE and create the compiler first without all the GUI stuff.
(2) Choose a GUI framework design which more closely talks to Windows
Well, if you want that to be totally OOP based, then hasn’t that already been done (aka. VB dot.net). So what is left ? Either a hybrid like classic VB or go all out using 100% procedural code. Now a limited class structure could be used if your compiler supports it, but once you start down the OOP path, it tends to take over. Now the WIN32 (core of it) is not OOP based, but is procedurally based. For example to create a window (form) or a control on it, using the WIN32 is a simple call to the CreateWindowEx function. That is procedural in nature, not OOP. So what would happen if you designed the GUI framework to be procedural in nature ? Can it even be done ?
Actually, yes it can be done that way and the surprising thing is that procedural frameworks lean towards being leaner, smaller and faster, unlike OOP based frameworks which tend to get bloated very quickly.
(3) The Visual Designer
If there is one thing which made Visual Basic, Visual Basic, it is the Visual Designer. In the beginning that is what caught every ones attention. Drag and drop visual design made software development so much faster. It turns out that this is one reason why the creation of a VB clone has been so difficult. A lot of people can write some kind of compiler (or at least build a parser on top of another one like LLVM), but the skills at building a real drag and drop visual designer are rare. Simply put, it is not easy. I know. I spent 20 years finetuning my skills in this. One reason it is so challenging is that the WIN32 API does not have a high level visual design engine in it. It is just not there. If you use a modern day programming language which provides some classes to do some basic drag and drop, you might think it is easy to do, but the underlying WIN32 code in those classes is quite complex. Now when you start adding things unique to programming language designers, such as snap to grids, dragging multiple controls together, dragging not simply a graphic image but a real GUI control (you have to turn off all input responses in the control first) is not as easy as it looks. If it were, then all those “indie” programming language developers out there would have recreated the Visual Basic experience already. But they haven’t and they can’t come close.
The original classic Visual Basic (1.0), the drag and drop experience, which was leading edge at the time, is actually very poor in comparison to what is possible today. The standards got higher and higher over time so if a VB clone Designer more closely resembles VB 1.0 rather than VB 6.0 then it just won’t do.
(4) Rely less on components
Some component models may be useful, but a VB replacement, unless supported by a huge portion of the software industry, needs to be less dependent upon a component model, especially VB 6.0’s OCX model and instead provide the low level tools so programmers can create anything missing in the language and use them via either source code or in one of the longest standing library models in Windows, which is the DLL (dynamic link library). DLL’s can be shared with other languages and they are simple to use and very efficient. Using a simple procedural based API in a DLL can be very powerful.
A Visual Basic replacement is possible, but …
Like I said above, a VB replacement is possible, but don’t try to recreate the original Visual Basic. The OOP version has already been tried (aka. dot.net) and it just doesn’t cut it for some. The other alternative is to “go native” as I describe above. It is a more procedural route. Is it even doable though ?
Absolutely. I should know. I am not experienced at building compilers, so that is the one skill I lack for me even to attempt it. But my experience is with the WIN32 API, procedural GUI frameworks based on the WIN32 and lastly Visual Design. The interesting thing is that when I resorted to a procedural style of coding using the WIN32 to start with, building a GUI framework was not only doable, but it put to shame the hybrid model of classic VB. I could squeeze in more features into a procedural framework in 25% the size of the VB 6.0 framework. Do you find that hard to believe ?
Using a native code BASIC compiler (powerbasic) and the low level WIN32 API, it is amazing what one can accomplish in building a GUI framework. Having built my own GUI framework, I also built into it a drag and drop visual design engine. Using that engine I then wrote a visual designer.
To see the visual designer in action check out this video: https://www.youtube.com/watch?v=QiB8BJG4Cnk&t=129s
To see the GUI framework in action and see how small it is, download this sample test app: http://cwsof.com/download/testwin8.zip
I applaud the desire and efforts to recreate classic Visual Basic. But unless those efforts take into consideration some of the above concerns, then they will likely never get past being just a “noble effort” and never fill the needs of those truly desirous of a real VB replacement. I found half of what I needed in Powerbasic, but it only provided me with the native code compiler part. For me, I had to build my own GUI framework and Visual Designer. Even there I had to make some compromises in my designer to satisfy the needs of Powerbasic users. The compiler had its own IDE which I chose to support, rather than put a complete code editing environment in my designer. But it helped me see the potential if all of it could be combined.