4 ms·

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 i

• int_19h 7y ago
  I think we need to distinguish between COM and OLE/ActiveX here. COM interop in .NET is two-way, and the consumer doesn't even need to be aware that there's a VM running the code that they're invoking. OLE is much more challenging, because the UI framework needs to be aware of it, and because it's built on Win32 UI primitives - so any framework that doesn't use those is going to have issues much like WPF (Qt is another example). Bitness is not a new problem - VB6 similarly has problem consuming COM components written in C++, but compiled as 64-bit. Or, to put it another way: VB6 didn't have a problem, because 64-bit wasn't a thing back when it was popular, and didn't really became common on Win32 until relatively recently. But in a similar vein, if you always compile .NET code targeting x86 rather than AnyCPU (which is the default for new .NET VS projects - not sure when that changed, but it's been several years), you get the same exact behavior as VB6. Getting back to OLE and ActiveX - I would say that it was killed by Microsoft directly, not because of .NET. Back in the day, most non-trivial Windows apps made by MS supported OLE for embedding - this was most commonly used with IE, but you could also do it with e.g. Word and Excel... until you couldn't anymore. If I remember correctly, it was Office 2007 that killed it as an officially supported scenario (you could still do it, but if anything broke, you were on your own). That roughly coincides with WPF, and I don't think that's a coincidence - but it doesn't mean that WPF/.NET was the primary cause.
  • DaiPlusPlus 7y ago
    > COM interop in .NET is two-way, and the consumer doesn't even need to be aware that there's a VM running the code that they're invoking. I understand that's because .NET components loaded into a native process via COM are done so in-proc but using a single instance of the CLR, means you can't have .NET 2.0 CLR and .NET 4.0 CLR components loaded at the same time into the same process. I also understand (but am unsure) about what this means for AppDomains. .NET Core simplifies things considerably: by being utterly broken when it comes to COM support and generally requiring each .NET Core program to have its own independent process rather than supporting multiple AppDomains in the same process (okay, that's a bit of hyperbole: .NET Core supports strongly-typed COM objects but they removed support for using `dynamic` with late-bound COM objects - and I can't find any documentation regarding loading .NET Core components via COM into a native VB6/C++ process. > But in a similar vein, if you always compile .NET code targeting x86 rather than AnyCPU (which is the default for new .NET VS projects - not sure when that changed, but it's been several years), you get the same exact behavior as VB6. I understand the default for .NET Framework application projects is still AnyCPU but a new option called "Prefer 32-bit" is selected by default. Whereas for library projects and all .NET Core projects the default is AnyCPU ("Prefer 32-bit" is only an option for *.exe projects). > If I remember correctly, it was Office 2007 that killed it as an officially supported scenario (you could still do it, but if anything broke, you were on your own). > That roughly coincides with WPF, and I don't think that's a coincidence - but it doesn't mean that WPF/.NET was the primary cause. I understand the reason was because very few applications in the wild depended on this functionality (that's what Microsoft's telemetry in Windows is for) - I think the only real application that made full use of this was MS Binder (rip 2002) - and I only ever got annoyed at the times when Internet Explorer would load Office Word or Excel directly into the browser shell. Office 2007's radically redesigned UI required much more screen real-estate - whereas Office's support for being loaded into an OLE window was back when people were running at 640x480 or 800x600 (if you were lucky!) and Office had 16px-sized toolbar buttons - which is another reason to avoid wasting developer time working on it.
    • int_19h 7y ago
      > I understand that's because .NET components loaded into a native process via COM are done so in-proc That's not necessarily so. By default, a .NET class exposed via COM is free-threaded, so it'll be instantiated in-proc. But you can have all the same complicated apartment arrangements as with native - and marshaling is done via type libraries that are generated from assembly metadata. So if you want an out-of-proc COM server written in .NET, it's quite possible. > but using a single instance of the CLR, means you can't have .NET 2.0 CLR and .NET 4.0 CLR components loaded at the same time into the same process. If you use in-proc components, then yes, the runtime is loaded. But .NET 2 and .NET 4 runtimes are intentionally designed to be possible to side-load. They don't see each other as .NET, of course - so if you take a reference to an object in one runtime, and pass it through native code as a COM reference to the other runtime, it'll see it as an opaque COM component. .NET Core is its own thing - it's clear that everything Win32 is legacy there, including COM. I was surprised it even got WinForms...