Windows memory management and protection discuss

NTDEV
61

EXACTLY! By the time this ferments completely, I will be feeling really
sorry for the flight attendants on Jet Blue…

-dave

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Friday, September 26, 2008 1:37 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Windows memory management and protection discuss

Yes. But some of us got bored explaining the rudiments of memory
management. And Anton set to trolling with talk of “anti C diatribes”,
promoting “singularity”, and talk of what “real programmers” do or do not
do/know.

So, because it was more fun than actually doing work, it’s a Friday and all
I really need to do is get ready to go to Microsoft, I figured I’d
“elaborate” and contribute further to side-tracking an already sidetracked
thread.

Sic transit gloria mundi,

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

62

W. Edwards Deming.

I agree. Software Engineering isn’t. I think we touched on this before, in another thread, many weeks back. Software is art. It’s craftsmanship. It ain’t science and it sure ain’t engineering.

I would say some some of verifiability is a must.

Having said that, there will ALWAYS be art in engineering. Correct is not necessarily the same as optimal.

Peter
OSR

63

Thanks for the name ( Mr Deming)…

And finally, yes this is what I believe ( as you noted in your post )…

-pro

On Fri, Sep 26, 2008 at 10:57 AM, wrote:

>


>
> W. Edwards Deming.
>
>


>
> I agree. Software Engineering isn’t. I think we touched on this before,
> in another thread, many weeks back. Software is art. It’s craftsmanship.
> It ain’t science and it sure ain’t engineering.
>
> I would say some some of verifiability is a must.
>
> Having said that, there will ALWAYS be art in engineering. Correct is not
> necessarily the same as optimal.
>
> Peter
> OSR
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

64

> And Anton set to trolling with talk of “anti C diatribes”, promoting “singularity”,

and talk of what “real programmers” do or do not do/know.

When I saw Ken’s statement I was about to say “I bet Peter is going to blame it one me”. However, after scrolling down the page I have realized that I am a bit too late here…

I figured I’d “elaborate” and contribute further to side-tracking an already sidetracked thread.

Actually, you have elaborated quite well. As I said, “get ready to see “anti-C diatribes” and the paragraphs explaining the great advantages of C# from the usual suspects in not-so-distant future”. Therefore, you had successfully proved that the future I was speaking about was just minutes away - you have responded with anti-C diatribe straight away, and immediately placed your bet on “some managed language for the system-level programming”(although, strange enough, you did not make it clear that this is C#) …

BTW, Ken has made a wonderful statement about specialization. Indeed, these days there are different types of developers that are working at the different levels of architecture, and they need different tools for their work. What would you say to someone who offers you to write a database app in assembly??? You should expect exactly the same response from the system-level developers when offering them to use managed languages in their work. There is nothing wrong with C# in itself, but this is just not the right language for system-level programmers - it is pretty much the same thing as using a hammer for screws…

Anton Bassov

65

Would you believe that I worked on a very large, commercially successful, data application – including GUI – that was entirely written in MACRO-11? It was a large retail credit authorization system that ran on a PDP-11. Everything from the OS to the drivers (my job) to the credit authorization algorithm, to the screen management. Every bit of it in MACRO-11.

If someone were to say they were going to write ANYTHING in assembler language today, I would ask “Why are you using such antiquated technology?”

It wouldn’t be like using a hammer for screws… it’d be like using a stone ax to cut trees. We’ve been there, we’ve done that, we’ve invented far better new stuff.

And so it will be some day for C and operating systems. Until that time, we’ll be stuck with SAL notations, and PreFast to catch errors that you aren’t even able to MAKE in managed languages.

But, you know… I see your point. We’ve written operating systems in C for 30+ years, so it must be good forever into the future. Like that stone ax.

Soooo… keep hacking away with that stone ax, you’ll get the tree cut down eventually. Me? I’m firing up my Husqvarna http: and have the job done… with no appreciation or nostalgia for stone axes whatsoever.

Peter
OSR</http:>

66

Sound power level, LWA 114 dB (Argh). If you use that for tackling every
challenge you face then soon you be deaf (and all your problems will start
to look like christmas trees).

Seriously though, I thought that drivers will belong in usermode so Antons
argument about system-level development does not apply no more.

//Daniel

Soooo… keep hacking away with that stone ax, you’ll get the tree cut
down eventually. Me? I’m firing up my Husqvarna
http: and have
> the job done… with no appreciation or nostalgia for stone axes
> whatsoever.
>
> Peter
> OSR
>
>
></http:>

67

Yeah, but that’s A-weighted :slight_smile:

I wear BOTH ear plugs and ear muff protectors. Seriously. I’ve already lost enough of my hearing skeet shooting.

Quite so. Absolutely correct. In user mode and in ANY modern language.

Perhaps we should advocate for using Haskell? It’s used in Linspire (which is Unix, really, so Anton should love it). And many of the world’s cell phone systems. And forms the basis for BSV (Blue Spec Verilog), which I mention in my next pontification in The NT Insider.

Haskell does automatic garbage collection and it has no pointers… So while it’s not C#, it has some of “the right stuff.” Now, whether you think functional programming is great or not is another story.

Peter
OSR

68

Engineers or not?

