VB6 - far from dead!
-
Oh I don't know about that. I wish I had my old Mach1 back, and I would most certainly still race it.(probably a good reason for me NOT to have it back, truth be told) EDIT: because I apparently cant spell today.
Let's face it, after Monday and Tuesday, even the calendar says WTF! Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow. You can't scare me, I have children.
Did you mean the "Mach 1"?
Just along for the ride. "the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011) -
Did you mean the "Mach 1"?
Just along for the ride. "the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011)!@#$#@!$ I'm going back to bed. I knew that didn't look right and typed it anyway.
Let's face it, after Monday and Tuesday, even the calendar says WTF! Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow. You can't scare me, I have children.
-
At least on CP: http://www.codeproject.com/script/Answers/List.aspx?tab=active&tags=75[^] Why are people still using this? I mean why not VB.NET? [I don't believe that people using VB6 would use the native code vs managed code argument]
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
This does not answer your exact question, but I do think it's important to remember that VBA and Office automation are both tightly coupled with some aspects of the "Classic VB" architecture. I think that this will probably continue to be true for some time. VBA is very much a member of the "Classic VB" language family, and until Microsoft offers something similar that's built on more modern underpinnings, people will continue to do VBA development, especially with Microsoft Access. More generally, Office automation is based on COM and in particular on ActiveX. I am a bit surprised this is still the case. When I first started using .NET, I expected the "PIA" wrappers used to do Office automation would get replaced with .NET-based equivalents within a reasonable time frame. This has not happened, and as a result the .NET languages do not offer a really compelling advantage for doing Office automation. If anything, VB6 (which was largely just a clever tool for commanding ActiveX components) probably still provides a better developer experience for this sort of work. Certainly this is the case if one is already familiar with VB6.
-
This does not answer your exact question, but I do think it's important to remember that VBA and Office automation are both tightly coupled with some aspects of the "Classic VB" architecture. I think that this will probably continue to be true for some time. VBA is very much a member of the "Classic VB" language family, and until Microsoft offers something similar that's built on more modern underpinnings, people will continue to do VBA development, especially with Microsoft Access. More generally, Office automation is based on COM and in particular on ActiveX. I am a bit surprised this is still the case. When I first started using .NET, I expected the "PIA" wrappers used to do Office automation would get replaced with .NET-based equivalents within a reasonable time frame. This has not happened, and as a result the .NET languages do not offer a really compelling advantage for doing Office automation. If anything, VB6 (which was largely just a clever tool for commanding ActiveX components) probably still provides a better developer experience for this sort of work. Certainly this is the case if one is already familiar with VB6.
_beauw_ wrote:
If anything, VB6 (which was largely just a clever tool for commanding ActiveX components) probably still provides a better developer experience for this sort of work. Certainly this is the case if one is already familiar with VB6.
Totally agree. VB6 was (still is) the greatest COM client ever invented.
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
-
In defence of some software houses the cost of upgrading from VB6 has been too high. Where I worked previously, their was a multiyear project to move everything from VB6 to C#, but it couldn't be done in one hit. The plan when I left was that it would take another 2-3 years.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
_beauw_ wrote:
If anything, VB6 (which was largely just a clever tool for commanding ActiveX components) probably still provides a better developer experience for this sort of work. Certainly this is the case if one is already familiar with VB6.
Totally agree. VB6 was (still is) the greatest COM client ever invented.
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
Nishant Sivakumar wrote:
Totally agree. VB6 was (still is) the greatest COM client ever invented.
Exactly... and Microsoft shows no signs of being able to do away with COM. Everything they try to do to replace COM seems to end up wrapping COM instead (and that's not so much an indictment of Microsoft as it is a simple fact of nature).
-
But upgrading VB6 (that isn't a horrible mess of spaghetti and implicit declarations that needs rebuilding anyway) to VB.net is nowhere near such a big hit, as most of the code will work with no or minor alterations.
It was decided to re-implement everything as it is mostly 5+ years old with so many modifications it would be like trying to rewire Hampton Court one plug at a time.
Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
-
At least on CP: http://www.codeproject.com/script/Answers/List.aspx?tab=active&tags=75[^] Why are people still using this? I mean why not VB.NET? [I don't believe that people using VB6 would use the native code vs managed code argument]
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
If it's not broke, don't fix it.
-
Nishant Sivakumar wrote:
Totally agree. VB6 was (still is) the greatest COM client ever invented.
Exactly... and Microsoft shows no signs of being able to do away with COM. Everything they try to do to replace COM seems to end up wrapping COM instead (and that's not so much an indictment of Microsoft as it is a simple fact of nature).
-
If it's not broke, don't fix it.
-
Rama Krishna Vavilala wrote:
Why not?
VB6 has not culturally been a toolset/language used by people with performance requirements.
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
-
At least on CP: http://www.codeproject.com/script/Answers/List.aspx?tab=active&tags=75[^] Why are people still using this? I mean why not VB.NET? [I don't believe that people using VB6 would use the native code vs managed code argument]
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
Nishant Sivakumar wrote:
Why are people still using this? I mean why not VB.NET?
- They're accustomed to VB6
- It requires less resources (think old machines)
- They're heavily invested in VB6 and can't afford to update the sourcecode to a new framework
..and some people still believe that you can only use VB6 to extend a VB6 application. One can seamlessly put some .NET in there using the Interop Forms Toolkit[^] :)
Bastard Programmer from Hell :suss:
-
I can think of several reasons. As others have mentioned, there is legacy code. Second, not every shop has the money to switch to VB.net, even if they have the interest: if they are already maintaining a significant codebase in VB6, and already have the expertise and compiler software, and everything is working just fine, why go to the effort and cost of changing? In my experience, the computer industry is pretty conservative when it comes to changes. When I started at my current company in 1996, I was hired because I was the only applicant who admitted to knowing COBOL: they needed my skills because our enterprise database -- which had been in place and largely unchanged since the early 1980s -- was a non-relational database on a Rand-McNally minicomputer with a JCL-like form generator for the user interface that used hundreds of COBOL applets to manipulate data. The one and only reason we got rid of it in 1999 was federal mandate to "address the Y2K problem" in the financial industry. Thirteen years later, we are still using the VB6 (originally VB4) application that replaced it, although we have plans to upgrade to a VB.Net version in a few months that will no doubt continue in use for at least another decade.
Excellent answer. Probably pretty close to correct also.
-
harold aptroot wrote:
VB6 not broke?
Not VB in so much as those who abuse the um... "forgiving" nature of VB6 when it comes to stuff like loose variable declaration, hell you don't even need to declare a variable to use one. :) The beauty of VB6 was that they made it simple enough that a child could use it to program. Unfortunately most of the users program like children. :~
It was broke, so I fixed it.
-
You read right! WinRT is new COM (COM with extra interfaces).
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
-
If it's not broke, don't fix it.
I agree completely; one of the reasons that we are paying for an OS is the fact that it's backward compatible. I can rely on Windows to run the first edition of Railroad Tycoon. If it was possible 30 years ago to run it, then it should be possible to run it now.
Bastard Programmer from Hell :suss:
-
it works for what it is. The thing is, an IT department may develop hundreds of line of business tools that just work. Here or there an adjustment may need to be made to the application to keep it compatible with other systems in the company that change. However, depending on the circumstances, it could be much less effort and expense to make minor modifications to an application that works than to rewrite from scratch. Then just move new application development to VB.Net or whatever language IT decides on as tools evolve.
-
At least on CP: http://www.codeproject.com/script/Answers/List.aspx?tab=active&tags=75[^] Why are people still using this? I mean why not VB.NET? [I don't believe that people using VB6 would use the native code vs managed code argument]
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
(twitch) (grabs a gun and proceeds to put vb6 out of everyone's else's misery)problem solved, For now.
///////////////// -Negative, I am a meat popsicle.
-
At least on CP: http://www.codeproject.com/script/Answers/List.aspx?tab=active&tags=75[^] Why are people still using this? I mean why not VB.NET? [I don't believe that people using VB6 would use the native code vs managed code argument]
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
Time, money, and existing investment are the three basic reasons I make a living supporting VB6 still. Mission critical software for production lines and PLC communication were already in place from nearly a decade ago. Over the years, modifications were needed, but the deadlines set made it unrealistic to consider replacing those programs with anything different. In addition, no one here wants to pay for another person to handle the non-VB6 workload so I can have time to convert these programs one by one either (and there are scores of them!). I did try to work through a couple of conversions to VB .net, but my deadlines always got too tight with far too little progress. I'm convinced that some of the things these programs are doing are not going to be easy to replicate in VB .net... So, here I sit maintaining them. I don't mind. After all, VB6 is the new COBOL, right? So...that makes me even more valuable! ;) ----- (FYI, I will code VB6 for food. If you have any projects you need help with, avoid the embarrassment and just hit me up via the contact form on my blog: http://www.lukegerhardt.com/ .)
-
At least on CP: http://www.codeproject.com/script/Answers/List.aspx?tab=active&tags=75[^] Why are people still using this? I mean why not VB.NET? [I don't believe that people using VB6 would use the native code vs managed code argument]
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
There is a lot of legacy VB6 code that is expensive to convert. Since many VB6 programmers did not make the shift to object-oriented (OO) programming with VB4, a lot of that remaining legacy code is written using procedural programming techniques rather than OO techniques. VB6 code that was written using OO techniques is easily portable to VB.NET, so I propose that most of the remaining code is written procedurally, and thus expensive to convert. Contrary to the FUD posters, VB6 programs, both UI and middleware, when written by a proficient professional developer, are fast, efficient, and able to go from design to market much faster than other languages such as C++ and Java. The early vesions of .NET were slower, took more time to code, so a lot of developers and IT managers were slow to choose what was (but not now) VB6's slower sibling. I believe as XP installations are upgraded to or replaced by Windows 7 or Windows 8, VB6 programs will have to be converted or lose market share. VB6 is simply not capable of taking advantage of the newer OSs, and cannot be used (as VB.NET can) to make mobile apps to match the desktop apps, or support HTML5 with its WebClasses. Add to that we still don't know if VB6 apps will run well on Windows 8, and that VB6 only supports 32 bit, not 64 bit. By the way, why would VB6 developers not use the native code argument? VB6 compiles to native code, and native code is usually faster than managed code. Disclaimer - I program new code in C#, and maintain somne VB6 code, at work and program in VB.NET for my own projects. I don't spend much time in VB6 any more, but developed a lot in VB from version 1 through 6 back in he day.