4 ms·

Well said. COM was one of the best realizations of "Component-based Software Engineering" and Brad Cox's "Software-IC" model. It was a binary standard and so c

Well said. COM was one of the best realizations of "Component-based Software Engineering" and Brad Cox's "Software-IC" model. It was a binary standard and so components could be written in any language and yet be assured of perfect interoperability provided you followed all the rules/conventions. There was a bunch of boiler-plate for the framework itself but once you understood it, everything was smooth sailing in your language of choice. One of the things i always advise people is not to focus only on the current way of doing things but to study older well-known libraries/frameworks/architectures/kernels/etc. to really understand "Software Engineering" from many perspectives. That is where insight comes from and real understanding happens. For people interested in understanding COM, see the classic Essential COM by Don Box.

pjmlp 2mo ago
COM is heavily used in Windows today, no need for past tense.
- rramadass 2mo ago
  Not directly by app developers. Everybody uses only WinRT/.NET based managed languages/runtimes/libraries/frameworks etc.
  - pjmlp 2mo ago
    Who uses WinRT besides Microsoft employees, or APIs that are only available in WinRT like MIDI 2.0? Regardless, WinRT is COM. It only adds IInspectable as additional interface alongside IUnknown, and .NET metadata files instead of type libraries.
    - rramadass 2mo ago
      I said "WinRT/.NET based managed languages/runtimes/libraries/frameworks" implying that it is the higher-level constructs that are used by app developers. If you were to interview any "standard" windows programmer today i can almost guarantee they know nothing about COM even though WinRT itself is an evolution of COM and .NET also provides COM interop. Only the older senior programmers who have used it directly know of it.
      - pjmlp 2mo ago
        Ignoring C++ devs on purpose? Also no one uses WinUI, if that is what you are implying with WinRT, only Microsoft employees on Windows team forced to deal with that clusterfuck framework after Project Reunion pivoted into WinAppSDK. What do you think Qt, VCL, FireMonkey, ImGui, wxWindgets, JUCE make use of?
        rramadass 2mo ago
        What are you talking about? None of it is relevant to the point i am making. Also you do not need COM to program in C/C++ directly on Windows API since they are all C interfaces anyway. COM is just an architecture you choose to use or not depending upon your needs. Ever since managed languages/virtual machines became "standard" programming platforms most Windows programmers only write to these. Everything is at such a high-level now that only curious programmers delve deeper into the rabbit-hole.
        pjmlp 2mo ago
        You definitely do, unless you are stuck in Windows XP view of computing world. It is like using ReactOS instead. All Windows APIs since Vista are delivered via COM. How much Windows development are you doing actually? Not that much apparently. Also someone has to surface Windows APIs to managed languages, they don't appear by magic.
        rramadass 2mo ago
        > All Windows APIs since Vista are delivered via COM. Nope, This right here tells me you do not have much actual programming experience in Win32/Win64 apis nor of Windows Internals. The C-style windows apis are from kernel32/gdi32/user32/etc. user-mode dlls which call into intermediate ntdll/win32u dlls which then calls into kernel mode ntoskernel.exe/win32k.sys. With modern Windows there are another layer of abstractions with "Windows API Sets" (https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets https://learn.microsoft.com/en-us/windows/win32/apiindex/win...) which decouple those user api from their actual implementation dlls. COM is at user-mode and so interfaces to the first set of dlls only. Since the windows api breadth is vast not all of them are exposed via COM. WinRT uses/enhances classic COM but also calls Win32 api as needed. So Win32 api and WinRT api coexist with the latter providing the "modern" way to api access - https://en.wikipedia.org/wiki/Windows_Runtime https://en.wikipedia.org/wiki/Windows_Runtime But because WinRT is oriented towards secure sandboxed apps many low-level Win32 apis dealing with memory management, thread/process manipulations, system hooking etc. are limited/removed entirely from WinRT api. For your edification see this detailed older article; Turning to the past to power Windows’ future: An in-depth look at WinRT - https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ https://arstechnica.com/features/2012/10/windows-8-and-winrt... Your claims must be backed up with references before asking others about their experience. I only see you name dropping and quoting historical data in all your comments which is not relevant to discussing/understanding anything.
deleted 2mo ago
[deleted]

pjmlp 2mo ago

COM is heavily used in Windows today, no need for past tense.

rramadass 2mo ago
Not directly by app developers. Everybody uses only WinRT/.NET based managed languages/runtimes/libraries/frameworks etc.
- pjmlp 2mo ago
  Who uses WinRT besides Microsoft employees, or APIs that are only available in WinRT like MIDI 2.0? Regardless, WinRT is COM. It only adds IInspectable as additional interface alongside IUnknown, and .NET metadata files instead of type libraries.
  - rramadass 2mo ago
    I said "WinRT/.NET based managed languages/runtimes/libraries/frameworks" implying that it is the higher-level constructs that are used by app developers. If you were to interview any "standard" windows programmer today i can almost guarantee they know nothing about COM even though WinRT itself is an evolution of COM and .NET also provides COM interop. Only the older senior programmers who have used it directly know of it.
    - pjmlp 2mo ago
      Ignoring C++ devs on purpose? Also no one uses WinUI, if that is what you are implying with WinRT, only Microsoft employees on Windows team forced to deal with that clusterfuck framework after Project Reunion pivoted into WinAppSDK. What do you think Qt, VCL, FireMonkey, ImGui, wxWindgets, JUCE make use of?
      - rramadass 2mo ago
        What are you talking about? None of it is relevant to the point i am making. Also you do not need COM to program in C/C++ directly on Windows API since they are all C interfaces anyway. COM is just an architecture you choose to use or not depending upon your needs. Ever since managed languages/virtual machines became "standard" programming platforms most Windows programmers only write to these. Everything is at such a high-level now that only curious programmers delve deeper into the rabbit-hole.
        pjmlp 2mo ago
        You definitely do, unless you are stuck in Windows XP view of computing world. It is like using ReactOS instead. All Windows APIs since Vista are delivered via COM. How much Windows development are you doing actually? Not that much apparently. Also someone has to surface Windows APIs to managed languages, they don't appear by magic.
        rramadass 2mo ago
        > All Windows APIs since Vista are delivered via COM. Nope, This right here tells me you do not have much actual programming experience in Win32/Win64 apis nor of Windows Internals. The C-style windows apis are from kernel32/gdi32/user32/etc. user-mode dlls which call into intermediate ntdll/win32u dlls which then calls into kernel mode ntoskernel.exe/win32k.sys. With modern Windows there are another layer of abstractions with "Windows API Sets" (https://learn.microsoft.com/en-us/windows/win32/apiindex/windows-apisets https://learn.microsoft.com/en-us/windows/win32/apiindex/win...) which decouple those user api from their actual implementation dlls. COM is at user-mode and so interfaces to the first set of dlls only. Since the windows api breadth is vast not all of them are exposed via COM. WinRT uses/enhances classic COM but also calls Win32 api as needed. So Win32 api and WinRT api coexist with the latter providing the "modern" way to api access - https://en.wikipedia.org/wiki/Windows_Runtime https://en.wikipedia.org/wiki/Windows_Runtime But because WinRT is oriented towards secure sandboxed apps many low-level Win32 apis dealing with memory management, thread/process manipulations, system hooking etc. are limited/removed entirely from WinRT api. For your edification see this detailed older article; Turning to the past to power Windows’ future: An in-depth look at WinRT - https://arstechnica.com/features/2012/10/windows-8-and-winrt-everything-old-is-new-again/ https://arstechnica.com/features/2012/10/windows-8-and-winrt... Your claims must be backed up with references before asking others about their experience. I only see you name dropping and quoting historical data in all your comments which is not relevant to discussing/understanding anything.

deleted 2mo ago

[deleted]