From my previous and present work experiences, I figured that enginneers use a lot of math and physics in their work while we don’t. Knowing the Laplace Transform of e^(j*omega*t) doesn’t help much writing a driver.

–
Calvin Guan
NetXtreme II 10Gbps Converged NIC
Broadcom Corp.
Connecting Everything(r)

— On Fri, 9/26/08, Prokash Sinha wrote:

> From: Prokash Sinha
> Subject: Re: [ntdev] Windows memory management and protection discuss
> To: “Windows System Software Devs Interest List”
> Received: Friday, September 26, 2008, 10:43 AM
> While we are at it …
>
> I’ve always thought ( and still think about ) certain
> things ----
>
> (0) what would it make or what do we need to make this
> programming to an
> engineering discipline? Just don’t call it as you
> wish(ed), but take a back
> sit a think what would it take to call it engineering …
> ? Well I would
> buy that engineering is a combination of (a) art (b)
> science… Then what
> the science part here… I know the art part somwhat:
> forexample don’t
> initialize stack variables, use more the 16KB as locals in
> KM code, use
> macros everywhere one fills like a gross ( gross == macro),
> write switch
> stmt with atleast 379 cases otherwise use if-then-else, run
> your c code thru
> lister so you get the assemble code, take/copy and paste
> back to your c code
> and feel you touched the metal (hot or cold ) …
>
> (1) When we find some science behind it, what are the ways
> to measure
> things, units of measure, confidence analysis and all that
> …
>
>
> I think, if not for anything else, verifiablity to an
> extent, and
> adjustablity/managibilty would move us to different
> approach to programming
> … C#, F# … no-sharp and whatever … And yes we need
> to move on before
> we call us engineers … Please takeout the word engineer
> in your business
> card ( it’s an earnest request ).
>
> In the 50s, (I forgot the name) American person wanted to
> introduce Sampling
> theory into the world of manufacturing/engineer, and was
> deeply rejected.
> But japan took him as an expert and proved that there is
> such a thing we
> need …
>
> -pro
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars
> visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer

__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!

http://www.flickr.com/gift/

69

Calvin Guan wrote:

Engineers or not?

From my previous and present work experiences, I figured that enginneers use a lot of math and physics in their work while we don’t. Knowing the Laplace Transform of e^(j*omega*t) doesn’t help much writing a driver.

Well, as a video capture and codec person, I can assure you that I got
my money’s worth out of those college mathematics courses. You can’t
play seriously in the world of JPEG amd MPEG unless you are quite
comfortable with trigonometry, and have a fairly reasonable grasp of
Fourier transforms.

Ever seen the equations for wavelet compression? Zowie.

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

70

Don’t forget the chemistry and biology too ( along with other branches of
science :-).

While most of the maths behind classical engineerings relate to classical or
continuous math, we as programmers are mostly under the discrete domain…,
including the logic we try to use (conciously or sub-conciously )… So
there is an element of science in it, but we mostly try to ignore it …
Good or bad is not the question here though. But it is almost clear that lot
of our creation are mostly based on Art or Craft. Should it change?. I think
it should. There has to be a systematic/methodical ( somewhat scientific)
way to do programming, proofing,debugging etc… Not every place has this
yet !!!

As a personal preference: I would love to program in functional language,
that has the proof system behind it… Not a total proof system perhaps, but
would cach me when I’m running fast with the keyboard or when have a mental
fatigue or when I’m simply stupid…

Legend:: continuous math -> Any math whose dimensions are real line or
complex plane. Other maths are discerete…

-pro

On Fri, Sep 26, 2008 at 3:03 PM, Calvin Guan wrote:

> Engineers or not?
>
> From my previous and present work experiences, I figured that enginneers
> use a lot of math and physics in their work while we don’t. Knowing the
> Laplace Transform of e^(jomegat) doesn’t help much writing a driver.
>
> –
> Calvin Guan
> NetXtreme II 10Gbps Converged NIC
> Broadcom Corp.
> Connecting Everything(r)
>
>
>
> — On Fri, 9/26/08, Prokash Sinha wrote:
>
> > From: Prokash Sinha
> > Subject: Re: [ntdev] Windows memory management and protection discuss
> > To: “Windows System Software Devs Interest List”
> > Received: Friday, September 26, 2008, 10:43 AM
> > While we are at it …
> >
> > I’ve always thought ( and still think about ) certain
> > things ----
> >
> > (0) what would it make or what do we need to make this
> > programming to an
> > engineering discipline? Just don’t call it as you
> > wish(ed), but take a back
> > sit a think what would it take to call it engineering …
> > ? Well I would
> > buy that engineering is a combination of (a) art (b)
> > science… Then what
> > the science part here… I know the art part somwhat:
> > forexample don’t
> > initialize stack variables, use more the 16KB as locals in
> > KM code, use
> > macros everywhere one fills like a gross ( gross == macro),
> > write switch
> > stmt with atleast 379 cases otherwise use if-then-else, run
> > your c code thru
> > lister so you get the assemble code, take/copy and paste
> > back to your c code
> > and feel you touched the metal (hot or cold ) …
> >
> > (1) When we find some science behind it, what are the ways
> > to measure
> > things, units of measure, confidence analysis and all that
> > …
> >
> >
> > I think, if not for anything else, verifiablity to an
> > extent, and
> > adjustablity/managibilty would move us to different
> > approach to programming
> > … C#, F# … no-sharp and whatever … And yes we need
> > to move on before
> > we call us engineers … Please takeout the word engineer
> > in your business
> > card ( it’s an earnest request ).
> >
> > In the 50s, (I forgot the name) American person wanted to
> > introduce Sampling
> > theory into the world of manufacturing/engineer, and was
> > deeply rejected.
> > But japan took him as an expert and proved that there is
> > such a thing we
> > need …
> >
> > -pro
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars
> > visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online
> > at http://www.osronline.com/page.cfm?name=ListServer
>
>
> __________________________________________________________________
> Looking for the perfect gift? Give the gift of Flickr!
>
> http://www.flickr.com/gift/
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

