I didn’t say it was the only example, I said it was a good example.
If you never have to write a driver that processes more than one type of
device object, but you are writing lots of different types of drivers, once
again C++ provides a better toolset for implementing designs where a common
set of functionality (e.g. a driver’s default dispatch routines for a WDM
style device) needs to be reimplemented with minor variations. What I see,
to my horror, in C-implemented driver after C-implemented driver, is
‘inheritance by cut’n’paste’, rather than inheritance by design and
implementation.
If you are simply implementing and maintaining a single type of device
driver, then there is no reason why my example would be compelling.
A C++ implementation of the MDL structure, clearly tying and restricting MDL
methods to data, would be a cleaner implementation, at essentially no cost.
(One this pointer exchanged for one pointer to MDL.) Of course you would
have to think that localizing data methods with the data being operated on
is a good idea. The literature on why this is a good idea is rather
extensive.
Argh! I actually intended to stay out of this round of the c+±in-the-kernel
flamewar, and yet here I am.
=====================
Mark Roddy
-----Original Message-----
From: Ilya Lifshits [mailto:xxxxx@jungo.com]
Sent: Monday, December 08, 2003 3:03 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: how to ensure atomic code in a kernel
mode drive r
Mark :
So the only advance is a virtual functions ? Never used it
in my drivers and never feel a need for this. The OS is
another issue but still OS does have verified and well
implemented mechanism , and once it’s implemented a don’t see
any reason to switch language especially if missing part is
already implemented.
I still think that MDL is very good example since MDL
implementation is more object oriented than you can achieve
in c++, and again may be i wrong since i don’t know c++ i
only make my conclusions from your (and other folks)
c++ advantage examples this is the reason why i want to see
an example
c++ of
better c++ implementation for this.
Alberto :
>If I were Microsoft, I would have structured MDLs as a list
of objects
I really don’t care how Microsoft will implement this
internally probably i even don’t want to know how it’s
implemented as long as i have good api to work with object,
this is the whole point of object oriented correct me if i wrong here.
I want to see what advantage i will have as a user if i will
have c++ object instead of c object. As example for disadvantage:
A need to recompile the entire project instead of relink when
something internal is changed in MDL implementation.
A small one i a agree, but i want to know what i get what i
got in advantage?
Regards Ilya.
At 12:24 PM 8/12/2003 -0500, you wrote:
>MDL’s are a bad example. A good example is a driver that needs to
>support multiple types of DeviceObjects. A good design,
independent of
>toolset used, will implement an object oriented solution
that provides
>both default and device-type specialized dispatching methods. C++ is
>simply a better language for implementing such a design than
is C, as
>the compiler has built into it standard, efficient, and verified
>mechanisms for generating such function dispatching tables.
You can of course ‘roll your own’ in C, but why?
>
>Even Microsoft is grudgingly (and glacially) moving in the
direction of
>accepting C++ as a valid and useful toolset for kernel development.
>
>
>=====================
>Mark Roddy
>
>
> > -----Original Message-----
> > From: Ilya Lifshits [mailto:xxxxx@jungo.com]
> > Sent: Monday, December 08, 2003 12:09 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] RE: how to ensure atomic code in a kernel mode
> > driver
> >
> > Alberto,
> >
> > Take the MDL object as example and describe how can you make it
> > better with c++ And i mean make it better not replace
IoAllocateMdl
> > with new because there is no real advantage here. I’m not
pretend to
> > know c++, never write more than few lines in c++, but i read
> > carefully all your holly war for last few years and i
never seen a
> > real life advantage in c++ side of war examples :). So
here a real
> > object, implemented in c, for my opinion clean object
oriented one,
> > just show me any advantage in implementing this object in c++.
> >
> > Regards Ilya.
> >
> >
> > At 10:27 AM 8/12/2003 -0500, you wrote:
> > >Let me give you guys a few suggestions.
> > >
> > >You call it Driver “object”, no ? Device “object” ? Make it
> > so ! Real
> > >objects, I mean. Make the driver stack an object too, make
> > the Irp have
> > >a member function that returns a reference to the stack.
Remove all
> > >need to pass Driver Object or Device Object as a parameter
> > by using the
> > >kinds of techniques employed by MFC to make templates out of
> > documents and views.
> > >Bury memory allocation inside the objects, so that we
never have to
> > >invoke any allocator function directly and we never have to
> > worry about
> > >which pool we getting data from: if an object requires
the nonpaged
> > >pool, for example, that should be buried inside the object
> > itself through overriding the “new”
> > >operator. Make partially opaque data structures into objects and
> > >use attributes such as “private” and “protected” to hide
what you
> > >don’t want the rest of the world to see. Use inheritance
to derive
> > >Irp objects from other Irp objects. Define all interfaces as
> > >abstract classes, COM style. Define objects for all relevant
> > >hardware
> > entities:
> > >buses, bridges, dma, agp, processor, you name it, and make those
> > >objects behave like OS monitors, multiprocessor safe: the
> > serialization
> > >is inherent to the object and needs not be negotiated by the
> > >programmer, it comes automatically. Give us a coherent
> > interface into the runtime, like for example what we have in STL.
> > >Give us polymorphic versions of the API functions, so that
> > we can omit
> > >unnecessary parameters from the function calls and thus
reduce the
> > >possibility of error.
> > >
> > >This and other things, would make writing drives a breeze.
> > >
> > >
> > >Alberto.
> > >
> > >
> > >-----Original Message-----
> > >From: xxxxx@lists.osr.com
> > >[mailto:xxxxx@lists.osr.com]On Behalf Of
Peter Wieland
> > >Sent: Friday, December 05, 2003 6:38 PM
> > >To: Windows System Software Devs Interest List
> > >Subject: [ntdev] RE: how to ensure atomic code in a kernel
> > mode driver
> > >
> > >
> > >Since this relates to code I was directly (and indirectly)
> > responsible
> > >for I feel compelled to say that C++ would have been of
little help
> > >here.
> > >
> > >I guess we might have written an allocator class for certain
> > structures
> > >that could keep some back-pocket resources to ensure we can make
> > >progress on one i/o request at a time. Instead we wrote
a set of
> > >functions to do it. Doing it with the class keyword would
> > have added
> > >little.
> > >
> > >Overriding operator-new so we didn’t define new
allocator functions
> > >would also provide little - either we pass in enough new
> > data at each
> > >invocation of operator-new to tell it to follow the
> > work-in-low-memory
> > >semantics, or we check the value when operator-new comes
back and
> > >do something special. Encapsulating it in a set of functions
> > was just as
> > >good as operator-new. And if you stick to a good
function naming
> > >scheme you can get most of the benefits of methods anyway.
> > >
> > >OOP design paradigms are what are valuable here. If
using an “OOP”
> > >language without the associated OOP paradigms is not
helpful, then
> > >perhaps it’s not the language that’s providing the benefits.
> > >
> > >-p
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: xxxxx@lists.osr.com
> > >[mailto:xxxxx@lists.osr.com] On Behalf Of
> > Moreira, Alberto
> > >Sent: Friday, December 05, 2003 1:26 PM
> > >To: Windows System Software Devs Interest List
> > >Subject: [ntdev] RE: how to ensure atomic code in a kernel
> > mode driver
> > >
> > >…
> > >
> > > >Given the amount of labour MS did to the disk stack on XP (NO
> > > >resources
> > >
> > > >are allocated in critical IO paths) - I can hardly imagine
> > C++ to be
> > > >suitable
> > >for
> > > >such a task.
> > >
> > >Let me put it this way: doing the XP stack in C++ would entail a
> > >lot less work.
> > >
> > >…
> > >
> > >—
> > >Questions? First check the Kernel Driver FAQ at
> > >http://www.osronline.com/article.cfm?id=256
> > >
> > >You are currently subscribed to ntdev as:
> > xxxxx@compuware.com
> > >To unsubscribe send a blank email to
> > >xxxxx@lists.osr.com
> > >
> > >
> > >
> > >The contents of this e-mail are intended for the named
> > addressee only.
> > >It contains information that may be confidential. Unless you are
> > >the named addressee or an authorized designee, you may not copy
> > or use it,
> > >or disclose it to anyone else. If you received it in
error please
> > >notify us immediately and then destroy it.
> > >
> > >
> > >—
> > >Questions? First check the Kernel Driver FAQ at
> > >http://www.osronline.com/article.cfm?id=256
> > >
> > >You are currently subscribed to ntdev as: xxxxx@jungo.com To
> > >unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@stratus.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>You are currently subscribed to ntdev as: xxxxx@jungo.com To
>unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as:
xxxxx@stratus.com To unsubscribe send a blank email to
xxxxx@lists.osr.com