Device Driver by C# ?

Hi,
I have reading a book about Device Driver programming in W2K by C++,
Can I do that by C# and convert it to C# language?
Thank you
bye

Maxim
Mon Mar 21 19:24:53 CST 2005

No.

There is no .NET in the kernel, and, from what I know from the Redmond's C#
program manager, there are no plans to introduce one.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Kazem" <mksepehrifar@gmail.com> wrote in message
news:d424226e.0503211709.96edf3a@posting.google.com...
> Hi,
> I have reading a book about Device Driver programming in W2K by C++,
> Can I do that by C# and convert it to C# language?
> Thank you
> bye

Tim
Mon Mar 21 22:51:08 CST 2005

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote:
>
> There is no .NET in the kernel, and, from what I know from the Redmond's C#
>program manager, there are no plans to introduce one.

Really? I don't have anything written down, but it was my impression from
some chats from a year ago or so that there actually WAS a plan to add a
just-in-time compile ability into the kernel. You wouldn't get the CLR, of
course, but you could write managed drivers. There are certain advantages
to such an approach, despite the horrified gasps I can already hear from
the purists.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc

Robert
Mon Mar 21 23:17:34 CST 2005

Tim Roberts wrote:

> Really? I don't have anything written down, but it was my impression from
> some chats from a year ago or so that there actually WAS a plan to add a
> just-in-time compile ability into the kernel. You wouldn't get the CLR, of
> course, but you could write managed drivers. There are certain advantages
> to such an approach, despite the horrified gasps I can already hear from
> the purists.

I always find it amusing what MS substitutes for good design.
A safe replacement for the WDM concept would be much better.
Kernel mode DLLs are horrific.

Ray
Tue Mar 22 12:15:31 CST 2005

Well, leaving aside the fact that it's contradictory to say "You
wouldn't get the CLR, of course, but you could write managed drivers."
(since the CLR is what manages managed code), the only mention I've
heard of this was pretty pie-in-the-sky. If there are any plans for
this, I'd like to hear about it so I can call in the assassins.

Tim Roberts wrote:
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote:
>
>> There is no .NET in the kernel, and, from what I know from the Redmond's C#
>>program manager, there are no plans to introduce one.
>
>
> Really? I don't have anything written down, but it was my impression from
> some chats from a year ago or so that there actually WAS a plan to add a
> just-in-time compile ability into the kernel. You wouldn't get the CLR, of
> course, but you could write managed drivers. There are certain advantages
> to such an approach, despite the horrified gasps I can already hear from
> the purists.

--
../ray\..

Maxim
Tue Mar 22 13:18:56 CST 2005

> > There is no .NET in the kernel, and, from what I know from the Redmond's
>C#
> >program manager, there are no plans to introduce one.
>
> Really? I don't have anything written down, but it was my impression from
> some chats from a year ago or so that there actually WAS a plan to add a
> just-in-time compile ability into the kernel. You wouldn't get the CLR, of
> course, but you could write managed drivers. There are certain advantages

CLR is the entity which executes the managed code. :)

The PM from the C# team - who made a Whidbey/C# 2.0 presentation on MVP Open
Days in Prague, told me that he knows nothing on any plans about kernel mode
CLR, and surely not in Longhorn.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Jürgen
Tue Mar 22 14:50:56 CST 2005

For Usermode not Kernel Mode in the yet to come WDF. See Page 28.

http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/DW04035_WINHEC2004.ppt

You can access the WDF Beta Program see this link (at the very bottom of it)

http://www.microsoft.com/whdc/driver/wdf/wdf-intro.mspx

What sort of driver do you want to write?

Regards,

Jürgen Hollfelder

www.hollfelder-it.com

info@hollfelder-edv.de

"Kazem" <mksepehrifar@gmail.com> schrieb im Newsbeitrag
news:d424226e.0503211709.96edf3a@posting.google.com...
> Hi,
> I have reading a book about Device Driver programming in W2K by C++,
> Can I do that by C# and convert it to C# language?
> Thank you
> bye

Don
Tue Mar 22 15:00:52 CST 2005

I'm curious what the book was? Microsoft still places serious warnings on
using C++ for drivers C is the only truly blessed language, with C++ being
somewhere between accepted and not. Please let us know the book.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"Kazem" <mksepehrifar@gmail.com> wrote in message
news:d424226e.0503211709.96edf3a@posting.google.com...
> Hi,
> I have reading a book about Device Driver programming in W2K by C++,
> Can I do that by C# and convert it to C# language?
> Thank you
> bye

Maxim
Tue Mar 22 17:03:33 CST 2005

> using C++ for drivers C is the only truly blessed language, with C++ being
> somewhere between accepted and not. Please let us know the book.

Good C++ coder can ignore this.

The problems of using C++ in the kernel is only due to C++'s tendency of
introducing hidden semantics etc., which is not a problem for a good coder. It
is much easier to write messy uncomprehendable C++ code then messy C code.

Remember - in system-level development, the devil is in the details, so, the
C++'s tendency of "details hiding" can be a bad idea. It will save seconds on
code typing but consume hours of debugging.

Nevertheless, if I understand Microsoft correctly, they do not trust the
third-party coders to be good (some small and not-so-small companies have
strict time-to-market requirements and can intentionally sacrifice the product
quality to meet them), and that's why they recommend the simpler tools.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Mark
Tue Mar 22 19:04:02 CST 2005

Maxim S. Shatskih wrote:
>>> There is no .NET in the kernel, and, from what I know from the Redmond's
>>
>>C#
>>
>>>program manager, there are no plans to introduce one.
>>
>>Really? I don't have anything written down, but it was my impression from
>>some chats from a year ago or so that there actually WAS a plan to add a
>>just-in-time compile ability into the kernel. You wouldn't get the CLR, of
>>course, but you could write managed drivers. There are certain advantages
>
>
> CLR is the entity which executes the managed code. :)
>
> The PM from the C# team - who made a Whidbey/C# 2.0 presentation on MVP Open
> Days in Prague, told me that he knows nothing on any plans about kernel mode
> CLR, and surely not in Longhorn.
>
Noise was made last year by the WDF team of an *intention* in the
direction of kernel CLR managed code C# support. This was way far away
from anything resembling a plan.

I'd settle for resolving the code and data segment issues with C++ :-)

--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

Pavel
Tue Mar 22 20:31:02 CST 2005

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message news:uH2ptLzLFHA.2736@TK2MSFTNGP09.phx.gbl...
> Good C++ coder can ignore this.

This is a kind of recursive definion:
Who can write drivers in c++? A good coder.
Then, who is a good coder? One who can write drivers in c++ :)

> Remember - in system-level development, the devil is in the details,
especially in undocumented details.

> C++'s tendency of "details hiding" can be a bad idea. It will save seconds on
> code typing but consume hours of debugging.
>
> Nevertheless, if I understand Microsoft correctly, they do not trust the
> third-party coders to be good

Ugm. Sometimes I distrust the second-party coder :)
IMO MS doesn't want to support C++ from one simple reason: C++ devs tend
to create their own frameworks, so it is hard to understand any code snippet
without learning their inheritance, hidden tricks, overloading etc.
In plain C, when you get is what you see.

--PA

Mark
Tue Mar 22 22:59:53 CST 2005

Pavel A. wrote:

> This is a kind of recursive definion: Who can write drivers in c++? A
> good coder. Then, who is a good coder? One who can write drivers in
> c++ :)

In the (admittedly few) drivers I've written, there's been nothing that
could've benefited even slightly from an object-oriented design. I'll
take the ability to declare variables anywhere and the C++ comments, but
I don't see any reason to want to use C++ otherwise.

It scares me that someone would even *contemplate* writing a driver in
C#. What's next, VB? What about LabView? Don't know about anyone else,
but when I'm writing a driver I want to be 'as close to the metal' as
possible!?! If I'm trying to run (and debug!) scatter-gather DMA at full
PCI bandwidth I sure as hell don't want a JIT compiler in my way...

Regards,
Mark

