New Crowd Funded Effort to Update VB6

[Michael Elliott]

New crowd funded effort to update VB6 here: https://www.indiegogo.com/projects/a-replacement-to-visual-basic-6-ide-and-compiler

[Mayayana]

| New crowd funded effort to update VB6 here:
https://www.indiegogo.com/projects/a-replacement-to-visual-basic-6-ide-and-compiler

I don't see any details about the project. People
are expected to donate simply to a general idea?
The only shortcoming of VB6 that I'm aware of
is 64-bit support. Why does it need a new IDE?

[Michael Elliott]

Post by Mayayana
The only shortcoming of VB6 that I'm aware of

is 64-bit support.

This will be a 64-bit IDE and create 64-bit executables.

[Nobody in particular]

Post by Michael Elliott
New crowd funded effort to update VB6 here: https://www.indiegogo.com/projects/a-replacement-to-visual-basic-6-ide-and-compiler

A few of these have been started over the last 20 some odd years, but inevitably they hit some
snag and decide to go in a different direction or simply decide to do something different and
then tell everyone that they really ought to be rewriting their VB code from scratch anyway.
A truly cross-platform 32/64 bit Visual Basic Classic would be really nice, but I'll believe
it when I see it. Well, there's always Lazarus, the 32/64 bit cross-platform Delphi 4 clone.

[ralph]

On Mon, 4 May 2015 18:17:34 -0700, "Nobody in particular"

Post by Nobody in particular

Post by Michael Elliott
New crowd funded effort to update VB6 here: https://www.indiegogo.com/projects/a-replacement-to-visual-basic-6-ide-and-compiler

A few of these have been started over the last 20 some odd years, but inevitably they hit some
snag and decide to go in a different direction or simply decide to do something different and
then tell everyone that they really ought to be rewriting their VB code from scratch anyway.
A truly cross-platform 32/64 bit Visual Basic Classic would be really nice, but I'll believe
it when I see it. Well, there's always Lazarus, the 32/64 bit cross-platform Delphi 4 clone.

Thirteen years ago, I was part of a group, very well funded backed by
some major players, that attempted to license the VBIDE* core. We were
met with initial stalls until running into a solid brick wall. It was
more than MS had no interest in allowing "VB" to continue at that
time, the basic problem was the VBIDE is made-up of many proprietary
components - and not the least of them the "VB Runtime Engine". We
also were faced with an internal MS battle between Office and
Development - Office wanted ownership of "VB". Probably
over-simplified but my impression was Office would let nothing go and
Development had no desire to chance competing against their own
product.

Since licensing was out we investigated re-writing essentially from
scratch - however, everything we came up with MS made it very clear
they would consider a "copy-right violation" and would take steps to
throttle it. Some of the objections were kind of thin - like "look &
feel", others more substantial in terms of specific code and
functional elements. How much they could have done, and whether we
might have won in the end didn't mattered - none of our backers wanted
to go there.

While, I have no idea what other groups may have run into, I suspect
it has been pretty much the same. MS is a Goliath and frankly Davids
only win in the movies. <g>

Part of the frustration, for me, is MS has everything in place to
deliver a 32/64 bit VB with multiple enhancements practically
overnight, any time they would choose to do so. Most of the code has
already been prototyped. There were many features that were planned to
be introduced in VB6 - like ability to do implementation inheritance;
building true code libraries; .Net inter-operability; improved
collection libraries; visual modeling / code generation; etc. - but
all work was stopped and it was shoved out the door - MS having
already decided to go with .Net.

[*VBIDE. I am using this term, because VB is far more than just a
language.]

[Nobody in particular]

Post by ralph
On Mon, 4 May 2015 18:17:34 -0700, "Nobody in particular"

Post by Nobody in particular

Post by Michael Elliott
New crowd funded effort to update VB6 here: https://www.indiegogo.com/projects/a-replacement-to-visual-basic-6-ide-and-compiler

A few of these have been started over the last 20 some odd years, but inevitably they hit some
snag and decide to go in a different direction or simply decide to do something different and
then tell everyone that they really ought to be rewriting their VB code from scratch anyway.
A truly cross-platform 32/64 bit Visual Basic Classic would be really nice, but I'll believe
it when I see it. Well, there's always Lazarus, the 32/64 bit cross-platform Delphi 4 clone.

Thirteen years ago, I was part of a group, very well funded backed by
some major players, that attempted to license the VBIDE* core. We were
met with initial stalls until running into a solid brick wall. It was
more than MS had no interest in allowing "VB" to continue at that
time, the basic problem was the VBIDE is made-up of many proprietary
components - and not the least of them the "VB Runtime Engine". We
also were faced with an internal MS battle between Office and
Development - Office wanted ownership of "VB". Probably
over-simplified but my impression was Office would let nothing go and
Development had no desire to chance competing against their own
product.
Since licensing was out we investigated re-writing essentially from
scratch - however, everything we came up with MS made it very clear
they would consider a "copy-right violation" and would take steps to
throttle it. Some of the objections were kind of thin - like "look &
feel", others more substantial in terms of specific code and
functional elements. How much they could have done, and whether we
might have won in the end didn't mattered - none of our backers wanted
to go there.
While, I have no idea what other groups may have run into, I suspect
it has been pretty much the same. MS is a Goliath and frankly Davids
only win in the movies. <g>
Part of the frustration, for me, is MS has everything in place to
deliver a 32/64 bit VB with multiple enhancements practically
overnight, any time they would choose to do so. Most of the code has
already been prototyped. There were many features that were planned to
be introduced in VB6 - like ability to do implementation inheritance;
building true code libraries; .Net inter-operability; improved
collection libraries; visual modeling / code generation; etc. - but
all work was stopped and it was shoved out the door - MS having
already decided to go with .Net.
[*VBIDE. I am using this term, because VB is far more than just a
language.]

