Hi !
Is there any C++ STL containers alternatives in kernel mode or should I
implement anything myself ?
Thanks in advance.
Best regards.
Matt
I don’t know of any template libraries that rely on returning error codes, everything relies on exceptions. As exceptions are not supported in the kernel, you need to go with your own
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Matthieu Collette
Sent: Tuesday, May 17, 2016 8:47 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Alternative to STL container
Hi !
Is there any C++ STL containers alternatives in kernel mode or should I implement anything myself ?
Thanks in advance.
Best regards.
Matt
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>
Didn’t Google or Amazon or somebody have a container library or a version of STL or STD or something that did not use exceptions? Gad… I remember looking at this and thinking to myself “I wish somebody would build this and try it in Windows Kernel Mode”…
Peter
OSR
@OSRDrivers
Well, my own unpublished, un-peer reviewed and generally private set of ?template? code that runs to about 1 million lines of C code does exactly what is needed here
This continues my recent streak of mostly unhelpful posts ? expect perhaps that it helps to convey to the OP that understanding fundamental concepts of sequential programming ? including the fundamental paradigms of structured versus exception based design as essential before undertaking more significant issues
For the OP: remember that some key issues that I have solved have been solved again by MSFT since I started programming for Windows KM / UM in and around 1995. My cancer doctors don?t care in the slightest except that … anyways my personal issues are irrelevant and at present I am too tired to restructure the previous sentence so as to make it work with out them
Sent from Mailhttps: for Windows 10
From: Doron Holanmailto:xxxxx
Sent: May 17, 2016 12:06 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: RE: [ntdev] Alternative to STL container
I don’t know of any template libraries that rely on returning error codes, everything relies on exceptions. As exceptions are not supported in the kernel, you need to go with your own
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Matthieu Collette
Sent: Tuesday, May 17, 2016 8:47 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Alternative to STL container
Hi !
Is there any C++ STL containers alternatives in kernel mode or should I implement anything myself ?
Thanks in advance.
Best regards.
Matt
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:></http:></http:></mailto:xxxxx></mailto:xxxxx></https:>
It used to be possible to build msvc++'s stl without exceptions with
_USE_EXCEPTIONS=0.
No idea of whether it works anymore, but I assume we’re talking about
something that solves problems like vector assignment?
I don’t know of anything that does that.
mm
On May 17, 2016 1:43 PM, wrote:
> Didn’t Google or Amazon or somebody have a container library or a version
> of STL or STD or something that did not use exceptions? Gad… I remember
> looking at this and thinking to myself “I wish somebody would build this
> and try it in Windows Kernel Mode”…
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:>
An alternative to STL in kernel is KISS (Keep It Simple).
– pa
For trees (and thus sets and maps) you can use generic tables.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
“Matthieu Collette” wrote in message news:xxxxx@ntdev…
> Hi !
>
> Is there any C++ STL containers alternatives in kernel mode or should I
> implement anything myself ?
>
> Thanks in advance.
>
> Best regards.
>
> Matt
>
>
On 2016-05-18 03:28:37 +0000, xxxxx@fastmail.fm said:
Hi Pavel!
An alternative to STL in kernel is KISS (Keep It Simple).
Thanks not having mentionned the last S
– pa
On 2016-05-17 15:47:18 +0000, Matthieu Collette said:
Hi !
Is there any C++ STL containers alternatives in kernel mode or should I
implement anything myself ?Thanks in advance.
Best regards.
Matt
Hi !
I have finally implemented my own queue based on an underlyning
circular buffer.
Thanks for your help and comments.
Best regards.
> finally implemented my own…
I think we’ve all been there. It is appalling that in 2016 we in the kernel don’t have STL or similar like all other developers this day in age have in their arsenal. Instead we must each roll our own data structures, waste development time, risk introduction of buggy drivers, and miss out on high performance algorithms and mechanisms. This situation really hurts driver quality and time to market. Instead the priority at Microsoft has been to create ever more creative ways of torturing us signing our drivers. I just don’t get it.
Why not Go or even better D, in kernel ? 
Why need a fat language?
_pro
On 05/19/2016 05:10 PM, xxxxx@gmail.com wrote:
> finally implemented my own…
I think we’ve all been there. It is appalling that in 2016 we in the kernel don’t have STL or similar like all other developers this day in age have in their arsenal. Instead we must each roll our own data structures, waste development time, risk introduction of buggy drivers, and miss out on high performance algorithms and mechanisms. This situation really hurts driver quality and time to market. Instead the priority at Microsoft has been to create ever more creative ways of torturing us signing our drivers. I just don’t get it.
NTDEV is sponsored by OSR
Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at http:
></http:></http:></http:>
> An alternative to STL in kernel is KISS (Keep It Simple).
Are you trying to provoke me to go on yet another “Windoze bashing frenzy” or what?
Let’s face it - the entire Windows kernel has been designed and built around the principles that are directly opposite to the one that you have mentioned. What you say is just one of the cornerstones of
UNIX philosophy - “Sounds a bit tricky? We’re going to do it in the userland then”…
Anton Bassov
> It is appalling that in 2016 we in the kernel don’t have STL or similar like all other
developers this day in age have in their arsenal.
Well, “all other developers” have plentry of mechanisms to simpliify their work - from automatic memory manangement to run-time array bounds checking. However, for this or that reason you chose to do system-level development…
Instead we must each roll our own data structures, waste development time, risk
introduction of buggy drivers, and miss out on high performance algorithms and mechanisms.
This situation really hurts driver quality and time to market.
Sounds almost like a business opportunity, don’t you think. Write your own library that relieves
Windows kernel developers from the worries that you have mentioned, and make some money
for yourself. Certainly, your library is going to be attacked here by 'ALL_CAPS_ON folks", but I would not be too worried about it…
Anton Bassov
> Why not Go or even better D, in kernel ?
Why not C#, which is better then D in absolutely all aspects?
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
> UNIX philosophy - “Sounds a bit tricky? We’re going to do it in the userland then”…
Funny.
VFS layer is definitely tricky. Still it is in the UNIX kernels, and yes, it is a major advantage.
BTW, STL is not supported in Linux kernel either.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
>> Why not Go or even better D, in kernel ?
Why not C#, which is better then D in absolutely all aspects?
Certainly, I cannot speak for other people, but I think Pro was just ironical about it. You just did not get it, and acted in your usual “Windows fanboy’s fashion”. BTW, unlike C#, D seems to be a language that offers some fairly low-level options, including even inline assembly…
VFS layer is definitely tricky. Still it is in the UNIX kernels, and yes, it is a major advantage.
It depends on your definition of “tricky”. VFS is most definitely a fairly complex piece of software, simply because everything that is meant to deal with file IO just cannot be too simple by its very definition. However, if you read Rajeev Nagar’s book about writing FSDs for Windows you will realize that VFS is, in actuality, a realtively simple thing. In general, all you have to do is simply to read MSDN docs and OSR articles about PnP, about the rules of IRP completion et all,and, at this point, you will realize that, in actuality, VFS is not that complex…
BTW, STL is not supported in Linux kernel either.
Well, I don’t find it particularly surprizing - after all, when it comes to hating C++ even our “Hanging Judge” can take a course from Linus. Therefore, the very idea of using C++ in the Linux kernel is just an anathema…
Anton Bassov
Agree. But devs lives being difficult because of the paucity of standard data structure support is really just a side-effect of the root problem.
If you look at the time/effort/money/energy spent on trying to counter or augment the “lovely” features provided by C, what would solve the problem entirely is replacing C entirely by a language and run-time where it’s impossible to make these types of errors in the first place and a piece of software can be “provably correct by construction.” Consider a world where there ARE no buffer overflows in any code that’s written. Where there ARE no leaks, no reference counting errors. No accidental (or deliberate) scribbles to memory that you don’t legitimately “own.”
This is how operating systems should be designed in the 21st century. Given that we could run legacy apps in skinny VMs these days (or as a pico-process), it seems to ME like this should be something that could realistically come to market. However, people who are smarter than me have tried this and not been successful. And no, I don’t know why.
The ability to do:
UCHAR fred[2];
fred[2] = 0x00;
in your kernel mode code in 2016 is, in my mind, absolutely ridiculous. This might have been cute in 1975 or 1990… but TODAY? And don’t even get me started on strings, string allocation, and string parsing in kernel mode. Who does THAT in pure C today, right? That’s why we have std::wstring and CString. But, clearly, we never need to create or parse strings in kernel-mode. No, not ever. And if you DO it in kernel-mode, there’s certainly no chance of making a mistake and causing a bug. Let’s just keep doing things the way we did them back in 1989. It was good enough back when NT was being written (hey, the OS was at least written mostly in a high level language and not all in assembler… YAY!)… it should still be good now.
Arrrgh…
I’ve Pontificated on this before.
Peter
OSR
@OSRDrivers
Well, if you are speaking about “provably correct by construction.”, I am afraid you have to consider
a TOTALLY different world that has no buffers, in the first place - this is the world with no memory, no variables for anything but write-once assignment, and, in general, no program state whatsoever. The only problem is that this world has nothing to do with the OSes, because the very purpose of the OS is to manipulate the state of memory and hardware devices. What probably can be done here is providing an abstract purely functional specification from which automated tools may generate C code that is guarateed to be correct. AFAIK,NICTA managed to do it - they claim to be the first ones who have designed a formally verified microkernel that gets generated from an abstract specification written in Haskel…
Anton Basssov
Well, no. It’s really a lot more interesting than that. Google “provably correct operating system” – Tons of work done in this space in the past 10+ years. Consider L4, Coyotos, and Singularity and its descendant(s)… to name just a few.
I’m not staying it’s been easy going, or that there’s been a lot of interest from entrenched interests. I’m just saying it’s absolutely an achievable goal. You just have to start by thinking differently. About everything.
Peter
OSR
@OSRDrivers