71

> we’ll be stuck with SAL notations, and PreFast

Well, you should realize that not everyone happens to be in this unfortunate position of having to deal with fundamentally broken system. More on it below…

We’ve written operating systems in C for 30+ years

Indeed, and that’s despite the fact that managed languages have been around all that time. Has it ever occurred to you, by any chance, to think that if people have been doing something for 30+ years this or that way without any interest in any fundamental innovations, it may well happen that they had just accidentally stumbled upon something that happens the most reasonable and convenient approach???

Soooo… keep hacking away with that stone ax, you’ll get the tree cut down eventually.
Me? I’m firing up my Husqvarna and have the job done… with no appreciation or nostalgia
for stone axes whatsoever.

Well, it depends on your targets. If you are planning to cut thick timber, then, indeed, it makes sense to use a chainsaw. However, as long as we speak about a bush, it would be much better idea to use old-fashioned garden scissors.

The general rule of UNIX kernel can be described as “Gee, that’s dodgy…let’s do it in the UM then”. However, Windows put an awful lot of stuff that objectively belongs in the UM, right to the kernel. It went as far as dealing with HTTP server-related stuff right in the kernel. If we combine it with its fundamentally broken driver model that is based upon IRPs, its centralized PnP management and resource allocation, we get to the position where we need to write complex drivers that have to deal with the stuff that is totally unrelated to its actual functionality 90% of the time. This is why they are looking for managed languages.
However, if they designed a proper kernel the way it is being done by everyone else in the last 30+ years, probably they would still be happy with old-fashioned C

The bottom line - before you buy your chainsaw, first try to find the right targets. Who knows, maybe you will be able to do the job with old-fashioned garden scissors, and do it much faster…

Anton Bassov

72

My chemistry was horrible I hated it the most, but damn it, it’s mandatory for every engineering student.

To hammer discrete-time system, such as digital systems, we use Discrete Fourier Transform, z-transform, difference equations, state-space analysis etc.

One of many beauties of traditional EE (as opposed to verilog/vhdl programming) is that one can characterize the system dynamics by putting down a set of governing differential equations, solve 'em, predict the performance & limitations and find the optimal solutions mathematically.

I tried to apply the similar quantitative analysis to my programming work but it’s not very successful. Maybe just because I don’t have a degree in CS.

–
Calvin Guan
NetXtreme II 10Gbps Converged NIC
Broadcom Corp.
Connecting Everything(r)

— On Fri, 9/26/08, Prokash Sinha wrote:

> From: Prokash Sinha
> Subject: Re: [ntdev] Windows memory management and protection discuss
> To: “Windows System Software Devs Interest List”
> Received: Friday, September 26, 2008, 3:36 PM

