[mono-vb] VB6 and the future cont

Wed Aug 23 20:47:56 EDT 2006

Hi Rob,

VB6 syntax is somewhat easy to compile into a .NET assembly, the
really trick part is that VB is too tied with COM, so it isn't always
possible to guarantee things will work.

I've written lots of code in VB6 and know how hard it is to make it
work without third-party controls and some custom C++/ATL components,
and both would pose real problems to compile and to run outside
Windows and even on .NET.

Mono doesn't support COM, yet, and will support it only in Windows,
but that may not stop you as maybe what you really want is just to
compile then with a vbnc-derivative and run them in plain MS
.NET/Windows.

Even so I believe that the old components will tie things down: for
instance, the current COM-Interop infrastructure may not be
appropriate for the task, as you already pointed some limitations it
imposes. Also dealing with .frm files, are surely to  bring some hard
to deal problems, as they don't map very well to SWF (and even less
with WPF/Avalon).

In other words, reversing some MS decisions to support managed VB6
apps, may mean to duplicate lots of .NET functionality to match more
properly what VBRUN6 and lots of standard and third-party OCXs
present.

For me, all the thousands of lines of VB6 code I wrote have been in
the care of other hands for the last 5 years, and since I've started
all new projects natively in Mono/.NET using C# and some in Java, so I
really doesn't feel the pressing need for a VB6 compiler, but I
sympathize with you, as my first attempt to migrate those hundreds of
VB6 classes and/or forms to VB.NET with the VS.NET wizard,
5-and-a-half years ago, generated something I could only call garbage.

Good luck,

On 8/23/06, Rob Conley <robertsconley at gmail.com> wrote:
> 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
>
>
>
>
>
>
> _______________________________________________
> Mono-vb mailing list
> Mono-vb at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-vb
>
>
>

-- 
Rafael "Monoman" Teixeira
---------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." George Bernard Shaw