If a job needs doing

I gather there's a petition going round to try to persuade Microsoft to
produce "VB.COM" - or some new version of VB that's backwards compatible,
out of the backlash from them not providing migration paths from VB6 to
VB.NET / VB2005.
Could we not discuss, why this can only be done by Microsoft. This sort of
thing would be easy for gcc. It could at least be possible to *attempt* an
open-source project that produces MSIL from VB6 code. While I'm not
suggesting there aren't specific reasons why it couldn't succeed - at least
to me, these certainly could do with being made clear, as it's perfectly
legal to produce (and even sell) tools that make use of other Microsoft
technologies so why not the .NET framework.... someone could simply split
the job horizontally (in terms of parser, lexer, optimizer, translator, etc)
and vertically (in terms of disk access, network functions, kernel API, etc)
and then split each square into a pyramid and fill in each brick with a
specification of interfaces and then assign it to a particular programmer.
In true chicken and egg style the program could be written in VB6.

"Bonj" <a@b.com> wrote in message
news:ucQbYe1SFHA.2432@TK2MSFTNGP12.phx.gbl
> I gather there's a petition going round to try to persuade Microsoft
> to produce "VB.COM" - or some new version of VB that's backwards
> compatible, out of the backlash from them not providing migration
> paths from VB6 to VB.NET / VB2005.

http://classicvb.org/petition/

> Could we not discuss, why this can only be done by Microsoft. This
> sort of thing would be easy for gcc. It could at least be possible to
> *attempt* an open-source project that produces MSIL from VB6 code.

I would wager that there are copyrights and/or other legal restrictions on
the VB6 syntax, especially with regard to producing a competing product.
Even if there aren't and a true VB.Net were produced would it be supported?
The ability to produce MSIL is not the goal; having a stable (not stagnant)
language that is supported is.

--
Reply to the group so all can participate
VB.Net: "Fool me once..."

Bonj,

What you are suggesting sounds fairly reasonable. However, IMHO kind of
misses the point and is backwards from the core problem.
The concept of the .NET Framework is anti-COM. This is MS' attempt to solve
DLL Hell. But they seem to have created .NET Framework Hell. Framework V1.1
apps might not work on V1.0 and vice-versa. Plus, if you or your clients
have installed interim patches, then you end up with a mess where your app
might only work correctly in your development evironment. Not to mention
that for reliable compilation, you need different development IDE's that are
version specific. But I digress.

VB6 is about easily creating and maintaining Native Code COM applications.
.NET is about replacing and eliminating COM altogether. Creating MSIL from
VB6 source to target the .NET Framework is "relatively" simple. However,
this isn't the desired goal. What I would like to be able to do is create
and maintain COMponents in the new development suite. But this is the sort
of thing that MS wants to prevent as they want COM to die.

In general, you just cannot create reliable COMponents in .NET unless you
use C++. Ok, yes you can, but with severe limitations. Just try to create an
OCX that can be used in VB6, VBA, or other legacy environments. If you go
over everything that is required to make a simple but reliable COMponent in
"FRED", you will find it is only slightly less complicated than just using
C++, and probably an effort in futility.

If MS' new development paradigm allowed me to maintain my existing code in
its current form, and even create new COMponents that were backwards
compatible, I would probably leave VB6 behind. This would allow me to move
forward and slowly re-engineer my existing applications over a long period
of time. Eventually, there might not be any trace of the original VB6 code
and it might be purely .NET. But this isn't the option they are providing.
Instead, I would need to rewrite hundreds of thousands of lines of code and
completely convert the applications. This just isn't going to happen. So
from the looks of it, I will always have a copy of VB6 around. Well, until
the OS release where it is no longer supported at all. Then I'm screwed.

Is this all just "backwards" thinking? Well, yeah, but that it is the
reality of business. Try as you might, not matter what new technology comes
along, COM based applications will be around for decades to come.

Just my 2c.

Gerald

Cheers both for the good points, ... both pretty much seem to be suggesting
the same thing - that it's not the virtue of having the tool that's the
goal, but to have a supported product.
My only issue with that is, 'support' means because you've paid for the
product you have the right to expect someone else (i.e. Microsoft) to fix
bugs that are found by releasing service packs; and while I agree that
(especially since you pay for VB6) the fulfillment of this expectation is an
important thing, I question whether it is actually better than the open
source model where bugs are fixed by the community, and yes - ok, you don't
get the *guarantee* that a specific problem will be fixed as may be
necessary for your product's release or project undertaking or whatever,
what you've got to consider aswell as the guarentee is the average
probability of bugs being fixed. If you consider how c++ has fared,
considering gcc vs. msvc compilers, one has people who get paid to fix bugs
and will get fired if they don't because they have people who have actually
paid for the product, the other has no such remittance to maintenance
programmers but no sales revenue either, but it has a wide range of people
who are proactively interested in fixing bugs themselves and they have the
inclination to do so because they know it's possible. While unfortunately
the former is in a lot of cases considered to be more suited to a
"business-critical" project, when you take a high-level comparison of
technical capabilities, I think they are somewhat similar, with gcc slightly
ahead in conformance, optimization, etc. but msvc ahead in terms of extra
features, but in any case they compete in a lot of the same ballparks - IOW,
if you consider (and engineer) your own product line at such a high level
aswell, enabling you to take advantages of the relative peaks and troughs of
individual ability patterns and bug-fixing trends, you don't suffer from the
lack of a 'support guarantee', and therefore what do you *actually* gain by
choosing to pay for a product rather than getting a free one?


"Bonj" <a@b.com> wrote in message
news:ucQbYe1SFHA.2432@TK2MSFTNGP12.phx.gbl...
>I gather there's a petition going round to try to persuade Microsoft to
>produce "VB.COM" - or some new version of VB that's backwards compatible,
>out of the backlash from them not providing migration paths from VB6 to
>VB.NET / VB2005.
> Could we not discuss, why this can only be done by Microsoft. This sort of
> thing would be easy for gcc. It could at least be possible to *attempt* an
> open-source project that produces MSIL from VB6 code. While I'm not
> suggesting there aren't specific reasons why it couldn't succeed - at
> least to me, these certainly could do with being made clear, as it's
> perfectly legal to produce (and even sell) tools that make use of other
> Microsoft technologies so why not the .NET framework.... someone could
> simply split the job horizontally (in terms of parser, lexer, optimizer,
> translator, etc) and vertically (in terms of disk access, network
> functions, kernel API, etc) and then split each square into a pyramid and
> fill in each brick with a specification of interfaces and then assign it
> to a particular programmer. In true chicken and egg style the program
> could be written in VB6.
>
>
>
>