Microkernel discussion continued....

[begin quote]

My Manifesto For Change: All drivers, except perhaps those needed to boot the system, should be in user mode… as should the vast majority of the operating system. Drivers should be restartable on error. All drivers, user-mode or not, should be “correct by construction” and written in high-level languages with only the very minimal-most support for direct pointer manipulation. ]

[end quote]

The above paragraph just describes how Singularity works, with run-time library running in the KM, and the rest of the OS in the user one. How “clever” (and,apparently, “efficient”) -typical MSFT-like “solution”…

As Darwin said: “Evolve or die!”

In fact, it looks more of a malevolent mutation, rather than “evolution”…

Anton Bassov

It also describes Chorus, although without the managed code
restrictions, which while very interesting was ultimately a failure.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, September 03, 2008 1:02 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Microkernel discussion continued…

[begin quote]

My Manifesto For Change: All drivers, except perhaps those needed to
boot the system, should be in user mode… as should the vast majority
of the operating system. Drivers should be restartable on error. All
drivers, user-mode or not, should be “correct by construction” and
written in high-level languages with only the very minimal-most support
for direct pointer manipulation. ]

[end quote]

The above paragraph just describes how Singularity works, with run-time
library running in the KM, and the rest of the OS in the user one. How
“clever” (and,apparently, “efficient”) -typical MSFT-like
“solution”…

As Darwin said: “Evolve or die!”

In fact, it looks more of a malevolent mutation, rather than
“evolution”…

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

xxxxx@hotmail.com wrote:

[begin quote]

My Manifesto For Change: All drivers, except perhaps those needed to boot the system, should be in user mode… as should the vast majority of the operating system. Drivers should be restartable on error. All drivers, user-mode or not, should be “correct by construction” and written in high-level languages with only the very minimal-most support for direct pointer manipulation. ]

[end quote]

The above paragraph just describes how Singularity works, with run-time library running in the KM, and the rest of the OS in the user one. How “clever” (and,apparently, “efficient”) -typical MSFT-like “solution”…

You disparage this, without seeming to grasp what it really represents.

Let me offer a parable. In the early part of the 20th century,
airplanes were things that were hand-crafted and hand-tuned, handled and
lovingly maintained by relative loonies who understood the purpose of
each nut and bolt. Today, you can still find such loonies, but they are
hobbyists. They do it for fun. The vast majority of the airplane-using
public just want to get from Chicago to Miami. I don’t care what grade
of hydraulic oil is driving those doohickies on the wings.

The same thing is going on in computing. Fifty years ago, we programmed
by writing lovingly hand-crafted and hand-tuned assembly code line by
line, squeezing every last millisecond out of every algorithm. The
advent of compilers meant that I could do 10 times as much work with
each line that I wrote, plus the compiler could keep me from hurting
myself. KMDF lets me write drivers by doing more work with each line
that I write, plus the framework keeps me from hurting myself. This is
a GOOD thing. I can write better drivers with less code, letting me get
my job done more efficiently. Managed code is another step in this
evolution. It lets me do 10 times as much work with each line of code,
plus the managed framework can keep me from hurting myself. Singularity
simply extends this paradigm into the operating system realm.

Now, there still exists a lunatic fringe that wants to write code in
lovingly hand-crafted assembler, but those people are hobbyists. They
aren’t getting real work done The hobbyists, the loonies, and the
hot-rodders will always want to tinker with the carburetor, install
chrome-plated rods, and worry about the last microsecond by maximizing
instruction pairing. Those people are perfectly welcome to go on
writing MASM to run under a DOS extender. However, those are not the
people who are getting real work done. The people who are getting real
work done want to produce working, large-scale systems. Singularity
lets me do that much more efficiently – optimizing MY efficiency, which
is much more valuable than the $250 piece of silicon sitting under my desk.

In fact, it looks more of a malevolent mutation, rather than “evolution”…

Only if you are a hobbyist.

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

Sounds all good and everything, but I think we are a LONG way from there.

