What if there was a NEW vb6

[Schmidt]

You think VB6 holds some special place in the decades of computer implementations?

FWIW, I surely do...

The platform-OS we use most, to *do-real-work* - (quite efficiently today, in uncounted
Offices, mostly using PC- or Notebook-Hardware), is based on some version of MS-Windows -
(there's a few exceptions, e.g. Designers and other creative folks always preferring their
Macs - but I think the percentage over-all - for "decent Desktop-work" is about 90%-Windows).

Since the dawn of "truly affordable PCs for every Office-clerk" (1990 or so), the "LOB-Apps"
as we call them these days, were now much easier to develop as well - now all following an
easier to manage Message- and Event-driven Paradigm, allowing User-Interaction over
"Windowed-InputScreens" and a "Set of Standard-Controls" + a graphics-abstraction-layer (GDI)
which (beside other things) made e.g. "direct Handling of Printer-Drivers" unnecessary .

Another boost for this paradigm came, when Win95 was entering the stage -
accompanied by the serious introducion of COM, which was now used not only at the
OS-Level, but more importantly also in the new MS-Office-Apps which were now all based
on a User-accessible (COM-)Object-Model, which was programmable not only by the new
introduced VBA-language from within these Office-Apps, but also by using a dedicated
standalone Environment (VB4-32) - which made glueing of COM-Objects (not only through
"Office-Automation", but also when using 3rd-party COM-Dlls and OCXes) extremely easy.

VBA and VB4/5/6 are the main-reason for the countless LOB-Apps (and "LOB-sidewards"
supporting Tools and MS-Office-Addins) which ensured the prevailing dominance of Windows-
OSes over the years in Offices worldwide.

So, the above was 1995 - and in 2015 absolutely *nothing* has changed with regards to
that paradigm (event-driven, windowed Apps, which still rely on flat C-style API-layers,
accompanied by COM-compatible implementations of said APIs - the new Win8/Win10
WinRT-runtime is native (as in "unmanaged") accessible by normal C++ as usual with COM -
and to reduce typing-efforts in C++, the new WinRT-COM-classes are (avoiding ATL) now
addressable also with the C++/CX extensions, but it's still all COM (still ref-counted on top
of IUnknown).

So, with that in mind - VB6 is still (always was) much more near that always used
(by MS in its bread and butter apps) paradigm than .NET.

Note, that I'm not trying to put .NET down in any way - I'm just saying what I think
makes the last version of: "COM-made easy" (aka VB6) stand out - and a valuable tool
for Desktop-Apps even these days.

VBClassic/VBA and COM made Windows what it is today (ensuring its dominance in
Offices worldwide - also against the attempts to use "Linux-Desktops in the Office") -
and there's (technically) no reason, not to make VBClassic a decent companion to
the new C++/CX again (with a fully supported WinRT-COM-lib, native compiling by
using an adapted C++ emitter and -linker, derived from the latest MS-C++ version,
as VB6 was doing with C2.exe, which at that time was derived from MS-VC++ 6.0).

Again - note that I'm not "whining to give us back VBClassic" - I'm quite sure MS will
not do so - I'm just saying that technically the CodeLine-Diffs to produce a modern,
native compiling "WinRT=COM made easy" environment again (based on the VB6-sources,
and what they already have with VBA-64Bit), would be *much* less - than any efforts
to compile .NET-MSIL natively (over cloud-services).

If what I tried to explain above doesn't make VB6/VBA stand out among Programming-
environments, then you're ignoring something in "Lalalala, I have my ears covered"-fashion,
I guess.

Olaf