C++ standards proposal for kernel STL subset

[Don_Burn]

As long as it is the horse’s mouth and not another piece of the anatomy. There were Pascal, Algol and PL/1 implementations that ran on multiple architectures natively with a high degree of portability. Of course there was also thing like basic interpreters where the programs would run on any architecture (the headache was moving the source code from one system to another).

C became portable when CPU architectures became 32-bit almost entirely. One of my jobs was developing the specifications for a mini-computer company’s C programming standards. You could not use any of the default types since int and long could be 32 or 16 bit. You could not equivalence a integer and a pointer since they were not always the same size, and some systems there were distinct word and byte pointers. Originally, the effort was to lead to a lint like program to check the portability, we gave up on this.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Wednesday, January 17, 2018 2:24 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] C++ standards proposal for kernel STL subset

Point taken, Don.

What other language was quite portable at that time, at that level ?
Asking to hear from horses mouth

-pro

On Wed, Jan 17, 2018 at 11:19 AM, xxxxx@windrvr.com wrote:
> “But for sure not at the register level. C really does not force you think at that level ( first portable language widely popular for different arch !)”
>
> It was far from portable in the early days, and there were other languages that were as portable in the same era. The problem with C is it does expose the architecture of the system to a large degree. I suffered through the nightmares of helping port Unix to a number of platforms that did not look like PDP-11’s. The language was a pain because not everyone had byte pointers, the joys of little endian versus big endian when people typecast, and a number of other smaller annoyances.
>
>
> Don Burn
> Windows Driver Consulting
> Website: http://www.windrvr.com
>
>
>
>
>
>
> —
> 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:>

[Prokash_Sinha]

Thanks Don,

Know nothing about Algol (except learning some in Programming
Languages crash course). But all along, including my days at IBM, I
never heard anyone speaking about Pascal or PL/1 being system
programming language though.

32 bit kicked off around early 90s, so C does have long heritage being
portable, then again I see your point in the yet earlier days (being
motorola, and intel, being little or big, being word vs. int width
etc.)

-Pro

On Wed, Jan 17, 2018 at 11:34 AM, xxxxx@windrvr.com wrote:
> As long as it is the horse’s mouth and not another piece of the anatomy. There were Pascal, Algol and PL/1 implementations that ran on multiple architectures natively with a high degree of portability. Of course there was also thing like basic interpreters where the programs would run on any architecture (the headache was moving the source code from one system to another).
>
> C became portable when CPU architectures became 32-bit almost entirely. One of my jobs was developing the specifications for a mini-computer company’s C programming standards. You could not use any of the default types since int and long could be 32 or 16 bit. You could not equivalence a integer and a pointer since they were not always the same size, and some systems there were distinct word and byte pointers. Originally, the effort was to lead to a lint like program to check the portability, we gave up on this.
>
>
> Don Burn
> Windows Driver Consulting
> Website: http://www.windrvr.com
>
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
> Sent: Wednesday, January 17, 2018 2:24 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] C++ standards proposal for kernel STL subset
>
> Point taken, Don.
>
> What other language was quite portable at that time, at that level ?
> Asking to hear from horses mouth
>
> -pro
>
> On Wed, Jan 17, 2018 at 11:19 AM, xxxxx@windrvr.com wrote:
>> “But for sure not at the register level. C really does not force you think at that level ( first portable language widely popular for different arch !)”
>>
>> It was far from portable in the early days, and there were other languages that were as portable in the same era. The problem with C is it does expose the architecture of the system to a large degree. I suffered through the nightmares of helping port Unix to a number of platforms that did not look like PDP-11’s. The language was a pain because not everyone had byte pointers, the joys of little endian versus big endian when people typecast, and a number of other smaller annoyances.
>>
>>
>> Don Burn
>> Windows Driver Consulting
>> Website: http://www.windrvr.com
>>
>>
>>
>>
>>
>>
>> —
>> 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:
>
>
> —
> 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:></http:></http:></http:>

[Tim_Roberts]

xxxxx@gmail.com wrote:

Know nothing about Algol (except learning some in Programming
Languages crash course). But all along, including my days at IBM, I
never heard anyone speaking about Pascal or PL/1 being system
programming language though.

