Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


С++ in kernel

2

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,090

    By default? I dunno. You want 17 or 20 just select it, in the usual way.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • RourkeRourke Member Posts: 60

    Why stop at 17? The compiler supports a lot of c++20 already. The new bit library in c++20 is useful for systems level work. The new bit_cast offers a another safer and highly useful cast compared to the old c cast. There are now designated initializers for initializing structure fields. And much more. The language just keeps getting better like getting on a highway that is wider, smoother, and straighter than before.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,090

    Std::bit... That’s one I hadn’t seen before, and indeed could be quite useful.

    Very good Mr. Rourke. Thanks for that suggestion.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 350
    via Email
    Considering you saw how much/little peeps on the board have used C++ in
    kernel, would it not be more prudent to try all these questions yourself?

    I bet at best, apart from the audio miniports and trying out exceptions,
    noone has any idea, really.
    As someone mentioned, this discussion has moved from no-way to maybe.. on a
    board that did not do such a thing before :)
    My two pennies :)
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,090

    @Dejan_Maksimovic: I don't understand your post. Who are you replying to?

    I can tell you, for sure that I've built Windows kernel-mode drivers specifying both /std:c++17 and /std:c++latest and they work just fine.

    trying out exceptions

    Huh? We know exceptions don't work.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 350
    via Email
    It is a reply to Alex. I keep forgetting this is not rganized as a list any
    more..

    Yes, we tried exceptions, and know they do not work. That is about it..
    I meant he should try all of it on his/her own.

    Are c++17 supported fir kernel? It takes 15 seconds to test, 15 to send the
    question snd ask, another 1500 to read the answers :)

    Let me quote you:
    "I think that'd be a great project for you to undertake.

    When you get that done, please be sure to post back here and let us know
    how it all turned out."


    :)
  • Peter_ScottPeter_Scott Member - All Emails Posts: 750

    I'm sorry, over the past 20+ years of doing this stuff debugging a driver written in anything other than C (no ++ variant) bleeds into a nightmare. Of course the caveat to this is if YOU wrote the driver. If you are debugging some other clients driver and they have implemented a perfectly written OO++ driver, it will take days of stepping through code, and reading their implementation, to understand what is happening. Just write it in C ... or assembly! My 2 cents ...

    Kernel Drivers
    Windows File System and Device Driver Consulting
    www.KernelDrivers.com
    866.263.9295

  • MBond2MBond2 Member Posts: 196

    I agree. The cost of C++ is not to the authors, but to the reviewers and maintainers.

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,090

    @Peter_Scott @MBond2

    I agree with you concerning fully OO implementations. Hideous beyond compare.

    But... Using C++ does not necessarily imply using an OO design.

    We’re talking Modern C++ here... unique_ptr, ranged for, constexpr... nothing hard about debugging or maintaining any of those.

    As long as one sticks to “C++ as a better C” you’re good to go.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • RourkeRourke Member Posts: 60

    @Peter_Scott said:
    over the past 20+ years of doing this stuff

    Note there are also those using c++ in the kernel 30+ years that have an opposing view. Circa 40 years ago I wrote assembly apps, TSR's, and drivers for Dos. When Borland and Microsoft introduced the C language for the PC I enthusiastically used it and loved it and got great mileage out of it for years. Today c++20 is my language of choice in windows for both kernel and user mode. Why? Because it blows C out of the water, period.

    anything other than C (no ++ variant) bleeds into a nightmare

    This is a common misconception that C++ = OO. But it's not true. When you rename your file extension from .c to .cpp the compiler doesn't refuse to compile it because there's no OO in it. On the contrary utilizing powerful c++ language features like a static assert or being able to use sizeof on a field is not a debugging nightmare but actually improves productivity all around. The C++ language is constantly getting refined. Not with OOP garbage, but lots of nuts and bolts basics for those writing kernel drivers. The latest c++20 language is brand new and absolutely awesome for driver developers. Some people don't know today's c++20 is nothing like C++ was 10 or 20 years ago. What the standards people have rolled out over the last decade is nothing short of miracles for people writing code.

    Just write it in C ... or assembly!

    Assembly in the kernel makes no sense since sometime in the last century. Too many reasons to list. It's not cross platform and besides just think of how unreadable your code would become trying to reorder the instructions for super scalar optimization which a c/c++ compiler does for you for free.

  • Pavel_APavel_A Member Posts: 2,739

    @Rourke said:
    Some people don't know today's c++20 is nothing like C++ was 10 or 20 years ago. What the standards people have rolled out over the last decade is nothing short of miracles for people writing code.

    This is precisely the point. Why they haven't moved their ass 10 years earlier? Was it a rocket science? All these "modern" languages - Go, nimrod, julia, Rust and so on - raised mostly because C++ was not good enough. One can't claim that they have 5 years of writing new code or maintaining existing code in C++20.

    -- pa

  • Alex_FunkyAlex_Funky Member - All Emails Posts: 171

    @Pavel_A said:
    This is precisely the point. Why they haven't moved their ass 10 years earlier? Was it a rocket science? All these "modern" languages - Go, nimrod, julia, Rust and so on - raised mostly because C++ was not good enough. One can't claim that they have 5 years of writing new code or maintaining existing code in C++20.

    -- pa

    This may have been due to problems with backward compatibility, the need for high performance, and so on. now C++ is developing very dynamically...

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,090

    I very much agree with Mr @Rourke ... which is unusual, because he and I have disagreed on numerous things in the past.

    To Mr. @Pavel_A's comment:

    Go, nimrod, julia, Rust and so on - raised mostly because C++ was not good enough

    This is a different category of issue. C++ is still "not good enough" for a modern operating system implementation language. Yes, it provides many of the tools to "do things right"_ if you use them_. But it does not force these constructs. I very much like this discussion on Reddit.

    Now, before we get too far down the "why is rust great and C++ not so great" road, let me hasten to add that having actually spent time trying to do something useful with rust on Windows, I'm not nearly as enthusiastic about it as I was when I read about the language. In fact, I'm willing to bet that rust's current popularity (in the "polls of programmers opinions" that we so often read) is due to a lot of people who did the rust-lang hello world, thought "that's pretty cool" and then stopped. I don't want to turn this thread into a rant on why rust in general, and particularly using rust on Windows, is frustrating... so I'll just leave it there.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 350

    Anyone know how much of the Linux kernel is in C, ASM and C++ respectively? (maybe other languages?)

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,627

    The Linux kernel is entirely in C with a smattering of assembler. There is no C++ at all, not for any technical reason, but because Linus Torvalds is personally allergic to C++. It is a particularly idiomatic C, nearly free of comments, and they use macros to simulate the kinds of data structures that are easy in C++.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Sergey_PisarevSergey_Pisarev Member - All Emails Posts: 264

    @Tim_Roberts said:
    The Linux kernel is entirely in C with a smattering of assembler. There is no C++ at all, not for any technical reason, but because Linus Torvalds is personally allergic to C++. It is a particularly idiomatic C, nearly free of comments, and they use macros to simulate the kinds of data structures that are easy in C++.

    I am not a linux dev myself, but my colleague told me that one of the reasons why Linux Kernel is C only is that some platforms simply don't have c++ compiler implemented for them (I think he was speaking about embedded systems)

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,627

    The Linux kernel is tightly bound to gcc. Once there is a port to a processor, that means you automatically get C and C++ (and Fortran and Pascal, for that matter).

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Sergey_PisarevSergey_Pisarev Member - All Emails Posts: 264

    @Tim_Roberts said:
    The Linux kernel is tightly bound to gcc. Once there is a port to a processor, that means you automatically get C and C++ (and Fortran and Pascal, for that matter).

    Does It mean that I can actually write drivers for linux in c++ as long as I don't care about integrating my driver in official kernel sources ?

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,090

    Does It mean that I can actually write drivers for linux in c++

    It’s been done. Google is your friend.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Pavel_APavel_A Member Posts: 2,739

    @Tim_Roberts said:
    .... but because Linus Torvalds is personally allergic to C++.

    To C++ in its state when Linux was founded. That's C++ 98 or older, and it was then not a clear winner over C (with extra tools).

    and they use macros to simulate the kinds of data structures that are easy in C++.

    But the C++ data structures are in its standard library, and this library is written in assembly or C.
    This library is part of the kernel, it needs to be build for kernel environment, reviewed and maintained.
    There's no miracles. It is made of extra memory and CPU cycles. Every time one uses a C++ thing in kernel, they cannot avoid thinking: will it do a trick under the covers: allocate something? execute something? could it be easier and safer to just use plain C with macros?

    By contrast, structures in python or js are magical, one can use them without importing anything and even knowing what's the name of [] or {}.
    Of course this magic is expensive and doesn't fit in the kernel. But every time I write something in python - after years of C - I smile (and thank you, Mr, Roberts again for hinting me to learn python!)

    -- pa

  • anton_bassovanton_bassov Member MODERATED Posts: 5,181

    Does It mean that I can actually write drivers for linux in c++ as long as I don't care about integrating my driver in official kernel sources ?

    Well, technically there is nothing that stands in your way, although you have to take care of quite a few issues. To begin with, you have to implement your own versions of new() and delete() operators . Furthermore, making C++ work with Linux kernel headers does not really seem to be the easiest job in existence, so that you will probably have to provide your own wrappers for the kernel functions that you call. You must always keep in mind that there is no C++ runtime in the Linux kernel so that you have to avoid certain C++ language features( like , for example, exceptions),et,etc, etc...

    When it comes to deciding upon the practical usefulness of this approach.....well, this is already a different story that happens to be well beyond the scope of this discussion

    Anton Bassov

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,627

    What you're describing is no different from the situation in Windows.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Sergey_PisarevSergey_Pisarev Member - All Emails Posts: 264
    > @"Peter_Viscarola_(OSR)" said:
    > (Quote)
    > It’s been done. Google is your friend.
    >
    > Peter

    I asked this question exactly because I used google to figure out Linux kernel + c++ viability. And my impression was that you will have to fight really hard with build system to make it work. However mr Robert’s message sounded to me like you basically need just write c++ code in cpp files - pretty much the same way as I do in drivers for windows. Maybe I just misunderstood.
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,090
    edited October 3

    no different from the situation in Windows

    Except (of course) you’ll have no problem with checking something in to Windows that’s written in C++, even into MinKernel.

    ETA:

    making C++ work with Linux kernel headers does not really seem to be the easiest job

    And, of course, the Windows kernel headers have long been C++ compatible.

    Peter

    Post edited by Peter_Viscarola_(OSR) on

    Peter Viscarola
    OSR
    @OSRDrivers

  • Prokash_SinhaProkash_Sinha Member - All Emails Posts: 210
    via Email
    In the past I've seen C++ code (file filter drivers ), with OO (
    class etc). Quite hard to debug, at least for me, when the designers
    failed to understand what is/are going on ...

    Then move on to BSD, then Apple mach based kernel ---, almost all is C
    code ( except some asm )... Get open source, map correctly ( or almost
    ), debug thru kernel ( not what I want to do or enjoy ) but debugging
    is bit easier, well just the debugger infrastructure is not as solid
    as Windbg...

    Given that, I always ask one question to any senior new hire --- What
    is the best code ? I would not answer the question, just in case ...
    And if I see a simple reasonable answer with some pseudo-codes that
    guy is hired, period...

    The trend I see, is that lately more candidates learn C++ ( Google ,
    FB, Amazon etc., wants C++), so it is natural people want to use that
    knowledge in kernel mode...

    Now, what is the year when Linux got started ( i.e. porting Xinu or
    something after wholesale changes )??? Perhaps early 90s in the lab,
    then around 94 or 96 it is out there !!!... By then lot of people
    using C++/ Java is or already coming ... So why Linus did not conform
    to it... Whatever ....

    I hear people love to code in Swift/Obj-C/C++, so outside kernel
    modules I create interfaces ( like in low level daemons / services )
    and open up the bridges, so one can use swift or anything else. Inside
    kernel, I use C ( and some asm for tickery).

    I see some benefits of using C++, other than that I would suggest (
    just like Dejon ) look at the archive, see the concerns, and come up
    with solutions ( if you can ) --- and enlighten us.

    -Pro
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,090
    edited October 3

    OK. Let's be clear: Coding in C++ these days can mean many things. This is particularly true when we're talking about coding to Windows kernel-mode C Language interfaces, and under the constraints imposed by the Windows OS environment.

    I see primarily three different "levels" of approaches to using C++ in Windows driver development:

    1. C++ as a Better C: In this approach, one typically uses C Language conventions, but with the addition of specific Modern C++ features. This also typically means directly using the OS-supplied C Language interfaces. Most devs who program in C would be happy with the code, and they'd see very few differences. You might see the occasional RAII pattern here, but only rarely (where you can really benefit from some complex custom destructor, for example). This is typically the approach we use in kernel-mode code for Windows at OSR. There'll be an article in the next issue of The NT Insider about this.

    2. C++ Wrappers: This approach expands the approach above with the addition of C++ classes/wrappers to do a lot of the driver's work and around some of the more common C Language OS interfaces. This approach is typically where devs bite-off overriding "new" and "delete." The approach makes the use of RAII patterns for common OS interface tasks like acquiring and automatically releasing locks. This can be done well, but it needs to be done with a lot of restraint. In my experience, it's quite easy for devs using this approach to "slip into darkness" and accidentally create an impenetrable mess that fall into category 3 below.

    3. Full-On OO C++: This approach is what I think most C Language folks envision when they think of "drivers in C++" ... and it makes them shudder. I don't commonly see this approach anymore, except from folks who are on dev teams where OO is a way of life and they really hate thinking in C Language interface terms. Having seen, and tried to understand and debug, fully class-based, object oriented approaches to writing Windows drivers I can personally attest to how very painful this can be.

    C was a terrific language for OS development when compared to assembly language, back in the late 20th Century. It is a shit language for OS development for the 21st Century. What's better is still an open question, and what we can actually use that's better... while we're still using an OS that was designed in the late 1980's... is a bigger question still.

    I think Modern C++ helps.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • Prokash_SinhaProkash_Sinha Member - All Emails Posts: 210
    via Email
    Thanks Peter_Viscarola, as always...

    Yea, looking forward to reading your NT article(s) on C++ in kernel mode !

    I would very much appreciate it if I see what are the things in C++
    that can be used with ease ( EASE ) without bending one's head to
    believe in the rituals :-)

    For example --- std::, algorithms etc. including others ...

    Pro


    -Pro
  • Prokash_SinhaProkash_Sinha Member - All Emails Posts: 210
    via Email
    BTW, the reason I have interest in this topic ---

    Two years ago, we were embarking on a project that would be C++ based
    cross platform ( Windows, MacOS, Linux being main ones ). Quite a few
    kernel modules ( for each platform 5 to 7 ). And lots of codes in
    umode.

    Back then C++17 is making its place, and I was trying to see how I can
    get a message passing module -- used BOOST and saw there are quite a
    bit of interesting features there ( quite a few of them are now in
    C++17 ). Had to move back for some kernel hacks, but there are lot
    more works in that ... Looks like I would be back next year to take a
    shot at it...

    Intellectual property protection is what we do, or at least try to do :-)

    So it would help a lot when I see some articles from horses mouth :-)

    -Pro
  • MBond2MBond2 Member Posts: 196

    In my shop, we do C and C# in equal measure. Use the right tool for the right job. In at least the last 20 years, no one has presented any compelling argument to me why any part of C++ represents 'super C' or anything except a regression that has all the ways to hang oneself tat the old way has, but provides multitudes more as well.

    To be sure C# has its own set of pitfalls as well

  • anton_bassovanton_bassov Member MODERATED Posts: 5,181

    Now, what is the year when Linux got started ( i.e. porting Xinu or something after wholesale changes )???

    What he actually did was providing his own implementation of UNIX (namely, its SVR2 version as described in Maurice Bach's
    "UNIX Operating System"), and used the MINIX source code in his project. He released it in 1991. You can check it if you wish.
    It is available from kernel.org (IIRC , as version 0.01)

    Perhaps early 90s in the lab, then around 94 or 96 it is out there !!!... By then lot of people using C++/ Java is or already coming ...
    so why Linus did not conform to it... Whatever ....

    Actually, according to him, he tried to use C++ at some point.

    [begin quote]

    In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA. The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:

        the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.
        any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
        you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.
    
    In general, I'd say that anybody who designs his kernel modules for C++ is either
    
        looking for problems
        C++ bigot that can't see what he is writing is really just C anyway
        was given an assignment in CS class to do so.
    
    Feel free to make up (d).
    
    Linus
    

    [end quote]

    Anton Bassov

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE