5 ms·

Win32 isn't plain C. Lots of Win32 functionality is only accessible via COM, which is C++ (though using only a small subset of features so as to achieve ABI sta

Win32 isn't plain C. Lots of Win32 functionality is only accessible via COM, which is C++ (though using only a small subset of features so as to achieve ABI stability).

ChrisSD 8y ago
COM isn't C++. It's a language independent interface. There's no reason why COM (and therefore UWP) can't be used from C.
- deleted 8y ago
  [deleted]
- userbinator 8y ago
  It can be used from C but is a huge pain that makes it obvious whoever designed the interface (or COM in general) really went off the deep end with the abstraction level. There's a major difference between a C API designed to be used from C (Win32, POSIX) and one that only happens to be usable from C. Compare a sane "C API designed to be used from C": https://docs.microsoft.com/en-us/windows/desktop/dlgbox/using-common-dialog-boxes#opening-a-file https://docs.microsoft.com/en-us/windows/desktop/dlgbox/usin... that involves nothing more than initialising a structure and calling a single function, with MS's "recommended replacement" using COM: https://msdn.microsoft.com/en-us/library/Bb776913(v=VS.85).aspx#basic_usage https://msdn.microsoft.com/en-us/library/Bb776913(v=VS.85).a... That is a ten level deep nested if with just as many function calls, to do essentially the equivalent of the code above. The first time I saw this, I seriously thought they were taking the piss.
  - pcwalton 8y ago
    Also, that code isn't C, it's C++. Method calls are a C++ feature. While you could use COM without language support for method calls, because the ABI is stable, it isn't really something that Microsoft supports.
    - teddyuk 8y ago
      I remember using C to call com components as a learning excercise - it was just that to see how it worked. You wouldn’t do it otherwise
    - Iwan-Zotow 8y ago
      Of course Microsoft supports it, why not? There is no magic in COM, had COM object written in C
      - pcwalton 8y ago
        I don't mean that calling COM objects from C doesn't work. I just mean that COM isn't designed to be used from C.
        tonyedgecombe 8y ago
        Actually I think it was, that was the lowest common denominator.
        pjmlp 7y ago
        Not really, COM is a subset of OLE 2.0, designed to replace VBX as OCX originally. Naturally OLE was designed as C framework back in Win16 days, with endless pages of boilerplate code. https://www.amazon.com/Windows-Programmers-Guide-Book-Disk/dp/0672302268 https://www.amazon.com/Windows-Programmers-Guide-Book-Disk/d... As such COM can be called from C, specially since C++ Windows compilers have a VTBL layout as if they were a plain old C struct with function pointers. However unless one is masochist, it is not sane to use COM from bare bones C.
  - maxxxxx 8y ago
    Without a language that wraps the naked COM calls it's truly a nightmare. Using COM from C# is pretty OK and VB6 was great too. C++ is worse. To me COM is like an assembly language for interop that needs to be wrapped with higher language constructs. You could probably write a few C macros to reduce the boilerplate code a lot.
    - snaky 8y ago
      ATL and WTL are such bunches of macros actually, but for C++.
      - maxxxxx 7y ago
        ATL yes, I think WTL is macros around Win32.
        dragontamer 7y ago
        WTL is built on top of ATL. Both use C++ isms, like curiously recurring template pattern. WTL is definitely "deep" C++. Templates, multiple inheritance, and more.
        maxxxxx 7y ago
        I worked a little with WTL a while ago and it felt like MFC done right.
  - marcoperaza 7y ago
    It’s funny that they use that awful pyramid-of-doom error handling style in a lot of the public documentation. The correct way is to have an “Error:” label at the end of the function before all the cleanup code. After calling any function that can return an error code, you check the error code and “goto Error” if necessary. You can encapsulate that whole logic in a macro so you just call something like CHK(hr) anytime you have an error code to check. CHK being defined as something like “if(FAILED(hr)) goto Error;”. This is how error handling for non-trivial functions is done in any serious C code, regardless of the platform. One common pattern is actually to just put the entire line of code inside the macro, so your code would look like CHK(hr = AWin32Function(param1, param2)). You can get real cute and even have the macro assign hr for you, so you can drop the “hr =“ from your code. I worked on Windows at Microsoft and with very few exceptions, the only time I saw the pyramid-of-doom was in the public documentation. I wonder if was just bowing to the irrational hostility some people have to any use of goto, even though this is a highly structured pattern that should be uniform across your codebase, the opposite of unstructured, ad-hoc uses of goto that are the actual problem.
    - userbinator 7y ago
      True, the error handling could be better, but my main point was really to say that much of that code should not even be necessary; the majority of those calls are really just doing the equivalent of setting a field in a structure in the old way. Furthermore, because it's a function call and "could" fail, "best" (more like dogmatic) practice dictates that the return values must be checked, despite the fact that failure means something was really wrong (like the hardware failing) and there's no way to recover from that, and you can argue that point as much as you like but your corporate-drone manager isn't going to care, only about whether you're "following the standards" and his precious metrics that are just as uncaring. (That's a rant for another day.) On the other hand, no one argues whether you need to check for errors when using assignment statements. Doing it the old way is so much simpler and avoids the whole aforementioned argument issue around pointless error-checking.
      - marcoperaza 7y ago
        You should always check the return value for an error, no matter what. I would not suggest otherwise. Whatever the source of the failure, you want to explicitly fail in a defined way rather than have your application behave in unexpected ways, potentially destroying user data or otherwise misbehaving.
Iwan-Zotow 8y ago
COM is COM, component object model, it is language-independent thing in itself
- srgpqt 8y ago
  Perhaps language-hostile would better describe it. Sure you can use it from any language that has some sort of ffi, but without compiler support it will not be pleasant.

Win32 isn't plain C. Lots of Win32 functionality is only accessible via COM, which is C++ (though using only a small subset of features so as to achieve ABI stability).

ChrisSD 8y ago

COM isn't C++. It's a language independent interface. There's no reason why COM (and therefore UWP) can't be used from C.

deleted 8y ago
[deleted]
userbinator 8y ago
It can be used from C but is a huge pain that makes it obvious whoever designed the interface (or COM in general) really went off the deep end with the abstraction level. There's a major difference between a C API designed to be used from C (Win32, POSIX) and one that only happens to be usable from C. Compare a sane "C API designed to be used from C": https://docs.microsoft.com/en-us/windows/desktop/dlgbox/using-common-dialog-boxes#opening-a-file https://docs.microsoft.com/en-us/windows/desktop/dlgbox/usin... that involves nothing more than initialising a structure and calling a single function, with MS's "recommended replacement" using COM: https://msdn.microsoft.com/en-us/library/Bb776913(v=VS.85).aspx#basic_usage https://msdn.microsoft.com/en-us/library/Bb776913(v=VS.85).a... That is a ten level deep nested if with just as many function calls, to do essentially the equivalent of the code above. The first time I saw this, I seriously thought they were taking the piss.
- pcwalton 8y ago
  Also, that code isn't C, it's C++. Method calls are a C++ feature. While you could use COM without language support for method calls, because the ABI is stable, it isn't really something that Microsoft supports.
  - teddyuk 8y ago
    I remember using C to call com components as a learning excercise - it was just that to see how it worked. You wouldn’t do it otherwise
  - Iwan-Zotow 8y ago
    Of course Microsoft supports it, why not? There is no magic in COM, had COM object written in C
    - pcwalton 8y ago
      I don't mean that calling COM objects from C doesn't work. I just mean that COM isn't designed to be used from C.
      - tonyedgecombe 8y ago
        Actually I think it was, that was the lowest common denominator.
        pjmlp 7y ago
        Not really, COM is a subset of OLE 2.0, designed to replace VBX as OCX originally. Naturally OLE was designed as C framework back in Win16 days, with endless pages of boilerplate code. https://www.amazon.com/Windows-Programmers-Guide-Book-Disk/dp/0672302268 https://www.amazon.com/Windows-Programmers-Guide-Book-Disk/d... As such COM can be called from C, specially since C++ Windows compilers have a VTBL layout as if they were a plain old C struct with function pointers. However unless one is masochist, it is not sane to use COM from bare bones C.
- maxxxxx 8y ago
  Without a language that wraps the naked COM calls it's truly a nightmare. Using COM from C# is pretty OK and VB6 was great too. C++ is worse. To me COM is like an assembly language for interop that needs to be wrapped with higher language constructs. You could probably write a few C macros to reduce the boilerplate code a lot.
  - snaky 8y ago
    ATL and WTL are such bunches of macros actually, but for C++.
    - maxxxxx 7y ago
      ATL yes, I think WTL is macros around Win32.
      - dragontamer 7y ago
        WTL is built on top of ATL. Both use C++ isms, like curiously recurring template pattern. WTL is definitely "deep" C++. Templates, multiple inheritance, and more.
        maxxxxx 7y ago
        I worked a little with WTL a while ago and it felt like MFC done right.
- marcoperaza 7y ago
  It’s funny that they use that awful pyramid-of-doom error handling style in a lot of the public documentation. The correct way is to have an “Error:” label at the end of the function before all the cleanup code. After calling any function that can return an error code, you check the error code and “goto Error” if necessary. You can encapsulate that whole logic in a macro so you just call something like CHK(hr) anytime you have an error code to check. CHK being defined as something like “if(FAILED(hr)) goto Error;”. This is how error handling for non-trivial functions is done in any serious C code, regardless of the platform. One common pattern is actually to just put the entire line of code inside the macro, so your code would look like CHK(hr = AWin32Function(param1, param2)). You can get real cute and even have the macro assign hr for you, so you can drop the “hr =“ from your code. I worked on Windows at Microsoft and with very few exceptions, the only time I saw the pyramid-of-doom was in the public documentation. I wonder if was just bowing to the irrational hostility some people have to any use of goto, even though this is a highly structured pattern that should be uniform across your codebase, the opposite of unstructured, ad-hoc uses of goto that are the actual problem.
  - userbinator 7y ago
    True, the error handling could be better, but my main point was really to say that much of that code should not even be necessary; the majority of those calls are really just doing the equivalent of setting a field in a structure in the old way. Furthermore, because it's a function call and "could" fail, "best" (more like dogmatic) practice dictates that the return values must be checked, despite the fact that failure means something was really wrong (like the hardware failing) and there's no way to recover from that, and you can argue that point as much as you like but your corporate-drone manager isn't going to care, only about whether you're "following the standards" and his precious metrics that are just as uncaring. (That's a rant for another day.) On the other hand, no one argues whether you need to check for errors when using assignment statements. Doing it the old way is so much simpler and avoids the whole aforementioned argument issue around pointless error-checking.
    - marcoperaza 7y ago
      You should always check the return value for an error, no matter what. I would not suggest otherwise. Whatever the source of the failure, you want to explicitly fail in a defined way rather than have your application behave in unexpected ways, potentially destroying user data or otherwise misbehaving.

Iwan-Zotow 8y ago

COM is COM, component object model, it is language-independent thing in itself

srgpqt 8y ago
Perhaps language-hostile would better describe it. Sure you can use it from any language that has some sort of ffi, but without compiler support it will not be pleasant.