Oh wait KMDF will do it all for us right?

While we are waiting billions of years for evolution to occur, how about we
make writing drivers the way they are today more approachable. I mean,
simply (not suggesting it is simple) documenting the APIs or DDIs correctly
and *thoroughly* would go a LONG way. Some good examples, like hey how
about KMDF source, would be really helpful as well.

I am all about new directions and solving the big problems, but in the mean
time if people REALLY want to make things better, it isn’t rocket science.
There are a lot of developers out there who really can grasp complex topics
if they are given the information they need. They really can. No really, I
am being serious. No no, I mean it…there are smart people out there that
do not work for Microsoft. Serious. No really.

Bill M.

“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@hotmail.com wrote:
>> [begin quote]
>>
>> My Manifesto For Change: All drivers, except perhaps those needed to boot
>> the system, should be in user mode… as should the vast majority of the
>> operating system. Drivers should be restartable on error. All drivers,
>> user-mode or not, should be “correct by construction” and written in
>> high-level languages with only the very minimal-most support for direct
>> pointer manipulation. ]
>>
>> [end quote]
>>
>>
>> The above paragraph just describes how Singularity works, with run-time
>> library running in the KM, and the rest of the OS in the user one. How
>> “clever” (and,apparently, “efficient”) -typical MSFT-like
>> “solution”…
>>
>
> You disparage this, without seeming to grasp what it really represents.
>
> Let me offer a parable. In the early part of the 20th century,
> airplanes were things that were hand-crafted and hand-tuned, handled and
> lovingly maintained by relative loonies who understood the purpose of
> each nut and bolt. Today, you can still find such loonies, but they are
> hobbyists. They do it for fun. The vast majority of the airplane-using
> public just want to get from Chicago to Miami. I don’t care what grade
> of hydraulic oil is driving those doohickies on the wings.
>
> The same thing is going on in computing. Fifty years ago, we programmed
> by writing lovingly hand-crafted and hand-tuned assembly code line by
> line, squeezing every last millisecond out of every algorithm. The
> advent of compilers meant that I could do 10 times as much work with
> each line that I wrote, plus the compiler could keep me from hurting
> myself. KMDF lets me write drivers by doing more work with each line
> that I write, plus the framework keeps me from hurting myself. This is
> a GOOD thing. I can write better drivers with less code, letting me get
> my job done more efficiently. Managed code is another step in this
> evolution. It lets me do 10 times as much work with each line of code,
> plus the managed framework can keep me from hurting myself. Singularity
> simply extends this paradigm into the operating system realm.
>
> Now, there still exists a lunatic fringe that wants to write code in
> lovingly hand-crafted assembler, but those people are hobbyists. They
> aren’t getting real work done The hobbyists, the loonies, and the
> hot-rodders will always want to tinker with the carburetor, install
> chrome-plated rods, and worry about the last microsecond by maximizing
> instruction pairing. Those people are perfectly welcome to go on
> writing MASM to run under a DOS extender. However, those are not the
> people who are getting real work done. The people who are getting real
> work done want to produce working, large-scale systems. Singularity
> lets me do that much more efficiently – optimizing MY efficiency, which
> is much more valuable than the $250 piece of silicon sitting under my
> desk.
>
>> In fact, it looks more of a malevolent mutation, rather than
>> “evolution”…
>>
>
> Only if you are a hobbyist.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>

[quote]
…All the lines of Tim’s reply ending with:

Only if you are a hobbyist.

[quote]

YAY!!! Somebody else with a brain who can see the future… who doesn’t suffer from paradigm paralysis! Somebody who isn’t stuck doing things “they way we’ve always done them!”

TIM ROBERTS TO THE RESCUE! Thanks, Tim. I was starting to doubt my own sanity.

Whew! I couldn’t have said it better myself, Tim. Beautifully written.

Here’s do getting real work done, and with the minimum effort possible.

Peter
OSR

Bill McKenzie wrote:

While we are waiting billions of years for evolution to occur, how about we
make writing drivers the way they are today more approachable. I mean,
simply (not suggesting it is simple) documenting the APIs or DDIs correctly
and *thoroughly* would go a LONG way. Some good examples, like hey how
about KMDF source, would be really helpful as well.

So the billion year wait is finally over, and here’s the superior life
form: the Penguin. www.kernel.org.
The code is the documentation - the whole kernel is completely, 100%
documented. All the real life, working drivers are to your service as
examples.

(Anybody not happy yet?! sure… never, ever can make everybody happy.)

Regards,
–PA

I agree with this utopia of an environment and know that maximizing my
time to develop some product for a client is of the utmost importance.
But having clients still requesting drivers for Windows NT 4.0/2000/XP
this is not realistic and will not be for at least another 5-10 years. I
am hopeful that by the time this paradigm is the norm being requested
from clients, I will be long retired and tinkering away at my own
projects in C and assembly.

I am not blind to the future, I am a realist in our present situation.

The models have changed, some for the better and some for the worse,
over the past decade but if the requirements which drive the market are
still requesting drivers that are not running on a future development
platform then I want to make the code I write the easiest to implement
and debug. I could really care less about Mr. Milktoast overwriting a
buffer in their driver since it will only shift the market into a more
manageable and realistic realm of not out sourcing kernel mode
development to Sing# based development companies and instead look for a
company which develops parts for the plane they are working on.

Pete

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

xxxxx@osr.com wrote:

[quote]
…All the lines of Tim’s reply ending with:

Only if you are a hobbyist.

[quote]

YAY!!! Somebody else with a brain who can see the future… who doesn’t suffer from paradigm paralysis! Somebody who isn’t stuck doing things “they way we’ve always done them!”

TIM ROBERTS TO THE RESCUE! Thanks, Tim. I was starting to doubt my own sanity.

Whew! I couldn’t have said it better myself, Tim. Beautifully written.

Here’s do getting real work done, and with the minimum effort possible.

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

I don’t agree with everything here, but it certainly would be hard to argue against improving the documentation (as in before more
extreme measures to improve reliability). A complete and accurate KRM and WinDbg RM would seem like a good starting point, with
complete, accurate, useful and REAL samples for the same (with heavy emphasis on the former) being a good encore. The good news is
that there are people at MSFT working on the documentation part of the problem as we speak, which did not appear to be the case a
little while back, so there is hope, but it does remain to be seen how it all works out, because all of this must of course coexist
within the budget constraints of competing ideas/tasks, like those for more extreme measures, for better or worse, not that this
probably has anything to do with Singularity in particular.

mm

Bill McKenzie wrote:

Sounds all good and everything, but I think we are a LONG way from there.

Oh wait KMDF will do it all for us right?

While we are waiting billions of years for evolution to occur, how about we
make writing drivers the way they are today more approachable. I mean,
simply (not suggesting it is simple) documenting the APIs or DDIs correctly
and *thoroughly* would go a LONG way. Some good examples, like hey how
about KMDF source, would be really helpful as well.

I am all about new directions and solving the big problems, but in the mean
time if people REALLY want to make things better, it isn’t rocket science.
There are a lot of developers out there who really can grasp complex topics
if they are given the information they need. They really can. No really, I
am being serious. No no, I mean it…there are smart people out there that
do not work for Microsoft. Serious. No really.

Bill M.

“Tim Roberts” wrote in message news:xxxxx@ntdev…
>> xxxxx@hotmail.com wrote:
>>> [begin quote]
>>>
>>> My Manifesto For Change: All drivers, except perhaps those needed to boot
>>> the system, should be in user mode… as should the vast majority of the
>>> operating system. Drivers should be restartable on error. All drivers,
>>> user-mode or not, should be “correct by construction” and written in
>>> high-level languages with only the very minimal-most support for direct
>>> pointer manipulation. ]
>>>
>>> [end quote]
>>>
>>>
>>> The above paragraph just describes how Singularity works, with run-time
>>> library running in the KM, and the rest of the OS in the user one. How
>>> “clever” (and,apparently, “efficient”) -typical MSFT-like
>>> “solution”…
>>>
>> You disparage this, without seeming to grasp what it really represents.
>>
>> Let me offer a parable. In the early part of the 20th century,
>> airplanes were things that were hand-crafted and hand-tuned, handled and
>> lovingly maintained by relative loonies who understood the purpose of
>> each nut and bolt. Today, you can still find such loonies, but they are
>> hobbyists. They do it for fun. The vast majority of the airplane-using
>> public just want to get from Chicago to Miami. I don’t care what grade
>> of hydraulic oil is driving those doohickies on the wings.
>>
>> The same thing is going on in computing. Fifty years ago, we programmed
>> by writing lovingly hand-crafted and hand-tuned assembly code line by
>> line, squeezing every last millisecond out of every algorithm. The
>> advent of compilers meant that I could do 10 times as much work with
>> each line that I wrote, plus the compiler could keep me from hurting
>> myself. KMDF lets me write drivers by doing more work with each line
>> that I write, plus the framework keeps me from hurting myself. This is
>> a GOOD thing. I can write better drivers with less code, letting me get
>> my job done more efficiently. Managed code is another step in this
>> evolution. It lets me do 10 times as much work with each line of code,
>> plus the managed framework can keep me from hurting myself. Singularity
>> simply extends this paradigm into the operating system realm.
>>
>> Now, there still exists a lunatic fringe that wants to write code in
>> lovingly hand-crafted assembler, but those people are hobbyists. They
>> aren’t getting real work done The hobbyists, the loonies, and the
>> hot-rodders will always want to tinker with the carburetor, install
>> chrome-plated rods, and worry about the last microsecond by maximizing
>> instruction pairing. Those people are perfectly welcome to go on
>> writing MASM to run under a DOS extender. However, those are not the
>> people who are getting real work done. The people who are getting real
>> work done want to produce working, large-scale systems. Singularity
>> lets me do that much more efficiently – optimizing MY efficiency, which
>> is much more valuable than the $250 piece of silicon sitting under my
>> desk.
>>
>>> In fact, it looks more of a malevolent mutation, rather than
>>> “evolution”…
>>>
>> Only if you are a hobbyist.
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>
>
>

At my age, nostalgia does sometimes make me want to try some of the old code
from my past. When I was younger I usually preferred to be writing in the
language I wasn’t currently using. As I wrote Cobol on mainframes most of
the time, I enjoyed it when I got a chance to write something in assembler.
Later when I was working most in assembly for MS-DOS drivers, I wanted to be
writing ‘C’ just to make it more interesting. Now, I will only switch to
another language when it is required or some side task can be done more
easily in something like Python.

However, you are correct in that moving to user mode is a good idea for most
drivers. I am not sure how the ACPI driver and maybe a couple of others
could be moved but it may be possible with a different OS model than
currently used in Windows. I had wondered why the Novell Netware idea of
writing drivers to run in ring 1 was never adopted for Windows NT. It must
have been the support for the now defunct platforms such as the Alpha.

Currently Microsoft dislikes, discourages, prohibits the use of higher level
languages such as C++ for most drivers. Otherwise, why aren’t runtime
library support routines for C++ available in the kernel? With the limited
kernal stack, it would be almost impossible to do real C++ exception
handling and SEH is not a drop-in replacement.

wrote in message news:xxxxx@ntdev…
>

[quote]

> …All the lines of Tim’s reply ending with:
>
> Only if you are a hobbyist.
>

[quote]

>
> YAY!!! Somebody else with a brain who can see the future… who doesn’t
> suffer from paradigm paralysis! Somebody who isn’t stuck doing things
> “they way we’ve always done them!”
>
> TIM ROBERTS TO THE RESCUE! Thanks, Tim. I was starting to doubt my own
> sanity.
>
> Whew! I couldn’t have said it better myself, Tim. Beautifully written.
>
> Here’s do getting real work done, and with the minimum effort possible.
>
> Peter
> OSR
>
>

I am not expert, just reading is better choice but i want to say something.

Compilers, linker etc make programmers job easier. Right.
It make easier because it handle routine things. Not engineering part.

What am i trying to say?

Managed code says that:
“I will handle memory management”

Memory management is the heart of “engineering”.
I think none of engineer give that job to the another unit, although it makes its job perfectly.
This is engineers job.

You are engineer because you can handle memory managment.

One more thing.
Why managed code?
It is
-Language independent
-Platform independent
-Processor independent(MSIL)

What is the feature of OS?
It is processor dependent.

Think that:
You try to use a language which aims processor, platform independency, to processor dependency.
Coding an OS with java or C# is completely wrong i think.

Using such a language which will run in kernel mode(writing OS, driver etc.) is against its nature i think.

xxxxx@hotmail.com wrote:

In fact, it looks more of a malevolent mutation, rather than “evolution”…

Virtualization gives a fresh, intereresting twist to the whole
user-kernel deal: a whole system, complete with the kernel, drivers,
ports, DMA and everything, runs inside an usermode app on another OS…

–pa

xxxxx@gmail.com wrote:

I am not expert, just reading is better choice but i want to say something.

Compilers, linker etc make programmers job easier. Right.
It make easier because it handle routine things. Not engineering part.

What am i trying to say?

Managed code says that:
“I will handle memory management”

Memory management is the heart of “engineering”.
I think none of engineer give that job to the another unit, although it makes its job perfectly.
This is engineers job.

You are engineer because you can handle memory managment.

I have a speech about that, too.

When I started in computers, oh so very long ago, computers were
freakin’ magic. The people who could manipulate them were magicians –
wizards – artists. I got into computers because I wanted to be an
artist like that. And indeed, for a very long time, computer
programmers were craftsmen. It’s FUN being a craftsman. I like it.
Crafting the next great memory management library is an art.

The problem with that is that craftsmen do not build reliable, large
solutions. Engineers do. An engineer knows that the memory management
problem has already been solved. He can fetch a memory management
library from his toolbox, confident that it solves the problem
adequately and reliably, and move on to solving the next engineering step.

We are now towards the tail end of an evolution, during which computer
programming changes from being an art to being an engineering
discipline. When that evolution is complete, it will certainly be
possible to build huge systems much more quickly and much more reliably
than we do today.

However, programming won’t be nearly as much fun. I’ll miss it. At
that point, I suppose I will have to turn into one of the hot-rodding
hobbyists that I referred to in my last essay.

Think that:
You try to use a language which aims processor, platform independency, to processor dependency.
Coding an OS with java or C# is completely wrong i think.

You think wrong. Coding an OS with Java or C# (or a similar managed
language) is perfectly sensible and, I would argue, inevitable.

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

Some GREAT replies to this thread. Really terrific posts.

I can’t believe some of the things Tim has posted. It’s like he’s in my head. I agree ALMOST 100% with the whole thing about craftsmanship and art versus engineering. In fact, I have long pontificated on the point that unlike ELECTRICAL engineering SOFTWARE “engineering” should be called “software arts”… it’s not engineering at all in the classic sense. Sure, there are “trade offs” but these are as much art as science.

Oh, there’ll always be a place for the art and craftsmanship. There is in ALL engineering.

Look at circuit board layout. Sure, you can auto-route most things and have a workable design. But even the high-end auto-routers benefit from hand-tweaking. Knowledge gained through experience. An appreciation for what makes a great looking – and working – board. Right down to the (what the HECK is the copper that’s put in otherwise bare areas of a board called… damn… “sacrificial material”… no, I’m not thinking of “ground plane”, duh!).

