20 ms·
This feels exactly like why Microsoft (and others) during the 90s started to define a well-defined subset of C, with some fancy IDL stuff, and a C-like ABI wher
by ntauthority 5y ago
This feels exactly like why Microsoft (and others) during the 90s started to define a well-defined subset of C, with some fancy IDL stuff, and a C-like ABI where all the C stuff needed could also be generated from the IDL, as standard somewhat-object-oriented interfaces like COM and other DCE RPC-likes.
Of course, the POSIX-likes never adopted this, whereas Microsoft nowadays has some fourth generation of this IDL stuff (WinMD) that they are also slowly porting all the old C API definitions to (see win32metadata, also used for defining stuff like the Win32 package for Rust).
Also, of course, this all has its own issues too, for one COM's definition of reference counting is a bit picky, and there were a lot of advanced 'implicit RPC' features that were also more inherent footguns, but at least it doesn't involve what is ranted about here.. mostly.
- pavlov 5y agoAgreed. This seems like a rant from someone who perhaps never used anything but Linux and Darwin (macOS). Windows went to substantial lengths to support non-C languages. It’s not obvious that the result was much of an improvement.
- saagarjha 5y agoFrom the blog post: > Case Study: MINIDUMP_HANDLE_DATA I think the author is well aware of Windows.
- sanxiyn 5y agoGNOME developed GObject Introspection and it works well for GNOME.
- Ericson2314 5y agoIt really sucks for cross compilation.
- Too 5y agoIf you reach a bit over into IPC/RPC, rather than just linking, the options with decent IDL and cross language code generators start to increase quickly. For example D-bus, or androids binder. Some even use grpc or thrift between processes on same machine. All of these are of course operating one or two abstraction levels up but are still good to consider.