There are limits to what could be done without breaking a lot of things people expect from VB6 now.
Anything that requires a new runtime will become a disaster for many. People have come to rely on a stable VB6 runtime being preinstalled as part of Windows. That precludes any changes to the set of instrinsic controls, native I/O, and other built in classes and functions.
What could be done includes things like an updated IDE, a new C2.EXE aware of newer CPUs to generate more optimal code, more OCXs containing Unicode as well as ANSI controls, and new OCXs and DLLs that follow the shift from 1998 to now. In many cases all that is needed for the latter are some wrapper-OCXs or even just some typelibs for things already implemented in Windows... and then some more VB-friendly documentation. The main "shifts" I'm referring to include less need for ANSI support, more need for Unicode including UTF-8, prevalence of HTTP and web services, and things like that.
Most of that could be done piecemeal, i.e. they might leave the IDE alone except to add a few compiler options to be passed through to C2 - if even that. Or they might just ship a "libraries add-on pack" with those new OCXs, DLLs, and typelibs.
Any or all of that could be part of a new Service Pack.
More radical changes that actually resulted in a real VB7 (not VFred7) would mean the runtime deployment requirement returns. I don't really care for that unless it made things that I need possible, and most of what I want or need could be accomplished through that "service pack" approach I already described.
In a UAC/least-privilege world being able to package VB6 programs as "portable apps" using reg-free COM has been important. With a "new VB6" we would lose that because of the new runtime requirement... unless they found a way to make the runtime libraries portable as well.
Hmm...
I might have to take some of that back.
With a new IDE/compiler and C2.EXE pass 2 I suppose they could add to native I/O syntax and even add new Unicode pseudo-intrinsic controls by compiling them as calls into a statically-linked extender library. Then the existing Earth Standard VB6 runtime that is preinstalled in Windows could still be used.
This would bloat compiled programs, but how much depends on how many things they put into the extender library. I suppose that could be an optional DLL though instead.
But that's still a minor update, not a "new VB6" at all. Call it "VB6.1" maybe?
by Dilettante