The fact of the matter is, when you don’t have to worry yourself with stupid little shit, you’ll be able to do more REAL engineering and even create better art if that is your want. Look at the bigger picture, optimize the overall process. Instead of worry about freakin’ reference counts on structures, whether “Length” is in WCHARs or bytes, and how to add entries to infinitely expanding arrays. I mean, seriously. WHO CARES? Let somebody write this junk once, and let us get on with using our talents to solve useful problems.

And already been done. Look at JNODE. I’m not saying it’s brilliant, but it’s entirely written in Java. Just shows you, it CAN be done.
…

Now, I’ve heard the argument that some folks have made – both here and in the responses I’ve received via email to my pontification in The NT Insider – that the DRIVER MODEL it more important than the language.

And, this is at least partially true. The driver model is of primary importance. If we could make writing drivers A FACTOR OF MAGNITUDE EASIER then this would make a great deal of sense.

How about if we could have a driver model that’s entirely single-threaded and non-reentrant. Imagine, coding an entire driver without having to worry about locking.

I remember arguing against the value of this model in the past (a well-known dev, now an architect, at Microsoft has periodically floated this idea for Windows from time to time). But I’ve changed my mind.

I say that would be grand. Glorious.

BRING ON THE FUTURE. Let’s USE some of the horsepower in mom and dad’s machine! As I type this (I just brought up task manager), I have 3 cores (of the 8 in my machine) ENTIRELY IDLE. Give me an operating system that makes driver writing easier, kernel mode coding less prone to errors, and USE those 3/8’ths of my machine!

Peter
OSR

xxxxx@hotmail.com wrote:

[begin quote]

My Manifesto For Change: All drivers, except perhaps those needed to boot the system, should be in user mode… as should the vast majority of the operating system. Drivers should be restartable on error. All drivers, user-mode or not, should be “correct by construction” and written in high-level languages with only the very minimal-most support for direct pointer manipulation. ]

[end quote]

The above paragraph just describes how Singularity works, with run-time library running in the KM, and the rest of the OS in the user one. How “clever” (and,apparently, “efficient”) -typical MSFT-like “solution”…

> As Darwin said: “Evolve or die!”

In fact, it looks more of a malevolent mutation, rather than “evolution”…

I’m going to mostly side with Peter on this one (except for restarting
drivers on failure).

Managed drivers are not too far away. If we had counted references
instead of mark/sweep (making deterministic finalization actually
usable), then we could do it now.

User-mode drivers should be preferred when possible, but there’s nothing
preventing an almost-.NET platform for kernel-level code (allowing
hardware access).

-Stephen Cleary

Tim,

In the early part of the 20th century, airplanes were things that were hand-crafted and
hand-tuned, handled and lovingly maintained by relative loonies who understood the purpose
of each nut and bolt. Today, you can still find such loonies, but they are hobbyists.
They do it for fun. The vast majority of the airplane-using public just want to get from Chicago to Miami.
I don’t care what grade of hydraulic oil is driving those doohickies on the wings.

Before we proceed to the future discussion of the issue, first of all, let’s decide whom we want to speak for. In your example, if you happen to be a passenger, I don’t expect you to know “what grade of hydraulic oil is driving those doohickies on the wings”. However, if you happen to be even maintenance mechanic, let alone plane engineer/designer, I DO expect you to understand the purpose of EVERY fucking bolt and screw on the plane.