When Control Data finally jumped into virtual memory with the Cyber 180,
their NOS/VE operating system was all written in Cybil, which was a
fairly straightforward implementation of Pascal.

Pascal was hugely successful on the Cyber 70s and 170s, probably because
Jensen & Wirth’s initial implementation was done on a 6000.  They had to
design the language to deal with unusual architectures.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[Prokash_Sinha]

>
Pascal was hugely successful on the Cyber 70s and 170s, probably because
Jensen & Wirth’s initial implementation was done on a 6000. They had to
design the language to deal with unusual architectures.

Thanks Tim …
-Pro

On Wed, Jan 17, 2018 at 11:53 AM, xxxxx@probo.com wrote:
> xxxxx@gmail.com wrote:
>> Know nothing about Algol (except learning some in Programming
>> Languages crash course). But all along, including my days at IBM, I
>> never heard anyone speaking about Pascal or PL/1 being system
>> programming language though.
>
> When Control Data finally jumped into virtual memory with the Cyber 180,
> their NOS/VE operating system was all written in Cybil, which was a
> fairly straightforward implementation of Pascal.
>
> Pascal was hugely successful on the Cyber 70s and 170s, probably because
> Jensen & Wirth’s initial implementation was done on a 6000. They had to
> design the language to deal with unusual architectures.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> 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:>

[Sven_Kreamer]

It is unfortunate everyone else has had no input on your paper and are trampling over your thread with prehistoric mumbo jumbo. I have another small, but pertinent note to add for you Ben. I cringe every time I hear the word c++ “subset” since it has very negative connotations. Some out there are trying to define a c++ subset they believe is pertinent to the kernel in their limited view but in actuality it comes off like adding training wheels to a bicycle so toddlers don’t fall over meanwhile hindering everyone else’s capabilities. Kernel developers do not want a subset, they want to leverage from the entire language what is most appropriate the same as enjoyed by any other developer. To be most effective and embraced it is important the tone of the pdf remains not about defining a subset per-se, but rather listing freestanding areas of c++ that therefore can safely be used in the kernel.

[Prokash_Sinha]

I tried few times to look at the pdf, not that I was intending to
provide any input, but just to learn something. The Github never
allowed me to get that. Kind of rare per my experience.

Ah, sometime unexpected things happens ( and we know it has more
information ). I was debating to suggest Github or having our own Git
server, since the monthly subscription is cheap. Now I’ve the
conclusion …

-Pro

On Wed, Jan 17, 2018 at 9:39 PM, xxxxx@gmail.com
wrote:
> It is unfortunate everyone else has had no input on your paper and are trampling over your thread with prehistoric mumbo jumbo. I have another small, but pertinent note to add for you Ben. I cringe every time I hear the word c++ “subset” since it has very negative connotations. Some out there are trying to define a c++ subset they believe is pertinent to the kernel in their limited view but in actuality it comes off like adding training wheels to a bicycle so toddlers don’t fall over meanwhile hindering everyone else’s capabilities. Kernel developers do not want a subset, they want to leverage from the entire language what is most appropriate the same as enjoyed by any other developer. To be most effective and embraced it is important the tone of the pdf remains not about defining a subset per-se, but rather listing freestanding areas of c++ that therefore can safely be used in the kernel.
>
>
> —
> 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:>

[Mark_Roddy]

prokash - likely your browser not github. The pdf viewer worked fine for
me. Also github’s monthly service fee is $0.00 unless you want extras.

Mark Roddy

On Thu, Jan 18, 2018 at 12:57 AM, xxxxx@gmail.com
wrote:

> I tried few times to look at the pdf, not that I was intending to
> provide any input, but just to learn something. The Github never
> allowed me to get that. Kind of rare per my experience.
>
> Ah, sometime unexpected things happens ( and we know it has more
> information ). I was debating to suggest Github or having our own Git
> server, since the monthly subscription is cheap. Now I’ve the
> conclusion …
>
> -Pro
>
> On Wed, Jan 17, 2018 at 9:39 PM, xxxxx@gmail.com
> wrote:
> > It is unfortunate everyone else has had no input on your paper and are
> trampling over your thread with prehistoric mumbo jumbo. I have another
> small, but pertinent note to add for you Ben. I cringe every time I hear
> the word c++ “subset” since it has very negative connotations. Some out
> there are trying to define a c++ subset they believe is pertinent to the
> kernel in their limited view but in actuality it comes off like adding
> training wheels to a bicycle so toddlers don’t fall over meanwhile
> hindering everyone else’s capabilities. Kernel developers do not want a
> subset, they want to leverage from the entire language what is most
> appropriate the same as enjoyed by any other developer. To be most
> effective and embraced it is important the tone of the pdf remains not
> about defining a subset per-se, but rather listing freestanding areas of
> c++ that therefore can safely be used in the kernel.
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > Visit the list online at: http:> 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&gt;
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> 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&gt;
></http:></http:></http:></http:>

[Peter_Viscarola_OSR]

It is unfortunate everyone else has had no input on your paper and are trampling
over your thread with prehistoric mumbo jumbo.

Well, I agree that the historic thread diversion was not useful… and I apologize for kicking it off with an exegesis on Mr. Penguin Pants’ rants about hating C++.

Given that I’m not a “language guy” – I’m a “systems guy” – I am perhaps too stooopid to understand Mr. Craig’s proposal. Regardless, my point to Mr. Craig was that – in my limited, and admittedly Windows-centric, systems programming viewpoint – I’m not looking for a small subset of C++ to use in the kernel. I guess that’d be fine, but… whatever. Rather, what I’m REALLY looking for an alternative that’ll help us all write safer and more reliable code in the kernel in the modern era.

It is possible that my wants/needs/interests are orthogonal to Mr. Craigs, and if that’s the case, I’d expect Mr. Craig to say so and I’ll personally wish him good luck and Gxd’s speed… sorry I can’t be helpful. OTOH, perhaps my narrow little view will serve to inform Mr. Craig a bit. And, if that’s the case, it’s all good.

Peter
OSR
@OSRDrivers

[Tim_Roberts]

xxxxx@gmail.com wrote:

It is unfortunate everyone else has had no input on your paper and are trampling over your thread with prehistoric mumbo jumbo. I have another small, but pertinent note to add for you Ben. I cringe every time I hear the word c++ “subset” since it has very negative connotations.

If I may be pedantic for a moment, I think it’s important to point out
that this is not a “C++ subset”, but rather a “standard library
subset”.  We’re talking about using the exact same compilers, but with a
different set of include files and libraries, which is exactly what
we’re doing now.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[Mark_Roddy]

kernel c++ is still missing basic runtime support, not sure if that was
called out in the paper.

Mark Roddy

On Thu, Jan 18, 2018 at 12:26 PM, xxxxx@probo.com
wrote:

> xxxxx@gmail.com wrote:
> > It is unfortunate everyone else has had no input on your paper and are
> trampling over your thread with prehistoric mumbo jumbo. I have another
> small, but pertinent note to add for you Ben. I cringe every time I hear
> the word c++ “subset” since it has very negative connotations.
>
> If I may be pedantic for a moment, I think it’s important to point out
> that this is not a “C++ subset”, but rather a “standard library
> subset”. We’re talking about using the exact same compilers, but with a
> different set of include files and libraries, which is exactly what
> we’re doing now.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> 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&gt;
></http:></http:>

[Tim_Roberts]

xxxxx@gmail.com wrote:

kernel c++ is still missing basic runtime support, not sure if that
was called out in the paper.

With the exception of I/O, almost all of the C runtime library is
available in the kernel in libcntpr.lib.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

[Prokash_Sinha]

Mark, I wish it were. I got what Peter mentioned about C++ link on
this thread, and that too is from GitHub

Yaah, I’m in the middle of deciding between Github and our own server.
At that time I read, that for some feature we will have fork out every
month…

I think, I will go for getting our own. Thanks though!

-Pro

On Thu, Jan 18, 2018 at 6:45 AM, xxxxx@gmail.com
wrote:
> prokash - likely your browser not github. The pdf viewer worked fine for me.
> Also github’s monthly service fee is $0.00 unless you want extras.
>
> Mark Roddy
>
> On Thu, Jan 18, 2018 at 12:57 AM, xxxxx@gmail.com
> wrote:
>>
>> I tried few times to look at the pdf, not that I was intending to
>> provide any input, but just to learn something. The Github never
>> allowed me to get that. Kind of rare per my experience.
>>
>> Ah, sometime unexpected things happens ( and we know it has more
>> information ). I was debating to suggest Github or having our own Git
>> server, since the monthly subscription is cheap. Now I’ve the
>> conclusion …
>>
>> -Pro
>>
>> On Wed, Jan 17, 2018 at 9:39 PM, xxxxx@gmail.com
>> wrote:
>> > It is unfortunate everyone else has had no input on your paper and are
>> > trampling over your thread with prehistoric mumbo jumbo. I have another
>> > small, but pertinent note to add for you Ben. I cringe every time I hear the
>> > word c++ “subset” since it has very negative connotations. Some out there
>> > are trying to define a c++ subset they believe is pertinent to the kernel in
>> > their limited view but in actuality it comes off like adding training wheels
>> > to a bicycle so toddlers don’t fall over meanwhile hindering everyone else’s
>> > capabilities. Kernel developers do not want a subset, they want to leverage
>> > from the entire language what is most appropriate the same as enjoyed by any
>> > other developer. To be most effective and embraced it is important the tone
>> > of the pdf remains not about defining a subset per-se, but rather listing
>> > freestanding areas of c++ that therefore can safely be used in the kernel.
>> >
>> >
>> > —
>> > 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:
>
>
> — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars on
> crash dump analysis, WDF, Windows internals and software drivers! Details at
> To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></http:></http:></http:>

[Mark_Roddy]

It is pretty trivial to standup gitlab locally. you can even host it in a
docker image.

Mark Roddy

On Thu, Jan 18, 2018 at 2:01 PM, xxxxx@gmail.com
wrote:

> Mark, I wish it were. I got what Peter mentioned about C++ link on
> this thread, and that too is from GitHub
>
> Yaah, I’m in the middle of deciding between Github and our own server.
> At that time I read, that for some feature we will have fork out every
> month…
>
> I think, I will go for getting our own. Thanks though!
>
> -Pro
>
> On Thu, Jan 18, 2018 at 6:45 AM, xxxxx@gmail.com
> wrote:
> > prokash - likely your browser not github. The pdf viewer worked fine for
> me.
> > Also github’s monthly service fee is $0.00 unless you want extras.
> >
> > Mark Roddy
> >
> > On Thu, Jan 18, 2018 at 12:57 AM, xxxxx@gmail.com <
> xxxxx@lists.osr.com>
> > wrote:
> >>
> >> I tried few times to look at the pdf, not that I was intending to
> >> provide any input, but just to learn something. The Github never
> >> allowed me to get that. Kind of rare per my experience.
> >>
> >> Ah, sometime unexpected things happens ( and we know it has more
> >> information ). I was debating to suggest Github or having our own Git
> >> server, since the monthly subscription is cheap. Now I’ve the
> >> conclusion …
> >>
> >> -Pro
> >>
> >> On Wed, Jan 17, 2018 at 9:39 PM, xxxxx@gmail.com
> >> wrote:
> >> > It is unfortunate everyone else has had no input on your paper and are
> >> > trampling over your thread with prehistoric mumbo jumbo. I have
> another
> >> > small, but pertinent note to add for you Ben. I cringe every time I
> hear the
> >> > word c++ “subset” since it has very negative connotations. Some out
> there
> >> > are trying to define a c++ subset they believe is pertinent to the
> kernel in
> >> > their limited view but in actuality it comes off like adding training
> wheels
> >> > to a bicycle so toddlers don’t fall over meanwhile hindering everyone
> else’s
> >> > capabilities. Kernel developers do not want a subset, they want to
> leverage
> >> > from the entire language what is most appropriate the same as enjoyed
> by any
> >> > other developer. To be most effective and embraced it is important
> the tone
> >> > of the pdf remains not about defining a subset per-se, but rather
> listing
> >> > freestanding areas of c++ that therefore can safely be used in the
> kernel.
> >> >
> >> >
> >> > —
> >> > 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:
> >
> >
> > — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
> on
> > crash dump analysis, WDF, Windows internals and software drivers!
> Details at
> > To unsubscribe, visit the List Server section of OSR Online at
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> 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&gt;
></http:></http:></http:></http:></http:></http:></http:></http:>

