[Mono-list] Good Mono Project

[Jonathan Pryor]

On Thu, 2005-03-17 at 21:25 +1300, Ralph Mason wrote:
> I was just reading 
> http://news.com.com/Microsoft+walks+VB+tight+rope/2100-1007_3-5620821.html?tag=nefd.lede 
> 
> 
> It seems to me that there is no reason that there can't be a VB6 
> compiler that would target the CLR.
> 
> For all you budding compiler writers out there, why not give this one a 
> crack.  It has a massive audience, and plenty of code to run.
> 
> Personally I never saw the need for VB.NET, you might as well use C#, 
> but vb before vb.net that was a different language, with it's own purpose.

HA-HA-HA-HA-HA-HA-HA-HA....

(...trying to catch breath...)

Implementing a VB compiler would be easy.  It's already been done, IIRC,
as Gnumeric has a VBA interpreter for Excel compatibility.

The problem is that a VB compiler is, at best, 1% of what the existing
VB6 user base would want.  The remaining 99% is *compatibility*.

VB6 users don't want to re-write their code -- if they did, they'd use
VB.NET.  They want their existing code to (1) continue to work (already
met -- just stick with VB6), and (2) have a future (not met, as VB6
won't get any future enhancements to work well with Avalon/Longhorn).

To understand the difficulty in this, you must realize what VB is.  VB
isn't a language, per se.  Rather, it's a scripting environment for COM
objects.  This makes it very useful, very fast to work with, and VERY
non-portable.  In order for existing VB6 code to work, you'd need to
ensure that every COM object it uses is on your desired platform.

This would include such things as Crystal Reports and other 3rd party
COM objects, which will likely *never* see native Linux support.

The only way to get real VB6 support is to use Wine, get Wine to the
point where it can run all those COM objects without change (which may
have already happened), and stay on x86/Linux.  This might not be too
bad, given the cost/performance of x86/Linux, but this isn't a portable
solution (PPC/Mac OS X or Linux is certainly out without an emulator).
Further, a Wine dependency would complicate Mono integration (see the
previous Wine-based System.Windows.Forms effort).

I'm not saying it can't be done -- it obviously can be.  I'm just
pointing out that this is A LOT of work; don't underestimate it.  A
Delphi-compatible compiler is trivial in comparison.  VB6 language
support is easy, the language semantics are easy, it's the class library
support (and implicit Win32 support) which will be hard, especially
since most of that "class library" consists of 3rd party components that
may not have a Linux equivalent.

 - Jon