4 ms·

> the saga of Microsoft throwing people who had relied on Visual Basic 6 under the bus Even though the IDE isn't supported, Microsoft still supports VB6 applic

> the saga of Microsoft throwing people who had relied on Visual Basic 6 under the bus Even though the IDE isn't supported, Microsoft still supports VB6 applications, and will throughout the lifetime of Windows 10 [0]. As an ex VB6 developer, I find this crazy. Just goes to show how much legacy VB6 must still be out there. VB.NET got me to move to dot.NET, and then to C#. And I'm a better dev because of it. So you could say it fulfilled its role at least once. And let's not kid ourselves here, VB6 was always limited. E.g. subclassing was almost mandatory for advanced functionality, but would cause the debugger and program itself to crash when it hit a breakpoint. 64-bit compatibility was never going to happen, my understanding is the IDE includes some 16-bit programs which is why it's no longer supported. At some point, you've got to cut your losses. If anything, IMO, Microsoft's continued support of VB6 is sending the wrong message to managers and developers. [0] https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx

deleted 10y ago
[deleted]
catnaroek 10y ago
The real reason why Microsoft had to drop VB6 is because its object model was fundamentally incompatible with .NET. VB6 was a very thin wrapper around COM, after all. That C# happens to be technically superior to VB6 in most (but not all) respects just provided Microsoft with a convenient excuse for deflecting criticism. That being said, I don't mourn the loss of VB6. It was a truly horrible language, and the fact a whole generation of programmers preferred it over superior contemporary alternatives (e.g. Delphi) doesn't speak well of them. The only good thing about VB6 was its form editor, and that isn't even a language feature.
- int_19h 10y ago
  It wasn't even just COM, it was specifically OLE Automation. VB6 Variants were OLE VARIANTs. VB6 strings were BSTRs. VB6 arrays were SAFEARRAYs. Date, Decimal, Currency - you name it, it's all OLE. And this went both ways, too - e.g. the reason why BSTR is called BSTR is because, well, it's a BASIC STRING... And if you want to add two OLE variants in a C++ Win32 app, with exact same semantics as in VB6, you can (to this day!) do this via VarAdd: https://msdn.microsoft.com/en-us/library/windows/desktop/ms221574(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms2.... Ditto VarSub, VarCat etc. You can see that this family of functions is very VB-centric actually, because it has VarAdd and VarCat separately (corresponding to + and & in VB); it conflates binary and boolean operators just as VB did; and it has VarEqv and VarImp, corresponding to VB operators EQV and IMP. And yet, it lives in oleaut32.dll...
ptx 10y ago
> 64-bit compatibility was never going to happen, But it did, more or less. VBA and VB6 are essentially the same thing, and VBA 7 (still used in MS Office) added 64-bit support: https://msdn.microsoft.com/en-us/library/office/gg264421.aspx https://msdn.microsoft.com/en-us/library/office/gg264421.asp...
peteri 10y ago
Given the macro engine in Excel is VBA (basically VB6) I suspect VB6 support will be around for a VERY long time.

deleted 10y ago

[deleted]

catnaroek 10y ago

The real reason why Microsoft had to drop VB6 is because its object model was fundamentally incompatible with .NET. VB6 was a very thin wrapper around COM, after all. That C# happens to be technically superior to VB6 in most (but not all) respects just provided Microsoft with a convenient excuse for deflecting criticism. That being said, I don't mourn the loss of VB6. It was a truly horrible language, and the fact a whole generation of programmers preferred it over superior contemporary alternatives (e.g. Delphi) doesn't speak well of them. The only good thing about VB6 was its form editor, and that isn't even a language feature.

int_19h 10y ago
It wasn't even just COM, it was specifically OLE Automation. VB6 Variants were OLE VARIANTs. VB6 strings were BSTRs. VB6 arrays were SAFEARRAYs. Date, Decimal, Currency - you name it, it's all OLE. And this went both ways, too - e.g. the reason why BSTR is called BSTR is because, well, it's a BASIC STRING... And if you want to add two OLE variants in a C++ Win32 app, with exact same semantics as in VB6, you can (to this day!) do this via VarAdd: https://msdn.microsoft.com/en-us/library/windows/desktop/ms221574(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms2.... Ditto VarSub, VarCat etc. You can see that this family of functions is very VB-centric actually, because it has VarAdd and VarCat separately (corresponding to + and & in VB); it conflates binary and boolean operators just as VB did; and it has VarEqv and VarImp, corresponding to VB operators EQV and IMP. And yet, it lives in oleaut32.dll...

ptx 10y ago

> 64-bit compatibility was never going to happen, But it did, more or less. VBA and VB6 are essentially the same thing, and VBA 7 (still used in MS Office) added 64-bit support: https://msdn.microsoft.com/en-us/library/office/gg264421.aspx https://msdn.microsoft.com/en-us/library/office/gg264421.asp...

peteri 10y ago

Given the macro engine in Excel is VBA (basically VB6) I suspect VB6 support will be around for a VERY long time.