> Don’t forget the chemistry and biology too ( along with
> other branches of
> science :-).
>
> While most of the maths behind classical engineerings
> relate to classical or
> continuous math, we as programmers are mostly under the
> discrete domain…,
> including the logic we try to use (conciously or
> sub-conciously )… So
> there is an element of science in it, but we mostly try to
> ignore it …
> Good or bad is not the question here though. But it is
> almost clear that lot
> of our creation are mostly based on Art or Craft. Should it
> change?. I think
> it should. There has to be a systematic/methodical (
> somewhat scientific)
> way to do programming, proofing,debugging etc… Not every
> place has this
> yet !!!
>
> As a personal preference: I would love to program in
> functional language,
> that has the proof system behind it… Not a total proof
> system perhaps, but
> would cach me when I’m running fast with the keyboard
> or when have a mental
> fatigue or when I’m simply stupid…
>
> Legend:: continuous math -> Any math whose dimensions
> are real line or
> complex plane. Other maths are discerete…
>
> -pro
>
>
>
>
>
>
> On Fri, Sep 26, 2008 at 3:03 PM, Calvin Guan
> wrote:
>
> > Engineers or not?
> >
> > From my previous and present work experiences, I
> figured that enginneers
> > use a lot of math and physics in their work while we
> don’t. Knowing the
> > Laplace Transform of e^(jomegat) doesn’t help
> much writing a driver.
> >
> > –
> > Calvin Guan
> > NetXtreme II 10Gbps Converged NIC
> > Broadcom Corp.
> > Connecting Everything(r)
> >
> >
> >
> > — On Fri, 9/26/08, Prokash Sinha
> wrote:
> >
> > > From: Prokash Sinha
> > > Subject: Re: [ntdev] Windows memory management
> and protection discuss
> > > To: “Windows System Software Devs Interest
> List”
> > > Received: Friday, September 26, 2008, 10:43 AM
> > > While we are at it …
> > >
> > > I’ve always thought ( and still think about )
> certain
> > > things ----
> > >
> > > (0) what would it make or what do we need to make
> this
> > > programming to an
> > > engineering discipline? Just don’t call it as
> you
> > > wish(ed), but take a back
> > > sit a think what would it take to call it
> engineering …
> > > ? Well I would
> > > buy that engineering is a combination of (a) art
> (b)
> > > science… Then what
> > > the science part here… I know the art part
> somwhat:
> > > forexample don’t
> > > initialize stack variables, use more the 16KB as
> locals in
> > > KM code, use
> > > macros everywhere one fills like a gross ( gross
> == macro),
> > > write switch
> > > stmt with atleast 379 cases otherwise use
> if-then-else, run
> > > your c code thru
> > > lister so you get the assemble code, take/copy
> and paste
> > > back to your c code
> > > and feel you touched the metal (hot or cold ) …
> > >
> > > (1) When we find some science behind it, what are
> the ways
> > > to measure
> > > things, units of measure, confidence analysis and
> all that
> > > …
> > >
> > >
> > > I think, if not for anything else, verifiablity
> to an
> > > extent, and
> > > adjustablity/managibilty would move us to
> different
> > > approach to programming
> > > … C#, F# … no-sharp and whatever … And yes
> we need
> > > to move on before
> > > we call us engineers … Please takeout the word
> engineer
> > > in your business
> > > card ( it’s an earnest request ).
> > >
> > > In the 50s, (I forgot the name) American person
> wanted to
> > > introduce Sampling
> > > theory into the world of manufacturing/engineer,
> and was
> > > deeply rejected.
> > > But japan took him as an expert and proved that
> there is
> > > such a thing we
> > > need …
> > >
> > > -pro
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other
> seminars
> > > visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of
> OSR Online
> > > at
> http://www.osronline.com/page.cfm?name=ListServer
> >
> >
> >
>
> > Looking for the perfect gift? Give the gift of Flickr!
> >
> > http://www.flickr.com/gift/
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other
> seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR
> Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars
> visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online
> at http://www.osronline.com/page.cfm?name=ListServer
Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://ca.promos.yahoo.com/newmail/overview2/

73

Of course people wrote OS’es in assember for almost 40 years, I don’t see a
lot of that anymore. Yes there were managed languages 30 years ago, but
they were pretty inadequate for anything in the OS realm. Also, of course
there is an overhead with managed languages and 30 years ago people were
scraping for the last cycle, today most systems run idle 50% or more.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

wrote in message news:xxxxx@ntdev…
>> we’ll be stuck with SAL notations, and PreFast
>
> Well, you should realize that not everyone happens to be in this
> unfortunate position of having to deal with fundamentally broken system.
> More on it below…
>
>> We’ve written operating systems in C for 30+ years
>
> Indeed, and that’s despite the fact that managed languages have been
> around all that time. Has it ever occurred to you, by any chance, to
> think that if people have been doing something for 30+ years this or that
> way without any interest in any fundamental innovations, it may well
> happen that they had just accidentally stumbled upon something that
> happens the most reasonable and convenient approach???
>

74

Frankly Cavin, I found science is a totally different thing… It is more of
a thinking than taking course. But surely, if someone take those courses and
like it, then that gives one a very very handy set of tools and perhaps
tuned the brain to think along that line. (BTW, there is a dog came to Opra
show that knows how to count — my wife taped it for me, and insisted I
watch it… I was amazed). …

But if you think about the CS guys, they don’t have enough exposure to
classical area of science and math, particulary when they are in
Undergraduate course. In graduate course, every one has options and everyone
tries to stay out of the trouble… they, in most cases, miss the part what
you and I’ve. May be i had the luck in disguise that my original backgroud
was “Applied science and Math”. Then I went to CS… It comes handy at times
!

-pro

On Fri, Sep 26, 2008 at 4:25 PM, Calvin Guan wrote:

> My chemistry was horrible I hated it the most, but damn it, it’s mandatory
> for every engineering student.
>
> To hammer discrete-time system, such as digital systems, we use Discrete
> Fourier Transform, z-transform, difference equations, state-space analysis
> etc.
>
> One of many beauties of traditional EE (as opposed to verilog/vhdl
> programming) is that one can characterize the system dynamics by putting
> down a set of governing differential equations, solve 'em, predict the
> performance & limitations and find the optimal solutions mathematically.
>
> I tried to apply the similar quantitative analysis to my programming work
> but it’s not very successful. Maybe just because I don’t have a degree in
> CS.
>
> –
> Calvin Guan
> NetXtreme II 10Gbps Converged NIC
> Broadcom Corp.
> Connecting Everything(r)
>
>
>
> — On Fri, 9/26/08, Prokash Sinha wrote:
>
> > From: Prokash Sinha
> > Subject: Re: [ntdev] Windows memory management and protection discuss
> > To: “Windows System Software Devs Interest List”
> > Received: Friday, September 26, 2008, 3:36 PM
>
> > Don’t forget the chemistry and biology too ( along with
> > other branches of
> > science :-).
> >
> > While most of the maths behind classical engineerings
> > relate to classical or
> > continuous math, we as programmers are mostly under the
> > discrete domain…,
> > including the logic we try to use (conciously or
> > sub-conciously )… So
> > there is an element of science in it, but we mostly try to
> > ignore it …
> > Good or bad is not the question here though. But it is
> > almost clear that lot
> > of our creation are mostly based on Art or Craft. Should it
> > change?. I think
> > it should. There has to be a systematic/methodical (
> > somewhat scientific)
> > way to do programming, proofing,debugging etc… Not every
> > place has this
> > yet !!!
> >
> > As a personal preference: I would love to program in
> > functional language,
> > that has the proof system behind it… Not a total proof
> > system perhaps, but
> > would cach me when I’m running fast with the keyboard
> > or when have a mental
> > fatigue or when I’m simply stupid…
> >
> > Legend:: continuous math -> Any math whose dimensions
> > are real line or
> > complex plane. Other maths are discerete…
> >
> > -pro
> >
> >
> >
> >
> >
> >
> > On Fri, Sep 26, 2008 at 3:03 PM, Calvin Guan
> > wrote:
> >
> > > Engineers or not?
> > >
> > > From my previous and present work experiences, I
> > figured that enginneers
> > > use a lot of math and physics in their work while we
> > don’t. Knowing the
> > > Laplace Transform of e^(jomegat) doesn’t help
> > much writing a driver.
> > >
> > > –
> > > Calvin Guan
> > > NetXtreme II 10Gbps Converged NIC
> > > Broadcom Corp.
> > > Connecting Everything(r)
> > >
> > >
> > >
> > > — On Fri, 9/26/08, Prokash Sinha
> > wrote:
> > >
> > > > From: Prokash Sinha
> > > > Subject: Re: [ntdev] Windows memory management
> > and protection discuss
> > > > To: “Windows System Software Devs Interest
> > List”
> > > > Received: Friday, September 26, 2008, 10:43 AM
> > > > While we are at it …
> > > >
> > > > I’ve always thought ( and still think about )
> > certain
> > > > things ----
> > > >
> > > > (0) what would it make or what do we need to make
> > this
> > > > programming to an
> > > > engineering discipline? Just don’t call it as
> > you
> > > > wish(ed), but take a back
> > > > sit a think what would it take to call it
> > engineering …
> > > > ? Well I would
> > > > buy that engineering is a combination of (a) art
> > (b)
> > > > science… Then what
> > > > the science part here… I know the art part
> > somwhat:
> > > > forexample don’t
> > > > initialize stack variables, use more the 16KB as
> > locals in
> > > > KM code, use
> > > > macros everywhere one fills like a gross ( gross
> > == macro),
> > > > write switch
> > > > stmt with atleast 379 cases otherwise use
> > if-then-else, run
> > > > your c code thru
> > > > lister so you get the assemble code, take/copy
> > and paste
> > > > back to your c code
> > > > and feel you touched the metal (hot or cold ) …
> > > >
> > > > (1) When we find some science behind it, what are
> > the ways
> > > > to measure
> > > > things, units of measure, confidence analysis and
> > all that
> > > > …
> > > >
> > > >
> > > > I think, if not for anything else, verifiablity
> > to an
> > > > extent, and
> > > > adjustablity/managibilty would move us to
> > different
> > > > approach to programming
> > > > … C#, F# … no-sharp and whatever … And yes
> > we need
> > > > to move on before
> > > > we call us engineers … Please takeout the word
> > engineer
> > > > in your business
> > > > card ( it’s an earnest request ).
> > > >
> > > > In the 50s, (I forgot the name) American person
> > wanted to
> > > > introduce Sampling
> > > > theory into the world of manufacturing/engineer,
> > and was
> > > > deeply rejected.
> > > > But japan took him as an expert and proved that
> > there is
> > > > such a thing we
> > > > need …
> > > >
> > > > -pro
> > > >
> > > > —
> > > > NTDEV is sponsored by OSR
> > > >
> > > > For our schedule of WDF, WDM, debugging and other
> > seminars
> > > > visit:
> > > > http://www.osr.com/seminars
> > > >
> > > > To unsubscribe, visit the List Server section of
> > OSR Online
> > > > at
> > http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> > >
> >
> > > Looking for the perfect gift? Give the gift of Flickr!
> > >
> > > http://www.flickr.com/gift/
> > >
> > > —
> > > NTDEV is sponsored by OSR
> > >
> > > For our schedule of WDF, WDM, debugging and other
> > seminars visit:
> > > http://www.osr.com/seminars
> > >
> > > To unsubscribe, visit the List Server section of OSR
> > Online at
> > > http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars
> > visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online
> > at http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> Get a sneak peak at messages with a handy reading pane with All new Yahoo!
> Mail: http://ca.promos.yahoo.com/newmail/overview2/
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

75

(emphasis added)

No. Not even for a second. Seriously.

I find such thinking in the face of massive technological advancement, and multiple magnitude paradigm shifts, to be positively laughable.

