4 ms·

COM is a (distributed) object model. It's mostly about structured object lifetimes. I don't think COM offers any solution for replacing bad use of preprocessor

COM is a (distributed) object model. It's mostly about structured object lifetimes. I don't think COM offers any solution for replacing bad use of preprocessor in APIs where we couldn't simply use plain C functions instead.

pjmlp 7y ago
> COM is a (distributed) object model. Not at all, that is why DCOM exists. COM offers a language agnostic component model for interoperability between development stacks on Windows, and a modern OS ABI.
- jstimpfle 7y ago
  I meant to say inter-process.
  - pjmlp 7y ago
    COM is also usable in-process.
    - jstimpfle 7y ago
      It is, that's why I wrote it in parentheses. And all of that wasn't my point anyway.
- jstimpfle 7y ago
  > a modern OS ABI. Last I looked at it, it was created in 1993 (enterprise OOP craze?) and was just regular DLLs containing regular code, wrapped in tons of symbols cruft to make a "dynamic classes protocol" work. If you actually have to deal with it directly from a non-managed language, I'm very doubtful that it's nicer than a well-written C header file. What I did when I saw MFC macros and 40 lines of boilerplate to marshal arguments to call into a single entry point, was to RUN, which is probably a good idea unless you want to put tons of supporting tooling and code generation in place.
  - pjmlp 7y ago
    Sorry to say, then you are stuck in the past and have a C tainted view of COM infrasture. Using COM from C++ Builder, VB 6, VB.Script, Delphi, Perl or Python, to use 90's only examples, did not have anything to do with "MFC macros and 40 lines of boilerplate to marshal arguments to call into a single entry point". No one uses MFC to create COM nowadays, unless they are dealing with mid-90's code. It is modern, because a component based ABI, with language interoperability in mind, is much better than a fossiled ABI designed for PDP-11 clones.
    - jstimpfle 7y ago
      It may well be that I missed an important development, but the underlying cruft of course didn't change. It's DLL based object code, just like regular C code, except that a lot of boilerplate is required to be a "blessed COM" DLL. https://en.wikipedia.org/wiki/Component_Object_Model#Technical_details https://en.wikipedia.org/wiki/Component_Object_Model#Technic... > No one uses MFC to create COM nowadays, unless they are dealing with mid-90's code. I guess that's what I was given... Now tell me what will be easier to call from my hobby programming language, COM or regular object code? > because a component based ABI > It is modern, because a component based ABI, with language interoperability in mind, is much better than a fossiled ABI designed for PDP-11 clones. It is literally the same "fossiled ABI", wrapped in more shitrolls to hold all the crap. If you just mean the APIs are more pleasant to use, then maybe that is so, due to the structured objects system, if you have all the tooling in place. I'm not sure I've ever used it from a managed language, and in general, hiding cruft by adding more cruft is not my cup of tea. Here is one example that I recently found. It shows the bullshit you have to go through to interface with COM as a C programmer: https://pastebin.com/3YvWQa5c https://pastebin.com/3YvWQa5c
      - pjmlp 7y ago
        The boilerplate is what happens when some people insist in using C instead of C++ or other modern languages to use COM, so they need to write manually what the compiler would do for them in more modern alternatives.

pjmlp 7y ago

> COM is a (distributed) object model. Not at all, that is why DCOM exists. COM offers a language agnostic component model for interoperability between development stacks on Windows, and a modern OS ABI.

jstimpfle 7y ago
I meant to say inter-process.
- pjmlp 7y ago
  COM is also usable in-process.
  - jstimpfle 7y ago
    It is, that's why I wrote it in parentheses. And all of that wasn't my point anyway.
jstimpfle 7y ago
> a modern OS ABI. Last I looked at it, it was created in 1993 (enterprise OOP craze?) and was just regular DLLs containing regular code, wrapped in tons of symbols cruft to make a "dynamic classes protocol" work. If you actually have to deal with it directly from a non-managed language, I'm very doubtful that it's nicer than a well-written C header file. What I did when I saw MFC macros and 40 lines of boilerplate to marshal arguments to call into a single entry point, was to RUN, which is probably a good idea unless you want to put tons of supporting tooling and code generation in place.
- pjmlp 7y ago
  Sorry to say, then you are stuck in the past and have a C tainted view of COM infrasture. Using COM from C++ Builder, VB 6, VB.Script, Delphi, Perl or Python, to use 90's only examples, did not have anything to do with "MFC macros and 40 lines of boilerplate to marshal arguments to call into a single entry point". No one uses MFC to create COM nowadays, unless they are dealing with mid-90's code. It is modern, because a component based ABI, with language interoperability in mind, is much better than a fossiled ABI designed for PDP-11 clones.
  - jstimpfle 7y ago
    It may well be that I missed an important development, but the underlying cruft of course didn't change. It's DLL based object code, just like regular C code, except that a lot of boilerplate is required to be a "blessed COM" DLL. https://en.wikipedia.org/wiki/Component_Object_Model#Technical_details https://en.wikipedia.org/wiki/Component_Object_Model#Technic... > No one uses MFC to create COM nowadays, unless they are dealing with mid-90's code. I guess that's what I was given... Now tell me what will be easier to call from my hobby programming language, COM or regular object code? > because a component based ABI > It is modern, because a component based ABI, with language interoperability in mind, is much better than a fossiled ABI designed for PDP-11 clones. It is literally the same "fossiled ABI", wrapped in more shitrolls to hold all the crap. If you just mean the APIs are more pleasant to use, then maybe that is so, due to the structured objects system, if you have all the tooling in place. I'm not sure I've ever used it from a managed language, and in general, hiding cruft by adding more cruft is not my cup of tea. Here is one example that I recently found. It shows the bullshit you have to go through to interface with COM as a C programmer: https://pastebin.com/3YvWQa5c https://pastebin.com/3YvWQa5c
    - pjmlp 7y ago
      The boilerplate is what happens when some people insist in using C instead of C++ or other modern languages to use COM, so they need to write manually what the compiler would do for them in more modern alternatives.