VB6 - far from dead!
-
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.
-
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.
Interesting points.
MSBassSinger wrote:
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.
Yes but a general assumption is that most VB6 devs do not keep performance as a high priority (there will always be exceptions of course).
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:
You got that right. Back in 2007, a "C# expert" told us that it was impossible to write an OCX in C#. (Note: our company, against my advice, fell prey to the myth that VB6 code has to be replaced with C# rather than VB.NET). So, I took the Interop Forms Toolkit you mentioned, figured out what I have to manually code in C# that is done for you in VB.NET, and oila! I had a C# DLL that had the COM wrapper for being used as an OCX in VB6. Since then, other developers in the company took what I did as a template, and started making their own OCXs. In almost 5 years, the template I originally wrote has changed little.
-
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
I'm in the process of migrating an old VB6, former VB3 application to .net. It's been around for ages and the only reason this migration is occuring is because of the need for the company to migrate to W7 and VB6 IDE does not get along with W7. It's about time I'd say, but then I can understand that the costs and risks to migrate such an application that evolves indefinitely can be high.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
Interesting points.
MSBassSinger wrote:
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.
Yes but a general assumption is that most VB6 devs do not keep performance as a high priority (there will always be exceptions of course).
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
I agree that is the perception. That perception is why companies waste millions converting from VB6 to C# rather than VB6 to VB.NET. But professionals are supposed to be able to see through the mythology and make decisions on the facts. That includes differentiating between professional, OO programmers who know how to program OO in VB6 and the less-than-professional procedural VB6 programmers. When I hear a programmer or IT manager tell me VB6 is something less than a powerful, versatile, fast, and efficient programming language, I know they are making a religious decision, not an engineering decision.
-
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.
You said it all... Currently I'm migrating a VB6 app because of the Windows 7 migration process within the company
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
I'm in the process of migrating an old VB6, former VB3 application to .net. It's been around for ages and the only reason this migration is occuring is because of the need for the company to migrate to W7 and VB6 IDE does not get along with W7. It's about time I'd say, but then I can understand that the costs and risks to migrate such an application that evolves indefinitely can be high.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
FWIW, we run the VB6 IDE just fine on Windows 7 32 bit and 64 bit. The only caveat is that MS broke compatibility with ADO#2.8 in Windows 7 SP1, but we can work around that. Our hybrid VB6/C# applications run just fine on Windows 7 (32 bit and 64 bit). Whether that will be true with Windows 8 is uncertain.
-
I agree that is the perception. That perception is why companies waste millions converting from VB6 to C# rather than VB6 to VB.NET. But professionals are supposed to be able to see through the mythology and make decisions on the facts. That includes differentiating between professional, OO programmers who know how to program OO in VB6 and the less-than-professional procedural VB6 programmers. When I hear a programmer or IT manager tell me VB6 is something less than a powerful, versatile, fast, and efficient programming language, I know they are making a religious decision, not an engineering decision.
MSBassSinger wrote:
waste millions converting from VB6 to C# rather than VB6 to VB.NET.
1 - Converting from VB6 to VB.NET or C# is basically the same thing. The only similarity between VB6 and VB.Net is the syntax, everything else is completely different. 2 - Trying to convert VB6 to VB.Net carries the risk of inheriting procedural practices and more. The lack of VB6's OO features, only increases thoses risks. 3 - C# has bigger community base and it might be easier to aquire skilled employees. The resources are also more widespread (as an example, search in CP for C# and VB.Net articles) 4 - It just might be a move towards standardization withing the company.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
FWIW, we run the VB6 IDE just fine on Windows 7 32 bit and 64 bit. The only caveat is that MS broke compatibility with ADO#2.8 in Windows 7 SP1, but we can work around that. Our hybrid VB6/C# applications run just fine on Windows 7 (32 bit and 64 bit). Whether that will be true with Windows 8 is uncertain.
MSBassSinger wrote:
FWIW, we run the VB6 IDE just fine on Windows 7 32 bit and 64 bit.
I haven't really tried that, but the owner of the VB6 project said he declined the move to Windows 7 so far because he couldn't get the IDE to run on it. Not sure why...
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
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 didn't know that was possible. I've used VB6 libraries in .Net apps, but never the other way around. It would have made a few projects easier in the short run, but, oh well: water under a burned bridge.
-
MSBassSinger wrote:
waste millions converting from VB6 to C# rather than VB6 to VB.NET.
1 - Converting from VB6 to VB.NET or C# is basically the same thing. The only similarity between VB6 and VB.Net is the syntax, everything else is completely different. 2 - Trying to convert VB6 to VB.Net carries the risk of inheriting procedural practices and more. The lack of VB6's OO features, only increases thoses risks. 3 - C# has bigger community base and it might be easier to aquire skilled employees. The resources are also more widespread (as an example, search in CP for C# and VB.Net articles) 4 - It just might be a move towards standardization withing the company.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
1. No it is not the same thing. A properly written VB6 program can be opened in VS2005/2008/2010 and converted by the IDE, with few manual changes, if any. 2. Converting VB6 programs with procedural code has the same risk whether going to C# or VB.NET. It makes more sense to fix the VB6 code first. 3. C# does have a bigger community, but every C# developer I've worked with not only switches to VB.NET easily (since most of the knowledge requirement is the .NET framework), but when they discover VB.NET's advantages to the developer, like it. Any good .NET developer should know both C# and VB.NET 4. It is a small company, so I can say with authority that it has nothing to do with standardization. C# is no more "standardized" than VB.NET. Both languages are supported in Mono, BTW. The decision to go C# instead of VB.NET is 100% religious. The langauge, whether C# or VB.NET is just syntactic sugar.
-
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
I can't speak for everyone else, but my company has millions of lines of VB6 code and it takes time to convert over to .NET. Had MS made a decent conversion utility from VB6 to VB.NET we would have moved years ago. As it is, we are maintaining the old VB6 code, and writing new apps in .NET.
-
1. No it is not the same thing. A properly written VB6 program can be opened in VS2005/2008/2010 and converted by the IDE, with few manual changes, if any. 2. Converting VB6 programs with procedural code has the same risk whether going to C# or VB.NET. It makes more sense to fix the VB6 code first. 3. C# does have a bigger community, but every C# developer I've worked with not only switches to VB.NET easily (since most of the knowledge requirement is the .NET framework), but when they discover VB.NET's advantages to the developer, like it. Any good .NET developer should know both C# and VB.NET 4. It is a small company, so I can say with authority that it has nothing to do with standardization. C# is no more "standardized" than VB.NET. Both languages are supported in Mono, BTW. The decision to go C# instead of VB.NET is 100% religious. The langauge, whether C# or VB.NET is just syntactic sugar.
MSBassSinger wrote:
The langauge, whether C# or VB.NET is just syntactic sugar.
Yes, but there is also language culture to consider. People coming from a C/C++ background will prefer C# to VB (syntactic similarity and similar programming approaches).
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
-
MSBassSinger wrote:
FWIW, we run the VB6 IDE just fine on Windows 7 32 bit and 64 bit.
I haven't really tried that, but the owner of the VB6 project said he declined the move to Windows 7 so far because he couldn't get the IDE to run on it. Not sure why...
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
The IDE definitely *runs* on Windows 7. As was mentioned before, MS broke ADO (with some workarounds available). In addition, any statement using DateDiff shows a phantom syntax error when I run via the IDE in Windows 7, and the Package Wizard hangs endlessly. So, I do the bulk of my compiling and testing in XP Mode[^] on my system. So, even though the IDE *runs* on 7, I don't really recommend it for those reasons.
-
MSBassSinger wrote:
The langauge, whether C# or VB.NET is just syntactic sugar.
Yes, but there is also language culture to consider. People coming from a C/C++ background will prefer C# to VB (syntactic similarity and similar programming approaches).
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
Exactly. That is the reason we have C# (for Java and C++ developers) and VB.NET (for VB developers), as well as the myriad 3rd party language add-ins for Visual Studio to support existing languages. Microsoft was aiming for havign one development environment for all major languages. In a shop where legacy code is VB6, the existing programmers will mostly be VB programmers, so the logical and efficient path is VB6 to VB.NET, not VB6 to C#. I've seen firsthand the difficulty that occurs when trying to take VB6 programmers backwards to a curly-bracket and semicolon language (C#). And it is even worse when C/C++ programmers try to migrate to .NET. Everyone loves to see a dancing bear, but it is just ugly to watch the bear being trained. :) When I hire a developer for .NET, I really am not interested in C/C++ programmers unless they have experience in .NET and can demonstrate they know the difference in development strategy between C/C++ and .NET.
-
The IDE definitely *runs* on Windows 7. As was mentioned before, MS broke ADO (with some workarounds available). In addition, any statement using DateDiff shows a phantom syntax error when I run via the IDE in Windows 7, and the Package Wizard hangs endlessly. So, I do the bulk of my compiling and testing in XP Mode[^] on my system. So, even though the IDE *runs* on 7, I don't really recommend it for those reasons.
We use it without a problem on Windows 7 every day. We don't use the package wizard, and have not had a problem when coding "DateDiff".
-
We use it without a problem on Windows 7 every day. We don't use the package wizard, and have not had a problem when coding "DateDiff".
-
I can't speak for everyone else, but my company has millions of lines of VB6 code and it takes time to convert over to .NET. Had MS made a decent conversion utility from VB6 to VB.NET we would have moved years ago. As it is, we are maintaining the old VB6 code, and writing new apps in .NET.
The only VB6 apps I have ever had a problem converting are the ones that use procedural programming techniques. For example, do you use BAS files in your VB6 programs? BAS files are a dead giveaway that there is procedural code.
-
Exactly. That is the reason we have C# (for Java and C++ developers) and VB.NET (for VB developers), as well as the myriad 3rd party language add-ins for Visual Studio to support existing languages. Microsoft was aiming for havign one development environment for all major languages. In a shop where legacy code is VB6, the existing programmers will mostly be VB programmers, so the logical and efficient path is VB6 to VB.NET, not VB6 to C#. I've seen firsthand the difficulty that occurs when trying to take VB6 programmers backwards to a curly-bracket and semicolon language (C#). And it is even worse when C/C++ programmers try to migrate to .NET. Everyone loves to see a dancing bear, but it is just ugly to watch the bear being trained. :) When I hire a developer for .NET, I really am not interested in C/C++ programmers unless they have experience in .NET and can demonstrate they know the difference in development strategy between C/C++ and .NET.
MSBassSinger wrote:
When I hire a developer for .NET, I really am not interested in C/C++ programmers unless they have experience in .NET and can demonstrate they know the difference in development strategy between C/C++ and .NET.
Good point. Personally my experience has been that .NET devs (whether VB or C#) with prior C++ experience typically seem to have a more in-depth understanding of how .NET works compared to people who started with .NET. I wouldn't say this holds true for all .NET devs out there but it has been what I've observed.
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics