4 ms·

> "Classic" Visual Basic has been ended for a long time now. It kinda still lives on in classic ASP. It will be supported indefinitely so far [1] [1] https:/

> "Classic" Visual Basic has been ended for a long time now. It kinda still lives on in classic ASP. It will be supported indefinitely so far [1] [1] https://support.microsoft.com/en-us/help/2669020/active-server-pages-asp-support-in-windows https://support.microsoft.com/en-us/help/2669020/active-serv...

DaiPlusPlus 7y ago
IIS ASP and the Shell CScript/WScript hosts are just environments for the COM-based Active Scripting engine. At the time it was very capable as lots of software titles opened themselves up to automation via COM - that's why you could have Classic ASP pages that invoked Office Excel to generate charts dynamically. Unfortunately it was all a mess, but it was also something beautiful because it meant that a desktop/server OS was more than just a place where heterogenous applications could live: they could truly interact with each other regardless of their programming language or runtime platform. That grand vision - itself an extension of OLE from the early 1990s - died down with the rise of .NET (this wasn't intentional - Microsoft just had a lot of reorgs around that time and COM was more-or-less feature-complete, and no-one was really using DCOM) - but with Windows 8 and the "WinRT" API I was hopeful that COM would be back and new ways of automating applications would come around, and that Microsoft would have a great system for non-programmer users wanting to build workflows like they can with Apple's macOS Automator and AppleScript. This also ties-in with the do-as-little-work-as-necessary being done for VBA support in Microsoft's products. While we all wish Microsoft would allow modern JavaScript as a first-class COM automation language - the Office VBA runtime only supports its own VB6-dialect (the VBA language), and while Active Scripting supports JScript (a snapshot of JavaScript version 3 from 1999-2001) it doesn't support static typing nor is any of the tooling inside Office compatible at all. - so instead we have JavaScript, but only for "Office Apps" which don't offer anywhere near the same kind of integration or control over Office applications (or things like filesystem access) that VBA does. It's like it's 2008 again and everyone's excited about the new iPhone OS App Store and thinking about all the cool iPhone OS system extensions they'd add, like a Today screen or a camera app that can record video by using low-level camera hardware APIs - only to be discover Apple will only let-in apps using nerfed and siloed high-level APIs that take away all of the fun from extending an OS.
- int_19h 7y ago
  I wouldn't say that COM died with .NET - .NET had COM support baked deeply into the platform, to the point of language hacks where to this day, you can "new" a specially defined interface in C# (originally it was a way to reference the associated default coclass for a COM interface, if any). It's very easy to use and create COM libraries, and WinForms fully supports ActiveX controls. Even as late as 2010, COM support in .NET was still being developed - C# 4 got named indexers for this reason alone, and its "dynamic" supported IDispatch out of the box - its main scenario being Office automation.
  - DaiPlusPlus 7y ago
    I argue that COM "died" when .NET rose in reference to the COM ecosystem because prior to the release of .NET on Windows most non-Java developers were writing in either VB6/Delphi or C/C++ for their desktop applications. VB6 and C++ (specifically, Microsoft VisualC++'s __declspec-punctuated dialect at least) were both intimately connected to COM with their respective compilers have built-in support for DOM/DCOM/etc (e.g. VC processing IDL files and generating TLB files, while the VB6 compiler seemingly reads-in TLB files natively - and can generate its own too) - and all major components for Windows desktop development (such as ADODB for OLE and ODBC database access, the Macromedia Flash player, OLE objects in general, and VB-ecosystem "components" like charting widgets and new styles of buttons were all done using COM - which means programs written in VB6 running in the VB runtime could use the same GUI components and platform feature libraries as C/C++ code running in its own world - that is cool! While .NET is fully compatible with COM - the ecosystem isn't the same: WinForms and WPF GUI components written for .NET now cannot be used by VB6 forms or C/C++ windows (at least not without hosting .NET in-process and then facing additional issues integrating your Win32/User32 GUI with a WinForms hosting surface) - while hosting COM GUI components in WinForms is straightforward and just like VB6, hosting a COM GUI component in a WPF environment is very, very painful (google "wpf airspace" to see why this is a bad problem). Additionally, consuming COM from .NET (even VB.NET) isn't as easy or as straightforward as it is with VB6 either - as you have to contend with the ISA of your .NET process (e.g. you can't load 32-bit COM components into an x64 .NET process). I feel the amount of third-party software on Windows that offered COM automation has dwindled in recent years because of those reasons.

DaiPlusPlus 7y ago

IIS ASP and the Shell CScript/WScript hosts are just environments for the COM-based Active Scripting engine. At the time it was very capable as lots of software titles opened themselves up to automation via COM - that's why you could have Classic ASP pages that invoked Office Excel to generate charts dynamically. Unfortunately it was all a mess, but it was also something beautiful because it meant that a desktop/server OS was more than just a place where heterogenous applications could live: they could truly interact with each other regardless of their programming language or runtime platform. That grand vision - itself an extension of OLE from the early 1990s - died down with the rise of .NET (this wasn't intentional - Microsoft just had a lot of reorgs around that time and COM was more-or-less feature-complete, and no-one was really using DCOM) - but with Windows 8 and the "WinRT" API I was hopeful that COM would be back and new ways of automating applications would come around, and that Microsoft would have a great system for non-programmer users wanting to build workflows like they can with Apple's macOS Automator and AppleScript. This also ties-in with the do-as-little-work-as-necessary being done for VBA support in Microsoft's products. While we all wish Microsoft would allow modern JavaScript as a first-class COM automation language - the Office VBA runtime only supports its own VB6-dialect (the VBA language), and while Active Scripting supports JScript (a snapshot of JavaScript version 3 from 1999-2001) it doesn't support static typing nor is any of the tooling inside Office compatible at all. - so instead we have JavaScript, but only for "Office Apps" which don't offer anywhere near the same kind of integration or control over Office applications (or things like filesystem access) that VBA does. It's like it's 2008 again and everyone's excited about the new iPhone OS App Store and thinking about all the cool iPhone OS system extensions they'd add, like a Today screen or a camera app that can record video by using low-level camera hardware APIs - only to be discover Apple will only let-in apps using nerfed and siloed high-level APIs that take away all of the fun from extending an OS.

int_19h 7y ago
I wouldn't say that COM died with .NET - .NET had COM support baked deeply into the platform, to the point of language hacks where to this day, you can "new" a specially defined interface in C# (originally it was a way to reference the associated default coclass for a COM interface, if any). It's very easy to use and create COM libraries, and WinForms fully supports ActiveX controls. Even as late as 2010, COM support in .NET was still being developed - C# 4 got named indexers for this reason alone, and its "dynamic" supported IDispatch out of the box - its main scenario being Office automation.
- DaiPlusPlus 7y ago
  I argue that COM "died" when .NET rose in reference to the COM ecosystem because prior to the release of .NET on Windows most non-Java developers were writing in either VB6/Delphi or C/C++ for their desktop applications. VB6 and C++ (specifically, Microsoft VisualC++'s __declspec-punctuated dialect at least) were both intimately connected to COM with their respective compilers have built-in support for DOM/DCOM/etc (e.g. VC processing IDL files and generating TLB files, while the VB6 compiler seemingly reads-in TLB files natively - and can generate its own too) - and all major components for Windows desktop development (such as ADODB for OLE and ODBC database access, the Macromedia Flash player, OLE objects in general, and VB-ecosystem "components" like charting widgets and new styles of buttons were all done using COM - which means programs written in VB6 running in the VB runtime could use the same GUI components and platform feature libraries as C/C++ code running in its own world - that is cool! While .NET is fully compatible with COM - the ecosystem isn't the same: WinForms and WPF GUI components written for .NET now cannot be used by VB6 forms or C/C++ windows (at least not without hosting .NET in-process and then facing additional issues integrating your Win32/User32 GUI with a WinForms hosting surface) - while hosting COM GUI components in WinForms is straightforward and just like VB6, hosting a COM GUI component in a WPF environment is very, very painful (google "wpf airspace" to see why this is a bad problem). Additionally, consuming COM from .NET (even VB.NET) isn't as easy or as straightforward as it is with VB6 either - as you have to contend with the ISA of your .NET process (e.g. you can't load 32-bit COM components into an x64 .NET process). I feel the amount of third-party software on Windows that offered COM automation has dwindled in recent years because of those reasons.