Hacker News Reader

Comment by chj | Hacker News Reader

Odd that all sources are c files. No cpp?

This doesn't look entirely accurate. My guess is that extensions were guessed when parsing symbols (which seem to be the source of this data). I'd bet that all of the things in minwin/kernel/io are pure C with upper layers being half-in-half C and C++ (most COM stuff has to be OO).

I was at microsoft from 2008-2011 and definitely saw some C++ in the kernel, even one driver using operator new for its allocations which I thought was a little nuts at the time. I also personally introduced some user mode .c files, it was just my preference. I don't think there's much rhyme or reason to which is used, although MS does lean very heavily towards C++ over C, seems like more and more as time goes on.

As for this directory tree... I found it creepy, like maybe source was leaked. The only inaccuracies I found relative to my memory of parts that I worked on was (1) I don't think they have done well tracking files that are part of static libraries and (2) what I presume are new files introduced by folks who came after me.

Indeed, static libs caused massive duplication and not-always-correct source location in my script. Nice catch :)

C++ code in kernel typically wouldn't fly for the new stuff, but I bet there were some legacy pieces, sure. But even then nothrow would be forced on new and prefast/prefix warnings around failed allocations would have to be handled.

This is true. The driver I am thinking of didn't use C++ exceptions. I just found it weird not to use the pool APIs like everything else.

But speaking of exceptions the kernel did use a lot of SEH.

I think the VC11 compiler adds official support with a /kernel switch.

AFAIR Windows is full-C and COM doesn't rely on C++ object semantics.

I'm not sure what you mean by "C++ object semantics" but COM objects are just objects, that I'm positive. My code was in .cpp file, not .c - that I'm sure of as well. This is why I'm saying that extensions seem to be guesses - PDBs carry module names w/o extensions.

Nothing stops you from following the COM ABI from C or any other language, which is kind of the point. The .h files generated from the idl have that CINTERFACE macro which has the vtable structs, in a form convenient for consuming from a C (and not C++) program.

Sure it's doable. I wrote some DirectX apps in pure C back in the days. Heck, I wrote one in ASM. But it's art for art's sake. There's no point in complicating your life like that, especially not when you're working on a commercial project.

I hardcoded the .obj extensions to .c -- it's not accurate because of that.

Reply on news.ycombinator.com