6 ms·

I ran into that at work a few years back. I was tasked with integrating OpenSSL into the commercial Smalltalk used for the project (last updated in 1999, for mo

I ran into that at work a few years back. I was tasked with integrating OpenSSL into the commercial Smalltalk used for the project (last updated in 1999, for more or less good reasons). A priori, not an unreasonable task as the Smalltalk had a pretty good FFI mechanism. Except of course the neverending cavalcade of functions documented in the OpenSSL docs that were actually preprocessor macros. In the end I wrote a Python script that parsed the C headers and generated FFI entry points for normal functions and Smalltalk code for preprocessor macros that weren't simple literals. The result was a small mountain of code, but it made all of OpenSSL available to our application, which was great.

wruza 7y ago
You’re still lucky it wasn’t like DirectDraw or something WinAPI in general. I had to reinvent entire preprocessors and investigate implicit compiler defaults to be able to wrap that, and still there was LOWORD, MAKE_XYZ, etc, which were official arbitrary code-in-a-header interfaces. Preprocessor is a scourge of an API.
- pjmlp 7y ago
  Hence why since Vista all major new Windows APIs are COM based (now UWP).
  - jstimpfle 7y ago
    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
- arnsholt 7y ago
  Yeah, that sounds even more... fun. It had most of User32 an friends (as of 1999 anyways) already wrapped from the Smalltalk vendor, thankfully.
- jstimpfle 7y ago
  The main problem with C macros is their usage when a regular function would do just fine. That goes for a lot of the cruft in the Windows headers. Having said that, while I object to most ideas that "C is missing", I do think that better constant expressions and expression macros (functions on the syntactic-expressions level) would be a usability improvement in APIs compared to (token stream) preprocessor macros. Even though in the presence of the preprocessor, constants and expression macros would be somewhat redundant. One advantage of expression macros is that you do macro expansion after parsing to an AST. You get a valid AST parse with macro expansion if and only if you get a valid parse without expansion. Expression macros are regular AST elements, and are scoped just like regular functions or variables. They don't have a weird textual scoping scheme with conditional compilation or un-/redefinability. Getting rid of that should make it easier to translate them to other languages. Another advantage is that they allow you to actually know which constructs in an interface are part of the API. An expression macro is always supposed to be used directly by the consumer of the API, or at indirectly through another macro that is. That particular problem of the C preprocessor could in fact be solved if headers cleaned up after themselves, but in practice, preprocessor is just to messy so nobody does that.
  - youdontknowtho 7y ago
    Isn't this what rustlang did? I have to admit that I'm coming around on rust. I still think that their fanboy marketing is obnoxious...but I need to get over my penchant for finding reasons to be angry.
    - jstimpfle 7y ago
      I think they have a variety of different kinds of them. I'm not sure I want to go there. There are already benefits to be had by something that looks basically like function-like macros in C, but where the replacement bodies are required to be valid expressions, and that is scoped like other functions and variables, and only expanded after parsing. I did that for my own (experimental) language and it was very easy to implement and use.
    - steveklabnik 7y ago

wruza 7y ago

You’re still lucky it wasn’t like DirectDraw or something WinAPI in general. I had to reinvent entire preprocessors and investigate implicit compiler defaults to be able to wrap that, and still there was LOWORD, MAKE_XYZ, etc, which were official arbitrary code-in-a-header interfaces. Preprocessor is a scourge of an API.

pjmlp 7y ago
Hence why since Vista all major new Windows APIs are COM based (now UWP).
- jstimpfle 7y ago
  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
arnsholt 7y ago
Yeah, that sounds even more... fun. It had most of User32 an friends (as of 1999 anyways) already wrapped from the Smalltalk vendor, thankfully.
jstimpfle 7y ago
The main problem with C macros is their usage when a regular function would do just fine. That goes for a lot of the cruft in the Windows headers. Having said that, while I object to most ideas that "C is missing", I do think that better constant expressions and expression macros (functions on the syntactic-expressions level) would be a usability improvement in APIs compared to (token stream) preprocessor macros. Even though in the presence of the preprocessor, constants and expression macros would be somewhat redundant. One advantage of expression macros is that you do macro expansion after parsing to an AST. You get a valid AST parse with macro expansion if and only if you get a valid parse without expansion. Expression macros are regular AST elements, and are scoped just like regular functions or variables. They don't have a weird textual scoping scheme with conditional compilation or un-/redefinability. Getting rid of that should make it easier to translate them to other languages. Another advantage is that they allow you to actually know which constructs in an interface are part of the API. An expression macro is always supposed to be used directly by the consumer of the API, or at indirectly through another macro that is. That particular problem of the C preprocessor could in fact be solved if headers cleaned up after themselves, but in practice, preprocessor is just to messy so nobody does that.
- youdontknowtho 7y ago
  Isn't this what rustlang did? I have to admit that I'm coming around on rust. I still think that their fanboy marketing is obnoxious...but I need to get over my penchant for finding reasons to be angry.
  - jstimpfle 7y ago
    I think they have a variety of different kinds of them. I'm not sure I want to go there. There are already benefits to be had by something that looks basically like function-like macros in C, but where the replacement bodies are required to be valid expressions, and that is scoped like other functions and variables, and only expanded after parsing. I did that for my own (experimental) language and it was very easy to implement and use.
  - steveklabnik 7y ago