4 ms·

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, afte

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...