You can keep beating on your car with that buggy whip that you insist on using. Those buggy whips, they worked for over 100 years! That must mean they were, and continue to be, THE MOST REASONABLE AND CONVENIENT way to manage your transportation needs. Doesn’t matter that we changed from horse and buggy to car. Yup. That buggy whip sure is great.

RIGHT!! Because… that makes the features that are intrinsic to the language (which is what we’re talking about) like pointers and buffer management much more reliable. You’re right. Gee, what was I thinking? You compile your C code for the Unix kernel and, BINGO! You’ll never ++ your way past the end of a buffer again! Those Unix folks ARE clever…

As far as no “interest in any fundamental innovations” in programming languages… You must not get out much. Did you miss my mention of Haskell? Just to choose one language for fun. One I don’t even know, to be honest.

Peter
OSR

76


From my previous and present work experiences, I figured that enginneers use
a lot of math and physics in their work while we don’t. Knowing the Laplace
Transform of e^(jomegat) doesn’t help much writing a driver.

I find myself in the uncomfortable position of disagreeing with Mr. Guan,
someone I have not met but respect greatly for his contribution to this
list.

Engineering as I try to practice and explain it (teach it sometimes) is
about discipline more than anything else. The mathematics associated with
an Engineering education is really more like the physical conditioning an
athlete performs in training for a particular event. It is about exercising
the mental (in the case of engineering) systems which beget the conditioning
to perform.

So yeah, I can hardly remember the details of Laplace transforms, most of
set theory, heck, all of differential equations, but what I do remember is
that these were all very difficult, detail laden and dense concepts which we
all trudged through with discipline.

Engineering is about the discipline to find solutions that are repeatable,
measurable, the thus improvable. It is about never being satisfied with
‘one’, seeking to do it again better, finding ways to measure how you did
last time so that you can improve next time. It is about seeking a better
solution each time but delivering a predictable result every time. Indeed,
sometimes that comes with revolution and sometimes it comes with long, hard,
refinement.

A good engineer in my book is one that is always looking for how to both
improve the on the past and for ways to replace the past. No solved problem
should ever be the last solution just because it works. Yet the fact that
it works should never be discounted nor under-estimated.

And for the record, I am just so glad that I don’t remember what the Laplace
transform of e^(j*omega*t) is. I long ago discovered symbolic calculators,
in fact, without DiffEQ (I think that was the name, a fine TOPS20 program),
I would have had to take Differential Equations a second time. Now it is
MathCAD and nobody thinks twice about that fantastic tool as *the* way to
solve some very difficult problems.

I got my log-log-deci-trig K&E slide-rule right here next to me and yup, I
remember how to use it. But hey, I also have more HP calculators (broken
and otherwise) and Wikipedia too to answer those calculus questions the kids
bring in. I’m an engineer. I found a better way (or it found me, no
matter).

I think engineers use lots of discipline always; math, physics, psychology,
marksmanship, welding, biology, or any other skill as necessary for the job
at hand. But the cycle of “plan, measure, improve” is what makes it
engineering. Science is predict, test, refine. Art is create, appreciate.
Engineering is repeatability. Science is exploration. Art is magic.

An engineer is truly not surprised when it works. That was the expected
outcome. I have always had trouble relating that to non-engineers;
especially the behavior of being critical of a successful outcome and
looking immediately for a way to improve. My kids refer to that as the
“What did Dad say about my grade of 95 on the test? He asked me what I got
wrong!” Yup. That is an engineer.

-dave

77

> No. Not even for a second. Seriously

Well, perhaps, you should give it a try…

I find such thinking in the face of massive technological advancement, and
multiple magnitude paradigm shifts, to be positively laughable.

Well, you can laugh as much as you want, but there are some certain things that just never change. Just to give you an idea, somehow it happened that, since the beginning of the world, people have been walking with their faces forward, rather than with their backs forward while looking over their shoulder. Please note that there are no biological reasons why the latter cannot be done - if you try it, you will see that it can be done pretty easily. The only problem is that you are going to find it inconvenient for yourself, so that, after a short while, you are going to give up all your ideas of making some kind of " revolution in walking", no matter how desperate you are to bring some innovation into this world.

I strongly suspect that we are facing more or less the same scenario - although there are no technical reasons that make writing OSes in managed languages impossible, people just find it inconvenient and unreasonable. Therefore, I am afraid you are just advertising some kind of “revolutionary approach to walking”…

You can keep beating on your car with that buggy whip that you insist on using.

The above example would be appropriate if modern computers relied upon some logical principles that are basically different from the ones that earlier computers relied upon. For example, when (and if) quantum computer gets built, apparently, all concepts that we know today will become meaningless, and, at this point, your example becomes appropriate. However, for the time being, what we are getting are more and more powerful horses that, despite their increasing power, are still horses, so that the good old whip is still the right tool for them…

Because… that makes the features that are intrinsic to the language (which is what we’re talking about)

Sorry, this is NOT what we are talking about. What we are talking about is whether use of a given language *for a given purpose* is reasonable - we are not discussing relative strengths and weaknesses of any given language, are we??? As I said already, I have nothing against C# or any other managed language- they all have their own applications, and in many cases it is more reasonable to use these languages, rather than C. However, kernel-level development is not among these cases - this is the only thing I am saying…