Peter
Wed Mar 23 10:03:22 CST 2005

that's not the reason. Using certain C++ language features can have
unexpected side effects that could cause the code to crash when run in the
kernel. Most significantly is the compiler's tendency to emit
compiler-generated functions into arbitrary code sections.

there are ways around this, and if you're careful you can write a working
C++ driver. But it's something you have to be very mindful of, and we have
a big enough problem with drivers crashing the system when they're written
in a langage without these side-effects.

The people who want to write convoluted code that uses macros, side effects,
blind typecasts, etc... - their code is just as hard to understand no matter
what language they use :)

-p

--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
news:OJJ$tC1LFHA.2604@TK2MSFTNGP10.phx.gbl...
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:uH2ptLzLFHA.2736@TK2MSFTNGP09.phx.gbl...
>> Good C++ coder can ignore this.
>
> This is a kind of recursive definion:
> Who can write drivers in c++? A good coder.
> Then, who is a good coder? One who can write drivers in c++ :)
>
>> Remember - in system-level development, the devil is in the details,
> especially in undocumented details.
>
>> C++'s tendency of "details hiding" can be a bad idea. It will save
>> seconds on
>> code typing but consume hours of debugging.
>>
>> Nevertheless, if I understand Microsoft correctly, they do not trust the
>> third-party coders to be good
>
> Ugm. Sometimes I distrust the second-party coder :)
> IMO MS doesn't want to support C++ from one simple reason: C++ devs tend
> to create their own frameworks, so it is hard to understand any code
> snippet
> without learning their inheritance, hidden tricks, overloading etc.
> In plain C, when you get is what you see.
>
> --PA
>
>
>

Robert
Wed Mar 23 11:02:29 CST 2005

Peter Wieland [MSFT] wrote:

> The people who want to write convoluted code that uses macros, side effects,
> blind typecasts, etc... - their code is just as hard to understand no matter
> what language they use :)

You can write FORTRAN in any language ;-)

The main problem with .net code in the kernel is that it creates
a sandbox for the code of the driver instead of creating a
secure environment for the driver framework itself.

Mark
Wed Mar 23 11:19:53 CST 2005

Read the white papers on this page for the pros and cons of using C++ in
kernel mode drivers. I have a minor problem with the paper having to do
with destuctors, but other than that, it states all the issues.....

http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

--
Mark Cariddi
Consulting Associate
OSR, Open Systems Resources, Inc.
http://www.osr.com/
"Robert Marquardt" <robert_marquardt@gmx.de> wrote in message
news:OyOmWo8LFHA.3420@tk2msftngp13.phx.gbl...
> Peter Wieland [MSFT] wrote:
>
>> The people who want to write convoluted code that uses macros, side
>> effects, blind typecasts, etc... - their code is just as hard to
>> understand no matter what language they use :)
>
> You can write FORTRAN in any language ;-)
>
> The main problem with .net code in the kernel is that it creates
> a sandbox for the code of the driver instead of creating a
> secure environment for the driver framework itself.

Maxim
Wed Mar 23 15:24:16 CST 2005

> This is a kind of recursive definion:
> Who can write drivers in c++? A good coder.
> Then, who is a good coder? One who can write drivers in c++ :)

Bad coder can also do this and overload the code with junk like redefined
operators, making it hard to comprehend even for himself in 6 months or so.

> IMO MS doesn't want to support C++ from one simple reason: C++ devs tend
> to create their own frameworks, so it is hard to understand any code snippet
> without learning their inheritance, hidden tricks, overloading etc.
> In plain C, when you get is what you see.

Exactly.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Maxim
Wed Mar 23 15:26:26 CST 2005

> could've benefited even slightly from an object-oriented design. I'll
> take the ability to declare variables anywhere and the C++ comments,

ANSI C allows to declare the variable in the beginning of each {} block.

MS compiler supports C++ comments in C code. I only use C++ comments in
ernel-mode code for Windows.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Pavel
Wed Mar 23 19:35:52 CST 2005

