Rosyln for VB6 :)

Topics: General, VB Language Design
May 19, 2014 at 11:29 PM
I understand the pressures to push all of us into the .NET world, and likely that is a prime motivator to not just open-source the VB6 compiler engine.

However, with Rosyln would it be possible to create a compiler for VB6 that would compile to .NET IL? Could we just move the current .NET VB compiler in Roslyn backwards to VB6 standards, thereby moving all of the VB6 code out there to a modern code base? It would bring another decade of life to that code and allow it to integrate with other modern code easier.

Perhaps I am being naïve at the immensity of the challenge, but I have a hard time believing it would not be worth it. That would be a huge influx of code to the .NET platform.
May 19, 2014 at 11:34 PM
Doesn't VB6 generate native code and don't VB6 programs use native (ActiveX) components?

Even if you could compile your VB6 program to IL, you'd need to do the same to all used components (sometimes third party).
May 19, 2014 at 11:49 PM
ActiveX is essentially COM, and you can use COM objects in .NET: http://support.microsoft.com/kb/315847/en-us.
For third party libraries, that would be an efficient solution if they were not also interested in having an IL based version of their codebase.
Jun 11, 2014 at 2:04 PM
What about a 'Classic' compatibility mode for VB.NET that adds some VB Classic (VB6/VBA) language compatibility, without changing the compiler, development environment or compilation target of VB.NET?

Some Option Classic On language features might be:
  • Implicit Modules (Subs and Functions not nested in a Module are placed in an implicit Module with the same name as the file)
  • Variant as a synonym for Object
  • An interpretation for Set allowing default properties to be used in some places
  • Convention-based event handlers installation (without the 'Handles' clause)
  • Subroutine calls without parentheses
  • Option Base and fixed length string support
  • Additional warning information for code likely to have changed semantics
The goal of Option Classic On would be to allow safe compilation of a larger subset of VB Classic code using the new VB.NET compiler. If this were possible, one might imagine an easy transformation that converts such Option Classic On code to conforming VB.NET code.

This would not nearly address all issues raised by those asking for a return of VB6, but maybe it could give another tranche of the VB6 codebases a migration path to the future.
Perhaps it could bring some of the VB6 discussion into the realm of 'language features', with some community project to improve compatibility. Concerns like simplicity and performance of the IDE, are orthogonal, and should be treated as such.
Jun 11, 2014 at 5:32 PM
govert wrote:
Some Option Classic On language features might be:
  • Implicit Modules (Subs and Functions not nested in a Module are placed in an implicit Module with the same name as the file)
  • Variant as a synonym for Object
Actually, what I'd like to see, whether in Classic mode or not, would be distinct types for "variant" and "reference to System.Object" where both would be stored as references of type System.Object, but e.g.
System.Object o1 = new System.Drawing.Point(3,5), o2 = o1;
variant v1 = o1,v2 = o1;
variables o1 and o2 would hold references to the same instance of System.Drawing.Point, while v1 and v2 would hold references to different instances. At present, even in Option Strict On mode, o1 and o2 would hold references to different instances of System.Object, a behavior which I would regard as bizarre even in Option Strict Off mode, and horrid in Option Strict On mode [I find it hard to believe that any Option Strict On program would break if the behavior were eliminated, unless the program was deliberately designed to do so].
  • Option Base and fixed length string support
Fixed-length strings, like C's fixed arrays, could not be accessed efficiently without unsafe code, since there is no provision in CIL to index items within a struct.
The goal of Option Classic On would be to allow safe compilation of a larger subset of VB Classic code using the new VB.NET compiler. If this were possible, one might imagine an easy transformation that converts such Option Classic On code to conforming VB.NET code.
Such a thing would have been great ten years ago; I'm not sure how much VB6 code there is which would be worth porting but hasn't been ported yet.
This would not nearly address all issues raised by those asking for a return of VB6, but maybe it could give another tranche of the VB6 codebases a migration path to the future.
A somewhat broader issue would be whether it would make sense to allow certain unfortunate design decisions in VB.NET and C# to be revisited by allowing code to request compilation with different dialects. possibly with options to enable certain warnings in cases where code would be legal in two different dialects but have different meanings in each. Such warnings should be enabled briefly when bringing code into the system, but could be disabled once it was confirmed that anything whose behavior would vary with dialect was in fact correctly written for the dialect selected.

For example, at present if there exists a method with an overload that accepts Single and one that accepts Double, and none that accept any other type, passing integer value 16777217 will cause both VB.NET and C# to decide that the overload which takes Single (and cannot take the given value without rounding it to 16777216.0f) is unambiguously better than the one taking Double (which could accept the value without rounding). Changing that behavior would potentially break compatibility with existing code which [for whatever reason] relies upon it, but allowing implicit lossy conversions to Single and Double in those cases--and only those cases--where the intended destination type was unambiguous, would IMHO improve the language.
Jun 11, 2014 at 10:28 PM
Edited Jun 11, 2014 at 10:30 PM
I'm not sure how much VB6 code there is which would be worth porting but hasn't been ported yet.
My own interest is actually VBA code in Excel, of which there is a lot with a lot still being written in the coming years. But the VB6 supporters also continue to be very vocal - witness the response on the Visual Studio Uservoice to the recently (again) declined suggestion to bring back VB6 support.
Implementing an improved VB6/VBA compatible Option Classic On on the new Roslyn Visual Basic compiler would not just be for one-time conversion, but to enlarge the VB6/VBA language fragment that can be compiled easily under both VBA and current VB.NET dialects.

This might very well be a separate branch of the compiler, unrelated to any official support, of course. But my suggestion is to define a set of VB.NET language features that are specifically aimed at VB Classic compatibility scenarios.

Regarding your broader issue of supporting language dialects - Visual Basic already sets the precedent of having a fair number of 'dialect' switches with, Option Explicit / Strict / Infer etc. While I have not looked, one would presume that the new compiler would make it a bit easier to understand and prototype further such dialect options (compared to a language like C# which has historically been very careful to avoid such fragmentation).
Jun 12, 2014 at 5:11 AM
govert wrote:
Regarding your broader issue of supporting language dialects - Visual Basic already sets the precedent of having a fair number of 'dialect' switches with, Option Explicit / Strict / Infer etc. While I have not looked, one would presume that the new compiler would make it a bit easier to understand and prototype further such dialect options (compared to a language like C# which has historically been very careful to avoid such fragmentation).
Really, the only one of those I'd regard as useful in most cases is Option Infer; the Option Strict Off dialect might be vaguely useful for porting, but the semantics are sufficiently bizarre and differ from those of VB6 in so many corner cases that I can't see much point. If Variant had been a type which mapped to System.Object but allowed dynamic binding, that would have been a useful feature even in Option Strict On mode.

With regard to dialect, I was thinking more along the lines of allowing context-sensitive overload resolution. Given an expression like:
    double d = f1/10 + f2;
it's plausible that a programmer might want the compiler to compute the value of f1/10.0f, rounded to the nearest float, add f2 and round to the nearest float, and then convert to double. It's plausible that the programmer would prefer that the division and addition be done as accurately as possible (and the fact that the conversion to double didn't happen until the end was accidental. It's plausible that the programmer wants the fastest calculation that would yield results at least as accurate as float could be expected to be (perhaps evaluating the expression as something like double d = f1 * .1 + f2;, perhaps jinxing the result of the multiplication so that in cases where the original float is a multiple of ten, the result will end up being correctly rounded). All three kinds of evaluation can be useful; rather than having language designers argue about what kind of semantics such an expression should have, it would be more helpful to provide a means by which programmers could request whichever form was more useful in each situation.
Aug 13, 2014 at 9:04 AM
Edited Aug 13, 2014 at 9:16 AM
Such a thing would have been great ten years ago; I'm not sure how much VB6 code there is which would be worth porting but hasn't been ported yet.
It would have. But it would still be useful now. Gartner research says there are still 14 billion lines of VB6 programming in use.

It is interesting to to see that the dotNet Native compiler does not require the framework on the target machine but instead compiles using the Cplusplus compiler (just like the VB6 programming language has used since 1998) and has a small runtime (mrt100_app.dll), just like VB6 has a small runtime (MSVBVM60.dll).

`
VB6 supporters also continue to be very vocal - witness the response on the Visual Studio Uservoice to the recently (again) declined suggestion to bring back VB6 support.
Yes Microsoft have again declined the call to update the VB6 programming language. But it is still supported. Microsoft have recently confirmed that VB6 programming will be supported until 'at least' 2024. It runs fine on Windows 7 and 8.x

A bigger issue is the way Microsoft abandon developers. At least with dotNet we are seeing some move towards open sourcing (with Roslyn). What will happen when Microsoft abandons dotNet ? The same thing that happened with SilverLight and XNA ?

Microsoft should commit to open sourcing all development tools they abandon.
And Satya Nadella should reply to the open letter calling for VB6 - The Visual Basic programming language - to be open sourced.
Dec 1, 2014 at 2:04 AM
VB6 programming is fine on the Windows 10 technical preview. The VB6 IDE installs and VB6 apps run OK.

And VBA programming continues in Office.
Dec 1, 2014 at 4:22 PM
VB6_Programming wrote:
VB6 programming is fine on the Windows 10 technical preview. The VB6 IDE installs and VB6 apps run OK.
I doubt that this will change anytime soon, just given the large quantity of VB applications that exist. I also believe that if MS releases the VB6 runtime with Windows 10 that they are effectively resetting the support date for another 5 years.
And VBA programming continues in Office.
This is the one thing that has really concerned me. I fully understand that Microsoft couldn't yoink VBA support from Office nor would I want them to, but in all this time there has not been a suitable replacement for it either. VSTA/VSTO don't seem to hit the mark primarily because they're more involved and require additional licensing. Office already hosts the CLR for both VSTA/VSTO, why not include the Visual Studio shell and allow recording macros in C# and VB.NET as well, perhaps with pluggable support for other languages? What's worse is that with 64-bit Office the VBA language has further diverged.

As for continuing support for VB5/6, as someone who maintains a relatively large and complex code base that spans VB6 and C# 4.x I couldn't hope for a faster death to the older language. I dread anytime I find that I have to change code in the VB6-side of the project because I know that it will require significantly more work than it should. We continue to migrate VB6 ActiveX libs over to C# as time and resources permit but it's always been tricky and the support for exposing ActiveX controls from .NET has always been lackluster even with the Interop Forms toolkit.

Just my opinion. I can understand the disdain among the VB6 devs given the abrupt change in direction of their language and the need to go through yet another learning curve in order to move forward. I know plenty of other devs who just prefer the VB6 or VBA languages. Perhaps a managed compiler supporting the VB6 dialect could bridge that gap but I have a feeling that it would have a limited appeal given how tightly intertwined the IDE and debugger is to the current compilation process.
Dec 1, 2014 at 4:43 PM
I think Microsoft should opensource the VB6 runtime and compiler. So that VB6 die-hards can maintain an update it. Microsoft then can concentrate on the maintaining the more "up to date" languages.
Dec 1, 2014 at 5:24 PM
AdamSpeight2008 wrote:
I think Microsoft should opensource the VB6 runtime and compiler. So that VB6 die-hards can maintain an update it. Microsoft then can concentrate on the maintaining the more "up to date" languages.
Even if MS could do that, and a seriously doubt that they could even if they wanted to due to licensed IP and the sheer manpower that would be associated with doing so, I think that would represent a massive undertaking. VB5/6 did not have a separate compiler and did not follow the same compilation/debugging process that most languages follow. The IDE would shell out to a heavily-modified VC++ compiler when producing final binaries, but that was not used for debugging at all. Rather it would resort to a form of on-demand interpretation I think using p-code as an in-memory intermediary. This is why it was possible for stuff like syntax errors to not be caught immediately when running from within the debugger, and the entire debugging experience to be incredibly fragile if you called out to Win32 API to attempt stuff like window subclassing or multithreading. I think that the amount of effort required to maintain the environment let alone expand upon it between the multiple compiler/interpreters would be far from worth the effort.

To me it seems that MS just wants pre-.NET VB and it's ilk, including VBA, to die.