You compile your C code for the Unix kernel and, BINGO! You’ll never ++ your way past the
end of a buffer again!

The larger the amount of your code, the higher the chance of a bug in it. If your code is modular and broken into numerous small-sized components with very well-defined and specific functionalities, it is much easier for you to see your bug. UNIX kernel encourages you to keep all your components small and specific for their purpose, while Windows forces you to do exactly the opposite, which tremendously increases the complexity of your code, and, hence, chances of introducing bugs into it…

Those Unix folks ARE clever…

Well, they are not just clever- they are true geniuses. You really need to be the one in order to invent something like UNIX. To be honest, I just cannot possibly imagine anything more reasonable than that. It is pretty much like LEGO - you’ve got numerous small pieces with specific well-defined purposes and interfaces that you can dynamically combine *at the run time* in a way that suits you in a given situation, which is not necessarily known at the compile time. As long as piece X appears as piece Y to the client code, they can be substituted for one another, and none of them cares whether the actual client is a local user who types on the terminal, or a program that is located on another continent… The same is true for client code - it has no idea who is actually doing the job that it has requested. To make it even more interesting, these components may be written in different languages , which is completely transparent to their clients. All these components run on top of relatively smal kernel that interfaces the hardware and provides some basic services - whenever it needs something that may be cumbersome or dodgy, it delegates the job to the UM components. Perfectly reasonable system, don’t you think???

Shit, it looks like I am already talking about some “revolutionary object-oriented distributed technology” like COM. Nope - in actuality, this is just a good old UNIX of 1970s, so that whenever you hear about some fancy distributed technology, be sure that this is just a new implementation of a “good old wheel” that had been invented 40 years ago…

Around a week ago you asked me to explain how come that Cutler’s designs because so successful, but somehow failed to provide any convincing evidence of this success. AFAIK, all his designs were successful in this or that field only until they faced competition from UNIX-like systems in a given field.
IMHO, the main reason for this is complete lack of flexibility of his designs - unlike UNIX-like systems, they are all rigid and tightly-coupled…

Anton Bassov

78


On Fri, Sep 26, 2008 at 11:06 PM, wrote:
>
> Yes. But some of us got bored explaining the rudiments of memory
> management.


And that hurts. Answer for some of the general queries can be found
by searching some old thread. but are they always correct in today’s
context?
with time things change and something which was correct few years ago; might
not be correct as of today.

Our earth was always spherical; but for centuries man-kind believed it as a
flat surface.

In declaring a UNION to save memory was a good idea in C until we ended up
in structures whose declarations go over 1000’s of lines.
How do you explain the necessity of UNION in todays programming ?

Flexibility to type cast any type of variable to any thing else; might
have helped some initial lazy coding. But over the years they become the
most buggy parts of the code.
The path for many seniors members of this group might be like below
Assembly -> C -> C++ -> C#
but then you understand how difficult it is for a person who starts his life
with C#. He starts wriing thousands of line of code before he really learns
what programming is all about.

One of the top IT company in India has the following questions in their set
of questions meant for interviews(something that was encountered by one of
our friend)

Question : From a C Code; how to get an executable without the help of
Compiler & Linker ?
Expected Answer : Write the corresponding opcode(s) for each of the
C statements.

and I wonder the person who phrased this question & its answer is a
Programmer.

On Fri, Sep 26, 2008 at 11:06 PM, wrote:

>


>
> Yes. But some of us got bored explaining the rudiments of memory
> management. And Anton set to trolling with talk of “anti C diatribes”,
> promoting “singularity”, and talk of what “real programmers” do or do not
> do/know.
>
> So, because it was more fun than actually doing work, it’s a Friday and all
> I really need to do is get ready to go to Microsoft, I figured I’d
> “elaborate” and contribute further to side-tracking an already sidetracked
> thread.
>
> Sic transit gloria mundi,
>
> Peter
> OSR
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
When I was born I was so surprised I didn’t talk for a year and a half.

79

Well, take examples first !

Sun micro, an Unix vendor by itself… They started java, and they
strongly approached JavaOS… Why? There could be very many reasons for
it, right?..

But the fact was that, their research community showed them how
dangerous was C (even to kernel programming)… A very good friend of
mine is a vetaran there for almost 20 yrs, so I get to hear some stories
about it…

When I was in graduate school in the 80s ( that was only 10+ some year
from C’s birth ), there were huge efforts towards functional programming
already… Why? Perhaps some was just for fun, perhaps some was to show
how we can make science out of it, perhaps something else … But as I
understand, they already saw the need …

When Ken Thomson declared his OS, he mentioned less than (or just over)
a thousand lines of Assembly code, rest is C… What so great about it,
while IBM OS written in BAL dutifully made the world happy by keeping
internation financial transactions happy?

In the 70s parsing was an ART, actually an arcane one. Now lot of
science in it …

Behind all of these, there are things all can feel, some observes, and
some other measures. And when it make sense, they move forward.

Not everything has to be labeled under some flag or ism?. Do we?

Memory has a relationship with the underlying language, so it is not
that off tangent …

Couple question(s) would be —