"Robert Marquardt" <robert_marquardt@gmx.de> wrote in message news:OyOmWo8LFHA.3420@tk2msftngp13.phx.gbl...
> The main problem with .net code in the kernel is that it creates
> a sandbox for the code of the driver instead of creating a
> secure environment for the driver framework itself.

Secure environment for drivers is the usermode framework.
You get all the security of Windows (of course, if your code doesn' t cause buffer
overflows ;)

--PA

Mark
Wed Mar 23 21:20:29 CST 2005

Maxim S. Shatskih wrote:
>>This is a kind of recursive definion:
>>Who can write drivers in c++? A good coder.
>>Then, who is a good coder? One who can write drivers in c++ :)
>
>
> Bad coder can also do this and overload the code with junk like redefined
> operators, making it hard to comprehend even for himself in 6 months or so.
>
>
>>IMO MS doesn't want to support C++ from one simple reason: C++ devs tend
>>to create their own frameworks, so it is hard to understand any code snippet
>>without learning their inheritance, hidden tricks, overloading etc.
>>In plain C, when you get is what you see.
>
>
> Exactly.
>

WDF.

--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

Tim
Wed Mar 23 22:42:19 CST 2005

Mark McDougall <markm@vl.com.au> wrote:

>Pavel A. wrote:
>
>> This is a kind of recursive definion: Who can write drivers in c++? A
>> good coder. Then, who is a good coder? One who can write drivers in
>> c++ :)
>
>In the (admittedly few) drivers I've written, there's been nothing that
>could've benefited even slightly from an object-oriented design. I'll
>take the ability to declare variables anywhere and the C++ comments, but
>I don't see any reason to want to use C++ otherwise.

Then you're not being creative enough. Just getting rid of that ugly
"pdx->" string for all those context variables -- which really are just C++
member variables -- is a big plus for me.

MANY tasks in drivers fall naturally into an object paradigm. My drivers
read much more sensibly when I have a CRingBuffer object that hides the
implementation and offers a well-defined implementation, or a CBufferQueue
object that understands doubly-linked lists, or a CIrpQueue that
understands cancellation so my mainline code doesn't have to. Just using
constructors and destructors to make sure I don't have the opportunity to
forget some important resource cleanup is a big help.

>If I'm trying to run (and debug!) scatter-gather DMA at full
>PCI bandwidth I sure as hell don't want a JIT compiler in my way...

Nonsense. Your CPU can lay down and take a short nap in the time it has to
wait for the PCI bus to get off of its lazy rear end and transfer some
data. A 4k-byte transfer at full speed takes as much time as 100,000
cycles on a 3GHz processor.

Plus, people who should know tell me that the performance of the JIT code
is quite competetive with straight C code.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc

Robert
Wed Mar 23 23:02:03 CST 2005

Pavel A. wrote:

> Secure environment for drivers is the usermode framework.
> You get all the security of Windows (of course, if your code doesn' t cause buffer
> overflows ;)

That is precisely the difference.
Currently WDM drivers are effectively kernel DLLs where
buffer overflows can destroy anything. Having your driver
interpreted by .net only moves that problem to the .net
sandbox. The driver framework itself is as insecure as before.

BTW BSD shows that most of the buffer overflows can be easily prevented
by replacing the most insecure functions like strcpy, memmove etc by
secure versions. For drivers it would be easy to implement that. It is
already a limited environment for specialists.

Pavel
Thu Mar 24 21:04:29 CST 2005

"Robert Marquardt" <robert_marquardt@gmx.de> wrote in message news:ub$Ub6CMFHA.3540@tk2msftngp13.phx.gbl...
> Currently WDM drivers are effectively kernel DLLs where
> buffer overflows can destroy anything. Having your driver
> interpreted by .net only moves that problem to the .net
> sandbox. The driver framework itself is as insecure as before.

