Visual Basic - when to switch?
-
Support policy for Visual Basic Support Statement for Visual Basic 6.0 | Microsoft Learn[^] Now as I read that it means that although they are not going to be improving VB they do intend, at least now, to make sure it runs until 2035 (presuming same life cycle for Windows 11 as was for Windows 10). But perhaps not beyond that. So people have those VB apps now so when do they really need to start refactoring the entire code base into something else? Start now and avoid the rush? Wait until 2034? Wait until 2037 and when enough customers move onto a different provider because they don't want to run an older unsupported OS?
Visual Basic stopped working with Windows 7. Microsoft dropped a bunch of required modules in Windows 7. The solution was to add these modules to the VB6 build. Again with Windows 10, Microsoft did the same thing, requiring modules to be included in the build. In addition, Microsoft changed the registry structure/contents on Windows 10. I am still trying to code replacement to find the full path to installed programs. Years ago, I was going to convert my VB6 programs to VB.net, but ran into big problems as the form handling routines did not have the same capabilities of VB6. That was probably 18 years ago, so I can't remember the details now, but I'd guess, and it is only a guess, that things like _LostFocus no longer worked and I didn't want to waste the time on how to get around the problem. As I recall, there were a lot of deficiencies with VB.net. With changes in Windows 10 and Windows 11, I may have to re-write all my applications in a new language. I've been retired for over 10 years, so I don't think that is going to happen. Microsoft sucks! And don't get me started on the 'unknown publisher' message that comes up every time I run an application on Windows 10. Microsoft doesn't want to make things easy for the developer anymore.
-
Support policy for Visual Basic Support Statement for Visual Basic 6.0 | Microsoft Learn[^] Now as I read that it means that although they are not going to be improving VB they do intend, at least now, to make sure it runs until 2035 (presuming same life cycle for Windows 11 as was for Windows 10). But perhaps not beyond that. So people have those VB apps now so when do they really need to start refactoring the entire code base into something else? Start now and avoid the rush? Wait until 2034? Wait until 2037 and when enough customers move onto a different provider because they don't want to run an older unsupported OS?
-
Very recently Damian Edwards[^] was asked about bringing VB in line with ASP.Net MVC, and the response was there is no plan to do it. That is just one example.
Graeme
"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee
-
Visual Basic stopped working with Windows 7. Microsoft dropped a bunch of required modules in Windows 7. The solution was to add these modules to the VB6 build. Again with Windows 10, Microsoft did the same thing, requiring modules to be included in the build. In addition, Microsoft changed the registry structure/contents on Windows 10. I am still trying to code replacement to find the full path to installed programs. Years ago, I was going to convert my VB6 programs to VB.net, but ran into big problems as the form handling routines did not have the same capabilities of VB6. That was probably 18 years ago, so I can't remember the details now, but I'd guess, and it is only a guess, that things like _LostFocus no longer worked and I didn't want to waste the time on how to get around the problem. As I recall, there were a lot of deficiencies with VB.net. With changes in Windows 10 and Windows 11, I may have to re-write all my applications in a new language. I've been retired for over 10 years, so I don't think that is going to happen. Microsoft sucks! And don't get me started on the 'unknown publisher' message that comes up every time I run an application on Windows 10. Microsoft doesn't want to make things easy for the developer anymore.
I wrote a Software Defined Radio in VB6 + Delphi + Assembler back in 2003, and it's still in use today - I still see downloads - https://www.g8jcf.uk/. The Delphi & Assembler were used to write the low level DSP and vector arithmetic - it was developed on a Celeron 333 with 192 MBytes of RAM a SONY VAIO laptop !!! The G8JCFSDR is a hobby program for free for a relatively small base, so it's not worthwhile me porting it to C#, although it might be an interesting excercise. Back in 2003, so much stuff had to be added around VB6 to hook message events, handle callbacks, etc, so it might be much easier/quicker today Ah those were the days :-) 73 Peter - GM8JCF
-
Support policy for Visual Basic Support Statement for Visual Basic 6.0 | Microsoft Learn[^] Now as I read that it means that although they are not going to be improving VB they do intend, at least now, to make sure it runs until 2035 (presuming same life cycle for Windows 11 as was for Windows 10). But perhaps not beyond that. So people have those VB apps now so when do they really need to start refactoring the entire code base into something else? Start now and avoid the rush? Wait until 2034? Wait until 2037 and when enough customers move onto a different provider because they don't want to run an older unsupported OS?
From my viewpoint it depends on what the code is for. I converted my VB6 programs to VB.NET over 20 years ago. Some things took very little effort as I was able to copy large chunks of code. I redid all of my forms from scratch, but I was able to reuse a lot of code. Most of the code I have written involves controlling test equipment and taking measurements. I like VB.NET because it is easier for someone with very little programming experience to follow what the test code is doing.
-
I bet some of those programs will be relevant. It really depends on what they're supporting. I have one program that was originally developed in 1997 using FoxPro for DOS, migrated to MS-Access, and is now written in VB.Net using a SQL Server database for the back end. We still have data from 1997 in the database. The core functions of this program haven't changed since the original version in 1997.
I have a very similar situation with software written in 1995 in a mix of QBasic and MS Access, migrated to a SQL server back-end, updated to VB for the QBasic stuff, back-end moved to MySQL, and numerous iterations since. What's interesting to me is the derision shown for powerful, capable and effective systems written in so-called "toy" languages. Many still run today because they just work and do what they were designed to do. I develop mostly in C# now but I would never look down on people still using VB, VB.Net, or any other language. If it works for them, then it must be doing something right. Program-language snobs are something I cannot understand. I will admit that I would never start developing a new project on any of the older languages, no matter how well I know them.
-
Why? To be one of the "cool kids"? confused: To be part of the "In-Crowd"? confused: To be "just like everybody else?": confused: How many people back into parking spots because the see other people doing it? confused: I guess haters going to hate.
Very Old Guy.
I back in to parking slots for the same reason I use C# rather than VB6 - it's easier and safer.
-
Support policy for Visual Basic Support Statement for Visual Basic 6.0 | Microsoft Learn[^] Now as I read that it means that although they are not going to be improving VB they do intend, at least now, to make sure it runs until 2035 (presuming same life cycle for Windows 11 as was for Windows 10). But perhaps not beyond that. So people have those VB apps now so when do they really need to start refactoring the entire code base into something else? Start now and avoid the rush? Wait until 2034? Wait until 2037 and when enough customers move onto a different provider because they don't want to run an older unsupported OS?
[disclaimer: I supervise a varied codebase that includes a few large VB apps, with many thousands of lines of code.] Interesting responses to this, ranging from funny to pragmatic to completely off-base. You need to look at these as IT projects and define your timelines based on need. You didn't provide any details about what the apps are or how they are used, so it's hard to do a decent analysis. Short answer: I'd look at 5-6 year target zone. No sense on pushing it to the limits. Depending on the apps involved, the write could take a few years so starting sooner is better than later. There is no "re-factoring"; this is a ground up, blank canvas rewrite for desktop apps. C# is the way to go but VB.net isn't terrible. But there's a lot of unknowns:* Are these just small apps serving limited functionality?
- Data connections and underlying database? Personally, I'm not a fan of migrating databases and codebase at the same time if it can be avoided. It interjects a ton of potential errors. Whether it's data first or code first depends on circumstance
- Printing. Many old VB apps do a lot of document printing (not reports). They take a lot of code/time in .net
- OOP analysis. Meh. Not knowing the codebase, can't answer that one. It's not trivial, and it can be tough to flesh out because you're looking at the existing app. Like anything else, lots of thinking here.
- Web? Two pronged-question. In our review of some of the VB uses, web-based apps are a more suitable replacement than rewriting desktop apps. We have several going in that direction, though the back end remains in .net in some cases. The second piece is if the apps or data interact with the internet as that plays into the design.
It boils down to the apps; how big they are and what they do. I'd start planning as soon as time allows. If you can transition functionality to a new program, it's not a bad approach. Avoid the light switch approach if you can.
-
Please recommend where to switch to. :laugh:
-
When to switch? I'd start now. Nothing ever goes as planned, so figuring things out now, well ahead of a complete drop in support, is the wiser choice. I have no idea where the OP is in his career, but any newer language is a more marketable skill, so starting now also adds to the resume. What to switch to? I was a VB developer (among other languages) from 1993 to 2003. At that point there was still a lot of 3rd party support for VB6, but without MS support it was a dead language. Yeah, obviously as dead as COBOL, but as an IT consultant, I had to focus on marketable skills, and VB was no longer "it". The obvious jump-to was VB.NET, but within a few months I formed the opinion that MS made VB.NET primarily to keep the VB5/6 developer base from jumping ship. VB.NET didn't get the same support and was not graining traction in market share. Next I investigated C#, and that has been my primary platform since then. It's the MS flagship for programming languages, gets the support, and has a viable future. Market share of the tool matters greatly to ensure continued employment, and C# is ranked 5 or 6 in most surveys. From the OP's POV? C# is going to be the easiest path. The environment is similar enough and C# has enough similarities in structure that the learning curve should not be too steep. Jumping from procedural to OO can be a difficult jump. VB6 has some OO, and if the OP has been using classes, the leap may not be a long one.
OOP's overrated :-D Seriously though, I use it where needed but depending on the desktop app and the object usage, procedural can be more efficient to build. Doing a complete from scratch rewrite, which these are, requires a ton of thought. I don't start by looking at code, I look at process and functionality. It's a good opportunity to really review processes in many cases.
-
OOP's overrated :-D Seriously though, I use it where needed but depending on the desktop app and the object usage, procedural can be more efficient to build. Doing a complete from scratch rewrite, which these are, requires a ton of thought. I don't start by looking at code, I look at process and functionality. It's a good opportunity to really review processes in many cases.
I agree with you regarding OOP -- it's A technique, not THE technique. C# is an OO language, so things are pushed in that direction. Something people don't often consider is that forms are classes. Forms in VB 4-6 are instantiable objects. It doesn't matter that the word "class" isn't there -- it's not a requirement, just a common convention. Re-writing an application from scratch is not a trivial thing. It can be rather expensive, and management often defers the task to avoid incurring what appears to be an unnecessary cost. Until replacement becomes a requirement, and things are crammed into production. As the old saying goes, we don't have time to implement correctly, but we do have time to fix it in production.
-
[disclaimer: I supervise a varied codebase that includes a few large VB apps, with many thousands of lines of code.] Interesting responses to this, ranging from funny to pragmatic to completely off-base. You need to look at these as IT projects and define your timelines based on need. You didn't provide any details about what the apps are or how they are used, so it's hard to do a decent analysis. Short answer: I'd look at 5-6 year target zone. No sense on pushing it to the limits. Depending on the apps involved, the write could take a few years so starting sooner is better than later. There is no "re-factoring"; this is a ground up, blank canvas rewrite for desktop apps. C# is the way to go but VB.net isn't terrible. But there's a lot of unknowns:* Are these just small apps serving limited functionality?
- Data connections and underlying database? Personally, I'm not a fan of migrating databases and codebase at the same time if it can be avoided. It interjects a ton of potential errors. Whether it's data first or code first depends on circumstance
- Printing. Many old VB apps do a lot of document printing (not reports). They take a lot of code/time in .net
- OOP analysis. Meh. Not knowing the codebase, can't answer that one. It's not trivial, and it can be tough to flesh out because you're looking at the existing app. Like anything else, lots of thinking here.
- Web? Two pronged-question. In our review of some of the VB uses, web-based apps are a more suitable replacement than rewriting desktop apps. We have several going in that direction, though the back end remains in .net in some cases. The second piece is if the apps or data interact with the internet as that plays into the design.
It boils down to the apps; how big they are and what they do. I'd start planning as soon as time allows. If you can transition functionality to a new program, it's not a bad approach. Avoid the light switch approach if you can.
MikeCO10 One of the BEST responses the post I bought VB 6 Pro Edition at a computer swap meet in Akron, Ohio for $40.00 and Yes I knew the savings. I was a old Apple /// and Palm Pilot hobbyist with a new Windows computer. It opened a door to learning programing and beat the pants off that DEC Writer I learned BASIC on at the University of Toledo College of Pharmacy. The way Microsoft pulled the plug on VB 6 made a lot of people who made good money from teaching newbies how to program with VB 6 a little more than angry. VB.Net and Visual Studio 2019 have been fun and enjoyable as a hobby. As for still being used this site still offers VB 6 apps. RxKinetics Pharmacokinetics and Nutrition Software for Pharmacists[^] The owner Rick Tharp taught me how to use Inno Setup and a lot of VB 6 code. That Kinetics software saves a lot of physicians from ruining peoples kidneys. If it works and is reliable why move on? What happens is the OS get better and can't support older languages and companies do not want to invest in new systems and software that cost a lot more money. As a Medication Safety Officer at a couple of large hospitals I have seen deaths due to outdated software. YES the CEO of each of the hospitals was not in favor of larger investments in new hardware and software. I am learning C# and the challenge is fun.
-
Support policy for Visual Basic Support Statement for Visual Basic 6.0 | Microsoft Learn[^] Now as I read that it means that although they are not going to be improving VB they do intend, at least now, to make sure it runs until 2035 (presuming same life cycle for Windows 11 as was for Windows 10). But perhaps not beyond that. So people have those VB apps now so when do they really need to start refactoring the entire code base into something else? Start now and avoid the rush? Wait until 2034? Wait until 2037 and when enough customers move onto a different provider because they don't want to run an older unsupported OS?
That's an issue for my successor to deal with - I'm retiring in no more than 3 years from now, so I'll just keep going with VB.Net. The programs I'm dealing with were here before I was hired, and I have no doubt that they'll still be around after I'm gone, so I don't feel a pressing need to change anything.
-
immediately after puberty. :)
>64 Some days the dragon wins. Suck it up.
:laugh:
Software Zen:
delete this; -
I agree with you regarding OOP -- it's A technique, not THE technique. C# is an OO language, so things are pushed in that direction. Something people don't often consider is that forms are classes. Forms in VB 4-6 are instantiable objects. It doesn't matter that the word "class" isn't there -- it's not a requirement, just a common convention. Re-writing an application from scratch is not a trivial thing. It can be rather expensive, and management often defers the task to avoid incurring what appears to be an unnecessary cost. Until replacement becomes a requirement, and things are crammed into production. As the old saying goes, we don't have time to implement correctly, but we do have time to fix it in production.
Very well said! Years ago, when converting a VB6 app, one of my programmers told me I had too much code "behind the buttons". My reply was that sometimes a button click is just a button click. An extreme example, but goes to the "THE" mentality. I don't know about all of you out there, but often times "agile" falls short of design flow. I'd call it more flux-rad. Easy to make the argument that OO is the way to go, but it takes some thought and a couple of lines of procedural code can be a better solution. And, as you said, cost is very often a factor. The other old saying we use is, if it ain't broke, don't fix it!
-
Correct. I should've specified desktop programs.
"If we don't change direction, we'll end up where we're going"
-
I have a very similar situation with software written in 1995 in a mix of QBasic and MS Access, migrated to a SQL server back-end, updated to VB for the QBasic stuff, back-end moved to MySQL, and numerous iterations since. What's interesting to me is the derision shown for powerful, capable and effective systems written in so-called "toy" languages. Many still run today because they just work and do what they were designed to do. I develop mostly in C# now but I would never look down on people still using VB, VB.Net, or any other language. If it works for them, then it must be doing something right. Program-language snobs are something I cannot understand. I will admit that I would never start developing a new project on any of the older languages, no matter how well I know them.
Carl Edwards In SA wrote:
Program-language snobs are something I cannot understand.
I understand your statement but there is a bit more to it that just that. Older implementations can have other problems which management is unwilling to address. For example one often gets to the point that the only way you can find maintenance programmers is by finding someone who doesn't know anything about the older language and convince them that learning that language that is unlikely to be used elsewhere is going to be a good choice for them. To be fair though I have seen a current trend where management has decided that micro-services can be written in any language and with any persisted data store which obviously completely ignores the longer term maintenance costs.
-
When to switch? I'd start now. Nothing ever goes as planned, so figuring things out now, well ahead of a complete drop in support, is the wiser choice. I have no idea where the OP is in his career, but any newer language is a more marketable skill, so starting now also adds to the resume. What to switch to? I was a VB developer (among other languages) from 1993 to 2003. At that point there was still a lot of 3rd party support for VB6, but without MS support it was a dead language. Yeah, obviously as dead as COBOL, but as an IT consultant, I had to focus on marketable skills, and VB was no longer "it". The obvious jump-to was VB.NET, but within a few months I formed the opinion that MS made VB.NET primarily to keep the VB5/6 developer base from jumping ship. VB.NET didn't get the same support and was not graining traction in market share. Next I investigated C#, and that has been my primary platform since then. It's the MS flagship for programming languages, gets the support, and has a viable future. Market share of the tool matters greatly to ensure continued employment, and C# is ranked 5 or 6 in most surveys. From the OP's POV? C# is going to be the easiest path. The environment is similar enough and C# has enough similarities in structure that the learning curve should not be too steep. Jumping from procedural to OO can be a difficult jump. VB6 has some OO, and if the OP has been using classes, the leap may not be a long one.
-
I counted 16 replies to the question of wich I se only two that tried to seiously anwer. I this the normal level of seriousness in this forum?
thermia wrote:
only two that tried to seiously anwer. I this the normal level of seriousness in this forum?
In this forum (not site)? Yes it is is. Although certainly with an open ended question I would expect answers that veer off in all sorts of ways anywhere. But also as the OP and with decades of experience I don't actually need an "answer". If I really needed an solution I would already know what it was and how to apply it for any specific situation I was in. I just thought the question was interesting.
-
never switch. VB Classic was right only now in C# you can write code without
XYZ partial class App public static void main SubscriberMethodController... cough coughStarting in C# 9, you don't have to explicitly include a Main method in a console application project. Instead, you can use the top-level statements feature to minimize the code you have to write. In this case, the compiler generates a class and Main method entry point for the application. guess what, we had that since VB 1.0, any language had that, the compiler behind the scenes generated the _app & _main. i wonder when they are going to get rid ofnewin C#, since the instances of a class are not created on the stack anyway... VB Classic will outlive VB .NET. if not, waiting for the shameful M$ narrative when they bring back the apparent syntax of VB to VB.NET those who put *class* in JavaScript are the same who put *var* in C#Martin ISDN wrote:
guess what, we had that since VB 1.0,
Just noting that I don't consider that a feature that would have any impact at all in a language choice. Further if one is spending a major part of their time creating new applications I would wonder what exactly is the business domain they are working in. After all if you are maintaining an application for 20 years then the entry point for that application should not change at all for the entire time.
