Printable View
Hello
Folks, 10 years ago, I was migrating from VB 5 to 6 ... excellent as it is today ... But there are rumors of the end of support for VB6 application in next Windows (Win 8).
I have a large project in VB6 .. and my fear is the future windows do not run softwares "made in VB6". Is this possible?
wanted the opinion of colleagues ... everyone's opinion is important.
What would you do? Rewrite all code to .net (over 200.000 lines); continue in VB6?
Thank you!
This thread should be in General Developers Section or Chit Chat Section...
Isn't it possible to run the application using some tools like Virtual PC...??? :wave:Quote:
I have a large project in VB6 .. and my fear is the future windows do not run softwares "made in VB6". Is this possible?
There is already an end to support for VB6 officially from MS, so it is likely that windows 8 won't have built in support for it, but backwards-compatibility has always been included somehow...windows 7 will run through compatibility mode easily, Vista runs fine with VB6 and applications. From what I remember, MS said VB6 wouldn't work with Win 7 either, and I think they said the same about Vista (when you install the IDE it tells you it's not compatible but it works fine if you ignore it).
IMO it'll always be around, there's people still using software older than VB6 and there always will be, but the level of usefulness in new versions of Windows will not be known until it comes out so it's entirely up to you.
If you're up for the task, start porting sections of the code over to .NET bit by bit and get it all working.
Another thing to think about is whether it'll be important or not...will your clients be using Windows 8? Even once Windows 8 comes out it'll be a few years before everyone's moved on to the new platform, most home PCs still use early versions of XP and most businesses are running XP/Vista with only the major ones upgrading to Windows 7.
I guess you need to consider the possibilities and work out a timeframe for when you'd need a compatible .NET version and how long it might take, and weigh out your options of whether you want to wait or start sooner and whether you mind wasting your time converting it when it just might work still in Windows 8 anyway.
Moved to general developer. Thanks for the report.
I'd start rewriting it and not because of the possibility of what a new operating system will or will not support.
Just because Microsoft releases a new OS doesn't mean you have to upgrade to it.
I'd start rewriting it because it is the wise thing to do, and, right now, you don't have to. If you started on the project now then long before you actually had to rewrite it you would be done.
I agree with Hack. VB6 is already long dead in Microsoft's eyes. Best to start converting now than later. Trust me, you'll never, ever want to go back. I must have talked with dozens of programmers who made the switch, and yes, it was grueling and ugly at first, but after 6 months, none of them ever wanted to go back to VB6.
200,000 lines of code could seriously probably be cut down to 150,000 in .NET. It's just that more efficient. All of my programs got smaller when I converted. Last program I converted around that size took me about 1 month. I started with my smallest programs and worked up to my largest ones.
As mentioned, there's no guarantee your program will continue to run on the next version of Windows. I think Microsoft realizes there are a lot of VB6 programs out there, and for that reason alone, continues their run-time support.
LOL... That's not the reason - major and medium corps are: there are tons of legacy code out there which was "one of the reasons" Vista failed in the corporate world.Quote:
Originally Posted by Jenner
However, I do agree with "rewriting idea" and the sooner it happens the better - whether you will be using VB.Net, C# or even Java isn't relevant.
The point I guess is that you have move ahead and away from being "legacy supporter".
VB6 in ten years? Let's see, that would be 15 years after MS stopped support (roughly). Fifteen years ago today would be 1994. Back then, you were targeting DOS and possibly Windows 3.1. How many DOS programs do you use today?
There are still programs that are older than that, running on legacy hardware or in virtual machines. But for the most part, thinking about a program lasting 15 years is not a reasonable idea. Ten years ago today, we were just approaching gigabyte size for HD, computers RAM was still in the few hundred MB range, processors were ALL single threaded, and speeds were around 1GHz. Oh yeah, and we were running Win95/98 or maybe NT. Where will we be in ten years?
Lets see, next 10 years we will have gone through 2 more Windows versions (8 and 9) and be ready for version 10 as MS puts out a new OS every 5 years on average and supportted for sure.
So who knows how drastic the changes will be by then but maybe we will all be doing touch screen and voice input programming. Not very VB6 friendly...
Will future OSs go .NET? Will native code software disappear altogether? Some experts have serious doubts about it.
You may find interesting what Marco Cantù (one of the most famous authors of books on Delphi) said about it in his blog:
http://blog.marcocantu.com/blog/micr..._security.html
The following is an extract from the same blog:
Interesting, isn't it?Quote:
Contrary to what Microsoft envisioned or hoped or simply told us, the Windows ecosystem is not moving towards a .NET centric solution, but .NET is only a powerful and sophisticated execution and development environment on top of Windows.
It's moving towards a total distributed, web-centric solution. MS is just hoping there will BE desktop apps in the future. I would say that increased broadband coupled with better web technology might remove the OS as a significant part of a computer.
As for the quote, it's kind of silly. You could say the same thing about a C++ app running on a Windows system. Virtually nobody writes code that doesn't work in the cradle of the OS anymore. It used to happen, back in the DOS/UNIX days, and may still happen over in LINUX, but for everything Windows, the app is hosted by the OS. The memory it uses is doled out by the OS. The events it receives are passed up by the OS. The calls it makes are filtered by the OS, and so forth. Therefore, ALL development environments that can be used with windows are 'on top of Windows'. That .NET happens to be a powerful and sophisticated one is a bit of a mistake, since .NET is just a set of languages within VS, which will also work fine with unmanaged C/C++ code. Therefore, it is VS that is the 'powerful and sophisticated execution and development environment', though it is on top of Windows.
Uhh.. yes, there are major and medium corps... and they still have a lot of VB6 programs... exactly my point. :confused:Quote:
Originally Posted by RhinoBullLOL... That's not the reason - major and medium corps are: there are tons of legacy code out there which was "one of the reasons" Vista failed in the corporate world.Quote:
Originally Posted by Jenner
It's moving, alright... Whether it reaches the destination is another story, though.Quote:
Originally Posted by Shaggy Hiker
I've heard that about 10 years ago and 10 years later they still moving toward that same thing - only thing that did change is the tool itself.
10 years from now there will probably be another tool (perhaps .God) to keep it moving and everybody occupied.
If MS had really wanted to make programmers continue to develop native software, they would not have abandoned VB6.Quote:
Originally Posted by Shaggy Hiker
Today it is probably too late for regrets or second thoughts, but I firmly believe that a very wise move would have been to come up with two distinct versions of VB, one for the development of native software and one for .NET. That's what CodeGear/Embarcadero have done with Delphi.
It is true that MS are still offering a tool for the production of native apps, but it is also true that C++ is quite difficult to learn for the average VB6 developer.
I agree with you entirely. There are some types of software that the user would never use on-line. Web-centric solutions make a lot of sense in some circumstances and much less sense in others.Quote:
Originally Posted by RhinoBull
Managing your accountancy through a Web-based application would mean to be unable to use it if, for some reason, you can't connect to the Internet. In addition, there is always the possibility that a hacker could break into your Web site and do some irreparable damage. Many people just don't feel like risking it.
So MS needs to create a native language for dummies? You may be right about that. After all, the syntax of C# is the same as C++ (though there may be a few things left out like parts of the STL), and since C++ is already an OO language, it is less of a change than VB6 to VB.NET, so C++ coders could move to .NET without any issues at all. Meanwhile, the attitude towards VB6 was that it was a toy language, and that attitude has not entirely carried over to VB.NET, though some still remains.Quote:
Originally Posted by esposito
It's not about "dummies" but about productivity.
Some of this is probably C/C++ bigots protecting their turf too. VB6 was becoming a threat, VB.Net will never be one.
Wise words. VB6 was -- and for many still is -- extremely easy to use and highly productive. In order to create commercial applications, sometimes all you need is a simple database and a good graphic interface, and VB6 served that purpose very well.Quote:
Originally Posted by dilettante
.NET is no different. In fact, with some of the newer things like the Entity Framework, TableAdapters, and so forth, it is FAR easier to do the same thing than it was in VB6. Of course, it is also different from VB6. If you know VB6, then .NET would seem alien until you had become familiar with it. If you were to learn .NET first, then VB6 would seem like a cripled mutant.
I learned both, but I learned C++ before I had learned either VB6 or .NET (naturally, since .NET didn't exist when I started into VB). I saw the flaws of VB6 while I was using it, and tried to implement a pseudo-OO design style, which is entirely possible in VB6, as long as you don't care about inheritance or runtime polymorphism, both of which can be trouble if used unwisely. Once I started into .NET, I quickly saw the advantages. It was a breath of fresh air in a stifling room. However, had I not learned C++ prior to VB, and was seeing OO for the first time in .NET, I might have found it harder to learn.
So, the comment about programming for dummies was ABOUT productivity. There is no productivity gain for VB6 over .NET. It's the other way around if you know both languages. You can get the same thing done faster in .NET than VB6 in all cases. The point Esposito is making is that he has evidence that people actually would steal his code if it was not compiled to native code. While that is not true of most people, he has clear evidence that it IS true for him. So he was saying that MS needs a language that compiles to native code but is not as hard to learn as C++.
I happen to know some of the people who made the decision to drop VB6.5. The decision was made to "put all their wood behind one arrow." In other words, MS didn't feel that there was sufficient market to justify adding yet another business group. Frankly, I agree. Need production code in native?: C/C++, at least for the core dlls. Need quick?: .NET. Need it to run anywhere? Yeah, right! Dream on! However, if that is really your goal, then only a byte code language has a hope of getting you there.
Correct.Quote:
Originally Posted by Shaggy Hiker