[Prokash_Sinha]

OK, I will look at it more then. Sure we will have dockers. Using CentOS.

One thing I will have to be sure about nothing exposed to beyond
intranet. As an example, I like and used MS Teamview, but not sure
what is/are exposed.

Also, getting a Git server straight out of the box is not much hassle .

-pro

On Thu, Jan 18, 2018 at 11:13 AM, xxxxx@gmail.com
wrote:
> It is pretty trivial to standup gitlab locally. you can even host it in a
> docker image.
>
> Mark Roddy
>
> On Thu, Jan 18, 2018 at 2:01 PM, xxxxx@gmail.com
> wrote:
>>
>> Mark, I wish it were. I got what Peter mentioned about C++ link on
>> this thread, and that too is from GitHub
>>
>> Yaah, I’m in the middle of deciding between Github and our own server.
>> At that time I read, that for some feature we will have fork out every
>> month…
>>
>> I think, I will go for getting our own. Thanks though!
>>
>> -Pro
>>
>> On Thu, Jan 18, 2018 at 6:45 AM, xxxxx@gmail.com
>> wrote:
>> > prokash - likely your browser not github. The pdf viewer worked fine for
>> > me.
>> > Also github’s monthly service fee is $0.00 unless you want extras.
>> >
>> > Mark Roddy
>> >
>> > On Thu, Jan 18, 2018 at 12:57 AM, xxxxx@gmail.com
>> >
>> > wrote:
>> >>
>> >> I tried few times to look at the pdf, not that I was intending to
>> >> provide any input, but just to learn something. The Github never
>> >> allowed me to get that. Kind of rare per my experience.
>> >>
>> >> Ah, sometime unexpected things happens ( and we know it has more
>> >> information ). I was debating to suggest Github or having our own Git
>> >> server, since the monthly subscription is cheap. Now I’ve the
>> >> conclusion …
>> >>
>> >> -Pro
>> >>
>> >> On Wed, Jan 17, 2018 at 9:39 PM, xxxxx@gmail.com
>> >> wrote:
>> >> > It is unfortunate everyone else has had no input on your paper and
>> >> > are
>> >> > trampling over your thread with prehistoric mumbo jumbo. I have
>> >> > another
>> >> > small, but pertinent note to add for you Ben. I cringe every time I
>> >> > hear the
>> >> > word c++ “subset” since it has very negative connotations. Some out
>> >> > there
>> >> > are trying to define a c++ subset they believe is pertinent to the
>> >> > kernel in
>> >> > their limited view but in actuality it comes off like adding training
>> >> > wheels
>> >> > to a bicycle so toddlers don’t fall over meanwhile hindering everyone
>> >> > else’s
>> >> > capabilities. Kernel developers do not want a subset, they want to
>> >> > leverage
>> >> > from the entire language what is most appropriate the same as enjoyed
>> >> > by any
>> >> > other developer. To be most effective and embraced it is important
>> >> > the tone
>> >> > of the pdf remains not about defining a subset per-se, but rather
>> >> > listing
>> >> > freestanding areas of c++ that therefore can safely be used in the
>> >> > kernel.
>> >> >
>> >> >
>> >> > —
>> >> > 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:
>> >
>> >
>> > — NTDEV is sponsored by OSR Visit the list online at: MONTHLY seminars
>> > on
>> > crash dump analysis, WDF, Windows internals and software drivers!
>> > Details at
>> > To unsubscribe, visit the List Server section of OSR Online at
>>
>> —
>> 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: MONTHLY seminars on
> crash dump analysis, WDF, Windows internals and software drivers! Details at
> To unsubscribe, visit the List Server section of OSR Online at</http:></http:></http:></http:></http:></http:></http:></http:></http:>

[Ben_Craig]

Thank you Sven, for dragging the thread back on topic. Also, thanks for providing feedback. It’s a big paper.

xxxxx@gmail.com wrote:

I cringe every time I hear the
word c++ “subset” since it has very negative connotations. Some out there
are trying to define a c++ subset they believe is pertinent to the kernel in
their limited view but in actuality it comes off like adding training wheels to a
bicycle so toddlers don’t fall over meanwhile hindering everyone else’s
capabilities. Kernel developers do not want a subset, they want to leverage
from the entire language what is most appropriate the same as enjoyed by
any other developer. To be most effective and embraced it is important the
tone of the pdf remains not about defining a subset per-se, but rather listing
freestanding areas of c++ that therefore can safely be used in the kernel.

There are several things that could work in the kernel, but currently don’t, purely because of implementation detail choices by the various C++ vendors. For example, the Visual Studio 2017 STL mostly doesn’t work in the kernel because it assumes that it is using the user mode C library, rather than using whatever C library is available. As another example, the header spews warnings about iostreams, even if you aren’t using any of the stream iterators.

A large part of the purpose of the paper is to get something standardized, so that vendors can provide useful tools to kernel developers. In order for vendors to take action, they need to know which areas need attention.

I want to be able to tell kernel developers that it is safe to use std::iterator_traits as a building block for their own containers, but right now I can’t do that due to the existing toolchain problems.

Also, while I would like to have all of C++ at my disposal, I don’t know how feasible that is in practice. For instance, I don’t know of a way to do thread local storage in the kernel. The lack of thread local storage also makes implementing exceptions in the kernel tricky. Picking default memory pools for new and delete is extremely contentious.

xxxxx@probo.com wrote:
> If I may be pedantic for a moment, I think it’s important to point out
> that this is not a “C++ subset”, but rather a “standard library
> subset”. We’re talking about using the exact same compilers, but with a
> different set of include files and libraries, which is exactly what
> we’re doing now.

For now, this is just a standard library subset. Later papers will likely try to go further. In general though, the idea is to follow existing practice for what people do with C++ in these constrained environments.

xxxxx@gmail.com wrote:
> kernel c++ is still missing basic runtime support, not sure if that was called out in the paper.

I believe this is a toolchain issue, and not a standards issue. Static and dynamic libraries work in the kernel, so long as they were built with the kernel in mind. The toolchains just haven’t provided a kernel aware C++ runtime.

[Mark_Roddy]

This is totally off topic, but as I’ve mentioned previously you get a lot
of added benefits from gitlab ce for free, like code review issue tracking
a full ci system backups web ui built in help system reporting - it is a
complete turnkey system, and no it is not leaking your secrets off of your
network.

Mark Roddy

On Thu, Jan 18, 2018 at 2:43 PM, xxxxx@gmail.com
wrote:

> OK, I will look at it more then. Sure we will have dockers. Using CentOS.
>
> One thing I will have to be sure about nothing exposed to beyond
> intranet. As an example, I like and used MS Teamview, but not sure
> what is/are exposed.
>
> Also, getting a Git server straight out of the box is not much hassle .
>
> -pro
>
> On Thu, Jan 18, 2018 at 11:13 AM, xxxxx@gmail.com
> wrote:
> > It is pretty trivial to standup gitlab locally. you can even host it in a
> > docker image.
> >
> > Mark Roddy
> >
> > On Thu, Jan 18, 2018 at 2:01 PM, xxxxx@gmail.com > >
> > wrote:
> >>
> >> Mark, I wish it were. I got what Peter mentioned about C++ link on
> >> this thread, and that too is from GitHub
> >>
> >> Yaah, I’m in the middle of deciding between Github and our own server.
> >> At that time I read, that for some feature we will have fork out every
> >> month…
> >>
> >> I think, I will go for getting our own. Thanks though!
> >>
> >> -Pro
> >>
> >> On Thu, Jan 18, 2018 at 6:45 AM, xxxxx@gmail.com
> >> wrote:
> >> > prokash - likely your browser not github. The pdf viewer worked fine
> for
> >> > me.
> >> > Also github’s monthly service fee is $0.00 unless you want extras.
> >> >
> >> > Mark Roddy
> >> >
> >> > On Thu, Jan 18, 2018 at 12:57 AM, xxxxx@gmail.com
> >> >
> >> > wrote:
> >> >>
> >> >> I tried few times to look at the pdf, not that I was intending to
> >> >> provide any input, but just to learn something. The Github never
> >> >> allowed me to get that. Kind of rare per my experience.
> >> >>
> >> >> Ah, sometime unexpected things happens ( and we know it has more
> >> >> information ). I was debating to suggest Github or having our own Git
> >> >> server, since the monthly subscription is cheap. Now I’ve the
> >> >> conclusion …
> >> >>
> >> >> -Pro
> >> >>
> >> >> On Wed, Jan 17, 2018 at 9:39 PM, xxxxx@gmail.com
> >> >> wrote:
> >> >> > It is unfortunate everyone else has had no input on your paper and
> >> >> > are
> >> >> > trampling over your thread with prehistoric mumbo jumbo. I have
> >> >> > another
> >> >> > small, but pertinent note to add for you Ben. I cringe every time I
> >> >> > hear the
> >> >> > word c++ “subset” since it has very negative connotations. Some out
> >> >> > there
> >> >> > are trying to define a c++ subset they believe is pertinent to the
> >> >> > kernel in
> >> >> > their limited view but in actuality it comes off like adding
> training
> >> >> > wheels
> >> >> > to a bicycle so toddlers don’t fall over meanwhile hindering
> everyone
> >> >> > else’s
> >> >> > capabilities. Kernel developers do not want a subset, they want to
> >> >> > leverage
> >> >> > from the entire language what is most appropriate the same as
> enjoyed
> >> >> > by any
> >> >> > other developer. To be most effective and embraced it is important
> >> >> > the tone
> >> >> > of the pdf remains not about defining a subset per-se, but rather
> >> >> > listing
> >> >> > freestanding areas of c++ that therefore can safely be used in the
> >> >> > kernel.
> >> >> >
> >> >> >
> >> >> > —
> >> >> > 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:
> >> >
> >> >
> >> > — NTDEV is sponsored by OSR Visit the list online at: MONTHLY
> seminars
> >> > on
> >> > crash dump analysis, WDF, Windows internals and software drivers!
> >> > Details at
> >> > To unsubscribe, visit the List Server section of OSR Online at
> >>
> >> —
> >> 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: MONTHLY seminars
> on
> > crash dump analysis, WDF, Windows internals and software drivers!
> Details at
> > To unsubscribe, visit the List Server section of OSR Online at
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> 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&gt;
></http:></http:></http:></http:></http:></http:></http:></http:></http:></http:></http:>

[Sven_Kreamer]

> I believe this is a toolchain issue, and not a standards issue.

Yes and now that we are in 2018 it is incomprehensible Microsoft has not done anything about this. When visual studio driver building came online I thought surely they would fix it just for that, but no.

[Gregory_G_Dyess]

Let’s keep something in mind here during this discussion. We’re talking about kernel code, not some simple application or web server.

Kernel programming, by its very nature, is unique. It has unique constraints and challenges and the consequences of failure are much higher. There are reasons why things like user-thrown exceptions and wasteful stack operations are difficult, if not impossible, to use in the kernel.

All these user-mode libraries and frameworks (stl, et. al.) were designed with a completely different environment in mind and are simply not suitable for use in the kernel. They were designed to make life easier for everyday run-of-the-mill apps code slingers. They were NOT meant for memory or performance efficiency. Take a look at the bloat and inefficiencies of some of these standard class libraries. Do you REALLY want something like MFC in ring 0?

I, for one, do NOT want it easy for just anyone to haphazardly slap together code and just start running it in the kernel. Kernel programming is an exacting sub-field of programming. This list alone is replete with REALLY bad ideas newbie apps programmers came up with because they didn’t know any better. Unfortunately, the industry, and even some on this list, are pushing to make is to anyone can *THINK* they are a kernel programmer. And we wonder why there are so many crappy drivers out there?

What *AM* I in favor of? I would love to see classes work and work well in the kernel. I would love to see enhancements in C++ that would work well with the unique memory management aspects of kernel programming such as pageable vs non-pageable chunks of memory, user vs kernel memory separations (Can we say Meltdown and Spectre?), kernel-supported exception catching and VERY light stack usage just to name a few.

I have been fortunate to work on an operating system that DID allow C++ in its kernel and device drivers since its inception and supported it well as long as the BSP/driver developers understood the environment. Unfortunately, Microslop mishandled it and dropped it completely. I’d love for desktop Windows to catch up.

OK, rant over. I’ll crawl back into my hole now.

Greg

— xxxxx@lists.osr.com wrote:

