[mono-vb] VB6 and the future cont

[Rob Conley]

Sorry for that the last message got sent accidentally
----------
This paided off when we made the transition from VB3 to VB6. Along with the
upgrade to 32-bit Windows we took advantage of the object-oriented features
turn our application to using Model-View-Presentation to allow more
flexiability in adding features for specific customers. Because the core
langauge did not change between VB3 and VB6 our testing suite was very easy
to implement as a lot of older testing code just transfered right over.

http://martinfowler.com/eaaDev/PassiveScreen.html
http://martinfowler.com/eaaDev/PresentationModel.html

As a result we had a piece of software that was well designed for any future
changes in Visual Basic.

However with VB.NET Microsoft made this upgrade more like Rocky Mountain
BASIC to VB3 than VB3 to VB6. At first myself and my staff kinda of said
"Well if that what it take to get all the new stuff." We schelduled the
upgrade for later rather than sooner but planned on doing it.

Then F# came out of Microsoft Research, then RUBY.NET, then we learned more
about how .NET really compilied to IL, and how VB.NET and
Microsoft.VisualBasic.dll worked together. By the end of two years we
decided that Microsoft really blew it and with all the annoucement about
changes to the form engine for future versions of .NET (Avalon) we lost
confidence that Microsoft will maintain a stable langauge platform. I signed
the petition, exchanged emails with Microsoft Managers but they simpily
don't get it.

Examples I can give is that Integer compile to Int32 and Longs compile to
Int64. While trival on the surface when you have a lot of math and binary
routines it is important. Plus the history of BASIC is that Integer and Long
definition doesn't change unlike the C/C++ world. You will find this 90% of
the BASIC dialect out there even in those BASIC that spanned the old
8-bit/16-bit transition. In 8-bit Microsoft Basic a integer was 16-bit. More
serious is the lack of compatibility objects that emulate the graphic and
printing commands of VB6. Another is the fact you can't implement a COM
interface with properties unless all the parameters of the properties on the
COM interface are declared ByVal instead ByRef.

In addition to our main development trunk, I maintain a conversion project
that has been worked on sproadically since the first version VB.NET. So my
experience with the problems of vb6 to vb.net is not the result of a few
days of work. We haven't pushed further because converting tests to pinpoint
the difference has been daunting and we are not sure whether problems are
because of change in the test or in the code. The real killer is that
management realizes that .NET doesn't bring enough to the table to derail
our main development in order to get a .net version out.

There is a bunch of other vb6 developer who are similarily fustrated.
Anybody who used vb6 for a serious application for anything but a database
front end that uses crystal reports has been hammered by this.

I think that vbnc can be used as a basis for a .NET compilier that can
create valid assemblies and exes from vb6 code. I am not a compilier whiz
or I would plunge in myself. I can learn with some help. I want to let you
all know that this problem exist and the MONO vbnc could be the way out of
this mess for all vb6 developers. Granted I realize that we can't get the
vb6 IDE back with this but if we can just compile our .vbp project files
into a valid .NET assembly then we can plan for a rational conversion
upgrade.

Rob Conley
Plasma Automation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-vb/attachments/20060823/ecbfcc4c/attachment-0001.html