So M$ was simply flat out LYING that everyone's code simply had to be
broken and rewritten completely from scratch in order to take advantage
of their new Java rip-off platform or even work at all in some future
Windows.NET. Big surprise there! I wonder if their legal beagles would
bark quite so loudly now. Unfortunately for us all, they probably would.

[Eduardo]

Post by ralph
MS made it very clear
they would consider a "copy-right violation" and would take steps to
throttle it.

I think that the new IDE (and everything else) must have the same
functionality basically, but not to be a copy of the original.

It would be something like OpenOffice: you can open a *doc document, and you
can also save it.
Projects are documents, I think they wouldn't have legal arguments if the
VB6 projects are opened, interpreted, and use to produce similar results as
their product did in the past (the exe, ocx or whatever).

And more if the IDE, compiler, Etc. is open source, they cannot stop it any
more.

[Gordon Levi]

Post by Eduardo

Post by ralph
MS made it very clear
they would consider a "copy-right violation" and would take steps to
throttle it.

I think that the new IDE (and everything else) must have the same
functionality basically, but not to be a copy of the original.
It would be something like OpenOffice: you can open a *doc document, and you
can also save it.
Projects are documents, I think they wouldn't have legal arguments if the
VB6 projects are opened, interpreted, and use to produce similar results as
their product did in the past (the exe, ocx or whatever).
And more if the IDE, compiler, Etc. is open source, they cannot stop it any
more.

Why not use an existing open source IDE like Netbeans
<https://netbeans.org/features/index.html>? It already supports
multiple languages and includes most of the code that the VB IDE would
require.

[Eduardo]

Post by Gordon Levi
Why not use an existing open source IDE like Netbeans
<https://netbeans.org/features/index.html>? It already supports
multiple languages and includes most of the code that the VB IDE would
require.

I think that the "VB Classic" IDE will be written in VB, so it would be
necessary to translate the code.

[GS]

With M$ Office 2010, VBA7 was introduced. If you write VBA projects in
the 32 bit version they work with the 32 bit office apps. If you write
VBA projects in the 64 bit version they work with 64 bit office apps.

The same IDE is used for both as far as I can tell, leaving only the
'compiler' the key difference between the two. I know VBA is
'interpreted', but it seems to me the ground work for moving to x64 is
done in terms of language and its IDE (called VB Editor or 'VBE' in M$
Office).

I've been duplicating my Excel based apps as stand-alone VB6 Windows
apps since M$ Office 2007 (v12) introduced the 'Ribbon' to replace
menus/toolbars. The main reason for doing this was to provide continued
support for clients not looking to go beyond M$O 2003 (v11), and those
moving away from M$ Office altogether.

It didn't seem to matter that my VBA apps persisted the same
menus/toolbars on their own Ribbon tab. The main point of contention
was the disorientation the new UI presented to users for daily use.
(IMO, the new UI is more productive!)

The Spread.ocx from Farpoint is what I use in my VB6 apps along with
3rd party commandbar controls. Unfortunately, they stopped development
on this component in favor of putting their focus on the .net version
for Windows Forms. I know the OCX works with VS2005 C# because they
provide samples for that, but I haven't seen anything beyond those
VS2005 samples.

It seems that .net has caused the demise of good ActiveX spreadsheet
controls. I suspect this is due to the fact that (as MikeD suggests)
there are things that can't be done with COM that .NET supports
natively via the 'Framework'. VBA7 supports using the Spread.ocx, but
behavior is very different on MS Office forms than when used on the VS
Ruby forms similar to the way some of the VBA intrinsic controls behave
differently. (I can't speak to M$ Office x64 because I haven't used it
yet!)

Ultimately, Classic 32 bit VB will die when x64 is the norm IMO. That's
not likely to happen during my lifetime and so no need for me to move
away from VB. I was looking at going with C++ so I didn't need to
replace my ActiveX components, but in the later versions of VS the only
way to do so is via MFC. VS6 C++ is still viable, though no x64
support.

Classic VB needs a revamp that allows x64 development AND supports
backward compatibility for using COM components. M$ just has to 'want'
to go there for this to happen...

[Eduardo]

Post by GS
It seems that .net has caused the demise of good ActiveX spreadsheet
controls. I suspect this is due to the fact that (as MikeD suggests) there
are things that can't be done with COM that .NET supports natively via the
'Framework'.

I think that strictly, it's not that "they can't be done", but they can't be
done because nobody made those tools or components for VB Classic.

But if VB is reborn, all those tools start to appear (as long as there is a
market in the case of enterprise products or enough interest in the case of
free-open source projects)

PS: we are following here some discussion from the group
microsoft.public.vb.general.discussion, of the thread ".Net-free VB6 Forum
sites?"