From: “xxxxx@gmail.com”
To: “Windows System Software Devs Interest List”
Subject: RE:[ntdev] C++ standards proposal for kernel STL subset
Date: Thu, 18 Jan 2018 20:02:07 -0500 (EST)

> I believe this is a toolchain issue, and not a standards issue.

Yes and now that we are in 2018 it is incomprehensible Microsoft has not done anything about this. When visual studio driver building came online I thought surely they would fix it just for that, but no.

—
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:>

[Mark_Roddy]

Greg, MSFT has supported basic C++ features like classes, templates, etc.
in the kernel for quite a while now. The issue at hand is the lack of
support for standard libraries (and the inexplicable lack of basic runtime
support, but that is somewhat separate.)

Mark Roddy

On Fri, Jan 19, 2018 at 10:11 AM, xxxxx@pdq.net
wrote:

>
> Let’s keep something in mind here during this discussion. We’re talking
> about kernel code, not some simple application or web server.
>
> Kernel programming, by its very nature, is unique. It has unique
> constraints and challenges and the consequences of failure are much
> higher. There are reasons why things like user-thrown exceptions and
> wasteful stack operations are difficult, if not impossible, to use in the
> kernel.
>
> All these user-mode libraries and frameworks (stl, et. al.) were designed
> with a completely different environment in mind and are simply not suitable
> for use in the kernel. They were designed to make life easier for everyday
> run-of-the-mill apps code slingers. They were NOT meant for memory or
> performance efficiency. Take a look at the bloat and inefficiencies of
> some of these standard class libraries. Do you REALLY want something like
> MFC in ring 0?
>
> I, for one, do NOT want it easy for just anyone to haphazardly slap
> together code and just start running it in the kernel. Kernel programming
> is an exacting sub-field of programming. This list alone is replete with
> REALLY bad ideas newbie apps programmers came up with because they didn’t
> know any better. Unfortunately, the industry, and even some on this list,
> are pushing to make is to anyone can THINK they are a kernel programmer.
> And we wonder why there are so many crappy drivers out there?
>
> What AM I in favor of? I would love to see classes work and work well
> in the kernel. I would love to see enhancements in C++ that would work
> well with the unique memory management aspects of kernel programming such
> as pageable vs non-pageable chunks of memory, user vs kernel memory
> separations (Can we say Meltdown and Spectre?), kernel-supported exception
> catching and VERY light stack usage just to name a few.
>
> I have been fortunate to work on an operating system that DID allow C++ in
> its kernel and device drivers since its inception and supported it well as
> long as the BSP/driver developers understood the environment.
> Unfortunately, Microslop mishandled it and dropped it completely. I’d love
> for desktop Windows to catch up.
>
> OK, rant over. I’ll crawl back into my hole now.
>
> Greg
>
>
>
>
> — xxxxx@lists.osr.com wrote:
>
> From: “xxxxx@gmail.com”
> To: “Windows System Software Devs Interest List”
> Subject: RE:[ntdev] C++ standards proposal for kernel STL subset
> Date: Thu, 18 Jan 2018 20:02:07 -0500 (EST)
>
> > I believe this is a toolchain issue, and not a standards issue.
>
> Yes and now that we are in 2018 it is incomprehensible Microsoft has not
> done anything about this. When visual studio driver building came online I
> thought surely they would fix it just for that, but no.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> 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&gt;
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> 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&gt;
></http:></http:></http:></http:>

[Ben_Craig]

xxxxx@pdq.net said:

Kernel programming, by its very nature, is unique. It has unique constraints
and challenges and the consequences of failure are much higher. There are
reasons why things like user-thrown exceptions and wasteful stack
operations are difficult, if not impossible, to use in the kernel.

All these user-mode libraries and frameworks (stl, et. al.) were designed with
a completely different environment in mind and are simply not suitable for
use in the kernel. They were designed to make life easier for everyday run-
of-the-mill apps code slingers. They were NOT meant for memory or
performance efficiency. Take a look at the bloat and inefficiencies of some
of these standard class libraries. Do you REALLY want something like MFC in
ring 0?

My paper addresses these concerns. None of the facilities I’m suggesting allocate heap memory. None of them throw, assuming that the user’s type doesn’t throw.