Confirmed: Microsoft Says It Will Open Source VB 6 205
msmoriarty writes "Microsoft told a group of MVPs today at Tech-Ed that it plans to take Visual Basic 6 open source and will release the source code on CodePlex. A source at the event said that Microsoft is planning to release only the VB6 language on codeplex – not Visual Studio or related tools." Update: 05/20 02:24 GMT by T : Alas, too good to be true. msmoriarty writes with an apologetic retraction: "We got it wrong — Microsoft denied and went back to our source and they pulled confirmation. Our apologies."
The Product Management for VS says it's not true (Score:5, Informative)
http://twitter.com/#!/dseven/status/71352709785198592 [twitter.com]
@dseven The rumors of VB6 going open source are simply not true. #msteched #vb6rumor #vb6
http://twitter.com/#!/dseven/status/71359684904366081 [twitter.com]
@dseven @beckynagel I'm the Director of Product Management for Visual Studio Tools & Languages. There's no more solid source than me. Its not true.
Re:And we care why? (Score:4, Informative)
Umm, VS2008 uses the old engine. VS2010 use the new engine, basically a true-to-form C++ front-end repurposed for online parsing.
That's what I meant.
VS2008 one was really bad. When it came to Boost, it wouldn't take long for it to choke and die completely, esp. if you used something like Boost Lambda. VS2010 handled everything I've thrown at it (heck, it can process polymorphic Boost lambdas!). And it feels plenty fast to me, once it's done parsing headers.
Re:And no... (Score:4, Informative)
No, it doesn't.
VB6 has an _option_ to compile to p-code interpreted executables, which is not switched on by default.
Native binaries produced by VB6 _do_ have a lot of dependencies on the VB runtimes, because it uses them for a lot of it's internal implementation, like bounds checks on primitive types, it's String type, it's array type (which is not a raw array like C but an array class), but they are definitely native binaries. Many of these runtime checks contribute to the perception that VB6 is slow - you can turn a lot of them off in the compiler options. I think you might even be able to remove it's dependency on the runtimes, but that's really a bit pointless for what is designed to be a rapid prototyping / development system - it would be the equivalent of removing all the Python runtimes and wondering why your pace of development ground to a halt.
The main thing that makes people think VB6 is slow is they build large strings by concatenating them - because the VB6 String is an immutable BSTR, this means that every time you append a character, it copies the whole string. Unlike Java, it lacked a StringBuilder class in the base runtimes, and you had to roll your own using memcopy() APIs.
People think VB6 was terrible because it would let you get away with stupid crap. Couple that to it's relatively shallow learning curve and you got a lot of low-quality but otherwise functional programs written by people with less than stellar programming ability, which then go on to cause massive maintenance headaches for people who program professionally.
One of the ancestor posters was right on the money though - it was and remains a way of knocking out something functional very quickly. If you wanted to write something a little more complex in it, you had to be a real hard-ass with yourself, because VB would give you a lot of rope to hang yourself with. But with discipline, and sometimes some advanced tricks to work around it's limitations, you could write high quality, functional software, very quickly compared to C++.
My VB6 skills are kind of my pension plan... it really is the modern COBOL. I see so many job opportunities now that are thinly veiled "VB6 maintenance programmer" roles.