After I loved on to .NET and C#, I was happy to leave the sinking ship that was VB6. As I learned C#, I became more and more aware of just how shoddy and poor that ship was. I had since put it behind me- Visual Basic 6 being long forgotten before I even came aboard.
It would seem however there are still those, in 2014, insisting that it is actually still used by the majority of programmers. I find this claim difficult to believe. Since the author has no ill-intentions, here is the link to that article.
Under normal circumstances this is the kind of ‘crazy-talk’ one is best to avoid. But I feel I am in a unique position. For many of the arguments presented if you had shown me them 6 years ago, I would have resoundingly agreed. I no longer do so and find my previous stance to be ignorant. With that in mind I’ve decided to write a blog post to fully explain why I switched to C# and why I do not regret it for a second. I may cover some of the deficiencies in VB6’s design role that I thought was par for the course for development environments until I switched.
The article in question starts with a rather brief history of Visual Basic 6. Not surprising. It references the prevalence of ADA and COBOL- which are both still used today- as evidence that “newer is not always better”. On the surface this seems like a reasonable argument. However, by following the link provided we see that the ADA Compiler had a release in 2012; and Cobol has “OpenCOBOL” (Now GNU Cobol) still actively maintained and available for download. This puts a bit of a problem in terms of the comparison, in my opinion; Visual Basic 6 has not seen a software update since 2003, with Service Pack 6. (which, reminds me I still need to install SP6). Thus the comparison is false; those other languages are older, however, they are also actively maintained.
It continues by making two claims. The first is that, with increasing processor speed, compiler designers have become increasingly careless and have overestimated hardware capabilities. The second isn’t really relevant and is a literary device theorizing that the above was taken from 3-D Game Makers.
This has some issues.
First, take BCSearch. This is a Program I wrote in VB6 and haven’t bothered to rewrite yet; this is because I Don’t really use it and because it works (for the most part). The project Group- which consists of BCFile (my IMO very nice Object-based File I/O library, with support for Alternate Data Streams, no less) BCSearch, and a few other programs, amounts to- totalling the .cls,.frm and .bas files, 3,703,486 bytes. BASeBlock consists of 3,640,350 Bytes of C# Code. Pretty comparable.
The Visual Basic 6 compilers takes 3 minutes to perform a full recompile of the entire project.
Visual Studio 2013 takes 40 seconds to perform a Clean&Build of the entire Project.
This would seem to demonstrably show (it is repeatable, both BCSearch and BASeBlocks are available on my github account) that the assertion that Compilers are effectively less efficient and slower to be false.
The next Paragraph has a header of “Why is VB6 still successful ?!”. This I think makes yet another false assertion; that being that VB6 is successful. This is perhaps difficult to properly define- since what exactly “success” means is difficult to come up with. After all, VB6 as it is cannot still be “successful” since it is no longer sold; so I would imagine this means that it is still used; which is what I base my objection on. It is hardly common to find a VB6 developer, and even harder to find programs written in VB6.
It’s next statement is that “VB6 get’s along well with embedded machine code and [Embedded] Assembly Language” This is actually not entirely accurate. The method used to run arbitrary Machine code is hardly “friendly”; the process involves creating a String that contains the binary machine code that you want to execute. In order to execute that code, you use the CallWindowProc() API function, but instead of passing a window procedure, you pass in a pointer to that string. Control will pass to the string and it will execute as machine code. The statement that this “get’s along” with VB6 is not the case; as this is rife with problems that can cause the IDE to crash or simply close itself. Mistakes within that compiled assembly cannot be debugged in place by any means, mistakes and bugs will take your entire application down with them. The article then discusses “advanced VB6 programmers”; what it fails to mention is that all of the advanced programmers that provided the wealth of capability to Visual Basic 6 (vbAccelerator, Edanmo, etc) have all moved on to C# and/or VB.NET. It would seem then that logically if those ‘advanced VB6 programmers’ moved on, moving on was in fact the wiser choice? They have left behind a lot of very useful VB6 oriented articles, type libraries, and controls, which we can still leverage, but it seems a curious omission to not mention how they are no longer active with VB6. It then says “Nowadays, through a simple copy and paste of the myriad of functions created by advanced programmers for VB6, an intermediate level programmer can create VB6 applications that run faster than those designed in C++ (no joke there).” They provide no examples or testable, repeatable observations; therefore this is yet another assertion. That isn’t to say that VB6 code cannot be faster than C++ code, but it has the flaw that it promotes cowboy coding (Just copy and paste this code of which you know very little about into your project) as well as working with a premise that a faster piece of software is always superior to a slower one, which is false.
It continues, and suggests that Microsoft should “perhaps listen to the hundreds of thousands of programmers who demand the introduction of VB6 to the market”; I assume, this means, the re introduction to the market, nearly a decade after it had been shelved. It cites the VB6 petition. This is present [url=http://classicvb.org/petition/]here[/url]. It’s notable, that this petition has been online for nearly a decade; to assert that all of the signatories still agree with the premise of the petition is false- I base this on a simple fact that I am a signatory! That is, my name is on the petition. I signed that petition 12 years ago; as did a large number of the other people listed. I obviously can only speak for myself, but if I was able to do so I would remove my name from the Petition, since I no longer feel the same way. It’s possibly many of the others on the petition also have completely forgotten about the petition and simply moved on. Thus the assertion that all the signatories still desire the petitioned results is disingenuous.
It then cites a few available VB6 projects; the display of these projects is something I find curious; the work and effort and the end result of these projects does not mean VB6 is viable, it simply means the developers are capable. After all, if an artist makes an extraordinary work of art out of a dog turd, people praise the artist, not the turd.
Let’s take a look at some of the examples.
This project appears interesting, However it sadly also steals most of it’s code. Some with attribution, some without. All taken from “Planet-sourcecode”. It was submitted recently, but the project file dates are last edited in 2006; that makes me suspicious that the person submitting it is the real author.
It features many issues that stem from it being in VB6. I was able to crash it by simply shrinking the form (division by zero). The Menu is emulated with PictureBox’s and not responding to any accelerator keys properly being one. These issues are not present in… say… Linqpad, which is written in .NET and runs .NET language code. To me this certainly feels like a project originally created by a high-schooler- the reason I think this is because I used to be one and I know I used to think those sorts of things were actually viable when they weren’t.
The article claims this is “as powerful as Photoshop is”. This is simply not true; and the author of the program makes no such claim. It is only getting layer support now, in the development builds. It’s definitely a very interesting project, but the claims made in the article are simply false, and do it a disservice.
Back in the day, I had a VB Module called “GRAPHICS.BAS”. This was a module I created with one of my early applications for drawing a Gradient. I don’t remember what the gradient was for- I suspect it was a stupid feature that just drew a background for no good reason. the function was called Paintfrm and I put a lot of work into it. It had loads of functions and I had much the same perspective expressed here. At any rate- all of the functions described do in fact have implementations in any number of other languages, and stating otherwise is rather foolish.
This is pretty much the same program as described earlier, but in a earlier variant. It’s posted by the same person on Planet Source Code.
Without a link I cannot really verify this. I guess it’s a program to open a certain file type.
It goes on to cite statistics about Visual Basic usage. the statistics are based on Search engine search results of certain queries. That is not a way to determine the popularity, capability, or even permeance of a Programming Language. remember that those search results will include websites that were indexed years ago; those webmasters could have moved on already. And certainly the argument that there is more code for a given language does not show that the language is better anyway.
VB programmers do not particularly like VB. NET and don’t like any other versions of VB after VB6. Why? VB6 is dependent on a single file, namely: msvbvm60.dll. On the other hand, VB .NET is dependent on the .NET Framework environment, which inhibits the individualism of the programmer and this is not consistent with the human nature.
This is my favourite portion of the article. I used to be a VB6 programmer, and I would have said the same thing. I would have been wrong; Visual Basic 6 applications typically have far more dependencies, including various Common Controls and libraries, depending on the Application. I was a big fan of vbAccelerator components, for example; when using COM components they need to be registered on the machine or else your application fails without a specific error (ActiveX Component cannot create object) and you have to find out what component was not registered. Quite painful. Most systems will have the .NET framework installed; arguing that you need it installed to run an application is pretty dumb, particularly since it doesn’t “inhibit the individualism of the programmer”, which is a extraordinarily silly claim.
Now, with that out of the way, let me be blunt about this.
C# and VB.NET are better languages than Visual Basic 6 in absolutely every single possible way. There is not a single thing that, while working in C#, I think “golly, I wish I could still do that” about VB6 features. Not a single one. I do not miss ANYTHING about that terrible, underachieving IDE and it’s accompanying language. And when I was using it, the only thing driving my dislike of .NET was misunderstanding and a fear of that which I didn’t understand. I slagged .NET and C# in order to bolster myself- I didn’t know C#… “but bah that didn’t matter right because C# is .NET and .NET sucks.” And I continued blithely along in my ignorance, working in VB6.
I can think of many specific situations where VB6’s language falls short. It does not allow for Enumerator Methods, you cannot use threads, and it’s standard library (VBRUN) is dismal. C# and VB.NET with the .NET framework provide a veritable wealth of classes that you can use for any number of purposes; to get many of those same capabilities with VB6 you have to fight against the IDE, the language, or the compiler. It’s simply not economical.
I have been using Visual Basic 6 for many years; I have come to the point where using it is effortless; nearly any problem I have I can design and program with Visual Basic 6.
However. Visual Basic six is over 10 years old. Mainstream support ended a few years ago, and after Vista Microsoft makes no promises that programs designed with Visual Basic 6 will work. Even creating programs that support the various UI features of XP could be a chore. With Vista, Not only does one need to include the proper manifest resource or file to force their VB6 applications to link with the newer version of comctl32, but it is almost always necessary to include an additional set of directives in the manifest to make the program request administrator permissions. I have yet to determine why some of my less trivial programs crash before they even start when run with the same security as the user, but I imagine it’s directly related to COM components, their usage, and the permissions surrounding them.
Another area of concern is with the use of proper icons; Visual Basic complains when you try to use a icon with a alpha channel. However, through a few API techniques and some resource editor trickery, it’s possible to have your application use 32-bit icons both as the program file icon as well as the icon for your forms. Rather then repeat the material here, I will point you in the right direction if this type of this piques your interest. www.vbaccelerator.com- I cannot praise that site and it’s creator enough. While many of the projects and controls he has on-line I have personally attempted before finding the site (I had a somewhat working toolbar control and a control I called “menuctl” that allowed moving the main menu around as a toolbar), the sheer number of completed, documented, and well written controls on his site is simply mind-blowing. There is also a .NET section to his site as well, which brings me to my next point.
There are only a few reasons why a programmer would choose to use Visual Basic 6 for a new project today. The main reason is simply because we are stubborn, for the most part. The fact that .NET is better in many ways then VB6 does not sway us to use it. The fact is, we all feel “betrayed” in a way, but the shift to .NET. Millions of lines of code that were dutifully compatible through all 6 versions of Visual Basic 6 now break when loaded in VB.NET. But I believe, that the majority of VB6 programmers have simply been blinded to the number of problems Microsoft would have faced to continue using the same COM oriented framework that VB4 and higher have used.
COM,or, Component Object Model,(sometimes referred to as “Common Object Model” which is dead-wrong) is a Binary compatible method of providing interoperability between applications. COM was essentially designed to prevent what was known as “DLL hell”, since at that point in time DLLs provided their functionality through exposed functions, some versions not compatible with previous versions, meaning it might be necessary to, for example, have 5 different versions of MFC41.dll on ones PC. The idea was, each version of a COM component would be Binary compatible with the previous version, which means, for example, that a program designed for version 1 of “foocomponent” could still run and use version 4, but without the new features of version 4. This functionality was implemented by the creation of Interfaces. Each version of a component would add a new interface- for example, IFooComponent, IFooComponent2,IFooComponent3, etc, and client applications who want to use FooComponent would use the interface appropriate to the version they wish to use.
There was, however, one problem. Most of the maintenance between versions was left to the programmer of the component- they had to create the new interface, make sure previous interfaces worked, that old clients could still instantiate their objects, etc. Basically, it made the critical mistake of putting the user of the technology (in this case, the programmer) in a critical position and with a number of responsibilities to get things to work properly.
Microsoft, of all companies, should know that putting the programmer in a position of such responsibility is prone to failure; hell, many of them can’t even be bothered to follow standard API documentation; for example, actually reading the documentation; this resulted in hundreds of man-hours of programmer time being consumed by the creation of “compatibility shims” to let these programs work. (otherwise, installing a new windows OS would break these programs; they worked before, so as far as the user sees the new Operating System is to blame). Anyway- this failed miserably. Programmers would sometimes simply change their interfaces rather then implement new and old ones, meaning, like with the DLLs of before, new DLL versions were incompatible with the old ones.
It was clear that COM, or, at least, COM as it was presently designed, was far to dependent on the programmer to “do the right thing” then was reasonable. So, Microsoft, at some point, decided they needed a new object framework architecture.
VB6, as a COM-based language, would have required extensive changes to support this new architecture. the prospect of such a huge revision probably made them take a second glance at the language itself, and the cruft it still has from previous iterations of the basic language. aside from retaining such archaic constructs as the “GoSub…Return”, VB6 also “failed” in a sense on a number of other areas. Error-Handling, for example, was still done using “On Error” statements, which redirected flow to another segment of code. It was up to that block of code to evaluated the error, using the “Err” object (In VB1-3 there was only Err which was the error number and Error$, which was the description), and then either resuming that same statement that caused the error (Resume) skipping that line, and continuing with the next, (Resume Next) or even raising the error again, causing the error to cascade up through the call stack.
This Error architecture had a critical flaw- by using this form of error handling, flow could change to the error block for any reason, at any time. This meant that if the procedure dealt with resources, such as file handles or memory blocks, it would have to keep track of what needs to be undone so that the error code could also double as partial cleanup code. Another critical flaw was simply that it was ugly; it looked and functioned nothing like the Try…Catch statements in many other languages. Also, it could become impossible to trace exactly where an error occured when errors cascaded; and error handler might be forced to handle an error from three levels down in the call-stack, so even if it understood the error in the context of the procedure, the context that the original error occured in and exactly what it means was lost.
My main language is Visual Basic 6, but I am not so blind as to reject VB.NET, or .NET as a whole, merely because it essentially replaced VB6. The truth is- we, as VB programmers, have made a large number of requests to the VB developers. VB .NET answered and fixed a huge number of those requests, and yet it is still shunned; it is clear to me that it is not merely the loss of backwards compatibility that causes such antagonism with VB6 programmers, but also the human element of resistance to change.
With previous versions of Visual Basic, one could migrate all their code to the new version with little or no difficulty.
This, however, had a price- since the new version made few, if any, requirements for conversion, old antique code would often be upgraded and imported into the new environment. Since backwards compatibility was the rule, old elements such as line numbers gotos, and gosubs remained in the language. Antiquated concepts such as type declaration characters remained in the language. Such visages of a forgotten era had no place in a modern language.
All the above being said, VB6 is still a language capable of creating modern applications; however it is important for the programmers who still use it to realize that they aren’t using it because it is superior or because .NET or any other language “sucks” by comparison, but rather as a result of their own stubborness and unwillingness to learn new programming concepts.
A anecdote, if I may, can be found in my introduction to the use of “class modules” within Visual Basic. at first, I had no idea what they were- I simply shied away from them, and stuck to Forms and code modules. I used all sorts of excuses- Class modules are slower, they bloat the code, etc. All of which were, almost universally fabricated or found on the web written by grade 8 students who barely understood the meaning of the word “class” in the context of programming or objects.
After, however, creating ActiveX Controls using the “userControl” Object, I realized the similarities, and the possibilities that could arise. My first conversion attempt was on my Current “flagship” program, the game I called “Poing”. At that time, the entire game was designed using User defined types as functions that operated on them. I understood the concept of encapsulation and managed to convert the entire architecture to a Class based object heirarchy- and it worked. My concepts still contained flaws, such as including critical game logic in down-level objects, but for the most part my udnerstanding was sound.
As my understanding of the concepts involved improved, so too did my antagonism disappear. It was clear to me that the fact that I didn’t understand classes at the time lent itself to a distaste for them- basically, the old adage that one is “afraid” of what one doesn’t understand was at least partly true. This, I feel, is at the very core of the antagonism against .NET. the main detractors of the framework are often people that neither understand the concepts involved nor do they realize how said concepts add increased possiblities and easier maintenance.
Even so- .NET has, in my opinion, one critical flaw. the IDE is slow. even on my quad core machine I see huge delays as intellisense is populated or any number of other operations. Perhaps it is a result of a mere 7200RPM hard drive? I don’t know. perhaps I need more then my current 8GB of RAM? who knows. I think, that using a 10 year old program and expecting and recieving quick responses from it have perhaps jaded me in terms of what the extra features of the new IDE actually cost in terms of performance; the delays feel like minutes, but in general it is only a few seconds. On the other hand- a few seconds is a lot longer then necessary to make one lose their train of thought. At the same time, this same argument was used against the initial usage of Intellisense; and there is no denying that although the initial display of a number of said intellisense lists can take some time, subsequent usage is nearly instantaneous, and the lists provide far more in terms of function information then the VB6 OR C++ 6 IDE could provide; this, in addition to the ease of use of assemblies between multiple .NET languages is not something that should be passed up because of an ego-centric desire to prevent change. The IT industry changes constantly. The fact that VB6 is now a “past item” should not dissuade us from moving forward because of a snobbish desire or fictitious affection for the corridor of our programming efforts for many years; the complaints about VB6 when it was introduced were very vocal. This is, no different with VB.NET, however the very complaints made about VB6 that have been remedied with .NET are now being passed off as inconsequential (since in many cases programmers have devised ways of working around limitations or even forcing behaviour that VB6 was not designed for, such as, for example the creation of Command-line programs.
The mistake Microsoft made was not the creation of .NET, but rather the belief that any sane person would move to a new platform if it was superior. They forgot the take account of the psychological factors involved.