4 ms·

How did Microsoft solve it with their C++ APIs? I've never ventured much into Windows programming, but I remember hearing that MFC uses C++, and newer stuff is

How did Microsoft solve it with their C++ APIs? I've never ventured much into Windows programming, but I remember hearing that MFC uses C++, and newer stuff is mostly C++-based.

pjmlp 9y ago
Usually everyone makes use of COM. With Longhorn's failure, most of the .NET APIs that were part of the design how Longhorn was supposed to be, became COM APIs in Vista. Since then all major APIs were always COM based, with WinRT design goal being to do with COM what was originally imagined for Longhorn. Just that the COM APIs in UWP have been improved. Interfaces must inherit from IInspectable instead of IUnknown and .NET Metada is used instead of COM type libraries. COM allows any language on Windows that can interface with it to have access to an OS OO ABI. Which means any .NET language, Delphi, C++ and if feeling masochist C. EDIT: I think Ruby and Python can also consume COM. I also forgot to mention VBScript and JavaScript.
thriftwy 9y ago
They carry around their bridge library called MSVC redistributable, and that one is tied to compiler version. Fortunately for them they don't release compiler versions too often, but stuff you have on your Windows install perhaps carries around half dozen of MSVC redistributable library sets. All Windows APIs are still C (stdcall to be precise) with some COM.
- pjmlp 9y ago
  > All Windows APIs are still C (stdcall to be precise) with some COM. Only if we are speaking about until Vista. With Vista the majority of Win32 API are only COM, not "with some COM", even the userspace drivers are COM. WinRT introduced in Windows 8, nowadays rebranded as UWP, is also COM. Of course one can be masochist and make use of the low level C compatible COM bindings, or embrace ATL, WTL, C++/CX or the new C++/WinRT and enjoy productivity.
  - thriftwy 9y ago
    During my life I didn't meet a single person who understood COM and could program with it. That's it, just sayin'. Maybe it IS awesome. It's just unreachable. Borland made a fortune by making COM go away for a subset of tasks. After that, DotNet.
    - captainmuon 9y ago
      There is a subset of COM that is elegant and usable. And there is a ton of stuff that is only rarely used and understood. I'm looking at you, apartment models. Basically, COM are conventions how to layout structs and name functions, such that other code can load your DLLs. Coincidentially, they are almost identical to C++ classes, so you can often just return a pointer to a C++ class. There are layers and layers of conventions stacked, which makes it a bit complicated. On the low level, you can call stuff by knowing the memory layout. You have a header file and a pointer, and call the function at pointer+4. Fine for consuming from C/C++. Later, they developed IDispatch to call a method by string name (good for Visual Basic or scripting). There were interfaces to make Widgets (Custom controls / ActiveX). I personally found that the documentation for all that stuff was not very good. However, it was fairly easy to create and consume COM components Visual Basic (and to some extend MSVC). There was a booming market for VB custom controls long before .NET. Its a bit unfortunate we don't have something like that today.
      - pjmlp 9y ago
        > Its a bit unfortunate we don't have something like that today. Sure we do. https://www.componentone.com/ https://www.componentone.com/ https://www.devexpress.com/ https://www.devexpress.com/ http://www.telerik.com/ http://www.telerik.com/ And given that UWP and .NET Native are COM reborn, we will keep on having them.
    - pjmlp 9y ago
      .NET was originally designed as COM+ Runtime, before they decided to create the CLR, the research project was called Ext-VOS. https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net-generics-research-project-history-the-msr-white-paper-from-mid-1999/ https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net... Basically WinRT, being based on COM, with .NET being compiled to native code via .NET Native and UWP controls being implementations of IInspectable, is the return to that original design idea of the COM+ Runtime.
captainmuon 9y ago
COM has some simularities to GObject, IMO. What they did is they restricted themselves to the parts of the C++ ABI that are stable in practice. This is C exports, C types, and the layout of classes and vtables. COM is entirely usable from C (although cumbersome). The layout of a COM class/interface just happens to be the layout of a C++ class or vtable.

How did Microsoft solve it with their C++ APIs? I've never ventured much into Windows programming, but I remember hearing that MFC uses C++, and newer stuff is mostly C++-based.

pjmlp 9y ago

Usually everyone makes use of COM. With Longhorn's failure, most of the .NET APIs that were part of the design how Longhorn was supposed to be, became COM APIs in Vista. Since then all major APIs were always COM based, with WinRT design goal being to do with COM what was originally imagined for Longhorn. Just that the COM APIs in UWP have been improved. Interfaces must inherit from IInspectable instead of IUnknown and .NET Metada is used instead of COM type libraries. COM allows any language on Windows that can interface with it to have access to an OS OO ABI. Which means any .NET language, Delphi, C++ and if feeling masochist C. EDIT: I think Ruby and Python can also consume COM. I also forgot to mention VBScript and JavaScript.

thriftwy 9y ago

They carry around their bridge library called MSVC redistributable, and that one is tied to compiler version. Fortunately for them they don't release compiler versions too often, but stuff you have on your Windows install perhaps carries around half dozen of MSVC redistributable library sets. All Windows APIs are still C (stdcall to be precise) with some COM.

pjmlp 9y ago
> All Windows APIs are still C (stdcall to be precise) with some COM. Only if we are speaking about until Vista. With Vista the majority of Win32 API are only COM, not "with some COM", even the userspace drivers are COM. WinRT introduced in Windows 8, nowadays rebranded as UWP, is also COM. Of course one can be masochist and make use of the low level C compatible COM bindings, or embrace ATL, WTL, C++/CX or the new C++/WinRT and enjoy productivity.
- thriftwy 9y ago
  During my life I didn't meet a single person who understood COM and could program with it. That's it, just sayin'. Maybe it IS awesome. It's just unreachable. Borland made a fortune by making COM go away for a subset of tasks. After that, DotNet.
  - captainmuon 9y ago
    There is a subset of COM that is elegant and usable. And there is a ton of stuff that is only rarely used and understood. I'm looking at you, apartment models. Basically, COM are conventions how to layout structs and name functions, such that other code can load your DLLs. Coincidentially, they are almost identical to C++ classes, so you can often just return a pointer to a C++ class. There are layers and layers of conventions stacked, which makes it a bit complicated. On the low level, you can call stuff by knowing the memory layout. You have a header file and a pointer, and call the function at pointer+4. Fine for consuming from C/C++. Later, they developed IDispatch to call a method by string name (good for Visual Basic or scripting). There were interfaces to make Widgets (Custom controls / ActiveX). I personally found that the documentation for all that stuff was not very good. However, it was fairly easy to create and consume COM components Visual Basic (and to some extend MSVC). There was a booming market for VB custom controls long before .NET. Its a bit unfortunate we don't have something like that today.
    - pjmlp 9y ago
      > Its a bit unfortunate we don't have something like that today. Sure we do. https://www.componentone.com/ https://www.componentone.com/ https://www.devexpress.com/ https://www.devexpress.com/ http://www.telerik.com/ http://www.telerik.com/ And given that UWP and .NET Native are COM reborn, we will keep on having them.
  - pjmlp 9y ago
    .NET was originally designed as COM+ Runtime, before they decided to create the CLR, the research project was called Ext-VOS. https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net-generics-research-project-history-the-msr-white-paper-from-mid-1999/ https://blogs.msdn.microsoft.com/dsyme/2012/07/05/more-c-net... Basically WinRT, being based on COM, with .NET being compiled to native code via .NET Native and UWP controls being implementations of IInspectable, is the return to that original design idea of the COM+ Runtime.

captainmuon 9y ago

COM has some simularities to GObject, IMO. What they did is they restricted themselves to the parts of the C++ ABI that are stable in practice. This is C exports, C types, and the layout of classes and vtables. COM is entirely usable from C (although cumbersome). The layout of a COM class/interface just happens to be the layout of a C++ class or vtable.