I cannot believe anyone else hasn't been through this pain barrier, with Migrating old code from VB 6. Any help; advise; shared experiences would be useful or even a nod in the right direction.
Post a Comment
1. What is moving forward? What is missing from the current VB6 app? Sometimes the answer is nothing, and that settles it. On the other hand, sometimes "progress" is mandated, so you must decide what progress is. This can help you decide what tool best provides this feature.
2. What is the skillset of the developer(s) involved? This can help filter out your choices.
3. What is the target platform of your application? Are you really going to be running on Linux? If not, then Gambas is not for you. If it is, then it might be a good choice, although it is probably more like VB.NET than VB6 - it is very object-oriented, which is usually what causes people to not like the transition from VB6 to .NET. Personally, I thought it was a breath of fresh air!
Lastly, I would just comment - treat this like a real project. Lay out the needs of the project, such as the new necessary features I mentioned above. Don't just go by "gut" feelings.
In this instance means Moving forward on some 300Mhz machine that was simply not up to anything anymore to a Duron with 192Mb of memory which dual boots win98 which is unstable(due to time), and Ubuntu. I chose Ubuntu simply because of its popularity. He's currently very exited with Ubuntu an Ibex beta chosen for its wireless as much as anything else, and has enjoyed I think updating more than anything else, but uses it to browse on because its more stable than anything else. We are talking skip computing here not Vista.
The program in question is not a commercial app its a hobby project that's got out of hand. Labeling something the best tool in this instance may be full .net with XP, but its not going to happen one of the problems of Mono is the problem faced is to do with developing in an Unfamiliar Environment. Microsoft is simply not an option and express does.
He is fa miler with dead languages and dead OS's, and the staple Microsoft Products until XP, Its like he stayed in 1999 and now how jumped to Ubuntu 8.10
Its not my application. The problem lies in the differences, The Point is the that Mono+Ubuntu is overwelming but Gambas might be a blind alley. .Net is simply too much cost in hardware+software going forward in every way.
The problem with a jump from one kind of basic to any other kind of basic is that it is never simple. The insane mix of object oriented and functional calls that makes you want to slit your wrists is something that you can only become comfortable with through sheer memorization. As soon as you move to another basic, syntax wise it may look more or less the same, but all that memorization goes flying out the window.
If he wouldn't mind paying money, I would recommend RealBasic. It is cross platform, it has a decent design surface, and it is a basic dialect. I'm not sure about the hardware requirements, but I can almost guarentee it will be be better then studio express and .net.
Its been a few years since I looked at GAMBAS, but last time I looked it was pretty unusable. When it comes to Free designers, I think the best solution at this point in time is monodevelop + mono, but the difference between VB.net and VB6 is pretty massive.
I would say look at realbasic, if that doesn't work just run the old app through WINE and forget about porting, because it is going to take significant amounts of retraining and work.
The problem is right not the move to Mono without the step to .net is just a step too far.
Realbasic looks quite nice, although even that kind of money for the personal edition, for a years support looks to be quite a lot, although I'm not sure how he would respond to community help.
The problem is not time or work, wine would work for running the program but for development I'd be a little concerned he is not google he does it as a hobby. I am concerned about Mono simply because it seems overwhelming as opposed to Gambas, but having looked at Mono and been somewhat impressed, and have a stong suspicion that long term its the better horse.
Realbasic looks quite nice, although even that kind of money for the personal edition, for a years support looks to be quite a lot, although I'm not sure how he would respond to community help.
REALbasic Standard is free to use on Linux. The support you pay for is more for upgrades than direct from company support. However, the forums are excellent and I have always found a solution to my problems there. Indeed, after using RB Standard for a couple of years (on Mac), I upgraded to the Pro license, so that I could have access to enterprise database platforms (MySQL and SQL Server mainly, although you can also access oracle, Sybase etc).
Two of the great benefits of RB Pro are that:
1. You write once, and you can then compile to *native* OS X, Windows or Linux platforms. There are some considerations of course, such as native font sizes, native widget placement conventions etc, but that's all taken care of thanks to platform directives which you can add to your code
2. Standalone apps. On Windows for example, I get a single .exe file (plus of course any text/sql files that I might need, but the app itself is a single executable). This does mean a more "bloated" file, as there is no sharing of common files with other apps, but in an environment where IT departments will not let yo install anything tat creates dependencies with other files, this is a great solution which is usually acceptable. If not, run it from a USB drive
As to the language, if he is comfortable with VB6, he will be more than comfortable with RB. It's very similar, but much richer (proper inheritance, scoping, namespaces etc). Use as much or as little OO as you feel comfortable with.
It's not perfect by any means: Real Software have a worrying tendency to deprecate features at every release (usually with good reasons, but with little or no warning - not good)
Why not just try a few of the options mentioned out for a few weeks and see what he is most comfortable with? VSE for C# is great. I have not tried Mono but I suspect from the comments I've read around the Web that it's pretty mature and very competent now.
Isn't choice wonderful?
I would still say that XP with some Visual Studio Express is the best option. Free, stable, productive and very nice to use. I haven't seen any real arguments against it.
If he cannot handle the transition between VB6 to .NET he is certainly unable to handle: Windows -> Linux + new possibly obscure language + environment, producing an application that will not run (well) on most people's computers.
If it all seems hopeless, just carry on with VB6.
Wait, a 300 MHz machine? Running Ubuntu? O.o Have it even finished booting yet?
Please, get an old P4 or even P3 from a second hand store or something. It would cost almost nothing.
This sounds like a good option to me.
If he wants to have it run Mono later you can install Mono Migration-assistent and test your app in that from time to time to make it sure it plays well with Mono as well as .net.
Then you can take .net first(not such a big step as Linux), and late if it makes sense take the full step towards Linux.
Its a Athalon, I migrated the 98 to the new *cough* machine. I'm sorry I didn't make that clear its the 192mb of memory that is the main problem.
The automatic VB migration tool is simply too expensive, and not available for express, but he would gain from the more familiar environment.
Lots and lots of people have, despite claims to the contrary around here. There was even a petition to get classical VB back in some form by Microsoft MVPs:
http://classicvb.org/
http://classicvb.org/Petition/
VB 6 and classical VB is simply completely and irreversibly incompatible with your existing code which means that you will inevitably have to rewrite large parts of it. Can you justify the cost and business case, considering that doing this will not make your applications run any better? Many people are just sitting on their copies of Visual Basic and continuing the develop with it, and with virtualisation you can keep a platform going somewhere well into the future where you can run it.
Get on to the Mono guys and tell them to implement a classic VB-like RAD environment on top of Mono that could reuse vast swathes of existing classic VB code, come up with some nice upgrades and allow people to use their existing COM components if necessary. However, even just being able to open code in such a RAD environment, make a few changes and then re-compile it to run under a Mono/.Net environment would be worth an awful lot.
If you do bother, make sure you port to a platform backed by people who don't see you as a one-night-stand ;-).
As Joel puts it:
http://www.joelonsoftware.com/items/2005/03/14.html
I think something like RealBasic is your best get-out if you don't want to start chewing code, but I haven't looked at it for a while.
VB.net is very rich object oriented language that is loosely based on BASIC syntax. VB6 is a hacky combination of functional methods and object oriented paradigms that are crammed together with no rhyme or reason. MS already has a migration tool, but it sucks because you would not write apps even remotely the same way on the two platforms.
In the old days, the ms dev community was split down the middle between VB and C++ guys. Nowadays, VB is seen as a migration path to C#, because if you are going to take the time to learn VB.net, you may as well go the extra few steps and learn C#. It is the same framework, libraries, and RAD tools for both now. Because of that, VB is mostly relegated to hobbyists and for legacy code.
What you are suggesting would be ridiculously difficult, not that useful for anything even remotely new that is happening in the .net world, and in the end wouldn't even be that great an idea.
You might call VB6 hacky, but the problem is that the vast majority of people simply don't need a full-blown object-oriented environment to run in. Classic VB was good at what it was good at being - a RAD environment without the OO features few needed that took care of memory management.
That's very true. Essentially. VB.Net is the same language as C# differing only via syntax and where C# is the primary .Net language.
However, there is no RAD environment for .Net. The object oriented cycle you need to be in to make .Net work cannot be considered as RAD development.
People with existing code don't care about new things that are happening in the .Net world. They care about their existing applications. It would be a good an exceptionally good idea because people could take the millions of lines of code they have an actually use them for something in a new version of Visual Studio or use Mono. Microsoft would also get VB developers forking out for new versions of Visual Studio, but Microsoft has lost that ideal and I don't think it is a good idea for Mono to follow it. At the moment, as this conversation implies, people have no option but to keep VB6 going and running somewhere or writing new code to stand still.
You might call VB6 hacky, but the problem is that the vast majority of people simply don't need a full-blown object-oriented environment to run in. Classic VB was good at what it was good at being - a RAD environment without the OO features few needed that took care of memory management.
I agree with the first part, and partially with the second part. The designer was the best out there, but the language was a raging piece of crap. IronPython + Winforms is a much better combination of scripting language + good RAD designer.
However, there is no RAD environment for .Net. The object oriented cycle you need to be in to make .Net work cannot be considered as RAD development.
I really disagree. OO and RAD are not mutually exclusive or anything. You can drag and drop yourself about 90% of the way to a full working application if you dont care about stuff like scalability and good application design in .net. And it is not hard to do functional programming in an OO language, just have a single class with a bunch of static methods.
What I am saying is that things are radically different, and you can only take an automated conversion so far. The fundamental structure of the way the two platforms work is very very different. It would be better to either take the time to port it, or just use COM interop with the existing code (which isn't that tough).





1 