> a standard, absolutely gigantic C/C++ project that re-invents absolutely everything including an event loop, http server, XML parser, a C++ tool to generate C code to create a “str hash” implementation, a custom lexer for WQL and a parser for a “mof” file format.

This is the part that gets missed when people talk about "dependency inflation" re: Rust. Absolutely, it is a problem, but most C codebases of a sufficient size and vintage are vendoring some absolutely insane hidden "dependencies" that, on average, probably get a lot less testing and attention than the average package on crates.io.

There are definitely risks with both approaches.

https://wiki.alopex.li/LetsBeRealAboutDependencies

Not sure why what you're saying would be more true for C/Rust/JavaScript or any other language. The perverse idea of adding dependencies without actually reading through all the code you pull in exists in basically all language ecosystems, Rust included.

In C it is much more inconvenient to include external dependencies, so it's much more common for people to roll their own implementations rather than using a tried-and-tested one.

Or copy in a .C/.h file that gets forgotten about, and therefore gets no security updates.

CIM/WBEM goes all the way back to 1996. They essentially wanted a management infrastructure on all kinds of devices (including different architectures, so actually C made sense then), but that also notably included remote access. At the time, SOAP was still popular, so here we are with a rather silly transport protocol and all kinds of overhead reinventing things like SSH. However, the overall goal still makes sense, it was essentially a way of 'object'-ifying everything from logs to other metrics. This fit in with the overall mode of thinking in MS with DCOM and COM (and registry), and structured configuration/management. I'm sure it's paid massive dividends on Azure Linux infrastructure. For highly structured objects, SOAP and XML aren't a terrible fit, but I doubt many people would do the same thing again today.

Honestly, they just needed to rewrite it in a safer stack. However, that still may not have saved them from all these vulnerabilities, given the scope of what they're implementing as remote management protocols. The relative scrutiny, fuzzing and manpower just hasn't been there, especially when it's obfuscated by various layers.

Not to take away from the rest of what you said, but I don’t think SOAP was _still_ popular in 1996. I don’t think it had become popular yet. I don’t think I even heard of SOAP before 1999 or 2000. I’m not a trend setter or anything, but if it was popular, I probably would have at least heard of it.

https://www.xml.com/pub/a/ws/2001/04/04/soap.html says SOAP was started in 98

That's fair, I was more speaking about XML and its use as a form of binary transport. Things like WS-Management and explicit SOAP obviously came a little bit later, and SOAP-like technologies were popularized for more general use in the 2000s. I think it's fair to say my experiences in general lean more towards observing standards groups.

Greenspun's law, "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." is really just a special case of a general principle. There's a lot of cases where if you use the wrong tool and/or don't know the right libraries, or don't or can't use them, or just won't, that you'll reinvent something that already exists, badly.

Looks like it’s mostly C, and not great C at that… In my humble opinion, this is a scary looking project.

Specifically- it appears to be mostly C99, lots of macros, lots of ugly buffer manipulation. But it's tooled for PREFast so you know it's secure! (https://github.com/microsoft/omi/blob/4ce2cf1cb0aa656b8eb934...) (j/k... I haven't seen that in ages). Guessing a port of MS's internal WMI codebase?

This codebase just smells of rot all over.

That is why there is "Modern C", "Modern C++" as talked at conferences, blog posts and endless over here, and then real life code that we actually find out in production.

I've seen and written plenty of modern (at the time of writing) C++ in production. It really depends on the team and the product.

Sure, yet this is the outcome from companies deeply involved in ISO, let alone those where regular folks don't even care HN exists.

Ironically, most modern C++ code I wrote was not for Microsoft, but a much smaller company that is not in any way involved in ISO C++ standardization process. It was due to that company culture - senior engineering leadership (which were also the founders) were all big standard C++ fans, and they wrote much of the original codebase.

Large companies like MS often have codebases that are so ancient (e.g. HRESULTs and IF_ERR_GOTO type macros everywhere), they only get modernized very gradually if at all.

I only use C++ for libraries that are then plugged into managed runtimes.

Most of the stuff I see in the wild could be considered what I call C+, basically MFC style with plenty of C love.

While Microsoft has the excuse for older code bases, stuff like WRL and C++/WinRT also has its share of not only following what is preached regarding C++ Core Guidelines love.

So the choice is RIIR or RIIC++ ?

It can also be RIIC#, RIID, RIIGo, RIIAda, RIIJava,... take your pick.

In typical Microsoft fashion, regardless of how much victories .NET and now Rust dev units achieve, the OS ones keep pushing for C and C++ no matter what.

That is also why we now have WinRT, WinUI, Sphere OS, Azure RTOS, regardless of what Microsoft Security advises.

But does it receive email?

http://catb.org/jargon/html/Z/Zawinskis-Law.html

The "fix" doesn't include any tests that would indicate that it actually works. Doesn't seem like a very healthy project.

The explanatory commit message of "Enhanced security" should be enough to document all you need to know!

You'd think a mention of the CVEs involved is mandatory for commits like these.