5 ms·

Odd that all sources are c files. No cpp?

by chj 12y ago

DominikD 12y ago
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).
- thibauts 12y ago
  AFAIR Windows is full-C and COM doesn't rely on C++ object semantics.
  - DominikD 12y ago
    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.
    - asveikau 12y ago
      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.
      - DominikD 12y ago
        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.
  - deleted 12y ago
    [deleted]
- asveikau 12y ago
  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.
  - DominikD 12y ago
    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.
    - asveikau 12y ago
      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.
  - yuhong 12y ago
    I think the VC11 compiler adds official support with a /kernel switch.
  - aionescu 12y ago
    Indeed, static libs caused massive duplication and not-always-correct source location in my script. Nice catch :)
aionescu 12y ago
I hardcoded the .obj extensions to .c -- it's not accurate because of that.

Odd that all sources are c files. No cpp?

by chj 12y ago

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).

thibauts 12y ago
AFAIR Windows is full-C and COM doesn't rely on C++ object semantics.
- DominikD 12y ago
  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.
  - asveikau 12y ago
    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.
    - DominikD 12y ago
      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.
- deleted 12y ago
  [deleted]
asveikau 12y ago
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.
- DominikD 12y ago
  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.
  - asveikau 12y ago
    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.
- yuhong 12y ago
  I think the VC11 compiler adds official support with a /kernel switch.
- aionescu 12y ago
  Indeed, static libs caused massive duplication and not-always-correct source location in my script. Nice catch :)

aionescu 12y ago

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