VB6 - far from dead!
-
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".
-
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.
-
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".
-
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
-
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.
1 - I want to see that in practice, it doesn't make too much sense. For what I've seen, it hardly requires minimal changes. The API's are completely different, UI controls are completely different, many don't even have an equivalent on the .net platform. Native unsafe calls to the OS are not required on many cases on .net because there's a wrapper built for most of them already. This alone can inherit lots of unsafe code. And in the end if it's easy to convert VB6 to VB.Net, then it's seamless to convert VB.Net code to C# code. Same methods, same framework. 2 - Not really, I'd like to think the opposite. Trying to convert VB6 code to VB.Net will inherit the whole model that lacks the OO principles down to the basic level like inheritance. Converting to C# will force to really rewrite it and give it a chance to design a domain model that take advantages of OO design patterns and principles. Fixing the VB6 code is just like patchin a hole in the old boat. 3 -
MSBassSinger wrote:
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). Any good .NET developer should know both C# and VB.NET
Agreee
MSBassSinger wrote:
but when they discover VB.NET's advantages to the developer,
Don't agree. C# and VB.Net have their own advantages and disadvantages. Personally I prefer C# for it's more declarative and do less stuff behind the scenes and is less forgiving to bad practices. This is where it becomes more religious. 4 - I was trying to say in a general way, not your case specifically. In that sense I don't think it's a valid argument that converting to VB.Net instead of C# will save money. There are too many factors involved to make such statement.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
May I ask, what version of 7 and VB are you using? Service pack 1? (FWIW, I'm on 7 Pro 64-bit w/ SP1, and using VB6 SP6)
Windows 7 Pro 64 bit, SP1. I and my coworkers have the VB6 IDE, VS2005, and VS2010 installed. All 3 IDE executables (and their shorcuts) are set to "run as Administrator". The VB6 and VS2005 IDEs have their OS compatibility set to run in XP SP3 compatibility mode as well.
-
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.
VB6 is procedural in essence with some OO aspects. And that's hardly the biggest problem of converting VB6 to .Net. As I mentioned earlier, the API's and controls are completely different. That's the root of the problem if you're not converting simple console applications.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
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
That has not been my experience. My experience, in general, is they "think" they do, but when it comes to actually accomplishing something, the lack of knowledge shows. For example, a lead C/C++ developer, after working with C# for 3 months, stated, "You don't need the .NET framework to write C# programs." Brilliant in the areas where he works, but clueless on the broader scope of software architecture and engineering. They do learn, after a while, but they often suffer from the myth that C/C++ programmers are better and more knowledgable than VB6 or .NET programmers. Being knowledgable and skilled are individual choices, not inherited by learning some specific programming language. There are good and bad C/C++ programmers, just as there are good and bad VB6, VB.NET, C#, and Java programmers.
-
That has not been my experience. My experience, in general, is they "think" they do, but when it comes to actually accomplishing something, the lack of knowledge shows. For example, a lead C/C++ developer, after working with C# for 3 months, stated, "You don't need the .NET framework to write C# programs." Brilliant in the areas where he works, but clueless on the broader scope of software architecture and engineering. They do learn, after a while, but they often suffer from the myth that C/C++ programmers are better and more knowledgable than VB6 or .NET programmers. Being knowledgable and skilled are individual choices, not inherited by learning some specific programming language. There are good and bad C/C++ programmers, just as there are good and bad VB6, VB.NET, C#, and Java programmers.
MSBassSinger wrote:
There are good and bad C/C++ programmers, just as there are good and bad VB6, VB.NET, C#, and Java programmers.
True, but statistically you'll find that the percentage of bad programemrs in a specific language will go up as the learning curve dips down. These days writing C/C++ applications is way harder than writing .NET applications so unless someone is passionate enough to learn C++, they'd typically go for an easier choice. This skews the results as you might imagine. Eventually good programmers will write good code in whatever language works best for their needs.
Regards, Nish
My technology blog: voidnish.wordpress.com Part 2 in my WinRT/C++ series : Visual C++ and WinRT/Metro - Databinding Basics
-
VB6 is procedural in essence with some OO aspects. And that's hardly the biggest problem of converting VB6 to .Net. As I mentioned earlier, the API's and controls are completely different. That's the root of the problem if you're not converting simple console applications.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
VB6 can be used, and MS recommended so when .NET was in beta, as a purely OO language, though some of the OO implementation is clunky (which means manual correction when converting from VB6 to VB.NET). You are correct on the conversion of usage with some 3rd party controls, but I have not run into the problems it sounds like you have with VB6 programs for those programs I designed. With the legacy code I inherited, all I can say is that even AI is not sufficiently advanced to unravel spaghetti code and spaghetti objects. :) I agree that where the MS user control APIs are significantly different, it will take a little coding. I wish I could find the online article MS published back in 1999/2000 on how to prep VB6 apps for .NET. It was a huge help.
-
1 - I want to see that in practice, it doesn't make too much sense. For what I've seen, it hardly requires minimal changes. The API's are completely different, UI controls are completely different, many don't even have an equivalent on the .net platform. Native unsafe calls to the OS are not required on many cases on .net because there's a wrapper built for most of them already. This alone can inherit lots of unsafe code. And in the end if it's easy to convert VB6 to VB.Net, then it's seamless to convert VB.Net code to C# code. Same methods, same framework. 2 - Not really, I'd like to think the opposite. Trying to convert VB6 code to VB.Net will inherit the whole model that lacks the OO principles down to the basic level like inheritance. Converting to C# will force to really rewrite it and give it a chance to design a domain model that take advantages of OO design patterns and principles. Fixing the VB6 code is just like patchin a hole in the old boat. 3 -
MSBassSinger wrote:
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). Any good .NET developer should know both C# and VB.NET
Agreee
MSBassSinger wrote:
but when they discover VB.NET's advantages to the developer,
Don't agree. C# and VB.Net have their own advantages and disadvantages. Personally I prefer C# for it's more declarative and do less stuff behind the scenes and is less forgiving to bad practices. This is where it becomes more religious. 4 - I was trying to say in a general way, not your case specifically. In that sense I don't think it's a valid argument that converting to VB.Net instead of C# will save money. There are too many factors involved to make such statement.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
1. If I had the time, I'd say send me a VB6 prgram you think is as OO as VB6 can do, but won't convert well. 2. Who says VB6 doesn't do both interface and binary inheritance? It doesn't do it like .NET and Java, but it does do it. 3. C# has advantages for people with a C, C++, or Java background. VB.NET has advantages for those with a VB6 background. VB.NET is just as unforgiving as C# if properly configured, but like VB6, it does allow a slight looseness that allows a programmer to do stupid things. 4. C#, like Java, takes a little longer to code. In large projects, that adds up. All the arcane legacy stuff that C# brings in to make it comfortable to C, C++, and Java programmers takes time. I've gone head-to-head with very capable Java and C# programmers on the same set of requirements, and the VB.NET is finished sooner without sacrificing quality, stability, scalability, comemnts, documentation, etc.)
-
Windows 7 Pro 64 bit, SP1. I and my coworkers have the VB6 IDE, VS2005, and VS2010 installed. All 3 IDE executables (and their shorcuts) are set to "run as Administrator". The VB6 and VS2005 IDEs have their OS compatibility set to run in XP SP3 compatibility mode as well.
Mine is also set for compatibility with XP SP3. I ran it just now as administrator and it bombed on
Debug.Print DateDiff("d", #10/26/2011#, #11/30/2011#)
with "invalid procedure call or argument". Same code works fine in VB6 under XP Mode. I get the same when I right-click the shortcut and select Run As Administrator as well as turning on the option in the shortcut's properties. I guess I've hit an edge case somewhere along the lines. :/
-
VB6 can be used, and MS recommended so when .NET was in beta, as a purely OO language, though some of the OO implementation is clunky (which means manual correction when converting from VB6 to VB.NET). You are correct on the conversion of usage with some 3rd party controls, but I have not run into the problems it sounds like you have with VB6 programs for those programs I designed. With the legacy code I inherited, all I can say is that even AI is not sufficiently advanced to unravel spaghetti code and spaghetti objects. :) I agree that where the MS user control APIs are significantly different, it will take a little coding. I wish I could find the online article MS published back in 1999/2000 on how to prep VB6 apps for .NET. It was a huge help.
MSBassSinger wrote:
VB6 can be used, and MS recommended so when .NET was in beta, as a purely OO language
There's no way VB6 can be used as a purely OO language. Again, the most basic feature of OO like inheritance is missing in VB6. You can, however, "mimic" inheritance on VB6, but that's hardly something to say about an OO language. Or like MS says on it's article on MSDN: "Arranging" Inheritance in VB6[^] ;P
MSBassSinger wrote:
but I have not run into the problems it sounds like you have with VB6 programs for those programs I designed.
It maybe so, but trying to make a FlexGrid a DataGridView is hardly a painless experience X| Basic controls like comboBoxes, textBoxes or listViews are ok, but things get ugly on more complex controls.
MSBassSinger wrote:
I wish I could find the online article MS published back in 1999/2000 on how to prep VB6 apps for .NET. It was a huge help.
I bet it was, but the cases I got, it'd need a miracle to be enough :^)
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
1. If I had the time, I'd say send me a VB6 prgram you think is as OO as VB6 can do, but won't convert well. 2. Who says VB6 doesn't do both interface and binary inheritance? It doesn't do it like .NET and Java, but it does do it. 3. C# has advantages for people with a C, C++, or Java background. VB.NET has advantages for those with a VB6 background. VB.NET is just as unforgiving as C# if properly configured, but like VB6, it does allow a slight looseness that allows a programmer to do stupid things. 4. C#, like Java, takes a little longer to code. In large projects, that adds up. All the arcane legacy stuff that C# brings in to make it comfortable to C, C++, and Java programmers takes time. I've gone head-to-head with very capable Java and C# programmers on the same set of requirements, and the VB.NET is finished sooner without sacrificing quality, stability, scalability, comemnts, documentation, etc.)
MSBassSinger wrote:
1. If I had the time, I'd say send me a VB6 prgram you think is as OO as VB6 can do, but won't convert well.
Ok, maybe it's not as OO as VB6 can do, but then, that's only part of the story. If I could control how VB6 projects were first designed, well I'd be living a dream.
MSBassSinger wrote:
2. Who says VB6 doesn't do both interface and binary inheritance? It doesn't do it like .NET and Java, but it does do it.
These are just two aspects of an OO language, there's much more to it. And interface, yes a little different (COM) but yes, you can do it. But inheritance, you need to mimic it. And I can keep going, on abstract classes, no trully polimorphism, no concept of abstraction and so on... 3. I wasn't really getting to the background, but yeah, got ya.
MSBassSinger wrote:
All the arcane legacy stuff that C# brings in to make it comfortable to C, C++, and Java programmers takes time
That's questionable, I don't think there is anything arcane about C#. And productiveness I'd say is more about the developer skill on the language than the language itself. This is just my opionion though.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
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 use it because I know it, and for the kinds of programming I do (small projects) it is a fast way to get the work done. It lacks nothing I need. There is no benefit to using anything else.