Therefore, my question is “In context of this discussion, are you a passenger or a plane engineer??? Are you speaking from the programmer’s perspective, or from end user’s one, or do you believe that programmer and end user is more or less the same thing (which I believe is 100% true
for .NET"gurus”)" ???"

Managed code is another step in this evolution. It lets me do 10 times as much work with
each line of code, plus the managed framework can keep me from hurting myself.

Well, then go and do web design or at least database programming. What are you doing in the kernel world then???

> In fact, it looks more of a malevolent mutation, rather than “evolution”…

Only if you are a hobbyist.

Well, I would say most of us are some kind of “hobbyists” here - otherwise, instead of writing drivers, we would rather do . NET programming, which is perfectly reasonable approach for someone who just wants to do the work quickly and get “a quick buck” without thinking too much…

Anton Bassov

xxxxx@osr.com wrote:

[quote]
…All the lines of Tim’s reply ending with:

Only if you are a hobbyist.

[quote]

YAY!!! Somebody else with a brain who can see the future… who doesn’t suffer from paradigm paralysis! Somebody who isn’t stuck doing things “they way we’ve always done them!”

Well actually, although I agree mostly, some of us *are* still writing
drivers in lovingly crafted x86 assembler, for a commercial product at
the moment, we’re not hobbyists, and we are getting stuff done.

Having said that - bring on the higher level abstractions …
*provided* they’re not too leaky.

c.f. http://www.joelonsoftware.com/articles/LeakyAbstractions.html

Abstractions are *utterly wonderful* when they work well, but if they
leak lots, then they cause plenty of pain.

MH.

xxxxx@osr.com wrote:

Oh, there’ll always be a place for the art and craftsmanship. There is in ALL engineering.

Absolutely - it’s in two places:

1. Where the fundamental complexity of stuff is such that you need a
   smart solution. “Elegant craftsmanship required”.
2. Where the abstractions are leaky to the extent that they can’t hide
   all the details. “Magic wizardry required.”

MH.

Joel On Software rules. As does FogBugz, by the way (which is not free, does not suck, but is AMAZINGLY inexpensive). Oh wait… thread.

Great cite, thanks.

Peter
OSR

xxxxx@hotmail.com wrote:

Tim,

> Managed code is another step in this evolution. It lets me do 10 times as much work with
> each line of code, plus the managed framework can keep me from hurting myself.
>

Well, then go and do web design or at least database programming. What are you doing in the kernel world then???

Why do you think they should be fundamentally different? Performance?
That is more and more a non-issue. Sure, some classes of drivers will
always need to count microseconds (10 gigabit Ethernet…), but that set
is growing smaller and smaller. Reliability? Having drivers be managed
code under the watchful eye of a framework is certainly going to improve
reliability and recoverability.

Look, to a certain extent, I’m playing devil’s advocate here, and
intentionally poking at some sacred cows. There is no denying that
there is a pervasive sense of elitism in this mailing list, and I’m as
guilty as the rest. “I’m a driver programmer, therefore I’m better than
you, you lowly little web coder.” I think that’s largely nonsense. If
I can get the job done by using better tools, then that makes me a more
productive programmer. Web and database programmers already have better
tools. Why shouldn’t I have the same benefits?

By the way, I would LOVE to do web programming for a living. I find it
interesting and fascinating. However, experience has showed me that
there are too many high school kids who are willing to do a hack-up job
for $10 an hour. They have reduced the market price to the point where
it isn’t attractive for me.

> Only if you are a hobbyist.
>

Well, I would say most of us are some kind of “hobbyists” here - otherwise, instead of writing drivers, we would rather do . NET programming, which is perfectly reasonable approach for someone who just wants to do the work quickly and get “a quick buck” without thinking too much…

That’s elitism. “My job is more important than yours because I have to
think harder.” A managed code framework can relieve you from having to
think about stupid things: memory management, object management,
interlocking, threading, etc. It provides you with guarantees, so you
can get your job done without having to think so hard about problems
that have already been solved.

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

“Martin Harvey” wrote in message
news:xxxxx@ntdev…
> Abstractions are utterly wonderful when they work well, but if they leak
> lots, then they cause plenty of pain.

Abstractions for me are welcome as long as they are not new religions which
are pushed down our throats.What I consider much important is if the new
layer indeed does leak or does not provide what you want out of the box, it
will still allow you to take a step down. I completely bought into Delphi
years ago because it provided full VCL source code and would allow you to
use Win32 Api without limiations. KMDF in this regard is probably good too
for it still compiles a standard binary and you can still issue standard
DDK/WDK calls if required. .NET in this regard sucks because it requires you
to make the abominable decision to include unmanaged code, this is for me
the breaking point where things start to itch.

//Daniel