VB6 - far from dead!
-
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.
-
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.
-
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
My company has a solid code base in VB6. When VB.NET appeared we tried the automatic conversion and it would not work. Also it is rather pointless - the code is not object oriented. We did convert, or rather rewrote, our infrastructure code for C# and Java, and we use them for new projects, but the existing projects work well and there is no reason to fiddle with them. We did need to change the data component from mdb, and we chose xml.
-
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. :/
FWIW I just installed VB6 onto my 64-bit Windows 7 Ultimate system along with its ancillary tools, etc. No problems whatsoever. The forms designer is a bit slow when I have Aero running but switching to Win7 Basic mode returns the IDE to its usual speed. I have a couple of old projects still in VB6 and wanted to be able to maintain them and this thread got me thinking I'd give it a shot. Everything (including VSS) works in the 64-bit environment fine. -Max
-
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.
Member 2630113 wrote:
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.
In our operation we have entire subsystems based on VB6. Some of them are COM DLL's that have a customized interface to the calling executable so converting them to .Net would be a complete rewrite. There's simply too much specialized VB6 coding (along with some 3rd-party custom controls) that prevent any kind of "conversion". As these are subsystems to our main product - and our product is in maintenance mode it is completely unlikely the company will ever invest a cent in converting them, so VB6 is going to be part of the mix until the product is shut down. It will be many years, I believe, before that happens. We have about 1,000 enterprise level clients using it, and they ain't going to move to the new company's products quickly. VB6 IS the new COBOL. ;-) -Max
-
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.
Member 4612192 wrote:
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.
... and that is enough reason to use it. :-) -Max
-
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. :/
Weird... I have Win7 SP1 x64 ADO Interface Hack VB6 SP6 I just tried that statement in a new project, no errors. I normally run Compatibility for Vista and disable Desktop Composition. I switched it to Compatability to XP SP3 and re-enabled Desktop Composition. Same thing.
-
My company has a solid code base in VB6. When VB.NET appeared we tried the automatic conversion and it would not work. Also it is rather pointless - the code is not object oriented. We did convert, or rather rewrote, our infrastructure code for C# and Java, and we use them for new projects, but the existing projects work well and there is no reason to fiddle with them. We did need to change the data component from mdb, and we chose xml.
I programmed in VB from it's onset when it was first published in Windows, and I can't remember if that was vb2 or 3. While it had it's drawbacks, (inheritance, polymorphism etc...) it worked, and for RAD there was no equal. There must be billions of lines of code out there still using VB6, and I was very puzzled when Microsoft withdrew support for it. I tend to live by the old engineers saying that 'If it ain't broke, don't fix it'. However, if anybody starts a project now, using VB, then they need their bumps read. Just as a bye the bye, has anyone tried using a dll written in VB as a reference in vb.net?
-
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.
VB.net is only an easy upgrade for good code. If you wrote VB.WTF it's still a total rewrite.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt