A group of VB MVPs recently signed a petition regarding the future of VB6 . I thought I’d take a minute and address some of their issues. I myself am a VB MVP, and have chosen not to sign at this time because I disagree with the recommendations listed in the petition, but not the objectives.
First, consider the objectives of the petition:
- Preservation of assets
- Continued support for the Visual Basic language
- Ease of migration of unmanaged VB/VBA code to VB.NET
If you have a business that has invested years of development effort in VB6 and VBA code, should you port that code to .NET? We�re talking existing working code here – not new projects. By any sane economic rational, the answer is no. In most cases porting is stupid and a complete waste of money.
The rational way to migrate to .NET is incrementally – using it for new development and porting selected components that can truly benefit from the .NET framework, relying on interop to allow existing code to work with .NET code.
The problem, if not tragedy, is that many developers are porting code to .NET purely out of fear – fear that they will no longer be able to receive support for VB6, fear that existing VB6 projects may not run on future operating systems, fear that they will not be able to obtain VB6 licenses.
Microsoft, perhaps in its desire to promote .NET, has not done enough to assuage these fears. Either they value .NET migration more than the best interests of their customers (which would be shameful), or they are just not able to get the message across. Porting is stupid (for proof – ask what percentage of the MS Office code base has been ported to .NET).
The classicVB petition recommends integrating some future VB6 into the Visual Studio IDE. I think this approach would be mistaken and a waste of resources.
I would like to offer the following recommendations as an alternative:
- A longer term commitment to providing support for VB6 and VBA
- Guaranteed support for VB6/VBA under future OS’s for an extended period (definitely including LongHorn and at least one more beyond).
- A commitment that once a decision is made to stop support on VB6/VBA, that the entire VB6/VBA code base will be placed into the public domain as an open source project, or perhaps a foundation similar to Mozilla, to assure that interested parties can continue to support and perhaps fork the project in the future.
I believe these alternatives would provide sufficient peace of mind for most VB6 developers to base their migration plans on sound economic factors relating to their individual situation – and not on fear, uncertainty and doubt.
Links:
Petition
Scobleizer (who blogged the petition under the “revolt” moniker, even though it isn’t)
It’s satisfying to see just how widespread the desire is amongst Microsoft customers for them to not cut off all support of Classic VB! (For those unaware, VB6 support ends on March 31!)
The basis for the recommendation that Classic VB be added to the list of languages supported under the Visual Studio IDE was simple — keep the support lifeline within grasp. I’d like to believe Microsoft were it to say they’ll meet the committments you ask for, but frankly there is little reason left for me to feel they’d be entirely honest in that regard. They did, afterall, tell us they “get it!” after some of the bonehead moves (like redefining the String datatype) made in the transition from Win16 to Win32. Five years later, it was clear that institutional memory had lapsed.
And don’t overlook that were Microsoft to have brought Classic VB to the .NET platform, the acceptance rate would have been greatly enhanced. They still stand to benefit by wrapping Classic VB into the IDE, as it would be the encouragement needed by many to start tinkering with VB.NET, while they’re maintaining their bread and butter Classic VB apps. A real stepping stone into the future.
Anyway, the fight for ongoing support is one we’re all in! The precedent set this last time around is not good for any customer of Microsoft’s! Thanks…
I really do feel that inclusion of vbClassic in the current vs ide would be a gigantic waste of time for all parties involved. For microsoft, it would be the expense of writing an upgrade, attempting to make it play nice in the .NET world (via vs.net), etc… for a product that may not sell all that well. In addition, developers would be demanding all the features of vb.net anyway (parametrized constructors, threading, variable assignment at declaration), which may or may not be easy to implement.
For developers… the petition signers are worried about maintaining existing vb6 code. What is stopping you from maintaining the code in vb6 now? Why do you need vb6Classic to be in the new IDE? I have a bunch of vb6 code and I can maintain it regardless of what microsoft does.
The petition just feels like people can’t let go. I felt that way when vb-dos was no longer developed after a fantastic v1.0 release. It also provided no easy way to port the code to vb2/3. And the vbdos to vb2 converter was about as good as the current vb6 to vb.net converter. Anyway, time to let go.
Finally, if the goal you are after is continued support, than that’s what you should say. Instead, the petition sugarcoats this goal with unrelated objectives.
Dan, consider your own words… “I disagree with the recommendations listed in the petition, but not the objectives.”.
The petition is meant to urge Microsoft to take action, more than has taken place thus far, with regards the staggering amount of VB6 code where it isn’t feasable to just rewrite it again.
There is a number of paths Microsoft can follow that will make things better than they are now. You offered your own suggestions and I’m sure there are yet many additional ways to improve the current situation.
If you support the objective, then add your support. We all know Microsoft is free to make up their own minds about how best to deal with this situation.
Dan, you say that “The rational way to migrate to .NET is incrementally â using it for new development and porting selected components that can truly benefit from the .NET framework, relying on interop to allow existing code to work with .NET code.”, which is something I absolutely agree with, and I’m sure Microsoft know that too. The question is how can that best be achieved? The suggestion in the petition envisages a single IDE that allows both VB.COM and VB.NET classes and modules to appear to be in the same ‘solution’, calling between each other at a procedure (rather than component) level. The fact that the solution would actually compile to an unmanaged dll/exe and a managed assembly linked by interop would be abstracted away from the developer, allowing them to concentrate on their incremental adoption of whichever bits of the .NET framework made most sense. And don’t forget that component-level interop isn’t an option for all the VBA code out there, simply because we don’t have the ability to create components from our VBA code.
I have responsible for maining a large CAD/CAM software written almost entirely in Visual Basic 6. (www.plasma-automation.com) The existing conversions are extermely limited are useless except for the most basic of software. This has been my experience based on trying the .NET conversion on our main software and on various utilities we use along our software which are simplier in setup.
At first when VB.NET I thought I saw the point. You have this .NET framework and the changes seemed logical in that context. And for starting new projects the new VB.NET is very nice indeed.
But in the years since .net has been release I steadily got more upset for the following reasons
1) There are too many what I call “stupid fred” changes. Stupid fred makes changes even when the requirements of the .NET framework are not relevent. For example the change from integer to short, type to structure, the inability for .NET to use global multiuse COM libraries properly, the loss of the traditional basic graphics, and others. For each change that Stupid Fred made I was forced to write my own work around code to work around the change. After doing this several dozen times I found that more most of Fred’s changes I was able a construct VB.NET equivalent that came close to what VB Classic was doing.
These changes are so many that to go from VB Classic to VB.NET is as different as going from Java to C#.
2) A variety of compliers have been written for different langauges to produce IL code and to use .NET Framework. There more than a half-dozen books and project that show you how to write your own compilier to produce. In short .NET and the runtime don’t really restrict what you can produce for a langauge especially for traditional language types like VB Class, C++, Java, etc
3) C++ doesn’t have to deal with this. They have the option of ignoring IL, intermixing it, or using it exclusively.
Given all that is I have question why couldn’t Microsoft written a VB classic complier that produces IL. We know .NET can deal with COM libraries, and Active X controls I see no technical excuse for this complier to exist. Given that there are millions of us VB6 programmer I see it as it very short sighted economically.
Rob Conley
Thanks for commenting on this issue, and sharing your considerable insight. I believe, and have long stated, that short of Microsoft re-embracing classic VB, the best hope for the language would be to make it an open source project. But Microsoft will never allow that. As far as the cost and complexity of integrating classic VB into .NET, that’s a red herring. How much cash is Microsoft sitting on? How many developers are on staff? How smart is Bill Gates & Co.? I’m certain they have the talent and skills on tap to get the job done in record time. It’s a matter of caring, not cash. If Borland or Sun introduced a classic VB compatible product, how fast do you think Microsoft would bring back classic VB? Interestingly, somehow also-ran Visual FoxPro has managed to remain relevant, right into the .NET era. Lasstly, imagine if the Office group decided to change their data file formats, and make them only partially compatible with documents created in earlier versions, all in the name of progress. This issue is no different to an ISV with a substantial investment in classic VB source code, or an enterprise shop with line-of-business apps built in classic VB. The argument that new development can be done in .NET simply doesn’t fly here. At some point the entire enchilada has to be ripped and replaced. In the early days of the popular Internet, Microsoft product managers used that same argument against the development of thin client apps, claiming Netscape required IT shops to rip and replace their code base, and promising the Microsoft provided the logical, smooth, painless migration path to the future. Ironic, ain’t it?
The argument that there is nothing stopping VB6 developers from maintaining their work in VB6 is questionable for a number of reasons.
First of all, can anyone with a long standing investment in VB6 really safely assume that the VB6 libraries will be ported to new CPU architectures and new versions of Windows? Can we safely assume vendors of ActiveX libraries will port their work as well? No we cannot.
Second, we’re already seeing a drop off in what VB can do in terms of OS support. Try implementing the new XP look and feel in a VB6 app for example.
We currently live in a life of uncertainty. Personally, after this show of commitment by Microsoft, We here at Captovation have moved on… to Java (for new products) where the compatibility story is a whole lot better. I recommend others do the same.
Hi Dan …
I think it is paramount to remember that Visual Basic developers supported you throughout your career through book purchases, links, quotes and recommendations. Now it’s time to return the favour by supporting those same developers. I’m disappointed in your reaction.
I also feel that termination of MS support is not a disaster. It was mainly required after MS stuffs things with new releases. Luckily, there are no more new releases (‘It’s an ill wind that blows nobody, no good”).
However, a commitment that future versions of windows can handle VB6, is essential.
If we all united and requested that, we will be doing all our clients, and ex clients, a tremendous favor.
Forget the goofy petition– what these guys are really complaining about is the diminishing role of VB in the pantheon of development languages. There’s a lot of data supporting their assertion:
http://www.codinghorror.com/blog/archives/000235.html
I think this was a case of “damned if you do, damned if you don’t” for Microsoft. The concept of VB.COM actually makes sense, but the framework was in development long enough without adding an additional VB.COM requirement.
Anyway, it’s fairly clear that VB, as a language, is in decline; it will never be as important or influential as it once was (due to continuing loss of developer mindshare), and that’s a little sad.
Support does not end on March 31st for Visual Basic 6.0. See here. What ends on March 31st is the end of Mainstream support. Visual Basic support continues for another 3 years beyond that. To say that support ends on March 31st is not true.
Yes, on April 1st you have to pay to speak with someone just as you do today after you have used up your 2 free incidents. On April 1st that same support profession is still answering the phone and your question as on March 31st.
Support is not ending, Mainstream support is ending. There is a large differance. Support is end leads one to believe that that phone is just going to keep ringing on April 1st, which is not the case. Support is ending in 2009, after which time if you still need support custom support contracts are an option for you.
OK, somebody needs to state one of the dirty “little” secrets behind the complaints. I’ve worked at so many places that have lost their VB6 source files… Prop up VB6 if you will, but all that sloppy stuff out there will die an ugly death someday. It’s a bummer to tell the boss you can’t upgrade because the program is missing. Lots easier to blame on Microsoft.
Rob Abbe said: “First of all, can anyone with a long standing investment in VB6 really safely assume that the VB6 libraries will be ported to new CPU architectures and new versions of Windows?”
Dude. 16 Bit DOS apps still run today on Windows XP. So do all previous versions of VB applications. Nobody ported the libraries. 32 bit windows supported the 16 bit world. 64 bit windows will support the 32 bit world. Beyond that, just how long do you think that VB6 is going to last? I’m personally glad you are moving to Java. You’re embarassing the rest of us.
Unlike most of the developers who expressed their comments on this post, I do believe that a common mistake is to take for granted that the .NET Framework will succeed to the throne of operating systems, currently held by Win32.
When the COM technology is abandoned by Microsoft, people will have the possibility of thinking about which operating system they should choose. Nowadays, Windows is the only logical choice.
As a VB6 programmer, what I am afraid of is not whether MS will continue to provide its support (there are so many forums dedicated to VB6 that I couldn’t care less), but whether my present knowledge will be completely useless when the Win32 API disappears.
Can we be sure MS will not be so stupid as to deny compatibility with Win32 executables in the next versions of its operating system?
If Bill Gates decides to start a new era abandoning the COM technology, many people could opt for Linux as an alternative to something completely new that has not yet been sufficiently tested. That’s when Microsoft could lose its monopoly on operating systems.
VB6 is certainly the most widespread programming language in the world but, after the advent of VB.NET, a lot of frustrated VB6 developers have decided to move to alternative languages such as Flash MX 2004 (which also allows you to manage databases), PowerBasic and so on.
A petition I would very much like to move is one encouraging Microsoft to sell the copyrights for VB6 to other software houses, allowing them to release new (COM based) versions of the product.
Similarly, if MS decides to abandon the COM technology, it should either sell the rights for Win32 to another software house or release the entire Win32 code base as public domain.
Dan, I agree with much of what you write, but my take on this is purely from a business perspective. Iâm not married to VB6. If it were magically ported to VB.Net, there would be no problem. My guys are smart and would hardly miss a beat. It is unconscionable that Microsoft created a new version of the product without a reasonable strategy for migration. I have worked on many platforms and with many languages and Iâve never seen anything like this. Iâve seen massive changes in compilers from IBM on the mainframe, but the old code either worked or there was an automated migration. I have the better part of a million lines of VB6 code. How much will it cost me to port that? Is this the price of trusting Microsoft with my investment? For me, there is only one solution thatâs reasonable. Microsoft needs to create a real migration that provides a near 100% port of working vb6 code. That is what every other enterprise vendor would do. To those that say it canât be done, I only have to smile. In the 80âs, we had programs to port 370 assembler into COBOL and it did a pretty darn good job. The differences between VB6 and .Net are far less significant. It will be expensive for Microsoft, but our cumulative cost is far greater. How much could it be⦠50 million, a billion? The ISVâs that are leaving VB6 for a non-Microsoft alternative are gone forever â and with them go the consumers of their solutions. I sell against anti-Microsoft bigotry (from our UNIX pals) all the time. Nothing would be easier than to give up and move to a platform and technology more commonly accepted as being âenterpriseâ ready. At this point the one thing that has kept me from the jump is disbelief with the current state of affairs. I canât believe this is an acceptable strategy for a software company their size. My companyâs software has undergone extremely large changes over the years as we enhance the offering. We wouldnât think creating a release that would not migrate existing information. If Microsoft is too strapped for cash ï maybe they should take up a collection.
I decided recently to transfer my skills from VB6. to VB.NET, but now I am having second thoughts. VB.NET is not Visual Basic, by any stretch on the imagination. It is indeed a very powerful language, but the amount of time I need to reskill is unreasonable. Why do I have to change to VB.NET? What was wrong with VB6.0? If there is a problem with VB6.0 why didn’t Microsoft ease the pain by giving Visual Studio .Net away free? I realise that I can’t stay with VB6.0, but where do I go now? Java or Delphi, RealBasic or do I bite the bullet and go with .NET (but how can I ever trust Microsoft again?)
Ok, so if VB6 can suffer through the seperation from .NET and VS.NET then why couldn’t C++?? Why did C++ get the red carpet .NET treatment for incremental migration, and VB6 got left by the roadside? Not fair, not appreciated, and many have taken notice. So for those of you who think VB.NET no longer makes you a second class citizen, think again. VB6 got the shaft.
I doubt that Microsoft will do anything to help old VB6 developers, since it did its best to screw them over in the first place with the new bastardised version known as VB.Net. Okay, sure, Microsoft spokesmen will waffle like they usually do, but in the end it will all turn out to be just that: something sweet and flaky you are fobbed off with, like Mom persuading you if you wash the car or clean the yard there’ll be Krispy Kremes for breakfast.
I envisage the day sometime in the maybe not too distant future when developers will have moved “on” to Java or some other curiously arcane language, when the 34% of developers allegedly using VB.Net have dwindled to single figures, and when there is a big box in the corner of a room somewhere on the Microsoft Campus which contains all the VB6 source code.
Every morning, Bill Gates or an approved acolyte will enter the room and sit on a carefully positioned chair for the Five Minute Gloat, then rise and leave until the next day, and the next. The message on the side of the box: “…and it shall never come to pass that VB will enter the Public Domain.”
Fuhgeddaboudit! I have. I moved, and took up gardening. Life’s too short. (Okay, so I did just download the free copy of RealBasic; old habits die hard.) But hell will freeze over before Bill Gates “donates” proper Visual Basic to the developer community, despite the fact that VB and VBA were pretty instrumental in getting Windows to be so widely accepted.
In discussing whether and when support for VB6 will end, as usual the word “support” is being used to mean two completely different things. The first meaning is technical support, i.e., “Will Microsoft continue to answer technical questions about VB6 when VB6 customers call them?”. The other meaning is compatibility, i.e., “Will future versions of Windows continue to run VB6, and run applications, dlls, etc. created with VB6?” Considering that peer support (newsgroups, VB web forums, etc.) are probably a more effective and more efficient way to get technical support for VB6 than calling Microsoft, I don’t think the first question is very important. And, considering the crusty old DOS applications, and 16-bit Windows applications, that run on XP, and considering how much easier it will be for Microsoft to get Win32 apps to run on Win64 that it was to get DOS and Win16 apps to run on Win32, and considering the gigantic installed user base of VB6 apps, I think the most likely case is that VB6 and applications created with it will continue to run on future versions of Windows for decades to come. Really the more interesting question for each VB6 developer is “When will I need programmatic access to something newer in the OS than VB6 knows about?”. Plugging VB6 into VS.NET won’t help with that question. Barring a miraculous about-face by Microsoft about classic VB, sooner or later most of us are going to find ourselves choosing something more modern.
There are two people in the industry whos advice I consider holy scrupture. Randy Birch and Dan Appleman. So when Dan suggested that the VB6 source and COM should go open source and let it be rub Mozilla style, I started to see a little white dot at the end of a very long tunnel. Could we get that lucky? I would personally support and serve on such a company if I thought it would save VB Classic. Great suggestion Dan!
I’ve been read the postings and coming across statements like “They [Microsoft] still stand to benefit by wrapping Classic VB into the IDE, as it would be the encouragement needed by many to start tinkering with VB.NET, while theyâre maintaining their bread and butter Classic VB apps. A real stepping stone into the future.” and “I decided recently to transfer my skills from VB6. to VB.NET…” Where were these people when Microsoft released VS.NET to the general public three years ago? Why does the writer of the first message quoted feel that it’s Microsoft’s responsibility to get people to “start tinkering with VB.NET”? When MS released VS.NET in 2002, I rushed out and bought myself a copy and immediately dove into working with it. Sure, the learning curve was steep, but it was worth it as I’m much more productive in the .NET environment than I could’ve ever hoped to be with the VB6 IDE; I much prefer using .NET when it comes to encryption, threading or working with XML/XSL. It’s not up to my employer to keep me up-to-date on the latest technologies, nor is it up to Microsoft to offer any more incentive to “tinker with” VB.NET other than to make it available.
It’s slightly under 5 years since I started using .NET and so I’ve been re-evaluating. For many desktop VB developers, I think the real reason they want to continue doing VB6 is because it does a better job than the .NET platform for the type of applications they create. Of course there are many amazing new features in VS 2005 – but what would VB6 look like now if it had received continued investment? If you think hard, it can be tricky to think of things that .NET has that could not have been added incrementally to VB6 (please don’t tell me that inheritance is a must-have for application developers, and take note that we now have registry-free COM). Perhaps .NET’s major innovation is its security framework, which most people ignore anyway. VB6 is only dead because it has been killed, and consequently, if you’re still using VB6, you will just have to move, sooner or later. Just remember that you are incurring the cost of re-skilling simply because Microsoft got scared by Java.
If it’s any consolation, when VS 2005 ships, all those C++ developers who learned C# will realise they didn’t need to. C++ in VS2005 scores over C# on all important measures.
Greetings Very good web site. I loved it. Found invaluable information. Just what I was looking for 🙂
My view of the world…
A. C# was invented to compete with Java.
B. VB.Net was invented to lure VB6ers.
C. Vb.Net is competing with C# (it takes money to support both).
D. VB.Net will be dropped or morphed into C#.
E. If you are going to leave VB6 (and I am not), do not go to VB.Net, go to C# or Delphi or something else.
F. Eventually Microsoft will get tired of .Net and decide to make money out of forcing the world to upgrade to its replacement.
G. When the last VB.Net programmer moves on, someone will still be programing in VB6 and there will still be more VB6 applications in circulation than VB.net.
I agree with Claude Canevese entirely. VB.NET is not at all the evolution of VB6. It has a lot of shortcomings in comparison with its “pseudo-predecessor”.
First of all, cracking a VB.NET executable is a piece of cake. If you want to protect your intellectual property, you have to make use of third-party (COM based) software. The protection level byte-coded programs can offer is more or less the same as the one offered by plain HTML pages.
Secondly, the .NET Framework you need to distribute to the final user of your applications is as problematic as the VB6 DLL hell. You must always make sure that your customer possesses the correct version of the Framework and, if he does not, you will have to oblige him to throw away dozens of megabytes just to make even the smallest of your VB.NET applications run.
No, thanks. I’ll stick to VB6. And when it becomes obsolete, I’ll switch to RealBasic.
I have several applications on VB6 (we all have).
I found all comments useful, but still don’t know what to do.
I’ll wait to see some statistics about popularity… because the more popular a programming language is, the more resources, code examples, third party products, and forums you find.
C# + SQL 2005 ?
VB.NET + SQL 2005 ?
C# + MySQL ?
VB.NET + MySQL ?
Java ?
There are millions of species… I wasn’t born that long ago, but I’m pretty sure that not even one of them was forced to evolve in a certain way.
Programming languages have to evolve… just like creatures evolved.
Every change in this evolution is for good (most of the times) when it comes to benefit the mayority.
I wouldn’t like to see Microsoft (and Bill Gates) at the Discovery Channel in 10 years through a nice ‘window’ JAVA application running a linux based OS.
(…Or maybe I would…)
Time will say… if .NET is the future or not.
Nobody knows, not even Billy G. Too sad.
Thanks,
The too-confused JAG
Dan, you are the man that teached me, being a dentist interessed in using a PC for real world work settings, how to program Windows as a dummy using VB from version 1. I bought all your books and learned a lot of them, thanks.
At last I got a product that is very stable, rock solid, easy to deploy, and graphically very pleasant.
But porting this solution for a vertical market using to .net for the 500.000 rows is a nightmare, and I understand what you mean with ‘do not port’. Porting resuls in a program taht does not do the job better, I have to leave advanced comport communications I could do in VB6 and the result is much slower. The peaces I can do teh job, do not do teh job better, buts are slower.
Help us again, we are not the high end professionals, but those ‘in between’ that try to realise real wordld applications for our profession. Microsoft is not interested in that nice markets, I am. You have to help us!!
Actually, there is a plus side to this all, if you take a longer point of view. Just as VB for Windows replaced DOS BASIC (same issues of existing code being obsoleted, and new programming skill sets being needed, etc) and just as VB.NET replaced VB6 (ditto), experience shows that we won’t have too many years of suffering with .NET before Microsoft once again pulls the plug and we all have to hop to a new flavor-of-the-day.
You know what may have been a better approach? MS could have introduced .NET side-by-side with COM, promoting it is as the wave of the future. Then, as .NET demonstrated its superiority as a platform, the users could choose to adopt it (maybe in easy steps, or not) as something easy to see as a better deal.
I mean, if .NET is really as good as it is being promoted to be, it should be self-sustaining on its own merits; let user market forces show which is the better choice as opposed to having the decision imposed from “above”.
Once upon a time there was COBOL. It’s been polished from time to time to deal with changes to the surrounding environment, to go from punch card to tape to disk drive, but it’s still COBOL. It got the Y2K treatment, but it’s still COBOL. It’s all about legacy systems.
Microsoft would do well to take heed. VB6 is the COBOL of the new millennia. It ain’t goin’ away any time soon! The testing cycles alone to go from 6 to .NET would kill a lot of companies. And as I sit here typing, I listen to Maria Callas, who also has made it to the new millennium, at least on CD.
I have been coding in VB, QuickBasic (PDS), QBasic, and Microsoft Basic OS for 25 years, and I don’t get it. For decades, Microsoft was the company that “got” upward compatibility. Back a couple of decades ago, I can remember it being a struggle to come to a profound understanding of event driven code and actually letting the operating system have control before my program terminated. However, I soon learned that I could cut-and-paste huge portions of existing code into procedures, and that they would run without modification. I eventually cleaned up this code, taking out the GOTOs and GOSUBs, but I didn’t have to! I remember when class modules and user control modules were added to VB. I now have a whole library of my own user controls, such as labels and buttons that have rich-text on them that can be pasted onto the control from WordPad. However, the important point is that I could ignore these new features until I needed the advanced functionality they offered. With VBNET, so much of my library is “broken” that it’s too much work to change. I love learning new things, but I HATE being told that I have to.
On the COM vs NET (i.e., managed vs unmanaged code) framework: personally, I couldn’t care less about this so long as I can still call DLLs, make API calls, build Access databases, and automate Microsoft Office applications. Furthermore, I can’t understand how this dichotomy drives many of the changes made in VBNET. For instance, what’s the deal with making all arrays zero bound? This breaks so much of my existing code that it’s ridiculous, and whatââ¬â¢s this have to do with COM vs NET? Sure, I can write a wrapper for each of my arrays so that they are zero bound, but why should I have to? Why doesnââ¬â¢t Microsoft add an ââ¬ÅOption ArraysAnyBoundââ¬Â statement to the language which will allow arrays dimensioned with negative subscripts, or whatever. Wouldnââ¬â¢t it be trivial to push this down into the bowels of VB so the programmer doesnââ¬â¢t have to worry with it?
Whatââ¬â¢s with changing all arguments to ByVal? Once again, why break everything? Why not have an ââ¬ÅOption ArgumentsByRefââ¬Â statement that fixes legacy code? I have gotten VERY familiar with keeping track of what is passed ByRef and what is passed ByVal. Why break so much existing code? Sure, code translators can attempt to fix this, but why do we need to bother?
The ââ¬Åshort circuit logicââ¬Â also breaks a great deal of code. Once again, I canââ¬â¢t see how this has anything to do with the COM vs NET issue. I have gotten very comfortable with using a ââ¬ÅSelect Case Trueââ¬Â statement when I am testing for several conditions and I want to jump over certain evaluations when an earlier one goes true. However, if I write ââ¬ÅIf ThisFcn() Or ThatFcn() Thenââ¬Â I expect both ThisFcn() and ThatFcn() to execute. In fact, I may depend on it. Once again, why not have an ââ¬ÅOption NoShortCircuitLogicââ¬Â statement in the language?
This one may be a little more difficult, but why do away with fixed strings? I use them frequently in structures (User Defined Types; UDTs), and I know exactly what to expect, even with the invisible ASCII to UNICODE conversion issues when writing to files? Are the hoards of programmers at Microsoft just too lazy to implement this feature?
Why change the value of ââ¬ÅTrueââ¬Â from -1 to +1? I know that other languages use 0 and 1 (or +1) as true bit operators to indicate ââ¬ÅFalseââ¬Â or ââ¬ÅTrueââ¬Â, but, since the beginning of time, a ââ¬ÅTrueââ¬Â in basic has been a two-byte integer will all the bits turned on (i.e., -1). This brings up another point. Whatââ¬â¢s the deal with changing the Logical Operators to pure Boolean Operators. Any VB6 programmer worth his (or her) salt knows that all the Logical Operators are actually bitwise operators in all cases. If you donââ¬â¢t believe me, try ââ¬ÅDebug.Print CInt(True Xor 5)ââ¬Â. Iââ¬â¢ll let you figure out the results. In VB6, when forced to make a Boolean interpretation, such as ââ¬ÅIf ââ¬Â¦Ã¢â¬Â, anything that wasnââ¬â¢t ZERO was True. This is why some novices canââ¬â¢t understand why ââ¬ÅIf 1 And 2 Then ââ¬Â¦Ã¢â¬Â evaluates to False. However, I digress. The point is, why ââ¬Åbreakââ¬Â all existing code that is based on these understandings? Once again, why not have an ââ¬ÅOption LogicalsAreBitwiseââ¬Â statement that allows legacy code to execute unaltered?
Why did Microsoft do away with statements that didnââ¬â¢t seem to do any harm. The LSET is a good example. I frequently deal with motion capture data files that have data stored in old DEC VAX floating point formats. I have routines that use LSET to convert this data to the IEEE floating point format. Sure, I can rewrite this code using the CopyMemory API call, but why am I being forced to? In fact, I have some old accounting applications that store data in the old Microsoft Binary Format (MBF) formats from the old QuickBasic days. Rather than writing data file conversion routines, I simply convert the MBF to IEEE in memory, do the math, and then convert back to MBF before I write it to disk. Why break these procedures? They have served me well for decades.
I could go on, but I will stop. To summarize, why not provide a set of ââ¬ÅOption ???ââ¬Â statements that modify VBNET to be as compatible as possible with VB6, hopefully, completely compatible, at least at the level of the core language. I will learn how to use the new features, such as multithreading, polymorphism, and overloading as I need them! I would love to upgrade but, because of my extensive library, I am stuck in VB6, and I will badmouth VBNET to younger programmers at every opportunity until the issues of ââ¬Åupward compatibilityââ¬Â are addressed in a respectful and thorough way.
Sullivan wrote, “Why did Microsoft do away with statements that didnââ¬â¢t seem to do any harm?”
Well, in Windows Vista, they have even done away with one of the most common statements used in VB6: SendKeys. All VB6 applications containing that cursed statement will just crash under MS new OS.
In theory, the solution to the problem exists (you have to replace SendKeys with an API function) but what is certainly difficult to do is provide all of your customers with an updated version of the software they bought from you.
If I think of all the VB6 applications I have sold over the last few years which make large use of the SendKeys statement… I can’t believe they now have their days numbered.
What is even more crazy is that SendKeys seems not to work even under .NET 2.0. I really hate it when Microsoft is not compatible with Microsoft!
What’s the point in neutralizing the SendKeys statement when it is equally possible to get the same results resorting to WinAPI32?
Let’s hope this bug will be fixed when the final version of Windows Vista is released, even though I doubt it.
I only used SendKeys to move the focus from a TextBox to the next one or to simulate the pressure of the F1 key in order to launch the help file. I’m afraid millions of VB6 programmers did the same.
Don’t you think it could have been much wiser to neutralize SendKeys only in the case of an interaction with an external application? What should the millions of VB6 developers tell their customers now? “Please, if you decide to upgrade to Vista, don’t ever push the Help button or press Enter to move to the next TextBox, otherwise the program will crash!”
And, besides, don’t you think it is absurd (or even unprofessional) to support SendKeys in .NET 2.0 and make it incompatible with a concomitant operating system?
If you give me teeth, you should not take them away from me the next day.
MS promised that, if a VB6 app works under XP, it will also work under Vista. Let’s wait until next January and see how reliable they are…
Elitism. And Protectionism. That’s all it is.
So there are somewhere between 3 and 6 million VB6 developers in the world. That must really stick in the craw of the handful (comparitively speaking) of so-called self-described ‘professional’ or ‘expert’ programmers.
3 to 6 million people who are “stealing” their work; 3 to 6 million who are doing work *they* should do.
So they lobbyed Microsoft to re-engineer the language so that only ‘real’ programmers could use it; to make it so complex that the majority of that 3 to 6 million wouldn’t or couldn’t understand it or use it.
I expect that, if these ‘professionals’ were electronics engineers or builders, they would have bought pressure on companies like ‘Radio Shack’ or ‘B&Q’ for allowing ‘hobbyists’ or ‘amateurs’ to get involved in soldering or DIY.
If these self-appointed experts are so clever, they should spend their time more creatively building applications like ‘VB6’ or ‘MS Access’ which allow computers to be used constructively by the masses.
Dave R of RadSolution (VB programmer of over 10 year’s standing)
Well, it looks like my prayer was heard by MS, eventually.
A few weeks after I complained to them about the SendKeys issue, I received the following answer from Chris Mayo, the VB Program Manager responsible for Visual Basic 6 on Vista:
———-
re: Vista To Support Legacy VB6 Apps
Pasquale,
I’m the VB Program Manager responsible for Visual Basic 6 on Vista. The SendKeys issues has been corrected and will be released in Vista RC1. The calls to SendKeys that work under Windows XP will work the same way under Vista.
Hope that helps.
Thanks,
Chris Mayo
Visual Basic Program Manager
Sunday, July 30, 2006 7:38 PM by cmayo
———-
You can reach the Blog page at
http://blogs.msdn.com/davbosch/arch…/26/539470.aspx
So, I have to take back what I said. This time the MS staff has revealed to be really professional.
Well here we are with the RTM version and sendkeys….. well Vista still doesn\’t allow it.
We have an application developed in 2000 using Visual Basic 6.0 and it uses number of Activex Controls and dlls.
The set for the same was created using InstallShield.
Windows XP supports this application without any problem/known issue.
However, when I try to install it on Windows Vista, I get an error viz. This application is not supported on this OS. I am really stuck at this point, as number of existing customers want to use Windows Vista.
I know that this may not be the place to raise this kind of question. But I hope all of you can understand my situation and I know that you are using Visual Basic since quite a long time.
Looking forward for your inputs!
Approximately half of all existing applications don’t run on Vista correctly. That has little if anything to do with VB6 itself. VB6 applications, like every other application, have to be retested against Vista and modified where needed.
The step towards .NET has been a step back in my opinion. Ever since the early days of programming coding has become more simplified. Moving from binary to keywords and later to components.
VB was a natural next step that allowed you to create quick and easy code. If you needed something VB didn’t offer, you could simply add a C++ function or API call in a module and get the job done that way. The point is that you shouldn’t have to type out loads of code (with the possiblity of coding errors) if you don’t have to.
The solution is not that difficult by the way. For every keyword thats “gone” you simply need to write your own function that does the same thing and use the keyword as the name of the function. Create a module that includes all these functions and add it to every project you want to port to .NET.
If you want to make VB open source, there’s your solution. You can even create similar modules for java or other programming languages if needbe.
Vote for an updated version of the VB6 programming language
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3440221-bring-back-classic-visual-basic-an-improved-versi
Microsoft’s Paul Yuknewicz has refused to update the VB6 programming language with the same changes already added to VBA, stating it is “not possible”.
Yuknewicz has also refused to open source the VB6 language, stating it is “not feasible”.
The refusals follow the rise of the call on Microsoft’s UserVoice forum (for an updated VB6) to fifth place out of over 8,500.
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/3440221-bring-back-classic-visual-basic-an-improved-versi
Microsoft now state that the VB6 programming language will be supported for the lifetime of Windows 10. That is until at least 2025.
https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx
It is interesting that Dan called for “A longer term commitment to providing support for VB6 and VBA” back in 2005. Yet the mean-minded Microsoft never did make that commitment. In fact, they did just the opposite with comments like “there are no plans to support VB6 programming in the next release of Windows”. Yet every version of Windows has supported VB6.
MS still refuse to open source VB6.
Microsoft have extended support of the VB6 programming language to include Windows Server 2016 (until at least 2027).
The Microsoft support statement is here…
https://docs.microsoft.com/en-us/dotnet/visual-basic/reference/vb6-support
There is an installer available to install the VB6 programming IDE on newer Windows releases http://nuke.vbcorner.net/
And VBA programming continues in Office 2016 (and is being extended to the MacOS versions of Office).
2019 and Microsoft still support VB6 programming.
And now support has been extended to include Windows Server 2019