(0) In the future ( let say 10 yrs from now), how much code would and
should be on your machine? And how much of it in privilage mode?.Then
what would be the machine like ? Can it just be a presentation device?
Can it be like a super-computer?

(1) What are defining criteria for measuring systems fundamental traits?
What are the fundamental traits? What are the methods to measure?..
And a whole of questions …

Lot of them are defined and or understood by people who drives the
researches and recommends new and hopefully better means to achieve
things… Denying it would be fine, but under what basis???

-pro

xxxxx@hotmail.com wrote:

> No. Not even for a second. Seriously
>

Well, perhaps, you should give it a try…

> I find such thinking in the face of massive technological advancement, and
> multiple magnitude paradigm shifts, to be positively laughable.
>

Well, you can laugh as much as you want, but there are some certain things that just never change. Just to give you an idea, somehow it happened that, since the beginning of the world, people have been walking with their faces forward, rather than with their backs forward while looking over their shoulder. Please note that there are no biological reasons why the latter cannot be done - if you try it, you will see that it can be done pretty easily. The only problem is that you are going to find it inconvenient for yourself, so that, after a short while, you are going to give up all your ideas of making some kind of " revolution in walking", no matter how desperate you are to bring some innovation into this world.

I strongly suspect that we are facing more or less the same scenario - although there are no technical reasons that make writing OSes in managed languages impossible, people just find it inconvenient and unreasonable. Therefore, I am afraid you are just advertising some kind of “revolutionary approach to walking”…

> You can keep beating on your car with that buggy whip that you insist on using.
>

The above example would be appropriate if modern computers relied upon some logical principles that are basically different from the ones that earlier computers relied upon. For example, when (and if) quantum computer gets built, apparently, all concepts that we know today will become meaningless, and, at this point, your example becomes appropriate. However, for the time being, what we are getting are more and more powerful horses that, despite their increasing power, are still horses, so that the good old whip is still the right tool for them…

> Because… that makes the features that are intrinsic to the language (which is what we’re talking about)
>

Sorry, this is NOT what we are talking about. What we are talking about is whether use of a given language *for a given purpose* is reasonable - we are not discussing relative strengths and weaknesses of any given language, are we??? As I said already, I have nothing against C# or any other managed language- they all have their own applications, and in many cases it is more reasonable to use these languages, rather than C. However, kernel-level development is not among these cases - this is the only thing I am saying…

> You compile your C code for the Unix kernel and, BINGO! You’ll never ++ your way past the
> end of a buffer again!
>

The larger the amount of your code, the higher the chance of a bug in it. If your code is modular and broken into numerous small-sized components with very well-defined and specific functionalities, it is much easier for you to see your bug. UNIX kernel encourages you to keep all your components small and specific for their purpose, while Windows forces you to do exactly the opposite, which tremendously increases the complexity of your code, and, hence, chances of introducing bugs into it…

> Those Unix folks ARE clever…
>

Well, they are not just clever- they are true geniuses. You really need to be the one in order to invent something like UNIX. To be honest, I just cannot possibly imagine anything more reasonable than that. It is pretty much like LEGO - you’ve got numerous small pieces with specific well-defined purposes and interfaces that you can dynamically combine *at the run time* in a way that suits you in a given situation, which is not necessarily known at the compile time. As long as piece X appears as piece Y to the client code, they can be substituted for one another, and none of them cares whether the actual client is a local user who types on the terminal, or a program that is located on another continent… The same is true for client code - it has no idea who is actually doing the job that it has requested. To make it even more interesting, these components may be written in different languages , which is completely transparent to their clients. All these components run on top of relatively smal kernel that interfaces the hardware and provides some basic services - whenever it needs something that may be cumbersome or dodgy, it delegates the job to the UM components. Perfectly reasonable system, don’t you think???

Shit, it looks like I am already talking about some “revolutionary object-oriented distributed technology” like COM. Nope - in actuality, this is just a good old UNIX of 1970s, so that whenever you hear about some fancy distributed technology, be sure that this is just a new implementation of a “good old wheel” that had been invented 40 years ago…

Around a week ago you asked me to explain how come that Cutler’s designs because so successful, but somehow failed to provide any convincing evidence of this success. AFAIK, all his designs were successful in this or that field only until they faced competition from UNIX-like systems in a given field.
IMHO, the main reason for this is complete lack of flexibility of his designs - unlike UNIX-like systems, they are all rigid and tightly-coupled…

Anton Bassov

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

80

> Perhaps we should advocate for using Haskell? It’s used in Linspire

(which is Unix, really, so Anton should love it)

Well, you’ve got pretty weird logic. According to this logic, I should be madly in love with C#, VB and all other .NET languages, simply because Linux supports them (this is what MONO is about)…

As I told you already, I have nothing against C#, Haskell, Tcl, Perl, bash, etc - they all have their own use. What I do find inappropriate is using these languages for OS-level design, exactly the same way I find it inappropriate to use assembly in web applications. I’ll tell you the secret - I write small shell scripts myself from time to time, because sometimes I find doing some tasks in C to be an overkill that is comparable to shooting a fly with a canon. However, there is no way that I would want to write system-level code in a scripting language…

Anton Bassov