But what if usermode driver uses a compact, robust kernel mode driver to
talk to physical devices (like printer drivers don't directly do the i/o).
Suppose there is a standard, well designed USB driver that allows access to all endpoints
from user mode, like you work with COM ports.
Then many USB drivers can be converted to usermode services.

/* By "stack overflows" I meant the infamous vulnerability that can be exploited
from pure user mode, and can give full control over the machine, including
permission to run kernel drivers */

--PA

Robert
Thu Mar 24 23:12:18 CST 2005

Pavel A. wrote:

> But what if usermode driver uses a compact, robust kernel mode driver to
> talk to physical devices (like printer drivers don't directly do the i/o).
> Suppose there is a standard, well designed USB driver that allows access to all endpoints
> from user mode, like you work with COM ports.
> Then many USB drivers can be converted to usermode services.
>
> /* By "stack overflows" I meant the infamous vulnerability that can be exploited
> from pure user mode, and can give full control over the machine, including
> permission to run kernel drivers */

That robust driver is still short of the real goal.
The driver framework should be compact and robust (and much simpler).

Still such a driver would be a good idea. Lowering the possibility of
bugs is always good. Lowering the number of kernel space actions is
also a good idea. It would also allow to add API layers which MS forgot
or deliberately removed.

Maxim
Fri Mar 25 07:17:55 CST 2005

> also a good idea. It would also allow to add API layers which MS forgot
> or deliberately removed.

USB and 1394 stacks in UNIXen allow the user mode apps to do all bus
transactions. I think you can open the USB pipe on the device just as a file
with the name suffix of the endpoint number.

Lack of this feature in Windows is not good. If this feature would be present -
then, say, the USB printer driver would be implemented in user mode only, with
only a tiny piece of kernel-mode code which do nothing except
IoRegisterDeviceInterface/IoSetDeviceInterfaceState. The latter functionality
could also be embedded to USBHUB in fact.

This is like IrDA printer driver, which is a user-mode DLL talking to IrDA
sockets.

BTW - exposing raw USB as sockets would also be a good idea.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Don
Fri Mar 25 07:31:56 CST 2005

They are adding this feature there are talks about it listed in the Driver
DevCon scheduled for next month. I don't think they forgot or deliberately
removed it this, I suspect that like a lot of things it wasn't high enough
on the priority list to make it. It probably wasn't a high priority till
they put together the user mode driver framework that is supposed to provide
the glue to make these drivers work in the standard device space.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:OQ5h31TMFHA.2988@TK2MSFTNGP14.phx.gbl...
>> also a good idea. It would also allow to add API layers which MS forgot
>> or deliberately removed.
>
> USB and 1394 stacks in UNIXen allow the user mode apps to do all bus
> transactions. I think you can open the USB pipe on the device just as a
> file
> with the name suffix of the endpoint number.
>
> Lack of this feature in Windows is not good. If this feature would be
> present -
> then, say, the USB printer driver would be implemented in user mode only,
> with
> only a tiny piece of kernel-mode code which do nothing except
> IoRegisterDeviceInterface/IoSetDeviceInterfaceState. The latter
> functionality
> could also be embedded to USBHUB in fact.
>
> This is like IrDA printer driver, which is a user-mode DLL talking to IrDA
> sockets.
>
> BTW - exposing raw USB as sockets would also be a good idea.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>

Robert
Sat Mar 26 23:21:41 CST 2005

Don Burn wrote:
> They are adding this feature there are talks about it listed in the Driver
> DevCon scheduled for next month. I don't think they forgot or deliberately
> removed it this, I suspect that like a lot of things it wasn't high enough
> on the priority list to make it. It probably wasn't a high priority till
> they put together the user mode driver framework that is supposed to provide
> the glue to make these drivers work in the standard device space.

Sorry, but USB has been rewritten several times (and did not improve on
theway). I cannot believe that MS missed such opportunities.
This is a bad habit of MS since ME/2000. Rewriting parts of Windows from
scratch instead of testing and improving what they already have.

Mark
Mon Mar 28 18:23:39 CST 2005

Tim Roberts wrote:

> MANY tasks in drivers fall naturally into an object paradigm.

Both my drivers have been miniport drivers, so there really wasn't much
benefit to be gained by using C++ at all.

> Plus, people who should know tell me that the performance of the JIT
> code is quite competetive with straight C code.

People who want to believe... ;)

Regards,
Mark