Is there any reason VB6 couldn't be ported to .Net?

Question

I'm not talking about porting VB6 application to .Net (that's been talked about plenty here).

I just wondered, if you can do IronPython, IronRuby, Phalanger, H#, etc, is there any technical reason that would prevent creating VB6.Net?

I'd think there would be a LOT of money in it.

UPDATE Sorry for all the purists, I KNOW that VB.Net is 'better', but when you have hundreds of thousands of lines of code, that just isn't a good enough argument. Here is the Joel post which was part of the inspiration for this question.

Answer 1

Why would you bother when there is VB.NET and tools to aid in migration from VB6? That very fact negates your money argument. Of course it probably is technically possible however it would be a big task. The barriers aren't technical, they are financial and motivational.

Answer 2

Visual Basic 4, 5 and 6 were based on COM. COM defines a binary interface between components (ABI) and an object model (including memory management).

.NET also defines these things, but in a fundamentally different way (e.g. GC rather than reference counting).

Since VB6 is predicated on COM's way of doing things, there would be an underlying impedance mismatch with "pure .NET", like you see in C++/CLI where you have to handle .NET and native objects and types a little differently.

Remember you can use VB6 components from .NET and visa versa via COM interop, so a gradual change is possible.

Answer 3

I guess that it absolutely could be ported. If you think there’s money to be made in it (and you could well be right), get to work. ;-)

Off the to of my head, I can’t see a reason that prevents this, and I’ve worked with both VB6 and .NET for quite a while. On the other hand, I don’t see a lot of benefits from it. Integrating VB6 meaningfully with the rest of the framework may be quite hard; VB6 simply lacks a lot of features which make this harder than necessary. Porting VB6 applications to a .NET environment (by porting VB6 to .NET) has thus no tangible benefits. Furthermore, new .NET code can interface with existing VB6 code, and vice versa.

The only benefit would be to get a modern IDE, but this is a completely different matter from porting the language.

Answer 4

Technically I think it would be hard. And I don't think there'd be any demand for it.

People are investing money and time in tools to port VB6 code to .Net, but not in creating "VB6.Net". Customers need to get their VB6 code assets to a supported programming platform. Personally speaking, I would need a lot of convincing that a port of VB6 would be reliable and supported.

Instead the migration vendors work on things like run-time libraries. For example VBMigration.COM announced this month they're adding a wrapper for ADO.Net. This is a set of native .NET classes that behave exactly like their ADODB counterparts, but use ADO.Net behind the scenes. If you can make .Net emulate VB6 runtime behaviour like this, there's no need to port the VB6 language itself.

EDIT: I've just come across another idea: produce a clone of VB6 that supports multiple platforms, like RealBasic: Windows, Mac, Linux... There could be some demand for that. You'd still need to convince people you'd go on supporting the language though.

Answer 5

I listened to a DotNetRocks podcast with Paul Vick a couple of years ago. This is the guy who was on the VB6 team. Iirc, he was asked a similar question. His response was that it was simply too complicated because over the years of development VB6 (and previously vb5, 4, 3, 2, 1) code base has acquired a massive amount of cruft that would be hugely difficult to port to a completely new platform.

Answer 6

1/2 Yes and 1/2 No. A complete 100% workalike will be a fairly hard conversion as the assumptions of VB6 is built on COM. The assumptions of COM are not the same as .NET. Where you really run into problem will be emulating the VB6 IDE.

Far easier is to write a compiler that is text compatible with Vb6. The esstential trick to remember that you can write assemblies that can adapt specific VB6 features to .NET. For example a printer object, vb6 graphics object. File Access etc, etc. There is also the issue of the wonky Form format, and you will need a converter for the FRX file. You will still have behavior issues but in theory you can minimize this in the VB6 support libraries.

Nothing prevented Microsoft from doing this. It was the arrogance of the original .NET team that lead down the path where they had to "fix" VB6. Yes as a language VB.NET has many cool features over VB6. But then VB6 had many cool features over QuickBASIC. But with VB6 I can take QuickBASIC code and dump it into VB6 and have a reasonable chance of getting it working. Especially for modules with nothing but business logic. It is not the same going from VB6 to VB.NET. Most of the problems are caused by the change in integer from 16 bit to 32 bit.

The lose of even minimal backwards compatibility was and still remains a problem. As Ruby, Python and other languages were ported over to .NET the arbitrary nature of the choices the original VB.NET team was exposed.

The best solution at this point is probably a minimal approach. Now that we had several years experience with VB.NET the most problematical areas are well known.

Some off the top of my head

1) Introduce a OPTION INT BASE statement. By default integers will be 32-bit and longs be 64-bit. However if you use OPTION INT BASE 16. Then Integer will compile to a Int16 and Longs will Compile to a Int32. This will require also some modifications to Intellisense. So when it queries the meta the correct type for the base is reported in the tip. Understand that in the metadata everything is Int16s and Int32s.

2) Have robust printer, screen, and vb6 graphics helper assemblies. Microsoft has a 3/4 implementation of the Printer Object. The Vb6 Graphis object is buried in there and can be extracted with .NET reflector and used separately. But there is a lot of fit and finish work that needs to be done.

3) Have an option use the original VB6 Keywords use those helper assemblies.. The compiler will translate them into calls to the helper assembly.

There are other concerns in database access and other different areas. Much of this can be addressed by expanding the option and keywords that VB.NET.

Of course now there is a major divide in Microsoft Basic community. Expect a lot of static and complaints if these options are added. Probably if I was VB.NET manager I would fork the VB.NET compiler into a VB6.NET compiler to minimize this. It would depend on if these option would impact the current version of VB.NET.

You can read more on the issues involved here.