At REAL World 2007, I met and talked with a lot of people that have software solutions written in Visual Basic 6 and are wondering what they should do about them. Since Microsoft is no longer supporting VB6, it has left many, many people with a quandary: Do they stick with Microsoft and move on up to Visual Basic .NET, do they tough it out with VB6 or do they consider moving to something else such as REALbasic?
Frankly, I think a lot of VB6 developers are overwhelmed by Microsoft’s .NET offerings. Microsoft has more technologies out now than anyone could possible follow and its mad rush of new technologies continues with .NET 3.0 and Orcas. It’s hard to keep up when you’re trying to deliver software. And besides, it’s not like it easy to migrate from VB6 to VB.NET, even with Visual Studio’s migration assistant.
I also don’t think people really want to continue with VB6. It’s several years old now, the IDE UI is poor, it probably isn’t fully Vista compatible and really just doesn’t have a future. I think REALbasic is a realistic alternative to Visual Basic and I don’t think I’m alone. In fact, I got the impression while at REAL World that there are a lot of companies that would be extremely interested in migrating from VB6 to REALbasic, but it’s not at straightforward as they would like.
First, there is not a lot of information on how to go about moving your software from VB6 to REALbasic. Sure, REAL Software has their VB6 to RB whitepaper and their VB project converter. But the white paper does not go into much depth and the project converter is not well regarded in the community. In fact, there’s been much talk on the REALbasic forums about creating an all-new community project converter.
In my opinion a converter is probably not a realistic goal. Sure, some simple code could be converted, but not the complicated stuff. And who really needs help with the simply stuff, anyway? I think that a migration analyzer would be more useful, perhaps like MoMA for .NET to Mono migration. An analyzer scans your projects and gives you a report of areas that you need to focus on while migrating your code.
In most cases, I think REALbasic is a much better choice for VB6 developers than .NET is. REALbasic is more powerful than VB, but not nearly as complex as .NET. RB has a fully object-oriented language, many more controls than VB and is currently supported by an excellent company. And of course, it is cross-platform, which is not insignificant.
The biggest areas where REALbasic falls down when compared to VB are:
- 3rd party controls. REALbasic cannot use all the ActiveX and COM controls that VB can. And there are fewer REALbasic 3rd party developers making controls.
- REALbasic cannot create DLLs or COM components
- Reporting solutions are few and far between
Still, I think it makes sense for more VB6 shops and developers to evaluate REALbasic to see if it makes sense for them to use. In order to help with this, I am pleased to announce that LogicalVue Software is now offering a new service: VB to REALbasic Migration Analysis
Follow the link for full details, but to briefly summarize: We will review your VB software and provide you with a report of how good of a candidate it is for migration to REALbasic. This report will describe the level of effort, areas to focus on and provide general guidance. And if you like, we can also provide estimates for helping you do the actual migration.
5 Responses to “Migrating From Visual Basic to REALbasic”
Unfortunately I believe that your last point about REALbasic not supporting ActiveX or COM would be a show stopper for the majority of VB6 shops. When was the last time you saw a VB6 program that didn’t use some 3rd-party ActiveX control or COM?
On an unrelated note, I feel REALbasic is good choice for developers who want to explore Mac OS X development. Before they move on to learn Objective-C and Cocoa.
Hello, Edward:
RB does support using some ActiveX and COM components, but certainly not everything that VB does. I agree, it could be a potential showstopper for switching, but it might be possible that RB doesn’t need to use the VB control or there’s another way to go about it.
Anyway, that’s what the analysis is for: look before you leap.
+1 for “REALbasic cannot create DLLs or COM components”
One area that I see REALbasic as a potential use is to create Office add-ins. Dealing with Office 2000 compatibility (unsupported by MS) and Primary Interop Assemblies is an absolute pain, so I’ve stuck with VB6.
But as you said, they don’t currently offer a way to create DLL’s. That’s too bad because there are a lot of people creating COM add-ins for Excel and Outlook, and to a lesser extent Word and PowerPoint. Having a non-.NET option with continued support would be a real boon.
Nick:
I don’t know why REALbasic doesn’t have the ability to create DLLs, but I would suspect it is because they are platform specific. Anyway, it looks like there is an item in the REAL Software feedback system regarding this (and it has 72 requests):
http://support.realsoftware.com/feedback/oswhlxub
The reasons for not being able to make shared libraries are actually technical more than philosophical — it’s something we’re working towards, but it takes a lot of work to accomplish (better linker support, PIC, not to mention syntax). It’s one of the most requested feature requests in the system, so don’t be too shocked if you see it pop up some day (I know I certainly want it!).
As for your point about COM, that really is a killer. Without true COM support, VB6 projects are pretty hard to get into REALbasic without a lot more re-working. But then again, re-working that code is in the best interests of the programmer since COM isn’t a cross-platform solution.